Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1341862

Re: [PATCH v2 0/3] drm: introduce bus_flags for pixel clock polarity

From Tomi Valkeinen <tomi.valkeinen@ti.com>
Newsgroups linux.kernel
Subject Re: [PATCH v2 0/3] drm: introduce bus_flags for pixel clock polarity
Date 2016-02-24 12:10 +0100
Message-ID <r5Fuq-3EV-31@gated-at.bofh.it> (permalink)
References <r020F-2D0-9@gated-at.bofh.it> <r5uIG-4hX-27@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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

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

 Tomi

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v2 0/3] drm: introduce bus_flags for pixel clock polarity Stefan Agner <stefan@agner.ch> - 2016-02-24 00:40 +0100
  Re: [PATCH v2 0/3] drm: introduce bus_flags for pixel clock polarity Philipp Zabel <p.zabel@pengutronix.de> - 2016-02-24 11:40 +0100
    Re: [PATCH v2 0/3] drm: introduce bus_flags for pixel clock polarity Manfred Schlaegl <manfred.schlaegl@gmx.at> - 2016-02-25 09:00 +0100
  Re: [PATCH v2 0/3] drm: introduce bus_flags for pixel clock polarity Tomi Valkeinen <tomi.valkeinen@ti.com> - 2016-02-24 12:10 +0100
    Re: [PATCH v2 0/3] drm: introduce bus_flags for pixel clock polarity Stefan Agner <stefan@agner.ch> - 2016-02-24 20:20 +0100
    Re: [PATCH v2 0/3] drm: introduce bus_flags for pixel clock polarity Ville Syrjälä <ville.syrjala@linux.intel.com> - 2016-02-24 21:20 +0100

csiph-web