More on the intel8x0 resume problems.

More on the intel8x0 resume problems.

[Itay Ben-Yaacov]

As I reported earlier, intel8x0 fails to resume properly on my Dell I8200 with alsa >= 0.9.7

This is due to the fact that snd_intel8x0_ich_chip_init() no longer waits that extra 1/4 second it
used to in 0.9.6 and ealier.  It seems to believe that all the codecs are ready, but apparently
they are not.

I tried to look into this a bit further and found that:
In intel8x0_resume() there are two ac97 codecs actually resumed on my machine (I suppose that
these are precisely the primary and secondary ones that snd_intel8x0_ich_chip_init() has waited
for already), indexed 0 and 1.

When resuming ac97 no. 0, in snd_ac97_resume() there are quite a few registers that do not get set
properly.  For example, here's a bit of my debugging messages: 

Nov 18 23:58:24 pisica kernel: PEZZ: bad register 2: c0c 8000
Nov 18 23:58:24 pisica kernel: PEZZ: bad register 6: 801f 8000
Nov 18 23:58:24 pisica kernel: PEZZ: bad register a: 801e 0
Nov 18 23:58:24 pisica kernel: PEZZ: bad register c: 801f 8008
Nov 18 23:58:24 pisica kernel: PEZZ: bad register e: 801f 8008
Nov 18 23:58:24 pisica kernel: PEZZ: bad register 10: 9f1f 8808
Nov 18 23:58:24 pisica kernel: PEZZ: bad register 12: 9f1f 8808
Nov 18 23:58:24 pisica kernel: PEZZ: bad register 14: 9f1f 8808
Nov 18 23:58:24 pisica kernel: PEZZ: bad register 16: 9f1f 8808
Nov 18 23:58:24 pisica kernel: PEZZ: bad register 18: 1010 8808
Nov 18 23:58:24 pisica kernel: PEZZ: bad register 1c: 0 8000
Nov 18 23:58:24 pisica kernel: PEZZ: bad register 1e: 0 8000

The first value is the one read from the register after writing into it, the second is what was
written.

On the other hand, if I just add a hard-coded 1/4 second wait before snd_ac97_resume(), emulating
the good old days, I only get:

Nov 19 00:00:26 pisica kernel: PEZZ: bad register 2a: 9 209

And the sound resumes fine.

The other ac97, indexed 1, seems to be indifferent to whether I resume it with or without such a
delay.

So I believe the problem is that codec no. 0 is not waited for properly, even though it reports to
be ready... Could that be?

Please help me out here.

Thanks,
Itay

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: More on the intel8x0 resume problems.

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]

At Tue, 18 Nov 2003 21:16:44 -0800 (PST),
Itay Ben-Yaacov wrote:
> 
> 
> As I reported earlier, intel8x0 fails to resume properly on my Dell I8200 with alsa >= 0.9.7
> 
> This is due to the fact that snd_intel8x0_ich_chip_init() no longer waits that extra 1/4 second it
> used to in 0.9.6 and ealier.  It seems to believe that all the codecs are ready, but apparently
> they are not.
> 
> I tried to look into this a bit further and found that:
> In intel8x0_resume() there are two ac97 codecs actually resumed on my machine (I suppose that
> these are precisely the primary and secondary ones that snd_intel8x0_ich_chip_init() has waited
> for already), indexed 0 and 1.
> 
> When resuming ac97 no. 0, in snd_ac97_resume() there are quite a few registers that do not get set
> properly.  For example, here's a bit of my debugging messages: 
> 
> Nov 18 23:58:24 pisica kernel: PEZZ: bad register 2: c0c 8000
> Nov 18 23:58:24 pisica kernel: PEZZ: bad register 6: 801f 8000
> Nov 18 23:58:24 pisica kernel: PEZZ: bad register a: 801e 0
> Nov 18 23:58:24 pisica kernel: PEZZ: bad register c: 801f 8008
> Nov 18 23:58:24 pisica kernel: PEZZ: bad register e: 801f 8008
> Nov 18 23:58:24 pisica kernel: PEZZ: bad register 10: 9f1f 8808
> Nov 18 23:58:24 pisica kernel: PEZZ: bad register 12: 9f1f 8808
> Nov 18 23:58:24 pisica kernel: PEZZ: bad register 14: 9f1f 8808
> Nov 18 23:58:24 pisica kernel: PEZZ: bad register 16: 9f1f 8808
> Nov 18 23:58:24 pisica kernel: PEZZ: bad register 18: 1010 8808
> Nov 18 23:58:24 pisica kernel: PEZZ: bad register 1c: 0 8000
> Nov 18 23:58:24 pisica kernel: PEZZ: bad register 1e: 0 8000
> 
> The first value is the one read from the register after writing into it, the second is what was
> written.

