From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Babic Date: Thu, 09 Jan 2014 11:44:14 +0100 Subject: [U-Boot] [PATCH 3/5] fdt: add fdt_add_display_timings(..) In-Reply-To: References: <1389165866-17509-1-git-send-email-christian.gmeiner@gmail.com> <1389165866-17509-3-git-send-email-christian.gmeiner@gmail.com> <52CD2E33.8000409@denx.de> Message-ID: <52CE7D7E.7040006@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. Regards, Stefano Babic -- ===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================