Subject: [PATCHv2 6/6] video: fb: vt8500: Convert framebuffer drivers to standardized binding

From: [email-masked] (Tony Prisk)
Date: Wed, 03 Apr 2013 07:18:29 +1300

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 <[email-masked]>:
>>> 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