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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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

 Tomi

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux