Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[albox]

Could this issue be related to the other one with Medion laptops :
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3160
Takashi, you said you were going to check the older patch that was working on
ALSA 1.0.13, did you have a chance to do that ?

Takashi Iwai wrote:
> At Mon, 25 Jun 2007 15:16:41 -0500,
> Matt Mullins wrote:
>> On 6/25/07, Takashi Iwai <tiwai@suse.de> wrote:
>>>> Yes, single_cmd mode is used always.
>>> That's bad.
>> I believe we have established that.  What can I do about it?  *Can* I
>> do anything about it?  What functions should I start debugging?  Has
>> this happened with other codecs before?  What documentation will I
>> need or want other than the Intel HDA and STAC9205 specifications?
>
> Similar problems have been seen in some laptops, too.  I vaguely
> remember that they need some ACPI-related boot options to fix it
> somehow.  I think it's likely irrelevant with the codec chip, but
> rather a problem of the controller side.
>
>> I'm definitely willing to help work on this, as not many people have
>> this hardware.  I'm just new to the sound system, so I'm still trying
>> to figure out what-calls-what.
>
>
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
>

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Takashi Iwai]

At Fri, 29 Jun 2007 08:13:08 +0200,
albox@free.fr wrote:
> 
> Could this issue be related to the other one with Medion laptops :
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3160

I guess it's not.

> Takashi, you said you were going to check the older patch that was working on
> ALSA 1.0.13, did you have a chance to do that ?

Err, no, sorry it's completely out of my head...


Takashi

> Takashi Iwai wrote:
> > At Mon, 25 Jun 2007 15:16:41 -0500,
> > Matt Mullins wrote:
> >> On 6/25/07, Takashi Iwai <tiwai@suse.de> wrote:
> >>>> Yes, single_cmd mode is used always.
> >>> That's bad.
> >> I believe we have established that.  What can I do about it?  *Can* I
> >> do anything about it?  What functions should I start debugging?  Has
> >> this happened with other codecs before?  What documentation will I
> >> need or want other than the Intel HDA and STAC9205 specifications?
> >
> > Similar problems have been seen in some laptops, too.  I vaguely
> > remember that they need some ACPI-related boot options to fix it
> > somehow.  I think it's likely irrelevant with the codec chip, but
> > rather a problem of the controller side.
> >
> >> I'm definitely willing to help work on this, as not many people have
> >> this hardware.  I'm just new to the sound system, so I'm still trying
> >> to figure out what-calls-what.
> >
> >
> > Takashi
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >
> >
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Matt Mullins]

I posted this to the LKML, I thought it should be reproduced on this list.

> > On Sunday, 17 June 2007 03:36, Matt Mullins wrote:
> > > I just received a Dell Latitude D630, with the new Intel Santa Rosa
> > > platform.  Currently, the only major driver issue I have is sound.  It
> > > worked fine in Ubuntu Feisty's 2.6.20 kernel, but now I am using Gutsy
> > > so I can have graphics drivers.  Gutsy's 2.6.22-rc3-based kernel no
> > > longer recognized my soundcard, a Sigmatel STAC9205, which uses the
> > > hda_intel driver.  I have since fixed that problem by compiling the
> > > hda_intel driver into the kernel (I used 2.6.22-rc4 vanilla sources),
> > > instead of a module, but it is still a bug that it does not work as a
> > > module.
> > >
> > > All the following debug information was obtained from kernel 2.6.22-rc4.
> > >
> > > However, the bug that is currently affecting me is that sound no
> > > longer works after using ACPI suspend-to-RAM or swsusp.  I compiled
> > > ALSA debugging in, and as soon as I resume, I get tons of messages
> > > like:
> > > [    8.474830] hda-intel: send_cmd timeout: IRS=0x1, val=0xd0970500
> > > [    8.474954] hda-intel: send_cmd timeout: IRS=0x1, val=0xd0af0009
> > > [    8.475078] hda-intel: send_cmd timeout: IRS=0x1, val=0xd0a70500
> > > [    8.475207] hda-intel: send_cmd timeout: IRS=0x1, val=0xd0bf0009
> > > (etc)
> > >
> > > There may be more before that, but that is more than the kernel
> > > message buffer can hold, so I can't ever see it.  I get similar
> > > timeout messages each time a PCM gets set up:
> > > [    8.972859] hda_codec_setup_stream: NID=0x10, stream=0x5, channel=0, format=0
> > > x11
> > > [    8.972987] hda-intel: send_cmd timeout: IRS=0x1, val=0x1070650
> > > [    9.006071] hda-intel: send_cmd timeout: IRS=0x1, val=0x1020011
> > > [    9.006081] hda_codec_setup_stream: NID=0x11, stream=0x5, channel=0, format=0
> > > x11
> > > [    9.006207] hda-intel: send_cmd timeout: IRS=0x1, val=0x1170650
> > > [    9.016117] hda-intel: send_cmd timeout: IRS=0x1, val=0x1120011
> > >
> > > I read some of sound/pci/hda/hda_intel.c, specifically the code that
> > > output those messages.  After octupling my kernel log buffer (to 1MB),
> > > I noticed that for the first set of timeouts (immediately upon
> > > resume), all the "codec" nibbles are odd, the last word of the val
> > > ("verb" and "para") are all either 0x0500 or 0x0009.  For the second
> > > set (when something tries to use the card) that last word is 0x0650 or
> > > 0x0011.
> > >
> > > I have yet to go back and re-test compiling snd-hda-intel as a module.

On 6/17/07, Matt Mullins <mokomull@gmail.com> wrote:
> I've been reading up on the Intel HD Audio specifications, and I found
> that the problem is most likely that the driver has to resort to PI/O
> (single_cmd) mode.  I really haven't had enough time or experience to
> figure out what is actually causing this.  This is the first time I've
> done any kernel development; thankfully, Intel has good documentation.
>  I'm going to keep hacking to see what information I can figure out.
>
> I just tried 2.6.22-rc5, and no behavior has changed.

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Lee Revell]

On 6/17/07, Matt Mullins <mokomull@gmail.com> wrote:
> > I've been reading up on the Intel HD Audio specifications, and I found
> > that the problem is most likely that the driver has to resort to PI/O
> > (single_cmd) mode.  I really haven't had enough time or experience to
> > figure out what is actually causing this.  This is the first time I've
> > done any kernel development; thankfully, Intel has good documentation.
> >  I'm going to keep hacking to see what information I can figure out.
> >
> > I just tried 2.6.22-rc5, and no behavior has changed.

Please retest with latest ALSA Hg sources.  You will first have to
rebuild the kernel with modular ALSA.

Lee

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Matt Mullins]

