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

From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Steffen Trumtrar <s.trumtrar@pengutronix.de>,
	linux-fbdev@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
	dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org
Subject: Re: [PATCH 1/2 v6] of: add helper to parse display timings
Date: Mon, 08 Oct 2012 15:20:16 +0300	[thread overview]
Message-ID: <1349698816.9437.5.camel@deskari> (raw)
In-Reply-To: <1479122.2xVsV4MZ4o@avalon>

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]