From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Fri, 26 Jul 2013 17:42:29 -0700 Subject: [U-Boot] [RFC] Remove static display data In-Reply-To: <51F28AEC.3070909@denx.de> References: <20130726095049.3ee4a02e@crub> <51F236CB.3060906@denx.de> <51F281E5.9010103@boundarydevices.com> <51F28AEC.3070909@denx.de> Message-ID: <51F31775.80409@boundarydevices.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Thanks for the thoughtful response, Stefano. On 07/26/2013 07:42 AM, Stefano Babic wrote: > Hi Eric, > > On 26/07/2013 16:04, Eric Nelson wrote: > >> >> The real question we have regarding DT is the timing. We're shipping >> DT files on secondary storage (SATA/SD card), and want/need something >> local (i.e. env in SPI-NOR) to present a U/I if either no storage >> available or if something goes wrong. > > ok, understood. > >> >> A secondary need/desire is to have something simple for configuring >> a new display. The process of tuning some of the parameters (esp >> margins) can sometimes be iterative because the data sheets aren't >> always clear and clock options are often imprecise. Since this >> iteration and configuration is often done by EEs in a lab who >> don't have an easy way to recompile a DTS, our inclination is >> to do something locally. > > ok, I understand the point. Maybe it should be even more simple for the > EEs if the would be such kind of special u-boot commands, able to set > the timing and reload the framebuffer. > > Can be a solution using the u-boot's fdt library enough ? With "fdt get" > and "fdt set" it is possible to read and modify a DT in memory, and > then the modified DT can be stored back - avoiding to compile directly > the DTS. > Perhaps. We're still n00bs when it comes to DT, so we may have to wait until we're further up the learning curve. It also seems that a bound U-Boot+DT isn't really any better than re-compiling U-Boot itself. If we need to flash everything, then there's not much benefit of the change. >> >> Is Tegra somehow using DT to configure U-Boot display? >> I'm not finding the code. > > ./board/compal/dts/tegra20-paz00.dts seems doing that, but I have no > experience with it ;( > > My thoughts are more related by comparing what the kernel does and how > the timing is configured. There are several examples (I am seeing the > imx23-dts, but it is not the only one) where the complete timing for a > panel is done inside the DT. > Again, we're not completely ready to comment, but it seems that using the phrase "what the kernel does" is going to be a moving target for a while. At least for i.MX. AFAIK, the 3.5.7 kernels from Freescale will still require kernel command lines for display configuration, so we may not have a firm target. I'm CC'ing Fabio and Jason for their 2c. > As you have already checked, using a U-Boot variable has some > limitations, because it does not contain all parameters that are needed. > And I think it could be quite difficult to get it general for all SOCs > because some SOCs need some specialties (VRAM for OMAP could be an example). > Anatolij's variable parser could be used and extended/wrapped to do the trick. I'm just not quite sure it's the right thing. >> No matter how we end up doing this, passing U-Boot's display >> setup to the kernel via DT is the **right thing**, so that >> there aren't two bits to maintain. > > Yes, I think we do not need to discuss how to pass to the kernel - but I > am checking if it is a suitable way to configure the u-boot display,too. > Anyway, I agree that using a U-Boot variable is much more simple to > implement.. > Okay. We'll keep thinking about this, but it will likely go toward the back of our 'to-do' list. > Best regards, > Stefano > Regards, Eric