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

[Stephen Warren]

On 01/18/2016 06:58 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 18 January 2016 at 12:52, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> 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?
>
> You might infer that from the movie, but divergence really means that
> things are getting further apart. So I think here we have convergence.
>
>>
>>> 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:-(
>
> Sounds a bit contrived to me.

I believe this approach has been taken after years of experience with DT 
and having to retro-fit bug-fixes and new features into existing DTs.

Still, you'd get the best background from the Linux kernel DT 
maintainers on this topic, since they have experience with DT over more 
years than me. I'm simply reporting the arguments they've presented.