Bug 6181

Ah, this is exactly as my bug 6072 with the snd_via82xx driver (and even without
it). At the report time I didn't have any headphones. Plugging in a nice set,
the sound does indeed come out there, even though the Headphone entry in
alsamixer is MM (muted).

I'm so happy about this progress :-) Gives a datapoint at least.

Here's a diff before and after s2ram of the sound chip registers:

--- via-01-ac97#0-0+regs        2006-03-09 00:44:36.000000000 +0100
+++ via-02-ac97#0-0+regs        2006-03-09 00:44:36.000000000 +0100
@@ -45,8 +45,8 @@
 0:58 = 0000
 0:5a = 8230
 0:5c = 0018
-0:5e = 0008
-0:60 = ffff
+0:5e = 0000
+0:60 = 0000
 0:62 = 0000
 0:64 = 0000
 0:66 = 0000

The 5e entry changes whenever I play something, also after resume, but 60
remains zeroed. And a "echo 60 ffff >
/proc/asound/card0/codec97#0/ac97#0-0+regs" does nothing. Neither 'echo "60
ffff"', and yes, I do have CONFIG_SND_DEBUG enabled.

Uploading the resulting info files:

Created attachment 7535 [details]
via-ac97#0-0

via-ac97#0-0 Before and after s2ram is unchanged.

Created attachment 7536 [details]
via-01-ac97#0-0+regs

via-01-ac97#0-0+regs Before s2ram.

Created attachment 7537 [details]
via-02-ac97#0-0+regs

via-02-ac97#0-0+regs After s2ram.

I have this in dmesg on return from suspend.
The code around it has a FIXME so it is probably not entirely unexpected behaviour

 AC'97 0 analog subsections not ready

it looks for 0x0F in register 0x26 (powerdown) and times out if the four bits
there are not 1 meaning subsytem ready. However when I check through /proc after
resume it is set to 0x0F.
other than that my registers look the same before and after resume. Sometimes reg
72 has the jack input bit set even that is not plugged in but that's all.

I had to cat /proc/asound/card0/codec97#0/ac97#0-0+regs twice after a resume to
see the altered regs. First cat was exactly as before suspend - like some kind
of cache ghost remaining on disk or in memory.

I'll be out at least six hours from now, should someone expect me available.

I have a HP nw8240, which I think is similar model in respect of which this bug
was submitted. The symptoms are the same: after suspend to ram, the internal
speakers do not work and cannot be made to work again without a reboot--but the
rest of the sound system is ok. I am not sure but I guess that the cause of my
problem is similar. I would appreciate it if anyone who does have this specific
problem could get in touch with me so we could diagnose it more easily. Here is
what I wrote about the problem on the ubuntu bug tracker:

I checked the hardware on my HP nw8240 laptop and the problem occurs because
after suspend to RAM, the 5V power supply to the audio power amp IC is turned
off. This is *not* controlled by the amplifier power down pin of the AC97 codec
as would usually be the case, so nothing you can do with the AC97 will fix the
problem. Indeed, all the AC97 registers are the same before and after suspend.
The audio controller PCI configuration space registers are also the same.

Clearly, the nw8240 (and maybe other HP laptops) control the audio power amp
power supply from somewhere else. I couldn't figure out physically where the
signal comes from on the motherboard. I guess it has to do with the ACPI
subsystem and the embedded controller-- but as I don't know much about this I am
not able to debug it. I am not even sure whether the embedded controller is part
of the Intel chipset, or a separate chip. I did play around with an adapted
version of the kernel ibm_acpi module's ecdump utility to read and modify the
embedded controller registers--but the best I could do by randomly tweaking the
registers was crash my machine. Maybe someone who knows a bit about ACPI could
suggest some productive ways of mapping out the hardware? Presumably other
special features of the laptop, like the shock sensor, could also be accessed
through ACPI if this could be figured out.

It is important to note that this issue is almost certainly HP-specific and not
related to the numerous other "no sound after resume" issues that people have,
which are fixable by simply setting the AC97 codec registers correctly.

It would be great if someone who is interested in this issue and knows something
about ACPI and/or HP laptops could contact me so we could diagnose it. You can
contact me on mb@gem.win.co.nz

Is the problem still there in 2.6.18?

I consider this bug as a duplicate of Bug #7236.  Whoever can mark that, please
do so.

*** This bug has been marked as a duplicate of 7236 ***

This is NOT a duplicate of 7236 - 7236 describes a totally different problem on
different hardware.

On HP laptops it appears that the internal amplifier is not powered after resume
from suspend-to-RAM, see here:

https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/21574

This is quite different from the issue described in 7236 - in this bug we cannot
get the internal speakers to work at all; 7236 describes a problem where the
internal speakers are completely functional but not muted.  Clearly in 7236 the
amp has power post-resume so we are dealing with a different issue.

There are some suspend fixes for that driver in 2.6.19-rc...

I hope this wasn't closed because of what I said...  I don't actually experience
the bug so I can't confirm or deny that the patches actually fixed the problem.
 I was just saying that there were some patches merged that might make a
difference.  

Sorry for the misunderstanding if that wasn't clear.

Created attachment 10623 [details]
avoid regression

I have this exact same behaviour on an hp nw8000, but my speakers have worked
fine from 2.6.16ish up to 2.6.18, and then broke between 2.6.19-rc2 and -rc3.
git-bisect showed that the commit 30b35399ceb2398d05837863476dcb12f12f3a82 was
the one that triggers it.

And as far as I can tell it's broken up to 2.6.20 and may or may not have been
fixed after that, because for me the mainline is busted since 2.6.21-rcX, it
won't wake up from suspend at all.

Attached patch avoids the regression caused by the said commit for 2.6.19 and
up, but obviously is not an actual fix for the problem.

If pci_set_power_state() is the cause, I suppose it's a missing piece in the PCI
core part.

Anyway, I'm not strongly against this workaround, but I'd rather comment out the
line (with some description), instead of removing it.  Will be committed to ALSA
tree soon.

Takashi, actually I think you should be strongly against it. I never meant it
for inclusion anywhere. I'm obviously hoping to get the thing fixed but not with
that patch.

Nevermind it fixes one odd laptop, the problem in any case is elsewhere and that
patch only tries to shed some light on that.  Besides, removing ok code to
get-by with quirky hardware is not something I want to advocate for.

Let's not haste into anything, eh?

It's awfully hard to find information and/or other reports about this issue,
because there have ac97 related issues recently that caused similar symptoms.
But I'll keep going at it.