Re: Longstanding bug in ac97/intel8x0 resume/init

[Takashi Iwai]

At Tue, 01 Jul 2008 16:37:42 +0200,
Johannes Weiner wrote:
> 
> Hi,
> 
> Takashi Iwai <tiwai@xxxxxxx> writes:
> 
> > At 30 Jun 2008 20:58:03 +0200,
> > Mathieu Chouquet-Stringer wrote:
> >> 
> >>         Hey there,
> >> 
> >> hannes@xxxxxxxxxxxx (Johannes Weiner) writes:
> >> > Johannes Weiner <hannes@xxxxxxxxxxxx> writes:
> >> > > my laptop has muted sound after resuming the soundcard (by
> >> > > s2ram/hibernation).  The problem seems to be that the cached register
> >> > > values are not written back to the device properly.
> >> 
> >> I've got the same exact issue on a Thinkpad T30:
> >> 
> >>  0 [I82801CAICH3   ]: ICH - Intel 82801CA-ICH3
> >>                       Intel 82801CA-ICH3 with AD1881A at irq 5
> >> 
> >> 00:1f.5 Multimedia audio controller: Intel Corporation 82801CA/CAM AC'97 Audio Controller (rev 02)
> >
> > Does this happen for both hibernation and S2RAM?
> > And, resetting the mixer repairs the mute state, right?
> > If yes, the problem appears independently from the codec chip.  Hmm...
> 
> Yes, happens in both cases here.
> 
> The alsamixer shows the state of the channels before the suspension(!).

Yes.  The driver returns the cached values.

> If I change the channel state, the sound works again.  No complete reset
> needed at all, I just have to increase/decrease the value a bit (for
> each affected channel).

Just touching one mixer element?

> >From my experiments with the code, I figured that the cached register
> values are not written back properly on resume.  The cache is in the
> correct state but the hardware is not.  This also explains the behaviour
> when changing the channels with alsamixer; the register cache is touched
> and written back (and this time, the value really gets through to the
> hardware).

Right.  

snd_ac97_resume() has a check whether the write to MASTER register
succeeds, but its timeout is 100ms.  Could you check whether this
check passes at resume or failed?  I remember that some device
actually passed the test but didn't update the real hardware state.
If it failed on yours, we may simply extend the timeout, or make it
pending somehow.  If the hardware fools us, however, it'd be toucher.


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/