[PATCH 1/2 v6] of: add helper to parse display timings

[Tomi Valkeinen]

On Mon, 2012-10-08 at 14:04 +0200, Laurent Pinchart wrote:
> 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.

Yes, I would have a table in the driver for all the devices it supports,
which would describe the device specific parameters.

But I don't have a problem with DT solution. Both methods have their
pros and cons, and perhaps DT based solution is more practical.

> 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 ?

Hmm, right, if it means native mode, then it is describing the hardware.
But would it make sense to require that the native mode is the first
mode in the list, then? This would make the separate
default-mode/native-mode property not needed.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20121008/f666c5ef/attachment.sig>