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

Stephen Warren swarren at wwwdotorg.org
Thu Jan 9 18:00:58 CET 2014


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.


More information about the U-Boot mailing list