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@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
