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.