Well, that fixed the as-module problem; now snd-hda-intel works as a
module.  However, suspend/resume still doesn't work:
[    7.287540] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:609:
hda-intel: send_cmd timeout: IRS=0x1, val=0x7c2f0009
[    7.287667] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:609:
hda-intel: send_cmd timeout: IRS=0x1, val=0x7c270500
[    7.287795] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:609:
hda-intel: send_cmd timeout: IRS=0x1, val=0x7c3f0009
[    7.287922] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:609:
hda-intel: send_cmd timeout: IRS=0x1, val=0x7c370500
[    7.288049] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:609:
hda-intel: send_cmd timeout: IRS=0x1, val=0x7c4f0009
[    7.288177] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:609:
hda-intel: send_cmd timeout: IRS=0x1, val=0x7c470500
[    7.288304] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:609:
hda-intel: send_cmd timeout: IRS=0x1, val=0x7c5f0009

This can be worked around by removing and reinserting the
snd-hda-intel module.  However, there is still a problem in the PM
code.

- Matt Mullins

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Takashi Iwai]

At Sun, 17 Jun 2007 20:59:14 -0500,
Matt Mullins wrote:
> 
> Well, that fixed the as-module problem; now snd-hda-intel works as a
> module.  However, suspend/resume still doesn't work:
> [    7.287540] ALSA
> /home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:609:
> hda-intel: send_cmd timeout: IRS=0x1, val=0x7c2f0009
> [    7.287667] ALSA
> /home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:609:
> hda-intel: send_cmd timeout: IRS=0x1, val=0x7c270500
> [    7.287795] ALSA
> /home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:609:
> hda-intel: send_cmd timeout: IRS=0x1, val=0x7c3f0009
> [    7.287922] ALSA
> /home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:609:
> hda-intel: send_cmd timeout: IRS=0x1, val=0x7c370500
> [    7.288049] ALSA
> /home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:609:
> hda-intel: send_cmd timeout: IRS=0x1, val=0x7c4f0009
> [    7.288177] ALSA
> /home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:609:
> hda-intel: send_cmd timeout: IRS=0x1, val=0x7c470500
> [    7.288304] ALSA
> /home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:609:
> hda-intel: send_cmd timeout: IRS=0x1, val=0x7c5f0009
> 
> This can be worked around by removing and reinserting the
> snd-hda-intel module.  However, there is still a problem in the PM
> code.

This timeout implies that the communication betweeen the codec and the
controller chips get broken.  The driver itself works fine with many
other devices, so it's likely another problem - in most cases, it's
either an ACPI problem or a conflict with non-working modem codec.   
The latter case is found, for example, on Thinkpad T60/X60.  If you
have a modem codec (see /proc/asound/card0/codec#*), try to exclude
the modem codec via probe_mask module option. 


Takashi

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Takashi Iwai]

[Please don't strip Cc to ML!]

At Tue, 19 Jun 2007 15:54:42 -0500,
Matt Mullins wrote:
> 
> I played around with probe_mask, and found that probe_mask=0x1 causes
> the error, but probe_mask=0x2 does not cause the timeout.  Codec 1 is
> my Sigmatel STAC9205, which is what plays sound on my laptop, and
> codec 2 is my Conexant modem.  The modem isn't the codec causing
> problems; the audio codec is!

OK, good to know.  Does this problem occur with S2D?
What is the very first command that triggers this timeout error?

I'm wondering what is the difference between them -- according to your
report, reloading the module fixes the problem.  But, the resume
callback is almost identical with the re-initiailzation.
Perhaps it's something to do with the power-state management.
What about the patch below?


Takashi

diff -r c531d63e820b sound/pci/hda/hda_intel.c
--- a/sound/pci/hda/hda_intel.c	Wed Jun 20 12:03:09 2007 +0200
+++ b/sound/pci/hda/hda_intel.c	Wed Jun 20 12:09:40 2007 +0200
@@ -1450,7 +1450,7 @@ static int azx_suspend(struct pci_dev *p
 		pci_disable_msi(chip->pci);
 	pci_disable_device(pci);
 	pci_save_state(pci);
-	pci_set_power_state(pci, pci_choose_state(pci, state));
+	/* pci_set_power_state(pci, pci_choose_state(pci, state)); */
 	return 0;
 }

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Matt Mullins]

That doesn't seem to change anything.  Maybe I should have been more
clear: I get the azx_get_response timeouts whenever the driver
initializes; DMA never works for that codec.  single_cmd mode just
happens to work before a suspend, but not after.  In other words,
reloading the module doesn't really fix the problem, it just masks it
decently enough.   I'll work a little bit trying to figure out which
commands cause the timeouts.  And what *is* S2D?

Sorry about not CCing the mailing list, Gmail makes it way too easy to
do that, and too unnoticeable when it happens.  I'll be more careful.

On 6/20/07, Takashi Iwai <tiwai@suse.de> wrote:
> [Please don't strip Cc to ML!]
>
> At Tue, 19 Jun 2007 15:54:42 -0500,
> Matt Mullins wrote:
> >
> > I played around with probe_mask, and found that probe_mask=0x1 causes
> > the error, but probe_mask=0x2 does not cause the timeout.  Codec 1 is
> > my Sigmatel STAC9205, which is what plays sound on my laptop, and
> > codec 2 is my Conexant modem.  The modem isn't the codec causing
> > problems; the audio codec is!
>
> OK, good to know.  Does this problem occur with S2D?
> What is the very first command that triggers this timeout error?
>
> I'm wondering what is the difference between them -- according to your
> report, reloading the module fixes the problem.  But, the resume
> callback is almost identical with the re-initiailzation.
> Perhaps it's something to do with the power-state management.
> What about the patch below?
>
>
> Takashi
>
> diff -r c531d63e820b sound/pci/hda/hda_intel.c
> --- a/sound/pci/hda/hda_intel.c Wed Jun 20 12:03:09 2007 +0200
> +++ b/sound/pci/hda/hda_intel.c Wed Jun 20 12:09:40 2007 +0200
> @@ -1450,7 +1450,7 @@ static int azx_suspend(struct pci_dev *p
>                 pci_disable_msi(chip->pci);
>         pci_disable_device(pci);
>         pci_save_state(pci);
> -       pci_set_power_state(pci, pci_choose_state(pci, state));
> +       /* pci_set_power_state(pci, pci_choose_state(pci, state)); */
>         return 0;
>  }
>
>

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Takashi Iwai]

At Wed, 20 Jun 2007 16:18:46 -0500,
Matt Mullins wrote:
> 
> That doesn't seem to change anything.  Maybe I should have been more
> clear: I get the azx_get_response timeouts whenever the driver
> initializes; DMA never works for that codec.

