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

[Jose Abreu]

Hi Daniel,


On 06-12-2016 08:23, Daniel Vetter wrote:
> 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 HDMI this is done in the I2C line. When the sink wants the
source attention it pulses the SDA low when the bus is free. This
should be correctly handled by the I2C controller that is
connected or included in the HDMI controller.

> 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

Best regards,
Jose Miguel Abreu