[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection
thierry.reding at gmail.com
Mon Dec 5 16:37:22 UTC 2016
On Mon, Dec 05, 2016 at 02:19:48PM +0000, Jose Abreu wrote:
> Hi Thierry,
> 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
> 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]
> 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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: not available
More information about the dri-devel