hmm, i guess in reverse, the left is the value written and the right
is the value read ?

> 
> On the other hand, if I just add a hard-coded 1/4 second wait before snd_ac97_resume(), emulating
> the good old days, I only get:
> 
> Nov 19 00:00:26 pisica kernel: PEZZ: bad register 2a: 9 209
> 
> And the sound resumes fine.
> 
> The other ac97, indexed 1, seems to be indifferent to whether I resume it with or without such a
> delay.
> 
> So I believe the problem is that codec no. 0 is not waited for properly, even though it reports to
> be ready... Could that be?

yes, it's likely.
could you try the attached patch?
it's to cvs but of course applicable to the new 1.0.0-pre1, too.

also, i'd like to ask you to test 1.0.0-pre1, because we have clean up
the handling of multiple codecs of intel8x0 driver, but it's not
tested well.  please check whether it works for you.


thanks,

Takashi

[-- Attachment #2: ad18xx-resume-fix.dif --]
[-- Type: application/octet-stream, Size: 1042 bytes --]

Index: alsa-kernel/pci/ac97/ac97_codec.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/pci/ac97/ac97_codec.c,v
retrieving revision 1.100
diff -u -r1.100 ac97_codec.c
--- alsa-kernel/pci/ac97/ac97_codec.c	10 Nov 2003 17:35:18 -0000	1.100
+++ alsa-kernel/pci/ac97/ac97_codec.c	19 Nov 2003 11:05:20 -0000
@@ -2088,9 +2088,9 @@
 	snd_ac97_write(ac97, AC97_GENERAL_PURPOSE, 0);
 
 	snd_ac97_write(ac97, AC97_POWERDOWN, ac97->regs[AC97_POWERDOWN]);
-	snd_ac97_write(ac97, AC97_MASTER, 0x8000);
+	snd_ac97_write(ac97, AC97_MASTER, 0x8101);
 	for (i = 0; i < 10; i++) {
-		if (snd_ac97_read(ac97, AC97_MASTER) == 0x8000)
+		if (snd_ac97_read(ac97, AC97_MASTER) == 0x8101)
 			break;
 		mdelay(1);
 	}
@@ -2099,7 +2099,7 @@
 	if (ac97->bus->init)
 		ac97->bus->init(ac97);
 
-	is_ad18xx = (ac97->id & 0xffffff40) == AC97_ID_AD1881;
+	is_ad18xx = (ac97->flags & AC97_AD_MULTI);
 	if (is_ad18xx) {
 		/* restore the AD18xx codec configurations */
 		for (codec = 0; codec < 3; codec++) {

Re: More on the intel8x0 resume problems.

[Itay Ben-Yaacov]

OK, I tested 1.0.0pre1, and it seems to solve the problem.  I think
I'll just stick with that.  Thanks.
                                                                                
BTW, the sound corruption on lost interrupts bug is still present
there -- any chances to get some tips on how to debug that one out?
                                                                                
                                                                                
Thanks,
Itay

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/