On Wed, Feb 24, 2016 at 01:06:39PM +0200, 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 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? Yes, the EDID/something will tell us the modes the display claims to use including the sync polarities (and note that they are not the same for every listed mode), but the way the kms API works is that the user specifies the full timings anyway. So if we didn't have sync polarities as part of the mode, we wouldn't know what to output unless we went trawling through the mode list looking for a match, which may not even be present if the user specified a custom mode. > > 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). In i915 we ignore the user requested timings almost entirely when dealing with LVDS/eDP/DSI. The only think we keep is that size of the active video portion, and we use that as the input size for the panel fitter (== scaler). All the actual timings used to drive the display come from EDID or the VBT (video BIOS table). For external displays we do respect what the user has requested, including the sync polarities. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
