Hi Tomi, On Monday 08 October 2012 12:01:18 Tomi Valkeinen wrote: > On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski wrote: > > In general, I might be misunderstanding something, but don't we have to > > distinguish between 2 types of information about display timings: (1) is > > defined by the display controller requirements, is known to the display > > driver and doesn't need to be present in timings DT. We did have some of > > these parameters in board data previously, because we didn't have proper > > display controller drivers... (2) is board specific configuration, and is > > such it has to be present in DT. > > > > In that way, doesn't "interlaced" belong to type (1) and thus doesn't need > > to be present in DT? > > As I see it, this DT data is about the display (most commonly LCD > panel), i.e. what video mode(s) the panel supports. If things were done > my way, the panel's supported timings would be defined in the driver for > the panel, and DT would be left to describe board specific data, but > this approach has its benefits. What about dumb DPI panels ? They will all be supported by a single driver, would you have the driver contain information about all known DPI panels ? DT seems a good solution to me in this case. For complex panels where the driver will support a single (or very few) model I agree that specifying the timings in DT isn't needed. > Thus, if you connect an interlaced panel to your board, you need to tell > the display controller that this panel requires interlace signal. Also, > pixel clock source doesn't make sense in this context, as this doesn't > describe the actual used configuration, but only what the panel > supports. > > Of course, if this is about describing the hardware, the default-mode > property doesn't really fit in... Maybe we should rename it to native-mode then ? -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
