On Tue, Jan 19, 2016 at 09:47:11AM -0700, Stephen Warren wrote:
On 01/18/2016 06:58 PM, Simon Glass wrote:
Hi Stephen,
On 18 January 2016 at 12:52, Stephen Warren swarren@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@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.
To be fair, the panel bindings came about after the display-timings binding. Perhaps the main reason why the panel bindings are what they are today is because I consider them devices no different at all from peripherals and the like. Back at the time, most of the pushback was because people believed that panels were somehow special in that they would simply require the video timings to make them work, and hence having some generic helpers to parse them from DT would be enough and is what many drivers ended up implementing.
But it turned out that there's more to panels than just the video timings. Many panels do have a varying number of inputs that need to be controlled before you can use them. There are voltage supplies and reset or powerdown GPIOs, PWM inputs for backlight etc. Like Stephen said it was at some point attempted to describe this completely generically in DT using power sequences, but that effort turned out to be much too complicated even considering only a subset of relatively simple panels.
Taking into account the various types of smart panels out there things get even more complicated. All of a sudden you need a sort of register programming sequence to enable or disable the panel. Of course with a generic panel binding you need to find a way to put that into the DT along with everything else. And then you need a way to specify where to write these registers in the enable/disable sequence, in some cases you might even need to split it up into several chunks, etc.
So the end result was that while you had a generic way for describing the video timings, every driver had to implement its own support infrastructure for the various resources that you need to turn on. In fact this became quite the opposite of generic.
Now when you consider panels to be devices and give them a proper compatible string things actually get almost trivial. Now each panel can have a binding that fully describes the supplies and GPIOs and the driver that binds to the device can contain the enable and disable sequences in code. This is completely normal for any other kind of device, why would panels need to be special? Now that a panel is simply a device like any other you can make things truly generic, create the abstractions you need and simply hook up outputs to panels and make them work together.
There is still some commonality in many panels, so in Linux we ended up implementing a "simple" panel driver, which can drive panels that have a backlight, a power supply and an enable GPIO, with an optional DDC bus that can be used to read EDID. That driver supports 34 different panels at the time of this writing and it's still fairly small. But there is a slew of options to reduce that size even further if you really need to. You could for example have Kconfig options for panel vendors, or even per-panel Kconfig options to minimize the data used for the panel. I suspect that you might end up with even less data than the equivalent DT content.
Thierry