Re: [PATCH 3/3] tda998x: add HPD delay to avoid disabling sound when EDID checksum fails.

[Russell King - ARM Linux <linux@armlinux.org.uk>]

On Tue, May 31, 2016 at 05:58:31PM +0100, Joao Pinto wrote:
> Hi Russell,
> 
> On 5/30/2016 8:10 PM, Russell King - ARM Linux wrote:
> > On Mon, May 30, 2016 at 04:15:54PM +0100, Joao Pinto wrote:
> >> When using ffplay to reproduce video+sound it was noticed that sometimes the
> >> sound was disabled. The cause was an initial EDID checksum error that disabled
> 
> (...)
> 
> >> @@ -1313,6 +1324,7 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv)
> >>  
> >>  		/* init read EDID waitqueue and HDP work */
> >>  		init_waitqueue_head(&priv->wq_edid);
> >> +		INIT_DELAYED_WORK(&priv->dwork, tda998x_hpd);
> >>  
> >>  		/* clear pending interrupts */
> >>  		reg_read(priv, REG_INT_FLAGS_0);
> > 
> > Clearly, this patch is incomplete.  There's nothing that schedules this
> > work to be run.
> 
> You are right, forgot to include the schedule in the patch!
> 
> > 
> > In any case, this is reintroducing the code which I deleted when I fixed
> > the (rather crappy) previous implemention of delaying the EDID read after
> > a hotplug event.  You should not need this patch.
> > 
> 
> If a checksum validation fails the video reproduction is done muted if
> you use a simple app like ffplay. This does not happen if using mplayer.

So?

We already delay the EDID read to work around reading a corrupted EDID.
If you need an additional delay, then it seems that the existing delay
is not long enough, and maybe we should extend it a little more.

What we should not do is to delay the HPD signalling.  That is definitely
the wrong solution.

In any case, I'm having a hard time understanding what the problem here
is.  You've unplugged the connected HDMI sink, so there's no longer a
display device connected, and the display hardware is shut down.  The
EDID becomes invalid.  You then plug in a HDMI sink, and now you have a
display device connected.  The EDID is read, and the display hardware is
configured according to the EDID details.  Video output is resumed, and
it takes a second or so for the sink to lock on and display the resulting
video.

At what point does the problem occur?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.