From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH v2 0/3] drm: introduce bus_flags for pixel clock polarity Date: Wed, 24 Feb 2016 22:17:29 +0200 Message-ID: <20160224201729.GG15993@intel.com> References: <1454968663-30066-1-git-send-email-stefan@agner.ch> <653e3f9d2d561a166a1768add0c59422@agner.ch> <56CD8EBF.9010804@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id 5309B6E858 for ; Wed, 24 Feb 2016 20:17:38 +0000 (UTC) Content-Disposition: inline In-Reply-To: <56CD8EBF.9010804@ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Tomi Valkeinen Cc: meng.yi@nxp.com, linux@arm.linux.org.uk, eric@eukrea.com, alison.wang@freescale.com, daniel.vetter@ffwll.ch, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, denis@eukrea.com List-Id: dri-devel@lists.freedesktop.org T24gV2VkLCBGZWIgMjQsIDIwMTYgYXQgMDE6MDY6MzlQTSArMDIwMCwgVG9taSBWYWxrZWluZW4g d3JvdGU6Cj4gSGksCj4gCj4gT24gMjQvMDIvMTYgMDE6MzAsIFN0ZWZhbiBBZ25lciB3cm90ZToK PiA+IEFueSBjb21tZW50cyBvbiB0aGlzPwo+ID4gCj4gPiBBbHNvIGFkZGVkIE1hbmZyZWQsIFRv bWkgYW5kIEJvcmlzIHRvIENDIHdoaWNoIHByZXZpb3VzbHkgYXR0ZW5kZWQgaW4KPiA+IHNpbWls YXIgZGlzY3Vzc2lvbnMuCj4gPiAKPiA+IFByZXZpb3VzIGRpc2N1c3Npb25zOgo+ID4gaHR0cDov L3RocmVhZC5nbWFuZS5vcmcvZ21hbmUubGludXgua2VybmVsLmFwaS8xMjgzMAo+ID4gaHR0cDov L3RocmVhZC5nbWFuZS5vcmcvZ21hbmUuY29tcC52aWRlby5kcmkuZGV2ZWwvOTYyNDAvCj4gPiAK PiA+IEkgdGhpbmsgb25lIG9mIHRoZSBtYWluIG9ic2VydmF0aW9uIHNvIGZhciB3YXMgdGhhdCB0 aGUgcGl4ZWwgY2xvY2sKPiA+IHBvbGFyaXR5IGlzIG5vdCBhIHByb3BlcnR5IG9mIHRoZSBtb2Rl LCBhbmQgdGhlcmVmb3IgZG9lcyBub3QgZml0IGludG8KPiA+IHRoZSBEUk1fTU9ERV9GTEFHLiBU aGlzIGhhcyBiZWVuIHBvaW50ZWQgb3V0IG5pY2VseSBieSBSdXNzZWw6Cj4gPiBodHRwOi8vdGhy ZWFkLmdtYW5lLm9yZy9nbWFuZS5jb21wLnZpZGVvLmRyaS5kZXZlbC85NjI0MC9mb2N1cz05NjI2 MAo+ID4gCj4gPiBFbWJlZGRlZCBkaXNwbGF5cyBjb25uZWN0ZWQgdGhyb3VnaCBwYXJhbGxlbCBi dXMgbWFrZSB1c2Ugb2YgdGhlCj4gPiBidXNfZm9ybWF0cyBmaWVsZCBpbiBkcm1fZGlzcGxheV9t b2RlLiBUaGlzIGZpZWxkIGRlZmluZXMgd2hhdCBraW5kIG9mCj4gPiBidXMgZm9ybWF0IHRoZSBk aXNwbGF5IHJlcXVpcmVzLiBUaGlzIHBhdGNoIGZvbGxvd3MgdGhhdCBpZGVhIGFuZCBhZGRzCj4g PiBidXNfZmxhZ3MuIGJ1c19mbGFncyBjYW4gYmUgdXNlZCB0byBkZWZpbmUgc3BlY2lmaWMgYnVz IHByb3BlcnRpZXMKPiA+IHJlcXVpcmVkIGJ5IHRoZSBkaXNwbGF5LCBzdWNoIGFzIHBpeGVsIGNs b2NrIG9yIGRhdGEgZW5hYmxlIHBvbGFyaXR5Li4uCj4gCj4gSSB0aGluayBpdCB3b3VsZCBiZSBn b29kIHRvIHNwbGl0IHRoZSBnZW5lcmljIGFuZCBmc2wgY2hhbmdlcyB0bwo+IHNlcGFyYXRlIHBh dGNoZXMuCj4gCj4gSSBhZ3JlZSB0aGF0IHBpeGVsIGNsb2NrIHBvbGFyaXR5IHNob3VsZG4ndCBi ZSB2aXNpYmxlIHRvIHVzZXJzcGFjZS4KPiAKPiBJIGhhZCBhIGxvb2sgYXQgTUlQSSBEUEkgc3Bl YywgYW5kIGl0IHNheXMgIlRoZSByaXNpbmcgZWRnZSBvZiBQQ0xLIGlzCj4gdXNlZCBieSB0aGUg ZGlzcGxheSBtb2R1bGUgdG8gY2FwdHVyZSBwaXhlbCBkYXRhLiIuIFNvLCBJIHRoaW5rIHRoYXQK PiBtZWFucyBpZiB0aGUgcGFuZWxzIGFyZSBNSVBJIERQSSBjb21wYXRpYmxlLCB0aGV5IHNob3Vs ZCBhbHdheXMgc2FtcGxlCj4gYXQgcmlzaW5nIGVkZ2UuIEknbSBzdXJlIHRoZXJlIGFyZSBleGNl cHRpb25zLCBidXQgdGhhdCBiZWhhdmlvdXIgc2hvdWxkCj4gcHJvYmFibHkgYmUgdGhlIGRlZmF1 bHQsIHRoZW4uCj4gCj4gSSdtIGFsc28gYSBiaXQgY3VyaW91cyBvbiB3aGF0IGlzICJ2aWRlb21v ZGUiLiBXaHkgaXMgc3luYyBwb2xhcml0eSBwYXJ0Cj4gb2YgaXQsIGFuZCBzZXR0YWJsZSBieSB0 aGUgdXNlcnNwYWNlLCBidXQgbm90IHBpeGVsIGNsb2NrIHBvbGFyaXR5Pwo+ICJ2aWRlb21vZGUi IGlzIGp1c3Qgd2hhdGV2ZXIgaXMgaW4gdGhlIENFQSBzcGVjLCBiZWNhdXNlIERSTSBvcmlnaW5h dGVzCj4gZnJvbSB0aGUgUEMgd29ybGQ/IElzIHRoZXJlIGFueSByZWFzb24gbm93YWRheXMgZm9y IHRoZSB1c2VyIHRvIGV2ZXIgc2V0Cj4gc3luYyBwb2xhcml0aWVzPwoKWWVzLCB0aGUgRURJRC9z b21ldGhpbmcgd2lsbCB0ZWxsIHVzIHRoZSBtb2RlcyB0aGUgZGlzcGxheSBjbGFpbXMgdG8KdXNl IGluY2x1ZGluZyB0aGUgc3luYyBwb2xhcml0aWVzIChhbmQgbm90ZSB0aGF0IHRoZXkgYXJlIG5v dCB0aGUgc2FtZQpmb3IgZXZlcnkgbGlzdGVkIG1vZGUpLCBidXQgdGhlIHdheSB0aGUga21zIEFQ SSB3b3JrcyBpcyB0aGF0IHRoZSB1c2VyCnNwZWNpZmllcyB0aGUgZnVsbCB0aW1pbmdzIGFueXdh eS4gU28gaWYgd2UgZGlkbid0IGhhdmUgc3luYyBwb2xhcml0aWVzCmFzIHBhcnQgb2YgdGhlIG1v ZGUsIHdlIHdvdWxkbid0IGtub3cgd2hhdCB0byBvdXRwdXQgdW5sZXNzIHdlIHdlbnQKdHJhd2xp bmcgdGhyb3VnaCB0aGUgbW9kZSBsaXN0IGxvb2tpbmcgZm9yIGEgbWF0Y2gsIHdoaWNoIG1heSBu b3QgZXZlbgpiZSBwcmVzZW50IGlmIHRoZSB1c2VyIHNwZWNpZmllZCBhIGN1c3RvbSBtb2RlLgoK PiAKPiBGb3IgTUlQSSBEUEkgcGFuZWxzLCBzeW5jIHBvbGFyaXR5IGlzIGFzIG11Y2ggYSBwcm9w ZXJ0eSBvZiB0aGUgcGFuZWwgYXMKPiBwaXhlbCBjbG9jayBwb2xhcml0eTogdGhlcmUncyBvbmx5 IG9uZSBjb3JyZWN0IHNldHRpbmcgZm9yIGl0ICh1c3VhbGx5KS4KCkluIGk5MTUgd2UgaWdub3Jl IHRoZSB1c2VyIHJlcXVlc3RlZCB0aW1pbmdzIGFsbW9zdCBlbnRpcmVseSB3aGVuCmRlYWxpbmcg d2l0aCBMVkRTL2VEUC9EU0kuIFRoZSBvbmx5IHRoaW5rIHdlIGtlZXAgaXMgdGhhdCBzaXplIG9m CnRoZSBhY3RpdmUgdmlkZW8gcG9ydGlvbiwgYW5kIHdlIHVzZSB0aGF0IGFzIHRoZSBpbnB1dCBz aXplIGZvcgp0aGUgcGFuZWwgZml0dGVyICg9PSBzY2FsZXIpLiBBbGwgdGhlIGFjdHVhbCB0aW1p bmdzIHVzZWQgdG8KZHJpdmUgdGhlIGRpc3BsYXkgY29tZSBmcm9tIEVESUQgb3IgdGhlIFZCVCAo dmlkZW8gQklPUyB0YWJsZSkuCgpGb3IgZXh0ZXJuYWwgZGlzcGxheXMgd2UgZG8gcmVzcGVjdCB3 aGF0IHRoZSB1c2VyIGhhcyByZXF1ZXN0ZWQsCmluY2x1ZGluZyB0aGUgc3luYyBwb2xhcml0aWVz LgoKLS0gClZpbGxlIFN5cmrDpGzDpApJbnRlbCBPVEMKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxA bGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxt YW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757526AbcBXURl (ORCPT ); Wed, 24 Feb 2016 15:17:41 -0500 Received: from mga04.intel.com ([192.55.52.120]:42307 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751305AbcBXURk (ORCPT ); Wed, 24 Feb 2016 15:17:40 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,494,1449561600"; d="scan'208";a="923191247" Date: Wed, 24 Feb 2016 22:17:29 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Tomi Valkeinen Cc: Stefan Agner , dri-devel@lists.freedesktop.org, thierry.reding@gmail.com, airlied@linux.ie, daniel.vetter@ffwll.ch, jianwei.wang.chn@gmail.com, alison.wang@freescale.com, meng.yi@nxp.com, linux@arm.linux.org.uk, p.zabel@pengutronix.de, denis@eukrea.com, eric@eukrea.com, linux-kernel@vger.kernel.org, manfred.schlaegl@gmx.at, boris.brezillon@free-electrons.com Subject: Re: [PATCH v2 0/3] drm: introduce bus_flags for pixel clock polarity Message-ID: <20160224201729.GG15993@intel.com> References: <1454968663-30066-1-git-send-email-stefan@agner.ch> <653e3f9d2d561a166a1768add0c59422@agner.ch> <56CD8EBF.9010804@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56CD8EBF.9010804@ti.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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