From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection Date: Mon, 5 Dec 2016 17:37:22 +0100 Message-ID: <20161205163722.GB21732@ulmo.ba.sec> References: <20161202192415.16110-1-thierry.reding@gmail.com> <20161202192415.16110-3-thierry.reding@gmail.com> <2c9513c5-2b71-e786-f202-eb1acc027578@synopsys.com> <20161205111456.GD19891@ulmo.ba.sec> <8dc4f5e4-37bf-6eda-390a-b31016149cb8@synopsys.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2060088196==" Return-path: Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3AC606E18C for ; Mon, 5 Dec 2016 16:37:27 +0000 (UTC) Received: by mail-wm0-x243.google.com with SMTP id m203so16907230wma.3 for ; Mon, 05 Dec 2016 08:37:27 -0800 (PST) In-Reply-To: <8dc4f5e4-37bf-6eda-390a-b31016149cb8@synopsys.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Jose Abreu Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============2060088196== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CUfgB8w4ZwR/yMy5" Content-Disposition: inline --CUfgB8w4ZwR/yMy5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 05, 2016 at 02:19:48PM +0000, Jose Abreu wrote: > Hi Thierry, >=20 >=20 > On 05-12-2016 11:14, Thierry Reding wrote: > > On Mon, Dec 05, 2016 at 11:06:15AM +0000, Jose Abreu wrote: > >> Hi Thierry, > >> > >> > >> Do you think while you are at it you could implement a > >> set_scrambling() callback? It should be pretty straight forward: > >> you read the SCDC_TMDS_CONFIG reg, do a mask, and then write it > >> again. > >> > >> > >> I think this is an important feature that we should have. > > Yeah, agreed. I was actually thinking about going one step further and > > provide more of the polling functionality as a helper. Even if we have > > accessors that wrap the low-level functionality, most drivers would > > still have to provide their own delayed workqueue to deal with sinks > > (or sources) that don't support read requests. Having this in standard > > helpers would help reduce the boilerplate a lot further. > > > > Does your hardware by any chance support read requests on SCDC? It'd be > > interesting to see how that works in practice. Unfortunately Tegra does > > not seem to support it. > > > > Thierry >=20 > Yes, my HW supports it though I don't have the setup here to test > right now (but it was used before). In our controller it is > pretty straight forward: > 1) Enable interrupt for rr indication [source] > 2) Enable update read on a rr [source] > 3) Set rr flag in the sink [sink] >=20 > Point 2) makes it clear: Whenever we get a rr then the source > will automatically read the sink and dump the contents read in > the regbank. Then the SW gets an interrupt and it should read the > contents of the registers. Yes, I suspect that there will be three types of setups: 1) fully supported and integrated RR capability (such as in your case) 2) external I2C controller with the means of detecting the read request (and signal via an interrupt) 3) no read request support at all, in which case a delayed work queue is needed to poll periodically For cases 1) and 3) it's probably only useful to have a helper to enable scrambling. For 2) there might be some use in having a helper that can setup the delayed work queue. Given that we don't have any implementation yet, maybe it's better to defer the creation of helpers until we see common patterns emerge. The helper to enable scrambling could be useful in any case, though, so I'll add one. Thierry --CUfgB8w4ZwR/yMy5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCAAGBQJYRZfCAAoJEN0jrNd/PrOh2xMP/RZb3OKYr9P1Tc+l+8E91otG z16VgukDqYD8KOG9/0LZgYS7hEX6NWZKru476iqlr03VPn/m2xRXJRO9NYpiDdEZ vMoo40eRsHg1qUsCe+qXRM7IpU1DIWrjJXsGi7mcZ8DTZ4tx5hpyTr9G7FvcIdM7 VPbf1F8RFR4FmlIZVJ1kzsRt+pTM0X2KBcO1OapFLg+47i+8bjd3DaBQCfRcyITx da9TLb8stkKTw+WGXLq+v1zk80hqG5VHviPFyNUxNCuZ9QQiQSqRLbHRu3F+iOhK 6W5Oxz5Fuq6fOYYYtd3uFmitOa9GbXuMcZOSNjrwEMxIkfqr2SCG3umF7RnJTs3S 1dufRijJRBo2KR9yQSbvmjf6X8sXizFlB7StYUuLjUe7N15qFt7O7S61t54x5adx 0rfhRWPJoIfp2Wt33SXIMKNbRyDzKNln8tz32R/VKT3YxRVRKdoOrUvQeLHdQ4/g C9xu1PQSHIR9w5kIkFxA1jm18XFvjptp3K5YTRRV1wj6RShnwsokGZPeejtBczmO pnqBbO/MXSyQp/sv/Nt794ZmWdetE5m5qMbImCP8JL74CHKb0VRci0PyaTUtxTN9 CiUhvnXGbE//JUegZc1FE7SyvYXENSnHHea0l4OC9ismv6vVBCtRtzs6hLLUEG8N C7b+8eKjK2SoJ28W9UxZ =KmPC -----END PGP SIGNATURE----- --CUfgB8w4ZwR/yMy5-- --===============2060088196== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============2060088196==--