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.
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.
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).
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..
Best regards, Stefano