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. 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot