On 01/18/2016 06:58 PM, Simon Glass wrote:
Hi Stephen,
On 18 January 2016 at 12:52, Stephen Warren <swar...@wwwdotorg.org> wrote:
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?
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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
