From: linux@prisktech•co.nz (Tony Prisk)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCHv2 6/6] video: fb: vt8500: Convert framebuffer drivers to standardized binding
Date: Wed, 03 Apr 2013 07:18:29 +1300 [thread overview]
Message-ID: <515B20F5.4000708@prisktech.co.nz> (raw)
In-Reply-To: <20130402115014.GL20693@game.jcrosoft.org>
On 03/04/13 00:50, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 14:41 Tue 02 Apr , Alexey Charkov wrote:
>> 2013/4/2 Tomi Valkeinen <tomi.valkeinen@ti•com>:
>>> On 2013-04-02 07:50, Tony Prisk wrote:
>>>> Now that a display timing binding is available, convert our almost identical
>>>> binding to use the standard binding.
>>>>
>>>> This patch converts the vt8500 and wm8505 framebuffer drivers and
>>>> associated dts/dtsi files to use the standard binding as defined in
>>>> bindings/video/display-timing.txt.
>>>>
>>>> There are two side-effects of making this conversion:
>>>>
>>>> 1) The fb node should now be in the board file, rather than the soc file as
>>>> the display-timing node is a child of the fb node.
>>>>
>>>> 2) We still require a bits per pixel property to initialize the framebuffer
>>>> for the different lcd panels. Rather than including this as part of the
>>>> display timing, it is moved into the framebuffer node.
>>> This means that the boards using the current DT bindings won't work with
>>> a kernel with these patches, right? Is that ok?
>> There are no known products shipping any DT-enabled firmware with
>> these chips in the wild. The only way to run modern kernels on
>> VIA/WonderMedia chips so far is by using the "appended DTB"
>> workaround, and the instructions that have been posted to Wiki's and
>> mailing list discussions imply that a fresh DTB is compiled from
>> current kernel sources to produce a bootable image.
>>
>> Thus, it seems that this change should not really break anything
>> major, as the user base is quite small and those who use new code are
>> most likely to use new DTB as well.
> I usually disagree but ok
>
> Best Regards,
> J.
The original binding was only ever meant to be a stop-gap as it was
required for us to make the conversion to multiplatform/devicetree, and
was only agreed upon because without it all the other code was pointless
and arch-vt8500 was suffering from bitrot at the time. It was always the
intention to update to the standardized binding once it was mainlined.I
haven't been able to find the original thread where it was discussed,
but it was around Aug 2012.
Regards
Tony P
prev parent reply other threads:[~2013-04-02 18:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-02 4:49 [PATCHv2 0/6] fb: vt8500: patches for 3.10 Tony Prisk
2013-04-02 4:49 ` [PATCHv2 1/6] video: vt8500: Make wmt_ge_rops optional Tony Prisk
2013-04-02 10:32 ` Jean-Christophe PLAGNIOL-VILLARD
2013-04-02 4:49 ` [PATCHv2 2/6] video: vt8500: Remove unused platform_data/video-vt8500lcdfb.h Tony Prisk
2013-04-02 4:49 ` [PATCHv2 3/6] video: vt8500: Correct descriptions in video/Kconfig Tony Prisk
2013-04-02 4:49 ` [PATCHv2 4/6] drivers/video/wm8505fb.c: use devm_ functions Tony Prisk
2013-04-02 4:49 ` [PATCHv2 5/6] video: vt8500: Adjust contrast in wm8505 framebuffer driver Tony Prisk
2013-04-02 4:50 ` [PATCHv2 6/6] video: fb: vt8500: Convert framebuffer drivers to standardized binding Tony Prisk
2013-04-02 10:25 ` Tomi Valkeinen
2013-04-02 10:41 ` Alexey Charkov
2013-04-02 11:50 ` Jean-Christophe PLAGNIOL-VILLARD
2013-04-02 18:18 ` Tony Prisk [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=515B20F5.4000708@prisktech.co.nz \
--to=linux@prisktech$(echo .)co.nz \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox