linux-kernel - Re: [RFC PATCH 1/2] drm: add support for for clk and de polarity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 30 Nov 2015 22:09:09 +0100
From:	Philipp Zabel <p.zabel@...gutronix.de>
To:	Tomi Valkeinen <tomi.valkeinen@...com>
Cc:	Manfred Schlaegl <manfred.schlaegl@....at>,
	David Airlie <airlied@...ux.ie>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	linux-api@...r.kernel.org,
	Manfred Schlaegl <manfred.schlaegl@...zinger.com>,
	Steve Longerbeam <slongerbeam@...il.com>,
	Deepak Das <deepak_das@...tor.com>,
	Jiada Wang <jiada_wang@...tor.com>,
	linux-fbdev@...r.kernel.org,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [RFC PATCH 1/2] drm: add support for for clk and de polarity

Am Freitag, den 27.11.2015, 09:37 +0200 schrieb Tomi Valkeinen:
> On 26/11/15 16:20, Manfred Schlaegl wrote:
> > Good to see that this discussion is triggered.
> 
> I seem to have missed this one. This is important for omapdrm also.
> We've had similar patch in TI's linux for a while, but I have never had
> time to start upstreaming it.
> 
> Two comments:
> 
> The "pixclock polarity" could be explained a bit, as it's not really
> about polarity. This was discussed when the display-timings stuff was
> worked on, and display-timings.txt explains what the "pixelclk-active"
> property means.

Yes, the relevant part of this setting is whether the panel will sample
the data bus on the falling or rising edge of the pixel clock signal.
The display interface has guarantee that the data bus is stable around
that time.

> So here I think you could maybe have a comment pointing to
> display-timings.txt, or perhaps a short comment about what the flag is.
> Or if you come up with a great name for the define, that's good too =).

We have the choice of describing the flag from point of view of the
display controller (as the DISPLAY_FLAGS do), from point of view of the
panel, or using a somewhat neutral description like in the device tree.
Which choice I'd prefer depends on whether the flags go into
drm_display_mode / drm_mode_modeinfo or in drm_display_info.

In any case, I think that it'd be better to talk about driving or
sampling data on rising or falling edges instead of clock polarity.

> The other comment is not about this patch as such, but similar flags
> that OMAP has, and possibly some other platforms too:
> 
> 1) sync signals driven on rising or falling edge of pixel clock
> 2) hsync and vsync happen at the same time or hsync happens first,
> followed by vsync
> 
> Any other platforms have similar features?

The i.MX6 display interface consists of a number of rather freely
configurable signal generators, so all of this should be possible to do.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/