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

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

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.

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.

> 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.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx