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

[Simon Glass]

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. The hardware includes the panel, so IMO
it makes perfect sense to describe it in the DT. Plus it is more
efficient as I mentioned.

Regards,
Simon