[PATCHv15 3/7] video: add of helper for display timings/videomode

Philipp Zabel p.zabel at pengutronix.de
Sat Dec 8 01:12:48 EST 2012


Hi,

Am Montag, den 26.11.2012, 18:56 +0200 schrieb Tomi Valkeinen:
> On 2012-11-26 18:10, Steffen Trumtrar wrote:
> > Hi,
> > 
> > On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote:
> 
> >>> +optional properties:
> >>> + - hsync-active: hsync pulse is active low/high/ignored
> >>> + - vsync-active: vsync pulse is active low/high/ignored
> >>> + - de-active: data-enable pulse is active low/high/ignored
> >>> + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/
> >>> +				non-inverted (active on rising edge)/
> >>> +				     ignored (ignore property)
> >>
> >> I think hsync-active and vsync-active are clear, and commonly used, and
> >> they are used for both drm and fb mode conversions in later patches.
> >>
> >> de-active is not used in drm and fb mode conversions, but I think it's
> >> also clear.
> >>
> >> pixelclk-inverted is not used in the mode conversions. It's also a bit
> >> unclear to me. What does it mean that pix clock is "active on rising
> >> edge"? The pixel data is driven on rising edge? How about the sync
> >> signals and DE, when are they driven? Does your HW have any settings
> >> related to those?
> >>
> > 
> > Those are properties commonly found in display specs. That is why they are here.
> > If the GPU does not support the property it can be omitted.
> 
> So what does the pixelclk-inverted mean? Normally the SoC drives pixel
> data on rising edge, and the panel samples it at falling edge? And
> vice-versa for inverted? Or the other way around?
>
> When is hsync/vsync set? On rising or falling edge of pclk?
>
> My point here is that the pixelclk-inverted is not crystal clear thing,
> like the hsync/vsync/de-active values are.
>
> And while thinking about this, I realized that the meaning of
> pixelclk-inverted depends on what component is it applied to. Presuming
> normal pixclk means "pixel data on rising edge", the meaning of that
> depends on do we consider the SoC or the panel. The panel needs to
> sample the data on the other edge from the one the SoC uses to drive the
> data.
> 
> Does the videomode describe the panel, or does it describe the settings
> programmed to the SoC?

How about calling this property pixelclk-active, active high meaning
driving pixel data on rising edges and sampling on falling edges (the
pixel clock is high between driving and sampling the data), and active
low meaning driving on falling edges and sampling on rising edges?
It is the same from the SoC perspective and from the panel perspective,
and it mirrors the usage of the other *-active properties.

[...]

regards
Philipp



More information about the devicetree-discuss mailing list