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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot