Re: [PATCH 3/3] tda998x: add HPD delay to avoid disabling sound when EDID checksum fails.
From: Russell King - ARM Linux
Date: Wed Jun 01 2016 - 12:32:45 EST
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.
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
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.