From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: [PATCH v2 0/3] drm: introduce bus_flags for pixel clock polarity Date: Wed, 24 Feb 2016 13:06:39 +0200 Message-ID: <56CD8EBF.9010804@ti.com> References: <1454968663-30066-1-git-send-email-stefan@agner.ch> <653e3f9d2d561a166a1768add0c59422@agner.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Q8PP7H9kaNBLbhdRBwvn4l3vxv9E6Dfab" Return-path: In-Reply-To: <653e3f9d2d561a166a1768add0c59422@agner.ch> Sender: linux-kernel-owner@vger.kernel.org To: Stefan Agner , dri-devel@lists.freedesktop.org, thierry.reding@gmail.com Cc: 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, ville.syrjala@linux.intel.com, linux-kernel@vger.kernel.org, manfred.schlaegl@gmx.at, boris.brezillon@free-electrons.com List-Id: dri-devel@lists.freedesktop.org --Q8PP7H9kaNBLbhdRBwvn4l3vxv9E6Dfab Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On 24/02/16 01:30, Stefan Agner wrote: > Any comments on this? >=20 > Also added Manfred, Tomi and Boris to CC which previously attended in > similar discussions. >=20 > Previous discussions: > http://thread.gmane.org/gmane.linux.kernel.api/12830 > http://thread.gmane.org/gmane.comp.video.dri.devel/96240/ >=20 > 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=3D96260 >=20 > 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 --Q8PP7H9kaNBLbhdRBwvn4l3vxv9E6Dfab Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWzY6/AAoJEPo9qoy8lh71JAAP/jsyVGhQJ21h5rlicDMmYZvl 2BJh1yRILxF3mhpSyeuAz0Ban980SjucwG315aGeYcZuWN405sPU0L3UU5V6wK0X 7zu7LS7Lb3jsazLztAhaZ1tcOcC75Ebxq015o8JwHgtL7sBx3ktDS6VZ6rJiyGx5 UMcqkJg1MdPdWU7KQOiz3qHquzaQivKhykYOgZ1IKXMYDarRaGYLuqfPQk5fe+nn fyvxCOQMvgJkQw41lfsKDct1As2q9PBUa+Cpx07s9ICCByUgjgaeoT+63JTiczAD lEQ9xEtOKkjlgVOCmBom2VWkm+TVIUSxw/g0TxKfAVwSikCZMm/ztSBx1YaonXSH tmBzkA7QdkkbYjui6DkXu3rrxHlomIgokFzfqz3zplZO5Oq/Jmcp6reqG2zJXbrg kGQ0t/IhvRTvXe2g0CLlN7A8pry79vj1Y5CWeYb0bqa2v1BK09+Ly0Zpg4JaO4LH B2E5anhQZjnZLPvhIstsibORLAYv+9RO7R4IAayoXKjxTrx4JLkHFxkg8HGjo6D0 +h5bIgwuqlpGMZAq7iabqRAbVMZ/ZanZ2QppIqQM4rwN3mldAmMrnWFt2IvHqHE8 ca30GnvuMc1FPaajNximI7hQnnluz2vAqKD2G52B5VIrvQPcGzhOK5PtGhwaq8+7 rhvx2z4kGcAKc+hlwfnu =M49Y -----END PGP SIGNATURE----- --Q8PP7H9kaNBLbhdRBwvn4l3vxv9E6Dfab-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756643AbcBXLIH (ORCPT ); Wed, 24 Feb 2016 06:08:07 -0500 Received: from devils.ext.ti.com ([198.47.26.153]:47240 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754924AbcBXLID (ORCPT ); Wed, 24 Feb 2016 06:08:03 -0500 Subject: Re: [PATCH v2 0/3] drm: introduce bus_flags for pixel clock polarity To: Stefan Agner , , References: <1454968663-30066-1-git-send-email-stefan@agner.ch> <653e3f9d2d561a166a1768add0c59422@agner.ch> CC: , , , , , , , , , , , , From: Tomi Valkeinen X-Enigmail-Draft-Status: N1110 Message-ID: <56CD8EBF.9010804@ti.com> Date: Wed, 24 Feb 2016 13:06:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <653e3f9d2d561a166a1768add0c59422@agner.ch> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Q8PP7H9kaNBLbhdRBwvn4l3vxv9E6Dfab" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Q8PP7H9kaNBLbhdRBwvn4l3vxv9E6Dfab Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On 24/02/16 01:30, Stefan Agner wrote: > Any comments on this? >=20 > Also added Manfred, Tomi and Boris to CC which previously attended in > similar discussions. >=20 > Previous discussions: > http://thread.gmane.org/gmane.linux.kernel.api/12830 > http://thread.gmane.org/gmane.comp.video.dri.devel/96240/ >=20 > 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=3D96260 >=20 > 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 --Q8PP7H9kaNBLbhdRBwvn4l3vxv9E6Dfab Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWzY6/AAoJEPo9qoy8lh71JAAP/jsyVGhQJ21h5rlicDMmYZvl 2BJh1yRILxF3mhpSyeuAz0Ban980SjucwG315aGeYcZuWN405sPU0L3UU5V6wK0X 7zu7LS7Lb3jsazLztAhaZ1tcOcC75Ebxq015o8JwHgtL7sBx3ktDS6VZ6rJiyGx5 UMcqkJg1MdPdWU7KQOiz3qHquzaQivKhykYOgZ1IKXMYDarRaGYLuqfPQk5fe+nn fyvxCOQMvgJkQw41lfsKDct1As2q9PBUa+Cpx07s9ICCByUgjgaeoT+63JTiczAD lEQ9xEtOKkjlgVOCmBom2VWkm+TVIUSxw/g0TxKfAVwSikCZMm/ztSBx1YaonXSH tmBzkA7QdkkbYjui6DkXu3rrxHlomIgokFzfqz3zplZO5Oq/Jmcp6reqG2zJXbrg kGQ0t/IhvRTvXe2g0CLlN7A8pry79vj1Y5CWeYb0bqa2v1BK09+Ly0Zpg4JaO4LH B2E5anhQZjnZLPvhIstsibORLAYv+9RO7R4IAayoXKjxTrx4JLkHFxkg8HGjo6D0 +h5bIgwuqlpGMZAq7iabqRAbVMZ/ZanZ2QppIqQM4rwN3mldAmMrnWFt2IvHqHE8 ca30GnvuMc1FPaajNximI7hQnnluz2vAqKD2G52B5VIrvQPcGzhOK5PtGhwaq8+7 rhvx2z4kGcAKc+hlwfnu =M49Y -----END PGP SIGNATURE----- --Q8PP7H9kaNBLbhdRBwvn4l3vxv9E6Dfab--