linux-kernel - Re: [PATCH v2 0/3] drm: introduce bus

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: <547082a6f42a86c374dbc9a3725394aa@agner.ch>
Date:	Wed, 24 Feb 2016 11:02:34 -0800
From:	Stefan Agner <stefan@...er.ch>
To:	Tomi Valkeinen <tomi.valkeinen@...com>
Cc:	dri-devel@...ts.freedesktop.org, thierry.reding@...il.com,
	airlied@...ux.ie, daniel.vetter@...ll.ch,
	jianwei.wang.chn@...il.com, alison.wang@...escale.com,
	meng.yi@....com, linux@....linux.org.uk, p.zabel@...gutronix.de,
	denis@...rea.com, eric@...rea.com, ville.syrjala@...ux.intel.com,
	linux-kernel@...r.kernel.org, manfred.schlaegl@....at,
	boris.brezillon@...e-electrons.com
Subject: Re: [PATCH v2 0/3] drm: introduce bus_flags for pixel clock polarity

On 2016-02-24 03:06, Tomi Valkeinen wrote:
> Hi,
> 
> On 24/02/16 01:30, Stefan Agner wrote:
>> Any comments on this?
>>
>> Also added Manfred, Tomi and Boris to CC which previously attended in
>> similar discussions.
>>
>> Previous discussions:
>> http://thread.gmane.org/gmane.linux.kernel.api/12830
>> http://thread.gmane.org/gmane.comp.video.dri.devel/96240/
>>
>> I think one of the main observation so far was that the pixel clock
>> polarity is not a property of the mode, and therefor does not fit into
>> the DRM_MODE_FLAG. This has been pointed out nicely by Russel:
>> http://thread.gmane.org/gmane.comp.video.dri.devel/96240/focus=96260
>>
>> Embedded displays connected through parallel bus make use of the
>> bus_formats field in drm_display_mode. This field defines what kind of
>> bus format the display requires. This patch follows that idea and adds
>> bus_flags. bus_flags can be used to define specific bus properties
>> required by the display, such as pixel clock or data enable polarity...
> 
> I think it would be good to split the generic and fsl changes to
> separate patches.

I guess we talk about PATCH 3/3?

This is intentionally in one patch: The problem is that the current
default setting of the driver is the correct setting for that one NEC
display. The patch changes the default setting of the display controller
driver, but to make sure the NEC display continues to work I need to add
the polarity flag to the display. Therefor I feel this is one logical
change... Also this way the display keeps working between every commit
(bisectability...)

The core changes (the flag defines and adding the field to struct
drm_display_info) are in a separate patch.

> 
> I agree that pixel clock polarity shouldn't be visible to userspace.
> 
> I had a look at MIPI DPI spec, and it says "The rising edge of PCLK is
> used by the display module to capture pixel data.". So, I think that
> means if the panels are MIPI DPI compatible, they should always sample
> at rising edge. I'm sure there are exceptions, but that behaviour should
> probably be the default, then.

Yes, that is the new default of the driver.

> 
> I'm also a bit curious on what is "videomode". Why is sync polarity part
> of it, and settable by the userspace, but not pixel clock polarity?
> "videomode" is just whatever is in the CEA spec, because DRM originates
> from the PC world? Is there any reason nowadays for the user to ever set
> sync polarities?
> 
> For MIPI DPI panels, sync polarity is as much a property of the panel as
> pixel clock polarity: there's only one correct setting for it (usually).
> 

We probably could add the sync properties to the bus_flags too, and
those would take precedence over the mode sync polarities...? Certainly
something which could be done in a follow up patch.

--
Stefan