Well, It has nothing to do with DMA...

>  single_cmd mode just
> happens to work before a suspend, but not after.  In other words,
> reloading the module doesn't really fix the problem, it just masks it
> decently enough.

So, do you mean that single_cmd _always_ appears even before the
suspend?  Then it's not the problem of suspend-to-RAM but rather it's
a pure luck that you can use that device.  The single_cmd is a last
but horrible resort for the systems that can't communicate with codec
chips properly.

>   I'll work a little bit trying to figure out which
> commands cause the timeouts.  And what *is* S2D?

suspend-to-disk.


Takashi

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Matt Mullins]

Yes, single_cmd mode is used always.  I haven't really had much time
this week to find out why.  This is what I get for getting bleeding
edge hardware.

- Matt Mullins

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Takashi Iwai]

At Fri, 22 Jun 2007 15:31:13 -0500,
Matt Mullins wrote:
> 
> Yes, single_cmd mode is used always.

That's bad.  It means that the communication with the codec is brokn
from the very beginning...


Takashi

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Takashi Iwai]

At Mon, 25 Jun 2007 15:16:41 -0500,
Matt Mullins wrote:
> 
> On 6/25/07, Takashi Iwai <tiwai@suse.de> wrote:
> > > Yes, single_cmd mode is used always.
> > That's bad.
> 
> I believe we have established that.  What can I do about it?  *Can* I
> do anything about it?  What functions should I start debugging?  Has
> this happened with other codecs before?  What documentation will I
> need or want other than the Intel HDA and STAC9205 specifications?

Similar problems have been seen in some laptops, too.  I vaguely
remember that they need some ACPI-related boot options to fix it
somehow.  I think it's likely irrelevant with the codec chip, but
rather a problem of the controller side.

> I'm definitely willing to help work on this, as not many people have
> this hardware.  I'm just new to the sound system, so I'm still trying
> to figure out what-calls-what.


Takashi

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Matt Mullins]

On a whim, I decided to extract the sound/pci/hda from vanilla 2.6.20
kernel sources and compile it under 2.6.22-rc5 (yes, I know, I
probably shouldn't have done that).  I had to add a typedef to
patch_sigmatel.c to get it to compile.  When I loaded the modules, I
did *not* get the "switching to single_cmd" error, but I haven't
gotten sound yet, either, probably because I'm using pieces of two
different versions of ALSA.  However, this suggests to me that perhaps
there is a problem with the hda_intel driver, and not necessarily an
ACPI problem.

I'm going to keep working on this, as much as I can understand right now.

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Takashi Iwai]

At Wed, 4 Jul 2007 15:37:22 -0500,
Matt Mullins wrote:
> 
> On a whim, I decided to extract the sound/pci/hda from vanilla 2.6.20
> kernel sources and compile it under 2.6.22-rc5 (yes, I know, I
> probably shouldn't have done that).  I had to add a typedef to
> patch_sigmatel.c to get it to compile.  When I loaded the modules, I
> did *not* get the "switching to single_cmd" error, but I haven't
> gotten sound yet, either, probably because I'm using pieces of two
> different versions of ALSA.  However, this suggests to me that perhaps
> there is a problem with the hda_intel driver, and not necessarily an
> ACPI problem.

That's possible.  It might be that an access to an unsupported widget
may trigger the unexpected behavior of the codec chip and the
communication is disturbed.

Maybe it's worth to trace which verb call triggers the communication
breakage.  (BTW, for testing, you should concentrate only on audio
codec, so skip modem codec via probe_mask option.)


Takashi

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Matt Mullins]

After some hacking, I found that for some reason, something is calling
azx_send_cmd with nids much wider than 7 bits.  This happens exactly
twice, once with nid=0x534c, and nid=0x8845.  Both times, the verb is
0xf1c, and para=0x00.  This clobbers parts of "val" in both
azx_single_send_cmd and azx_corb_send_cmd.  I added the following code
to azx_send_cmd, and it works now:
if (!direct && (nid >> 7)) {
        snd_printd(SFX "Uh oh, too wide an NID value. codec=0x%x,
direct=0x%x, nid=0x%x, verb=0x%x, para=0x%x\n", (codec->addr)&0xf,
direct, nid, verb, para);
        return -EIO;
}

This outputs:

[136890.000388] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:644:
hda-intel: Uh oh, too wide an NID value. codec=0x0, direct=0x0,
nid=0x534c, verb=0xf1c, para=0x0
[136890.000393] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:644:
hda-intel: Uh oh, too wide an NID value. codec=0x0, direct=0x0,
nid=0x8845, verb=0xf1c, para=0x0

I do realize that the problem is not completely fixed, and we still
need to figure out what actually calls azx_send_cmd with the offending
parameters.  However, I am now lost in a sea of function pointers...

And it still doesn't work after a suspend, and I get a handful more
"uh oh"s upon resume:
[    3.942647] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:644:
hda-intel: Uh oh, too wide a NID value. codec=0x0, direct=0x0, nid
=0x534c, verb=0x71c, para=0xff
[    3.942658] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:644:
hda-intel: Uh oh, too wide a NID value. codec=0x0, direct=0x0, nid
=0x534c, verb=0x71d, para=0xff
[    3.942668] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:644:
hda-intel: Uh oh, too wide a NID value. codec=0x0, direct=0x0, nid
=0x534c, verb=0x71e, para=0xff
[    3.942678] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:644:
hda-intel: Uh oh, too wide a NID value. codec=0x0, direct=0x0, nid
=0x534c, verb=0x71f, para=0xff
[    3.942688] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:644:
hda-intel: Uh oh, too wide a NID value. codec=0x0, direct=0x0, nid
=0x534c, verb=0xf1c, para=0x0
[    3.942697] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:644:
hda-intel: Uh oh, too wide a NID value. codec=0x0, direct=0x0, nid
=0x8845, verb=0x71c, para=0xff
[    3.942707] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:644:
hda-intel: Uh oh, too wide a NID value. codec=0x0, direct=0x0, nid
=0x8845, verb=0x71d, para=0xff
[    3.942717] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:644:
hda-intel: Uh oh, too wide a NID value. codec=0x0, direct=0x0, nid
=0x8845, verb=0x71e, para=0xff
[    3.942727] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:644:
hda-intel: Uh oh, too wide a NID value. codec=0x0, direct=0x0, nid
=0x8845, verb=0x71f, para=0xff
[    3.942736] ALSA
/home/mmullins/Desktop/alsa/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:644:
hda-intel: Uh oh, too wide a NID value. codec=0x0, direct=0x0, nid
=0x8845, verb=0xf1c, para=0x0
----
Matt Mullins

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Matt Mullins]

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

