[U-Boot] [RFC] Remove static display data

[Eric Nelson]

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