Re: [PATCH 2/3] drm/i915: Reinitialize sink scrambling/TMDS clock ratio on HPD

["Sharma, Shashank" <shashank.sharma@intel.com>]

Regards

Shashank


On 1/10/2018 9:53 PM, Ville Syrjälä wrote:
> On Wed, Jan 10, 2018 at 10:07:43AM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 1/9/2018 11:31 PM, Ville Syrjälä wrote:
>>> On Thu, Dec 28, 2017 at 08:32:05PM +0530, Sharma, Shashank wrote:
>>>> On 12/22/2017 11:58 PM, Ville Syrjala wrote:
>>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>
>>>>> The LG 4k TV I have doesn't deassert HPD when I turn the TV off, but
>>>>> when I turn it back on it will pulse the HPD line. By that time it has
>>>>> forgotten everything we told it about scrambling and the clock ratio.
>>>>> Hence if we want to get a picture out if it again we have to tell it
>>>>> whether we're currently sending scrambled data or not. Implement
>>>>> that via the encoder->post_hotplug() hook.
>>>> I am not sure if I understood the problem statement correctly. Even if
>>>> the TV triggers HPD line while turning it back, I would expect:
>>>> - EDID read for TV's detection, which will refresh SCDC and scrambling
>>>> capabilities
>>>> - A new modeset will be triggered, which will program the scrambling and
>>>> high tmds clock ratio again
>>>> - Once HDMI controller is programmed, it will generate scrambled signals
>>>> till next modeset / disable.
>>>>
>>>> So why do we need to do this ? I might be missing something, but lets
>>>> discus about it.
>>> The EDID is readable even when the HPD gets deasserted for a short
>>> perios, hence we never consider the sink as being disconnected. Hence
>>> there will be no modeset triggered by userspace.
>> This is a bigger problem then, in that case, the pipe/port would be
>> enabled, and IMHO I don't think fixing just the scrambling status is
>> right thing to do.
> Hmm. The spec does say "the Source shall not begin transmission of a
> scrambled video signal before writing a 1 to the Scrambling_Enable bit".
> So I guess you're right. We can't follow that rule 100% though because
> we can't detect that the the sink has been turned off.
>
> If we checked the live hpd status during hpd processing we should be
> able to detect that the sink was logically disconnected for a short
> period, but as we know the live hpd status is not exactly reliable
> for HDMI. Also that would still be racy on account of hpd processing
> delays.
Agree. This inaccuracy of Live status HW has been a nightmare for us 
since a long time,
it really cripples proper hotplug handling.
>
> When talking about the TMDS clock ratio the spec says that we have to
> suspend TMDS clock/data transmission when we change the TMDS clock ratio
> setting in the sink.
>
> So I guess what we could do is force a full modeset if and when the sink
> has become confused about these settings. Or if we want to optimize
> things a bit I suppose we could just turn off DDI_BUF_CTL around the
> operation. But probably no point in optimizing that part since it's a
> rare event.
Agree, again. Also it would be difficult to detect exactly when do we 
have a genuine confusion :-)

- Shashank
>
>> Also, is this the right behavior from the monitor ? I am also worried if
>> we are trying to fix the monitor's fault in our driver.
> I don't think that's specified anywhere. Also doesn't matter because we
> have to fix sink specific issues in the driver all the time. Otherwise
> a lot of sinks would just fail to work.
>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx