From mboxrd@z Thu Jan 1 00:00:00 1970 From: eric@anholt.net (Eric Anholt) Date: Mon, 29 Jan 2018 15:55:41 -0800 Subject: [PATCH 4/4] drm/pl111: Support multiple endpoints on the CLCD In-Reply-To: <20180126132033.19744-4-linus.walleij@linaro.org> References: <20180126132033.19744-1-linus.walleij@linaro.org> <20180126132033.19744-4-linus.walleij@linaro.org> Message-ID: <87wp00w77m.fsf@anholt.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Linus Walleij writes: > The Versatile PL110 implementations use multiple endpoints: > from the PL111 port, the lines are routed through a PLD, > and from there forked so the same lines go to a VGA DAC and > an external TFT panel connector. This is discrete wireing > so there is no way to turn of one output, i.e. this is > really two endpoints, not two ports. > > We model this with multiple endpoints, so we need to loop > over the available endpoints, check for panel or bridge on > each and accumulate the result before continuing. > > The code already will give the panel preference over the > bridge, if present, so the output will be sent to the panel > if both a panel and a bridge is present on two endpoints > of the same port. > > If they all return -EPROBE_DEFER we return -EPROBE_DEFER > as well. > > If just one endpoint is present on the port, the behaviour > is the same as before. > > Signed-off-by: Linus Walleij Huh, from the binding I would have thought that we were describing things to the point of the pins coming out of the PLD, not past whatever splitting comes after that. I'm also confused how this would work. You're talking about the DT looking like: clcd at 10020000 { compatible = "arm,pl111", "arm,primecell"; reg = <0x10020000 0x1000>; interrupt-names = "combined"; interrupts = <0 44 4>; clocks = <&oscclk1>, <&oscclk2>; clock-names = "clcdclk", "apb_pclk"; max-memory-bandwidth = <94371840>; /* Bps, 1024x768 at 60 16bpp */ port { dac_pads: endpoint1 { remote-endpoint = <&vgadac>; arm,pl11x,tft-r0g0b0-pads = <0 8 16>; }; tft_pads: endpoint2 { remote-endpoint = <&tftpanel>; arm,pl11x,tft-r0g0b0-pads = <0 8 16>; }; }; }; Are you anticipating that a DT would actually connect up to two endpoints on the CLCD? How should we resolve the pads property, in that case? Is there much point in supporting this, if we don't actually support panels or bridges on both of the endpoints at once (since we pick only one to do panel/bridge setup/teardown on)? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH 4/4] drm/pl111: Support multiple endpoints on the CLCD Date: Mon, 29 Jan 2018 15:55:41 -0800 Message-ID: <87wp00w77m.fsf@anholt.net> References: <20180126132033.19744-1-linus.walleij@linaro.org> <20180126132033.19744-4-linus.walleij@linaro.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0868189857==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id EE77C6E015 for ; Tue, 30 Jan 2018 04:27:15 +0000 (UTC) In-Reply-To: <20180126132033.19744-4-linus.walleij@linaro.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Linus Walleij , Daniel Vetter , Jani Nikula , Sean Paul Cc: linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0868189857== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Linus Walleij writes: > The Versatile PL110 implementations use multiple endpoints: > from the PL111 port, the lines are routed through a PLD, > and from there forked so the same lines go to a VGA DAC and > an external TFT panel connector. This is discrete wireing > so there is no way to turn of one output, i.e. this is > really two endpoints, not two ports. > > We model this with multiple endpoints, so we need to loop > over the available endpoints, check for panel or bridge on > each and accumulate the result before continuing. > > The code already will give the panel preference over the > bridge, if present, so the output will be sent to the panel > if both a panel and a bridge is present on two endpoints > of the same port. > > If they all return -EPROBE_DEFER we return -EPROBE_DEFER > as well. > > If just one endpoint is present on the port, the behaviour > is the same as before. > > Signed-off-by: Linus Walleij Huh, from the binding I would have thought that we were describing things to the point of the pins coming out of the PLD, not past whatever splitting comes after that. I'm also confused how this would work. You're talking about the DT looking like: clcd@10020000 { compatible = "arm,pl111", "arm,primecell"; reg = <0x10020000 0x1000>; interrupt-names = "combined"; interrupts = <0 44 4>; clocks = <&oscclk1>, <&oscclk2>; clock-names = "clcdclk", "apb_pclk"; max-memory-bandwidth = <94371840>; /* Bps, 1024x768@60 16bpp */ port { dac_pads: endpoint1 { remote-endpoint = <&vgadac>; arm,pl11x,tft-r0g0b0-pads = <0 8 16>; }; tft_pads: endpoint2 { remote-endpoint = <&tftpanel>; arm,pl11x,tft-r0g0b0-pads = <0 8 16>; }; }; }; Are you anticipating that a DT would actually connect up to two endpoints on the CLCD? How should we resolve the pads property, in that case? Is there much point in supporting this, if we don't actually support panels or bridges on both of the endpoints at once (since we pick only one to do panel/bridge setup/teardown on)? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlpvtH0ACgkQtdYpNtH8 nuhclg//ZrhBg6m2Rrly2z5r5ctWPGIGqfPW/ZGVsGeQy17ADPFiqg/a+q5lrzj7 JRb0u5dYStjt9YVGH/t/Ph7EaNbZnJgPKt8SmY7hC84t0AtwXn0QRVhMhbdNyat4 JIeavcHlHYmXu0/gbIej3rKSru5yingHw9+Co08yUm+vmWUs68oFFL156U87K1uw AujeARutjChg4+8O0PcmdRgUPBuMl0FCFXkmO9tBY1V5+nkSzKQE6pdqKnuXeDpt AVbc0ZeL6auAOXVSpty296+PB7MSAVyldxYCWie838lwTjjLp4gKHyywK8P5Twhv v1Js+/Oo3lRhY4I9ZgQk2o1HlN4PXikgkivWVfP/frAsoDTZ92l/kvjmiC59GSeD hIUFcyiO166vgGVhFCO4UqA7Gtov2LhvdNTnqoVERW4yO23wEPQSUziZEFyXjBKI ZGBMb/aU+InpReh9Yn5VDAD23l24m/E6GPIxzXXFYyv5YwLSeU0CY/Tum8+apVRQ mgh96iWdsuUw4cef/xU55Dydb8hLr7a90v0hd9FdOqrZo2DJ06LeTZntFihlCyK9 9WHU6OucmCDt4lStj6KOvmUJgjQJPiwVpzPCZEPDW5JK6igp32aZ9Uj3+t1YZZ7X /rQaMtfGz84F7bPhK05xeHHS7OSrVnUwfxp4SFZtRLEblOGxxws= =k7ep -----END PGP SIGNATURE----- --=-=-=-- --===============0868189857== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0868189857==--