From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751298AbdAaWMB (ORCPT ); Tue, 31 Jan 2017 17:12:01 -0500 Received: from mail-wj0-f196.google.com ([209.85.210.196]:34006 "EHLO mail-wj0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751238AbdAaWL7 (ORCPT ); Tue, 31 Jan 2017 17:11:59 -0500 Date: Tue, 31 Jan 2017 22:42:43 +0100 From: Thierry Reding To: Eric Anholt , Mark Rutland , Florian Fainelli , Stephen Warren , Michael Turquette , Lee Jones , Stephen Boyd , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Rob Herring , bcm-kernel-feedback-list@broadcom.com, linux-rpi-kernel@lists.infradead.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 09/11] drm/panel: Add support for the Raspberry Pi 7" Touchscreen. Message-ID: <20170131214241.GE872@mithrandir.ba.sec> References: <20161214194621.16499-1-eric@anholt.net> <20161214194621.16499-10-eric@anholt.net> <20170131210717.GA872@mithrandir.ba.sec> <20170131211702.o2he5o6ktaztmrkx@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ffoCPvUAPMgSXi6H" Content-Disposition: inline In-Reply-To: <20170131211702.o2he5o6ktaztmrkx@phenom.ffwll.local> User-Agent: Mutt/1.7.2 (2016-11-26) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --ffoCPvUAPMgSXi6H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2017 at 10:17:02PM +0100, Daniel Vetter wrote: > On Tue, Jan 31, 2017 at 10:07:19PM +0100, Thierry Reding wrote: > > On Wed, Dec 14, 2016 at 11:46:19AM -0800, Eric Anholt wrote: > > > +static int rpi_touchscreen_enable(struct drm_panel *panel) > > > +{ > > > + struct rpi_touchscreen *ts =3D panel_to_ts(panel); > > > + int i; > > > + > > > + rpi_touchscreen_i2c_write(ts, REG_POWERON, 1); > > > + /* Wait for nPWRDWN to go low to indicate poweron is done. */ > > > + for (i =3D 0; i < 100; i++) { > > > + if (rpi_touchscreen_i2c_read(ts, REG_PORTB) & 1) > > > + break; > > > + } > >=20 > > Don't you want to fail when power on doesn't succeed? Seems kind of > > pointless to continue if the panel doesn't power on. >=20 > kms works under the assumption that even when the sink is dead, the > display pipe (well, vblanks and pageflips) keep working. There's a patch > floating around to give userspace more information about what's going > wrong through an async uevent+read-only property for cases where an > unresponsive sink is normal, i.e. link training for dp. >=20 > But either way, continuing is generally the right thing to do, there's no > way to report -EIO from here (because no reasons than that's where > accidentally ended up with our evolved design ...). I think this depends on the specific case. I was assuming that if the panel fails to power up, then any subsequent operations like register reads or writes would also fail, potentially causing a lot of confusing error messages that could easily be avoided. Also, the panel API is usually called from encoder or connector drivers and propagating error codes might give them a chance of reacting. Thierry --ffoCPvUAPMgSXi6H Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAliRBNEACgkQ3SOs138+ s6ErbRAApmTIsMNua/mJJO2KS72Frpyf0fOANkvTTTreRfoapD98RZCSfQrNrnlr YJE8tTOMSEw7Y4tYeTkPlFKbKC636YqqNWksf/X8RR3KyW/8ZHndjhmC8N6l4i74 LA/B2D/XXSqHMdtDlMKzv9qmiYYZWqznjpIzGGIkB5BA1m3LyDWCSpMvkb/P17US VRwCVKTCNP4QWmSe0zsvSQRj8nAR3Pug9ok9HIOyodGZC33js8hoS21IWpbCzKqG ObFBiORPtrqGFppkEz9Tg3HBXCkAK/0dGcRkpCbeJXleDhTK702b5JI8EO/7IVvh jejT1vtRRAlvGog1t4Bftd/y02ODszPFvEgdpDwUvCKazssN7NQHJbXcF4YiMH1n vFZh+Yumpt+UoT0lAm84+6WCzG1tPjCnIRXC35YGjxjm6+ya594piHUynzSR1GVw HlD0eVJkCLBHKbAHQ493IZqUCKpn9T6mby5PDdVRuH0Jpkw0cNBjO+Pu3hQBu2yS zSwHK0nyVPzya9IEk9QKbZFq/0Hp/qu5qO6hlkTV3IWKyWNO1kUCjs4Ru49shn4Q APYXonsFH0+E0CmRBEykRD2jkkAZTjWbuUzR0kbYim2+xAcjQCB5wlcHEqM9rKHH Lg8I2aOwZYSXa7CpC6GcpN6VK6yUTk9voZ07/bb33wHwuoJC72I= =8mCq -----END PGP SIGNATURE----- --ffoCPvUAPMgSXi6H-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: thierry.reding@gmail.com (Thierry Reding) Date: Tue, 31 Jan 2017 22:42:43 +0100 Subject: [PATCH 09/11] drm/panel: Add support for the Raspberry Pi 7" Touchscreen. In-Reply-To: <20170131211702.o2he5o6ktaztmrkx@phenom.ffwll.local> References: <20161214194621.16499-1-eric@anholt.net> <20161214194621.16499-10-eric@anholt.net> <20170131210717.GA872@mithrandir.ba.sec> <20170131211702.o2he5o6ktaztmrkx@phenom.ffwll.local> Message-ID: <20170131214241.GE872@mithrandir.ba.sec> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Jan 31, 2017 at 10:17:02PM +0100, Daniel Vetter wrote: > On Tue, Jan 31, 2017 at 10:07:19PM +0100, Thierry Reding wrote: > > On Wed, Dec 14, 2016 at 11:46:19AM -0800, Eric Anholt wrote: > > > +static int rpi_touchscreen_enable(struct drm_panel *panel) > > > +{ > > > + struct rpi_touchscreen *ts = panel_to_ts(panel); > > > + int i; > > > + > > > + rpi_touchscreen_i2c_write(ts, REG_POWERON, 1); > > > + /* Wait for nPWRDWN to go low to indicate poweron is done. */ > > > + for (i = 0; i < 100; i++) { > > > + if (rpi_touchscreen_i2c_read(ts, REG_PORTB) & 1) > > > + break; > > > + } > > > > Don't you want to fail when power on doesn't succeed? Seems kind of > > pointless to continue if the panel doesn't power on. > > kms works under the assumption that even when the sink is dead, the > display pipe (well, vblanks and pageflips) keep working. There's a patch > floating around to give userspace more information about what's going > wrong through an async uevent+read-only property for cases where an > unresponsive sink is normal, i.e. link training for dp. > > But either way, continuing is generally the right thing to do, there's no > way to report -EIO from here (because no reasons than that's where > accidentally ended up with our evolved design ...). I think this depends on the specific case. I was assuming that if the panel fails to power up, then any subsequent operations like register reads or writes would also fail, potentially causing a lot of confusing error messages that could easily be avoided. Also, the panel API is usually called from encoder or connector drivers and propagating error codes might give them a chance of reacting. Thierry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH 09/11] drm/panel: Add support for the Raspberry Pi 7" Touchscreen. Date: Tue, 31 Jan 2017 22:42:43 +0100 Message-ID: <20170131214241.GE872@mithrandir.ba.sec> References: <20161214194621.16499-1-eric@anholt.net> <20161214194621.16499-10-eric@anholt.net> <20170131210717.GA872@mithrandir.ba.sec> <20170131211702.o2he5o6ktaztmrkx@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1184137345==" Return-path: Received: from mail-wj0-x244.google.com (mail-wj0-x244.google.com [IPv6:2a00:1450:400c:c01::244]) by gabe.freedesktop.org (Postfix) with ESMTPS id DBF0F6E72A for ; Tue, 31 Jan 2017 21:42:46 +0000 (UTC) Received: by mail-wj0-x244.google.com with SMTP id kq3so12082895wjc.3 for ; Tue, 31 Jan 2017 13:42:46 -0800 (PST) In-Reply-To: <20170131211702.o2he5o6ktaztmrkx@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Eric Anholt , Mark Rutland , Florian Fainelli , Stephen Warren , Michael Turquette , Lee Jones , Stephen Boyd , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Rob Herring , bcm-kernel-feedback-list@broadcom.com, linux-rpi-kernel@lists.infradead.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org List-Id: dri-devel@lists.freedesktop.org --===============1184137345== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ffoCPvUAPMgSXi6H" Content-Disposition: inline --ffoCPvUAPMgSXi6H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2017 at 10:17:02PM +0100, Daniel Vetter wrote: > On Tue, Jan 31, 2017 at 10:07:19PM +0100, Thierry Reding wrote: > > On Wed, Dec 14, 2016 at 11:46:19AM -0800, Eric Anholt wrote: > > > +static int rpi_touchscreen_enable(struct drm_panel *panel) > > > +{ > > > + struct rpi_touchscreen *ts =3D panel_to_ts(panel); > > > + int i; > > > + > > > + rpi_touchscreen_i2c_write(ts, REG_POWERON, 1); > > > + /* Wait for nPWRDWN to go low to indicate poweron is done. */ > > > + for (i =3D 0; i < 100; i++) { > > > + if (rpi_touchscreen_i2c_read(ts, REG_PORTB) & 1) > > > + break; > > > + } > >=20 > > Don't you want to fail when power on doesn't succeed? Seems kind of > > pointless to continue if the panel doesn't power on. >=20 > kms works under the assumption that even when the sink is dead, the > display pipe (well, vblanks and pageflips) keep working. There's a patch > floating around to give userspace more information about what's going > wrong through an async uevent+read-only property for cases where an > unresponsive sink is normal, i.e. link training for dp. >=20 > But either way, continuing is generally the right thing to do, there's no > way to report -EIO from here (because no reasons than that's where > accidentally ended up with our evolved design ...). I think this depends on the specific case. I was assuming that if the panel fails to power up, then any subsequent operations like register reads or writes would also fail, potentially causing a lot of confusing error messages that could easily be avoided. Also, the panel API is usually called from encoder or connector drivers and propagating error codes might give them a chance of reacting. Thierry --ffoCPvUAPMgSXi6H Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAliRBNEACgkQ3SOs138+ s6ErbRAApmTIsMNua/mJJO2KS72Frpyf0fOANkvTTTreRfoapD98RZCSfQrNrnlr YJE8tTOMSEw7Y4tYeTkPlFKbKC636YqqNWksf/X8RR3KyW/8ZHndjhmC8N6l4i74 LA/B2D/XXSqHMdtDlMKzv9qmiYYZWqznjpIzGGIkB5BA1m3LyDWCSpMvkb/P17US VRwCVKTCNP4QWmSe0zsvSQRj8nAR3Pug9ok9HIOyodGZC33js8hoS21IWpbCzKqG ObFBiORPtrqGFppkEz9Tg3HBXCkAK/0dGcRkpCbeJXleDhTK702b5JI8EO/7IVvh jejT1vtRRAlvGog1t4Bftd/y02ODszPFvEgdpDwUvCKazssN7NQHJbXcF4YiMH1n vFZh+Yumpt+UoT0lAm84+6WCzG1tPjCnIRXC35YGjxjm6+ya594piHUynzSR1GVw HlD0eVJkCLBHKbAHQ493IZqUCKpn9T6mby5PDdVRuH0Jpkw0cNBjO+Pu3hQBu2yS zSwHK0nyVPzya9IEk9QKbZFq/0Hp/qu5qO6hlkTV3IWKyWNO1kUCjs4Ru49shn4Q APYXonsFH0+E0CmRBEykRD2jkkAZTjWbuUzR0kbYim2+xAcjQCB5wlcHEqM9rKHH Lg8I2aOwZYSXa7CpC6GcpN6VK6yUTk9voZ07/bb33wHwuoJC72I= =8mCq -----END PGP SIGNATURE----- --ffoCPvUAPMgSXi6H-- --===============1184137345== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1184137345==--