linux-kernel - Re: [PATCH 7/7] drm/fsl-dcu: use mode flags for hsync/vsync pixelclk 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <9cd8445adf5bddd84932c94c228c6769@agner.ch>
Date:	Thu, 04 Feb 2016 12:31:18 -0800
From:	Stefan Agner <stefan@...er.ch>
To:	Thierry Reding <thierry.reding@...il.com>
Cc:	airlied@...il.com, alison.wang@...escale.com,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	airlied@...ux.ie, daniel.vetter@...ll.ch,
	jianwei.wang.chn@...il.com, Shawn Guo <shawnguo@...nel.org>
Subject: Re: [PATCH 7/7] drm/fsl-dcu: use mode flags for hsync/vsync pixelclk
 polarity

On 2016-02-03 15:18, Stefan Agner wrote:
> On 2016-02-03 06:00, Thierry Reding wrote:
>> On Wed, Jan 27, 2016 at 06:46:50PM -0800, Stefan Agner wrote:
>> [...]
>>> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
>>> > b/drivers/gpu/drm/panel/panel-simple.c
>>> > index f97b73e..fa68b56 100644
>>> > --- a/drivers/gpu/drm/panel/panel-simple.c
>>> > +++ b/drivers/gpu/drm/panel/panel-simple.c
>>> > @@ -960,6 +960,8 @@ static const struct drm_display_mode
>>> > nec_nl4827hc19_05b_mode = {
>>> >  	.vsync_end = 272 + 2 + 4,
>>> >  	.vtotal = 272 + 2 + 4 + 2,
>>> >  	.vrefresh = 74,
>>> > +	.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC |
>>> > +		 DISPLAY_FLAGS_PIXDATA_POSEDGE,
>>
>> It doesn't seem like these two types of flags should be mixed because
>> they overlap. DISPLAY_FLAGS_PIXDATA_POSEDGE has the same value as the
>> DRM_MODE_FLAG_CSYNC define.
> 
> There are other entries such as hannstar_hsd100pxn1_timing which make
> use of DISPLAY_FLAGS too, hence I did not bother further. Having a
> conflict is definitely not what we want.

Oh, just realized, hannstar_hsd100pxn1_timing is actually a different
type of struct, and for this struct the DISPALY_FLAGS make sense...

> 
>> The definition of the DISPLAY_FLAGS_PIXDATA_POSEDGE is also not very
>> clear to me. I don't think we have an equivalent DRM_MODE_FLAG_* but
>> we could add one if there's really a need.
> 
> E.g. assuming a parallel video signal, the pixel data signals could be
> changing on positive or negative edge relative to the clock signal. Most
> displays _sample_ the data on rising edge, hence controllers should
> normally drive data on falling edge.
> 
> However, as always, there are exceptions to the rule, and one of the
> exception is Freescales default display for the Tower evaluation board.
> It samples data on falling edge, hence the controller should drive data
> on rising edge...
> 
> Yeah I also did not found an equivalent in DRM_MODE_FLAG_*. I have here
> also other displays where we would need this flag. The display-timings
> binds and enum display_flags support it too, hence I guess we should
> have it here too.
> 
> I will split out this patch from the patchset (I already applied the
> rest), add another patch to add the flag, make use of the flag in this
> patch and resend it as v2.

I realized that after this, there are only two flags which are not yet
in DRM_MODE_FLAG: DE_LOW/DE_HIGH.

Thierry, what do you think, should I add these remaining two flags too?

--
Stefan