Found what I think is the problem... patch_sigmatel.c set
spec->num_pins=14, yet spec->pin_nids pointed to stac9205_pin_nids,
which was an array of only 12 NIDs.  That caused [total guess here]
either stac92xx_save_bios_config_regs or stac92xx_set_config_regs to
read past the end of the array and into an uninitialized area.  I
changed the 14 to a 12, and it seems to work.  The attached patch is
against the current Mercurial sources, but I made the similar change
to kernel 2.6.22-rc7, and it doesn't use single_cmd anymore.  It still
doesn't work after a suspend, though, making me unload and reload the
module.

[-- Attachment #2: patch_mokomull --]
[-- Type: application/octet-stream, Size: 409 bytes --]

--- alsa-kernel-stock/pci/hda/patch_sigmatel.c	2007-07-05 20:44:46.000000000 -0500
+++ alsa-kernel/pci/hda/patch_sigmatel.c	2007-07-05 20:34:23.000000000 -0500
@@ -2259,7 +2259,7 @@
 		return -ENOMEM;
 
 	codec->spec = spec;
-	spec->num_pins = 14;
+	spec->num_pins = 12;
 	spec->pin_nids = stac9205_pin_nids;
 	spec->board_config = snd_hda_check_board_config(codec, STAC_9205_MODELS,
 							stac9205_models,

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Takashi Iwai]

At Thu, 5 Jul 2007 21:42:21 -0500,
Matt Mullins wrote:
> 
> Found what I think is the problem... patch_sigmatel.c set
> spec->num_pins=14, yet spec->pin_nids pointed to stac9205_pin_nids,
> which was an array of only 12 NIDs.  That caused [total guess here]
> either stac92xx_save_bios_config_regs or stac92xx_set_config_regs to
> read past the end of the array and into an uninitialized area.  I
> changed the 14 to a 12, and it seems to work.  The attached patch is
> against the current Mercurial sources, but I made the similar change
> to kernel 2.6.22-rc7, and it doesn't use single_cmd anymore.

Argh!  Thanks for spotting this nasty bug.

It'd be better to use ARRAY_SIZE there.  Then typos would be more
obvious.  Could you check the patch below?

>  It still
> doesn't work after a suspend, though, making me unload and reload the
> module.

Do you mean you'll get a communication error after suspend, or got no
sound output, or any other problem?


thanks,

Takashi

diff -r 42d31b8a307d pci/hda/patch_sigmatel.c
--- a/pci/hda/patch_sigmatel.c	Thu Jul 05 13:10:51 2007 +0200
+++ b/pci/hda/patch_sigmatel.c	Fri Jul 06 11:30:50 2007 +0200
@@ -1958,7 +1958,7 @@ static int patch_stac9200(struct hda_cod
 		return -ENOMEM;
 
 	codec->spec = spec;
-	spec->num_pins = 8;
+	spec->num_pins = ARRAY_SIZE(stac9200_pin_nids);
 	spec->pin_nids = stac9200_pin_nids;
 	spec->board_config = snd_hda_check_board_config(codec, STAC_9200_MODELS,
 							stac9200_models,
@@ -2008,7 +2008,7 @@ static int patch_stac925x(struct hda_cod
 		return -ENOMEM;
 
 	codec->spec = spec;
-	spec->num_pins = 8;
+	spec->num_pins = ARRAY_SIZE(stac925x_pin_nids);
 	spec->pin_nids = stac925x_pin_nids;
 	spec->board_config = snd_hda_check_board_config(codec, STAC_925x_MODELS,
 							stac925x_models,
@@ -2080,7 +2080,7 @@ static int patch_stac922x(struct hda_cod
 		return -ENOMEM;
 
 	codec->spec = spec;
-	spec->num_pins = 10;
+	spec->num_pins = ARRAY_SIZE(stac922x_pin_nids);
 	spec->pin_nids = stac922x_pin_nids;
 	spec->board_config = snd_hda_check_board_config(codec, STAC_922X_MODELS,
 							stac922x_models,
@@ -2181,7 +2181,7 @@ static int patch_stac927x(struct hda_cod
 		return -ENOMEM;
 
 	codec->spec = spec;
-	spec->num_pins = 14;
+	spec->num_pins = ARRAY_SIZE(stac927x_pin_nids);
 	spec->pin_nids = stac927x_pin_nids;
 	spec->board_config = snd_hda_check_board_config(codec, STAC_927X_MODELS,
 							stac927x_models,
@@ -2259,7 +2259,7 @@ static int patch_stac9205(struct hda_cod
 		return -ENOMEM;
 
 	codec->spec = spec;
-	spec->num_pins = 14;
+	spec->num_pins = ARRAY_SIZE(stac9205_pin_nids);
 	spec->pin_nids = stac9205_pin_nids;
 	spec->board_config = snd_hda_check_board_config(codec, STAC_9205_MODELS,
 							stac9205_models,

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Thorsten Leemhuis]

Hi!

FYI, I own the same laptop-model as Matt and have similar (identical?)
problems.

On 06.07.2007 11:32, Takashi Iwai wrote:
> At Thu, 5 Jul 2007 21:42:21 -0500,
> Matt Mullins wrote:
>> Found what I think is the problem... patch_sigmatel.c set
>> spec->num_pins=14, yet spec->pin_nids pointed to stac9205_pin_nids,
>> which was an array of only 12 NIDs.  That caused [total guess here]
>> either stac92xx_save_bios_config_regs or stac92xx_set_config_regs to
>> read past the end of the array and into an uninitialized area.  I
>> changed the 14 to a 12, and it seems to work.  The attached patch is
>> against the current Mercurial sources, but I made the similar change
>> to kernel 2.6.22-rc7, and it doesn't use single_cmd anymore.
> Argh!  Thanks for spotting this nasty bug.

Agreed; Matt, thx for your work.

> It'd be better to use ARRAY_SIZE there.  Then typos would be more
> obvious.  Could you check the patch below?

Works fine for me (patch was applied to alsa-driver 1.0.14 sources and
compiled against/tested on a Fedora 2.6.21 kernel and a 2.6.22-rc7-git3
kernel from the Fedora devel tree)

>>  It still
>> doesn't work after a suspend, though, making me unload and reload the
>> module.
> Do you mean you'll get a communication error after suspend, or got no
> sound output, or any other problem?

I simply don't get any audio output at all after either suspend or
hibernate. Reloading the module after suspend/hibernate makes the sound
working again.

CU
thl

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Takashi Iwai]

At Fri, 06 Jul 2007 17:46:04 +0200,
Thorsten Leemhuis wrote:
> 
> Hi!
> 
> FYI, I own the same laptop-model as Matt and have similar (identical?)
> problems.
> 
> On 06.07.2007 11:32, Takashi Iwai wrote:
> > At Thu, 5 Jul 2007 21:42:21 -0500,
> > Matt Mullins wrote:
> >> Found what I think is the problem... patch_sigmatel.c set
> >> spec->num_pins=14, yet spec->pin_nids pointed to stac9205_pin_nids,
> >> which was an array of only 12 NIDs.  That caused [total guess here]
> >> either stac92xx_save_bios_config_regs or stac92xx_set_config_regs to
> >> read past the end of the array and into an uninitialized area.  I
> >> changed the 14 to a 12, and it seems to work.  The attached patch is
> >> against the current Mercurial sources, but I made the similar change
> >> to kernel 2.6.22-rc7, and it doesn't use single_cmd anymore.
> > Argh!  Thanks for spotting this nasty bug.
> 
> Agreed; Matt, thx for your work.
> 
> > It'd be better to use ARRAY_SIZE there.  Then typos would be more
> > obvious.  Could you check the patch below?
> 
> Works fine for me (patch was applied to alsa-driver 1.0.14 sources and
> compiled against/tested on a Fedora 2.6.21 kernel and a 2.6.22-rc7-git3
> kernel from the Fedora devel tree)

Thanks for confirmation.  I committed the patch to HG tree now.

> >>  It still
> >> doesn't work after a suspend, though, making me unload and reload the
> >> module.
> > Do you mean you'll get a communication error after suspend, or got no
> > sound output, or any other problem?
> 
> I simply don't get any audio output at all after either suspend or
> hibernate. Reloading the module after suspend/hibernate makes the sound
> working again.

Doesn't changing the mixer values after resume have any effect?

Also, could you compare the codec#* proc dump before and after
suspend/resume?


thanks,

Takashi

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Thorsten Leemhuis]

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

On 06.07.2007 18:19, Takashi Iwai wrote:
> At Fri, 06 Jul 2007 17:46:04 +0200,
> Thorsten Leemhuis wrote:
>> On 06.07.2007 11:32, Takashi Iwai wrote:
>>> At Thu, 5 Jul 2007 21:42:21 -0500,
>>> Matt Mullins wrote:
> [...]
>>>>  It still
>>>> doesn't work after a suspend, though, making me unload and reload the
>>>> module.
>>> Do you mean you'll get a communication error after suspend, or got no
>>> sound output, or any other problem?
>> I simply don't get any audio output at all after either suspend or
>> hibernate. Reloading the module after suspend/hibernate makes the sound
>> working again.
> Doesn't changing the mixer values after resume have any effect?

No, I tried that beforehand already and just re-tried -- changing 
the mixer values does not help. Everything still silent. 
 
> Also, could you compare the codec#* proc dump before and after
> suspend/resume?

--- codec0-before       2007-07-06 18:40:47.000000000 +0200
+++ codec0-aftersuspend 2007-07-06 18:42:50.000000000 +0200
@@ -22,7 +22,7 @@
     Conn = 1/8, Color = Black
   Pin-ctls: 0x20: IN
   Connection: 2
-     0x10 0x11*
+     0x10* 0x11
 Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
   Pincap 0x081737: IN OUT Detect
   Pin Default 0x90a70120: [Fixed] Mic at Int N/A
@@ -103,7 +103,7 @@
   Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
   Amp-Out vals:  [0x00 0x00]
   Connection: 7
-     0x0e 0x16 0x0f 0x0b 0x0c* 0x0d 0x0a
+     0x0e* 0x16 0x0f 0x0b 0x0c 0x0d 0x0a
 Node 0x1b [Audio Selector] wcaps 0x300103: Stereo Amp-In
   Amp-In caps: N/A
   Amp-In vals:  [0x00 0x00]


-----

No changes for codec#1; full file before suspend attached.

HTH and thx for your help.

CU
thl

[-- Attachment #2: codec0-before --]
[-- Type: text/plain, Size: 4981 bytes --]

Codec: SigmaTel STAC9205
Address: 0
Vendor Id: 0x838476a0
Subsystem Id: 0x102801f9
Revision Id: 0x100204
Default PCM:
    rates [0x7e0]: 44100 48000 88200 96000 176400 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
Default Amp-In caps: ofs=0x00, nsteps=0x0f, stepsize=0x05, mute=0
Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1
Node 0x0a [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x08173f: IN OUT HP Detect
  Pin Default 0x0321101f: [Jack] HP Out at Ext Left
    Conn = 1/8, Color = Black
  Pin-ctls: 0xc0: OUT HP
  Connection: 2
     0x10* 0x11
Node 0x0b [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x0381102e: [Jack] Line In at Ext Left
    Conn = 1/8, Color = Black
  Pin-ctls: 0x20: IN
  Connection: 2
     0x10 0x11*
Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x90a70120: [Fixed] Mic at Int N/A
    Conn = Analog, Color = Unknown
  Pin-ctls: 0x24: IN
  Connection: 1
     0x11
Node 0x0d [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x083f: IN OUT HP Detect
  Pin Default 0x90170110: [Fixed] Speaker at Int N/A
    Conn = Analog, Color = Unknown
  Pin-ctls: 0x40: OUT
  Connection: 1
     0x10
Node 0x0e [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x40f000f0: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 1
     0x10
Node 0x0f [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x40f000f1: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 1
     0x11
Node 0x10 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
  Amp-Out caps: N/A
  Amp-Out vals:  [0x5f 0x5f]
  Power: 0x0
Node 0x11 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
  Amp-Out caps: N/A
  Amp-Out vals:  [0x5f 0x5f]
  Power: 0x0
Node 0x12 [Audio Input] wcaps 0x1d0541: Stereo
  Power: 0x0
  Connection: 1
     0x1d
Node 0x13 [Audio Input] wcaps 0x1d0541: Stereo
  Power: 0x0
  Connection: 1
     0x1e
Node 0x14 [Pin Complex] wcaps 0x40010c: Mono Amp-Out
  Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-Out vals:  [0x00]
  Pincap 0x0810: OUT
  Pin Default 0x40f000f2: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 1
     0x15
Node 0x15 [Audio Mixer] wcaps 0x200100: Mono
  Connection: 1
     0x10
Node 0x16 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x0820: IN
  Pin Default 0x40f000f3: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
Node 0x17 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x0820: IN
  Pin Default 0x40f000f4: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x20: IN
Node 0x18 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x0820: IN
  Pin Default 0x40f000f5: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x20: IN
Node 0x19 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 7
     0x0e 0x16 0x0f 0x0b 0x0c* 0x0d 0x0a
Node 0x1a [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 7
     0x0e 0x16 0x0f 0x0b 0x0c* 0x0d 0x0a
Node 0x1b [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Amp-In caps: N/A
  Amp-In vals:  [0x00 0x00]
  Connection: 1
     0x19
Node 0x1c [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Amp-In caps: N/A
  Amp-In vals:  [0x00 0x00]
  Connection: 1
     0x1a
Node 0x1d [Audio Selector] wcaps 0x30090d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Connection: 3
     0x1b* 0x17 0x18
Node 0x1e [Audio Selector] wcaps 0x30090d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Connection: 3
     0x1c* 0x17 0x18
Node 0x1f [Audio Output] wcaps 0x40211: Stereo Digital
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
Node 0x20 [Audio Input] wcaps 0x140311: Stereo Digital
  PCM:
    rates [0x160]: 44100 48000 96000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
  Connection: 1
     0x22
Node 0x21 [Pin Complex] wcaps 0x400301: Stereo Digital
  Pincap 0x0810: OUT
  Pin Default 0x40f000f6: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 3
     0x1f* 0x1d 0x1e
Node 0x22 [Pin Complex] wcaps 0x430681: Stereo Digital
  Pincap 0x0810024: IN EAPD Detect
  Pin Default 0x40f000f7: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Power: 0x0
Node 0x23 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out
  Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0
  Amp-Out vals:  [0x00]
Node 0x24 [Volume Knob Widget] wcaps 0x600000: Mono
Node 0x25 [Vendor Defined Widget] wcaps 0xf00001: Stereo

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Takashi Iwai]

At Fri, 06 Jul 2007 18:56:54 +0200,
Thorsten Leemhuis wrote:
> 
> On 06.07.2007 18:19, Takashi Iwai wrote:
> > At Fri, 06 Jul 2007 17:46:04 +0200,
> > Thorsten Leemhuis wrote:
> >> On 06.07.2007 11:32, Takashi Iwai wrote:
> >>> At Thu, 5 Jul 2007 21:42:21 -0500,
> >>> Matt Mullins wrote:
> > [...]
> >>>>  It still
> >>>> doesn't work after a suspend, though, making me unload and reload the
> >>>> module.
> >>> Do you mean you'll get a communication error after suspend, or got no
> >>> sound output, or any other problem?
> >> I simply don't get any audio output at all after either suspend or
> >> hibernate. Reloading the module after suspend/hibernate makes the sound
> >> working again.
> > Doesn't changing the mixer values after resume have any effect?
> 
> No, I tried that beforehand already and just re-tried -- changing 
> the mixer values does not help. Everything still silent. 

I suppose that re-plugging the headphone also doesn't help?

>  
> > Also, could you compare the codec#* proc dump before and after
> > suspend/resume?
> 
> --- codec0-before       2007-07-06 18:40:47.000000000 +0200
> +++ codec0-aftersuspend 2007-07-06 18:42:50.000000000 +0200
> @@ -22,7 +22,7 @@
>      Conn = 1/8, Color = Black
>    Pin-ctls: 0x20: IN
>    Connection: 2
> -     0x10 0x11*
> +     0x10* 0x11
>  Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
>    Pincap 0x081737: IN OUT Detect
>    Pin Default 0x90a70120: [Fixed] Mic at Int N/A
> @@ -103,7 +103,7 @@
>    Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
>    Amp-Out vals:  [0x00 0x00]
>    Connection: 7
> -     0x0e 0x16 0x0f 0x0b 0x0c* 0x0d 0x0a
> +     0x0e* 0x16 0x0f 0x0b 0x0c 0x0d 0x0a
>  Node 0x1b [Audio Selector] wcaps 0x300103: Stereo Amp-In
>    Amp-In caps: N/A
>    Amp-In vals:  [0x00 0x00]

They are input pins, so it should be irrelevant to outputs.

You wrote that re-loading the module works;  could you compare the
proc file before and after reloaind the module?


Takashi

Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend

[Thorsten Leemhuis]

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

On 09.07.2007 14:52, Takashi Iwai wrote:
> At Fri, 06 Jul 2007 18:56:54 +0200,
> Thorsten Leemhuis wrote:
>> On 06.07.2007 18:19, Takashi Iwai wrote:
>>> At Fri, 06 Jul 2007 17:46:04 +0200,
>>> Thorsten Leemhuis wrote:
>>>> On 06.07.2007 11:32, Takashi Iwai wrote:
>>>>> At Thu, 5 Jul 2007 21:42:21 -0500,
>>>>> Matt Mullins wrote:
>>> [...]
>>>>>>  It still
>>>>>> doesn't work after a suspend, though, making me unload and reload the
>>>>>> module.
>>>>> Do you mean you'll get a communication error after suspend, or got no
>>>>> sound output, or any other problem?
>>>> I simply don't get any audio output at all after either suspend or
>>>> hibernate. Reloading the module after suspend/hibernate makes the sound
>>>> working again.
>>> Doesn't changing the mixer values after resume have any effect?
>> No, I tried that beforehand already and just re-tried -- changing 
>> the mixer values does not help. Everything still silent. 
> I suppose that re-plugging the headphone also doesn't help?

/me wanders off to find a headphone

Well, it helps partially; sounds comes from the headphone after I
plugged it in. But the build in speakers stay silent even after I unplug
the headphone again.

>>> Also, could you compare the codec#* proc dump before and after
>>> suspend/resume?
>> --- codec0-before       2007-07-06 18:40:47.000000000 +0200
>> +++ codec0-aftersuspend 2007-07-06 18:42:50.000000000 +0200
>> @@ -22,7 +22,7 @@
>>      Conn = 1/8, Color = Black
>>    Pin-ctls: 0x20: IN
>>    Connection: 2
>> -     0x10 0x11*
>> +     0x10* 0x11
>>  Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
>>    Pincap 0x081737: IN OUT Detect
>>    Pin Default 0x90a70120: [Fixed] Mic at Int N/A
>> @@ -103,7 +103,7 @@
>>    Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
>>    Amp-Out vals:  [0x00 0x00]
>>    Connection: 7
>> -     0x0e 0x16 0x0f 0x0b 0x0c* 0x0d 0x0a
>> +     0x0e* 0x16 0x0f 0x0b 0x0c 0x0d 0x0a
>>  Node 0x1b [Audio Selector] wcaps 0x300103: Stereo Amp-In
>>    Amp-In caps: N/A
>>    Amp-In vals:  [0x00 0x00]
> They are input pins, so it should be irrelevant to outputs.

Well, computers in my experience sometimes are stupid beasts :-/

> You wrote that re-loading the module works;  could you compare the
> proc file before and after reloaind the module?

I just retried. The diff stays the same. Find all files attached fyi.
The data for codec#1 doesn't change at all.

CU
thl

[-- Attachment #2: c0-after-s3 --]
[-- Type: text/plain, Size: 4981 bytes --]

Codec: SigmaTel STAC9205
Address: 0
Vendor Id: 0x838476a0
Subsystem Id: 0x102801f9
Revision Id: 0x100204
Default PCM:
    rates [0x7e0]: 44100 48000 88200 96000 176400 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
Default Amp-In caps: ofs=0x00, nsteps=0x0f, stepsize=0x05, mute=0
Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1
Node 0x0a [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x08173f: IN OUT HP Detect
  Pin Default 0x0321101f: [Jack] HP Out at Ext Left
    Conn = 1/8, Color = Black
  Pin-ctls: 0xc0: OUT HP
  Connection: 2
     0x10* 0x11
Node 0x0b [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x0381102e: [Jack] Line In at Ext Left
    Conn = 1/8, Color = Black
  Pin-ctls: 0x20: IN
  Connection: 2
     0x10* 0x11
Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x90a70120: [Fixed] Mic at Int N/A
    Conn = Analog, Color = Unknown
  Pin-ctls: 0x24: IN
  Connection: 1
     0x11
Node 0x0d [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x083f: IN OUT HP Detect
  Pin Default 0x90170110: [Fixed] Speaker at Int N/A
    Conn = Analog, Color = Unknown
  Pin-ctls: 0x40: OUT
  Connection: 1
     0x10
Node 0x0e [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x40f000f0: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 1
     0x10
Node 0x0f [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x40f000f1: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 1
     0x11
Node 0x10 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
  Amp-Out caps: N/A
  Amp-Out vals:  [0x74 0x74]
  Power: 0x0
Node 0x11 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
  Amp-Out caps: N/A
  Amp-Out vals:  [0x71 0x6e]
  Power: 0x0
Node 0x12 [Audio Input] wcaps 0x1d0541: Stereo
  Power: 0x0
  Connection: 1
     0x1d
Node 0x13 [Audio Input] wcaps 0x1d0541: Stereo
  Power: 0x0
  Connection: 1
     0x1e
Node 0x14 [Pin Complex] wcaps 0x40010c: Mono Amp-Out
  Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-Out vals:  [0x00]
  Pincap 0x0810: OUT
  Pin Default 0x40f000f2: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 1
     0x15
Node 0x15 [Audio Mixer] wcaps 0x200100: Mono
  Connection: 1
     0x10
Node 0x16 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x0820: IN
  Pin Default 0x40f000f3: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
Node 0x17 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x0820: IN
  Pin Default 0x40f000f4: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x20: IN
Node 0x18 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x0820: IN
  Pin Default 0x40f000f5: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x20: IN
Node 0x19 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 7
     0x0e 0x16 0x0f 0x0b 0x0c* 0x0d 0x0a
Node 0x1a [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 7
     0x0e* 0x16 0x0f 0x0b 0x0c 0x0d 0x0a
Node 0x1b [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Amp-In caps: N/A
  Amp-In vals:  [0x00 0x00]
  Connection: 1
     0x19
Node 0x1c [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Amp-In caps: N/A
  Amp-In vals:  [0x00 0x00]
  Connection: 1
     0x1a
Node 0x1d [Audio Selector] wcaps 0x30090d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Connection: 3
     0x1b* 0x17 0x18
Node 0x1e [Audio Selector] wcaps 0x30090d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Connection: 3
     0x1c* 0x17 0x18
Node 0x1f [Audio Output] wcaps 0x40211: Stereo Digital
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
Node 0x20 [Audio Input] wcaps 0x140311: Stereo Digital
  PCM:
    rates [0x160]: 44100 48000 96000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
  Connection: 1
     0x22
Node 0x21 [Pin Complex] wcaps 0x400301: Stereo Digital
  Pincap 0x0810: OUT
  Pin Default 0x40f000f6: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 3
     0x1f* 0x1d 0x1e
Node 0x22 [Pin Complex] wcaps 0x430681: Stereo Digital
  Pincap 0x0810024: IN EAPD Detect
  Pin Default 0x40f000f7: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Power: 0x0
Node 0x23 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out
  Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0
  Amp-Out vals:  [0x00]
Node 0x24 [Volume Knob Widget] wcaps 0x600000: Mono
Node 0x25 [Vendor Defined Widget] wcaps 0xf00001: Stereo

[-- Attachment #3: c0-after-s3-and-module-reload --]
[-- Type: text/plain, Size: 4981 bytes --]

Codec: SigmaTel STAC9205
Address: 0
Vendor Id: 0x838476a0
Subsystem Id: 0x102801f9
Revision Id: 0x100204
Default PCM:
    rates [0x7e0]: 44100 48000 88200 96000 176400 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
Default Amp-In caps: ofs=0x00, nsteps=0x0f, stepsize=0x05, mute=0
Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1
Node 0x0a [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x08173f: IN OUT HP Detect
  Pin Default 0x0321101f: [Jack] HP Out at Ext Left
    Conn = 1/8, Color = Black
  Pin-ctls: 0xc0: OUT HP
  Connection: 2
     0x10* 0x11
Node 0x0b [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x0381102e: [Jack] Line In at Ext Left
    Conn = 1/8, Color = Black
  Pin-ctls: 0x20: IN
  Connection: 2
     0x10 0x11*
Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x90a70120: [Fixed] Mic at Int N/A
    Conn = Analog, Color = Unknown
  Pin-ctls: 0x24: IN
  Connection: 1
     0x11
Node 0x0d [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x083f: IN OUT HP Detect
  Pin Default 0x90170110: [Fixed] Speaker at Int N/A
    Conn = Analog, Color = Unknown
  Pin-ctls: 0x40: OUT
  Connection: 1
     0x10
Node 0x0e [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x40f000f0: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 1
     0x10
Node 0x0f [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x40f000f1: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 1
     0x11
Node 0x10 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
  Amp-Out caps: N/A
  Amp-Out vals:  [0x74 0x74]
  Power: 0x0
Node 0x11 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
  Amp-Out caps: N/A
  Amp-Out vals:  [0x71 0x6e]
  Power: 0x0
Node 0x12 [Audio Input] wcaps 0x1d0541: Stereo
  Power: 0x0
  Connection: 1
     0x1d
Node 0x13 [Audio Input] wcaps 0x1d0541: Stereo
  Power: 0x0
  Connection: 1
     0x1e
Node 0x14 [Pin Complex] wcaps 0x40010c: Mono Amp-Out
  Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-Out vals:  [0x00]
  Pincap 0x0810: OUT
  Pin Default 0x40f000f2: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 1
     0x15
Node 0x15 [Audio Mixer] wcaps 0x200100: Mono
  Connection: 1
     0x10
Node 0x16 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x0820: IN
  Pin Default 0x40f000f3: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
Node 0x17 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x0820: IN
  Pin Default 0x40f000f4: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x20: IN
Node 0x18 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x0820: IN
  Pin Default 0x40f000f5: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x20: IN
Node 0x19 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 7
     0x0e 0x16 0x0f 0x0b 0x0c* 0x0d 0x0a
Node 0x1a [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 7
     0x0e 0x16 0x0f 0x0b 0x0c* 0x0d 0x0a
Node 0x1b [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Amp-In caps: N/A
  Amp-In vals:  [0x00 0x00]
  Connection: 1
     0x19
Node 0x1c [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Amp-In caps: N/A
  Amp-In vals:  [0x00 0x00]
  Connection: 1
     0x1a
Node 0x1d [Audio Selector] wcaps 0x30090d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Connection: 3
     0x1b* 0x17 0x18
Node 0x1e [Audio Selector] wcaps 0x30090d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Connection: 3
     0x1c* 0x17 0x18
Node 0x1f [Audio Output] wcaps 0x40211: Stereo Digital
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
Node 0x20 [Audio Input] wcaps 0x140311: Stereo Digital
  PCM:
    rates [0x160]: 44100 48000 96000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
  Connection: 1
     0x22
Node 0x21 [Pin Complex] wcaps 0x400301: Stereo Digital
  Pincap 0x0810: OUT
  Pin Default 0x40f000f6: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 3
     0x1f* 0x1d 0x1e
Node 0x22 [Pin Complex] wcaps 0x430681: Stereo Digital
  Pincap 0x0810024: IN EAPD Detect
  Pin Default 0x40f000f7: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Power: 0x0
Node 0x23 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out
  Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0
  Amp-Out vals:  [0x00]
Node 0x24 [Volume Knob Widget] wcaps 0x600000: Mono
Node 0x25 [Vendor Defined Widget] wcaps 0xf00001: Stereo

[-- Attachment #4: c0-booted --]
[-- Type: text/plain, Size: 4981 bytes --]

Codec: SigmaTel STAC9205
Address: 0
Vendor Id: 0x838476a0
Subsystem Id: 0x102801f9
Revision Id: 0x100204
Default PCM:
    rates [0x7e0]: 44100 48000 88200 96000 176400 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
Default Amp-In caps: ofs=0x00, nsteps=0x0f, stepsize=0x05, mute=0
Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1
Node 0x0a [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x08173f: IN OUT HP Detect
  Pin Default 0x0321101f: [Jack] HP Out at Ext Left
    Conn = 1/8, Color = Black
  Pin-ctls: 0xc0: OUT HP
  Connection: 2
     0x10* 0x11
Node 0x0b [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x0381102e: [Jack] Line In at Ext Left
    Conn = 1/8, Color = Black
  Pin-ctls: 0x20: IN
  Connection: 2
     0x10 0x11*
Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x90a70120: [Fixed] Mic at Int N/A
    Conn = Analog, Color = Unknown
  Pin-ctls: 0x24: IN
  Connection: 1
     0x11
Node 0x0d [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x083f: IN OUT HP Detect
  Pin Default 0x90170110: [Fixed] Speaker at Int N/A
    Conn = Analog, Color = Unknown
  Pin-ctls: 0x40: OUT
  Connection: 1
     0x10
Node 0x0e [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x40f000f0: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 1
     0x10
Node 0x0f [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x081737: IN OUT Detect
  Pin Default 0x40f000f1: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 1
     0x11
Node 0x10 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
  Amp-Out caps: N/A
  Amp-Out vals:  [0x74 0x74]
  Power: 0x0
Node 0x11 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
  Amp-Out caps: N/A
  Amp-Out vals:  [0x71 0x6e]
  Power: 0x0
Node 0x12 [Audio Input] wcaps 0x1d0541: Stereo
  Power: 0x0
  Connection: 1
     0x1d
Node 0x13 [Audio Input] wcaps 0x1d0541: Stereo
  Power: 0x0
  Connection: 1
     0x1e
Node 0x14 [Pin Complex] wcaps 0x40010c: Mono Amp-Out
  Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-Out vals:  [0x00]
  Pincap 0x0810: OUT
  Pin Default 0x40f000f2: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 1
     0x15
Node 0x15 [Audio Mixer] wcaps 0x200100: Mono
  Connection: 1
     0x10
Node 0x16 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x0820: IN
  Pin Default 0x40f000f3: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
Node 0x17 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x0820: IN
  Pin Default 0x40f000f4: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x20: IN
Node 0x18 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x0820: IN
  Pin Default 0x40f000f5: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x20: IN
Node 0x19 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 7
     0x0e 0x16 0x0f 0x0b 0x0c* 0x0d 0x0a
Node 0x1a [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 7
     0x0e 0x16 0x0f 0x0b 0x0c* 0x0d 0x0a
Node 0x1b [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Amp-In caps: N/A
  Amp-In vals:  [0x00 0x00]
  Connection: 1
     0x19
Node 0x1c [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Amp-In caps: N/A
  Amp-In vals:  [0x00 0x00]
  Connection: 1
     0x1a
Node 0x1d [Audio Selector] wcaps 0x30090d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Connection: 3
     0x1b* 0x17 0x18
Node 0x1e [Audio Selector] wcaps 0x30090d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Connection: 3
     0x1c* 0x17 0x18
Node 0x1f [Audio Output] wcaps 0x40211: Stereo Digital
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
Node 0x20 [Audio Input] wcaps 0x140311: Stereo Digital
  PCM:
    rates [0x160]: 44100 48000 96000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
  Connection: 1
     0x22
Node 0x21 [Pin Complex] wcaps 0x400301: Stereo Digital
  Pincap 0x0810: OUT
  Pin Default 0x40f000f6: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Connection: 3
     0x1f* 0x1d 0x1e
Node 0x22 [Pin Complex] wcaps 0x430681: Stereo Digital
  Pincap 0x0810024: IN EAPD Detect
  Pin Default 0x40f000f7: [N/A] Other at Ext N/A
    Conn = Unknown, Color = Unknown
  Pin-ctls: 0x00:
  Power: 0x0
Node 0x23 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out
  Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0
  Amp-Out vals:  [0x00]
Node 0x24 [Volume Knob Widget] wcaps 0x600000: Mono
Node 0x25 [Vendor Defined Widget] wcaps 0xf00001: Stereo

[-- Attachment #5: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel