[U-Boot] [PATCH 3/5] fdt: add fdt_add_display_timings(..)

[Christian Gmeiner]

HI Stephen.

2014/1/9 Stephen Warren <swarren at wwwdotorg.org>:
> On 01/09/2014 07:52 AM, Eric Nelson wrote:
>> Hi Stefano,
>>
>> On 01/09/2014 03:44 AM, Stefano Babic wrote:
>>> Hi Christian,
>>>
>>> On 09/01/2014 08:12, Christian Gmeiner wrote:
>>>
>>>>> Agree that we have to sync u-boot and kernel, and this can be a way in
>>>>> the short term.
>>>>>
>>>>> I am asking if this is in the long term the best way to do it. You are
>>>>> converting EDID values to fb_videomode *mode, and then again to the
>>>>> device node as required by DT.
>>>>> We have already had some talks about moving U-Boot configuration to DT,
>>>>> that is U-Boot can be also configured by a DT file (see for example
>>>>> support for Nvidia processors, they already support DT in U-Boot).
>>>>>
>>>>
>>>> The problem for me here is that DT only does not work in my case. As
>>>> it is
>>>> possible to attach different panels/displays via lvds (different
>>>> timings and resolutions)
>>>> we have put an at24 on our print, which contains the suitable EDID data.
>>>>
>>>> So I need to readout the at24 every boot and need to manipulate the
>>>> loaded (emmc) DT.
>>>
>>> Understood, thanks for clarification. Agree that we need functions for
>>> EDID manipulation. My only concern remains if we need a temporary
>>> conversion to videomode as in this patch, or we go towards a
>>> edid-to-fdt() function.
>
> In my opinion, without having read the patch or the rest of the thread:
> Both the DT and the EDID are sources for information about supported
> video modes. Those two sources (and any others that might appear later
> like ACPI or hard-coded modes inside U-Boot) should be directly
> converted to U-Boot's internal mode representation, rather than chaining
> conversions e.g. EDID -> DT -> internal.

The patch does this:
EDID -> internal -> DT

But it depends a little bit on your definition of "internal".

greets
--
Christian Gmeiner, MSc