[U-Boot] [PATCH 0/4] tegra: Move tegra20 towards the 'new' display bindings

[Stephen Warren]

On 01/14/2016 04:12 PM, Simon Glass wrote:
> Hi Lucas,
>
> On 14 January 2016 at 13:34, Lucas Stach <dev at lynxeye.de> wrote:
>> Am Donnerstag, den 14.01.2016, 13:26 -0700 schrieb Simon Glass:
>>> The original tegra20 display driver was written before Linux had
>>> device tree
>>> bindings for display. Since then Linux has developed a robust set of
>>> bindings
>>> covering various aspects of enabling a display.
>>>
>>> This series moves closer to those bindings by using the panel and
>>> backlight
>>> as separate drivers. The device tree files for seaboard, ventana and
>>> harmony
>>> thereby become almost the same as Linux.
>>>
>>> Unfortunately this breaks the other boards, which will need a similar
>>> sync.
>>> So I'm not sure how easy it will be to accept this series. Still, it
>>> seems
>>> worth sending it out in the hope that board maintainers can help. I
>>> have
>>> kept this series separate so that it can progress separately.
>>>
>> By pushing display timings into the DT you are actually diverging from
>> mainline, as mainline doesn't require this, but instead infers the
>> timings from the panel compatible. Is this a desired goal?
>
> This is not divergence.

Really? The DT content is different. Isn't that the definition of 
divergence?

> Please take a look at the patch series. The
> device tree files are very close to the same now. The existing U-Boot
> support has display timings in the device tree too, so this is not
> being added.
>
> The display timings are a small part of the work, but in the back of
> my mind is that we don't want to have a big table of display panel
> timings as exists in Linux. This is a waste of space when a board will
> only use one panel.

That was rather the point of the panel-specific compatible values: To 
force the DT to contain a semantic definition of the type of panel, 
rather than a "generic" definition of timings. A benefit of the semantic 
representation is that if we later find bugs that need to be fixed on 
certain panels, if we know the panel type, then bug fixes can be 
applied. Equally, if we enhance the SW to require more data about the 
panel, that can be added to a driver without the need to change the DT, 
thus allowing old DTs to continue to work. More semantic rather than 
purely "syntactic" knowledge is available. However, if we only have a 
generic timing definition (or other data suitable for current SW 
features or code-paths), then panel-specific bug fixes will never be 
possible since SW can't know the identify of the panel. The disadvantage 
of requiring a mapping table between panel type and display timings was 
considered reasonable for SW stacks at which DT was targeted (i.e. main 
OSs rather than HW-specific bootloaders). Even so, to avoid the bloat 
issue, you can always just #ifdef the mapping table and end up with the 
same code size; even less perhaps since no timing DT parsing code is 
required.

At least, that was the reasoning when the DT bindings for Tegra panels 
were first created; IIRC there was discussion of bindings for generic 
panels, timings, panel power sequences, etc., and they were rejected for 
the reason I explained above and perhaps others. However, it does seem 
someone has changed their mind again given that the generic 
panel-timings binding does exist now. This is one of the many things 
that sucks about DT; no decision is ever kept, so consistency in design 
and implementation isn't possible:-(