On 01/14/2016 04:12 PM, Simon Glass wrote:
Hi Lucas,
On 14 January 2016 at 13:34, Lucas Stach <d...@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:-(
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
