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

[Eric Nelson <eric.nelson@boundarydevices.com>]

Thanks Anatolij,

On 07/26/2013 12:50 AM, Anatolij Gustschin wrote:
> Hello Robert,
>
> On Thu, 25 Jul 2013 11:21:10 -0700
> Robert Winkler <robert.winkler@boundarydevices.com> wrote:
>
>> Hello all,
>>
>> We're trying to figure out how best to get rid of static code like this:
>>
>> http://git.denx.de/?p=u-boot.git;a=blob;f=board/boundary/nitrogen6x/nitrogen6x.c;h=8f0f9b8de2e8e77fcbf477728ea063a213941dd0;hb=HEAD#l526
>>
>> and turn it into run time data.
>>
>> Our idea is to use an environment variable so adding support for new
>> screens and iterating on minor settings is quick and easy and then we can
>> remove the static arrays like the one above and in wandboard.c and other
>> places.
>
> We have some code and users to define timing parameters in an environment
> variable "videomode". video_get_params() is used to read the parameters
> into a structure "struct ctfb_res_modes".
>

:)

When searching for the proper way to do things, we found two data
structures in wide use:
	fb_videomode
	vidinfo

We didn't find ctfb_res_modes...

>> One way to do this is to create a data structure that can subsume the
>> functionalities of of display_info_t and the various structures in lcd.h
>> and elsewhere that can be used throughout U-Boot both with CONFIG_LCD and
>> CONFIG_CFB_CONSOLE.  Combined with the EDID functionality already in U-Boot
>> this would allow code to easily select the "best" display supported by the
>> monitor or closest to what the user wanted (given in the environment
>> variable).  This data structure would then be passed to Linux on boot up.
>>
>> I realize that there's already the FDT and CONFIG_OF_CONTROL functionality
>> and device trees sort of cover the passing to Linux part so maybe before
>> handing it off, converting the relevant data into a device tree that Linux
>> can already use/parse would work.
>
> Devicetree bindings for describing display timings info exist in recent
> Linux kernel versions (since v3.9 I think) and are documented under
> Documentation/devicetree/bindings/video/display-timing.txt. In Linux
> there are also DT helpers to parse display timings nodes and read the
> timing values into fb_videomode structure (of_get_display_timings,
> of_get_fb_videomode). Code for adding such display timings nodes to
> the device tree under U-Boot doesn't exist yet.
>
>> Is anyone working on something like this?  Am I missing something that's
>> already in place to accomplish this?
>
> Maybe you can use "videomode" Variable and video_get_params().

That would handle most things, though there are some bits missing.

In particular, these things aren't expressed in either fb_videomode
or ctfb_res_modes:

	- which display connection? Our SABRE Lite and Nitrogen6x
	boards have three display connections (HDMI, LVDS, RGB)

	- details of the connection. For instance, the LVDS output
	on our boards can send data using either the SPWG or JEIDA
	standards, and the RGB connection can be configured for
	either 16, 18, or 24 bit displays

It seems that at least two-levels of data structure are needed:
one to represent the board-level options for display, and another
for the panel-specific resolution information.

That lack of separation seems to be behind the big set
of #ifdefs around the declaration of vidinfo in lcd.h.

Regards,


Eric