http://bugzilla.kernel.org/show_bug.cgi?id=6072
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
------- Additional Comments From [EMAIL PROTECTED] 2006-05-21 21:01 -------
Yes, 2.6.17-rc4-git6 is speaker mute after s2ram, only headphone out available.
Reading the actual chip markings of the southbridge reveals it to be a VT8235
and I've managed to hunt down the full datasheet.
As can be seen in my original pci-dumps 00:11.5 (audio) has been initialized to
C1 at offset 41 [AC Link Interface Control] after boot - without alsa loaded.
Offset 40 [AC Link Interface Status] is a read-only register and showing 05.
This means:
_Offset 40 (bit 0->7 order) RO_
1 = Codec CID=00b -- ready (audio ctrlr can access codec)
0 = Low-Power Status -- AC97 Codecs not in low-power mode
1 = Codec CID=01b -- ready (...)
0 = Reserved
0 = Codec CID=10b -- not ready
0 = Codec CID=11b -- not ready
0 = Reserved
0 = Reserved
_Offset 41 (bit 0->7 order) RW_
1 = Reserved (datasheet wrongly claims it to always read 0 - it's always 1 here)
0 = Reserved
0 = 3D Audio Channel Slots 3/4 -- disabled (default)
0 = Variable-Sample-Rate On-Demand Mode -- disabled (default)
0 = AC-Link Serial Data Out -- Release SDO (default)
0 = AC-Link Sync -- Release SYNC (default)
1 = AC-Link Reset -- De-assert AC-Link Reset (not default)
1 = AC-Link Interface -- Enable (not default)
So when offset 40 turns up as 00 and offset 41 as 01 after a resume from s2ram
it clearly reveals that someone/something has turned off the whole AC-Link.
When alsa is loaded at boot, offset 41 is a CD instead of C1 - meaning that 3D
audio channel and variable sample rate has been enabled. Doing a s2ram and
resume from this stage, the audio registers come up unchanged (ie 05cd). So
alsa(?) ensures the state to be unaltered.
>From a speaker-mute situation I've unloaded alsa and written to offset 41, but
neither ED (warm reset) nor 8D (cold reset) could restore the speakers when alsa
got loaded again.
The recently filed bug 6575 "sound only through headphones when acpi turned on"
also hints towards acpi pulling nasty tricks. So, David (comment #6 ) I do
believe this bugreport to belong here.
I've looked at all the other PCI registers that change after a s2ram, but
nothing else seem to be related. They are perfectly natural things like "PCI PNP
Interrupt routing" and "GP3 Timer" etc.
Pavel, is NEEDINFO satisfied? I'll try to flip it back to NEW... unsure about
the finer points of bugzilla reporting, I am.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
