Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759506AbYGAPQx (ORCPT ); Tue, 1 Jul 2008 11:16:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754944AbYGAPQp (ORCPT ); Tue, 1 Jul 2008 11:16:45 -0400 Received: from ns.suse.de ([195.135.220.2]:42585 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753361AbYGAPQo (ORCPT ); Tue, 1 Jul 2008 11:16:44 -0400 Date: Tue, 01 Jul 2008 17:16:43 +0200 Message-ID: From: Takashi Iwai To: Johannes Weiner Cc: Mathieu Chouquet-Stringer , Jaroslav Kysela , linux-kernel@vger.kernel.org Subject: Re: Longstanding bug in ac97/intel8x0 resume/init In-Reply-To: <87fxqt4p19.fsf@skyscraper.fehenstaub.lan> References: <87hcca3xkx.fsf@saeurebad.de> <8763rsa5qk.fsf@skyscraper.fehenstaub.lan> <87k5g54qmh.fsf@skyscraper.fehenstaub.lan> <87fxqt4p19.fsf@skyscraper.fehenstaub.lan> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.2 (x86_64-suse-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3447 Lines: 92 At Tue, 01 Jul 2008 17:12:02 +0200, Johannes Weiner wrote: > > Hi, > > Takashi Iwai writes: > > > At Tue, 01 Jul 2008 16:37:42 +0200, > > Johannes Weiner wrote: > >> > >> Hi, > >> > >> Takashi Iwai writes: > >> > >> > At 30 Jun 2008 20:58:03 +0200, > >> > Mathieu Chouquet-Stringer wrote: > >> >> > >> >> Hey there, > >> >> > >> >> hannes@saeurebad.de (Johannes Weiner) writes: > >> >> > Johannes Weiner 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. > > Okay. > > >> 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? > > What means `element' here? I have to touch MASTER and PCM in order to > get some output again, at least ;) Well, for example, some laptops with maestro3 have a similar problem, but in that case, you just need to touch one mixer element (e.g. Master), and you don't have to re-adjust PCM volume. > >> >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. > > By experimentation I found that the writeback works with a two seconds > delay before writeback. I can't remember if it was before or after the > check. Another approach was to hammer down the value by writing and > reading back in a loop until the hardware responded with the correct > value. > > I will redo the tests later and report back to you what helped. Yeah, that'll be appreciated. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/