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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
