[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

[Daniel Vetter]

On Mon, Dec 05, 2016 at 05:37:22PM +0100, Thierry Reding wrote:
> 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
> 	   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.

So no idea how this works, but how is a read request signalled? On the DP
side there's just a short pulse hpd when the sink wants the source's
attention. And iirc hdcp uses similar tricks when e.g. a downstream device
has changed. We don't yet have it for DP, but some helper to handle hdp
interrupts with a parameter to indicate long/short pulse is probably all
that's really needed. But we don't yet have that for DP either :(
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch