idt blue jack patch

idt blue jack patch

[Paulo Cavalcanti]

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

Hi,

I received a patch form Fengguang that
made my Intel DG45ID (snd-hda-intel, codec IDT 92HD73E1X5)
behave the way it should, in my opinion.

It just makes the blue jack behave as an input source by default (in alsa
1.0.19 it is
an output jack).

It is widespread that the green jack is output, the blue input and the pink
is mic.
Some cards allow reconfiguring the jacks in alsamixer, but the DG45ID
already has
an orange and black jacks for rear and center speakers, and a digital
output.

Other people have also raised this problem some time ago:

https://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=threaded&order=ASC&topic_id=62855&forum=12&move=prev&topic_time=1224179600

Fengguang suggested me to direct my request to the development list,
so the other developers could decide what to do.

I would like to add that I can use the input source and the mic just fine
now
(the mic could be a bit louder, but it works fine with skype).

The patch is very simple and is attached. This would conclude the fix
for this card, Takashi started with me some time ago (I just made the
tests).

Thanks.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ

[-- Attachment #2: idt-blue-linein.patch --]
[-- Type: application/octet-stream, Size: 521 bytes --]

diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index a7df81e..afdb655 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -4793,6 +4793,10 @@ again:
 		spec->num_smuxes = ARRAY_SIZE(stac92hd73xx_smux_nids);
 		spec->eapd_switch = 1;
 	}
+
+	/* was 0x01113014 */
+	stac92xx_set_config_reg(codec, 0x0c, 0x01813021);
+
 	if (spec->board_config > STAC_92HD73XX_REF) {
 		/* GPIO0 High = Enable EAPD */
 		spec->eapd_mask = spec->gpio_mask = spec->gpio_dir = 0x1;

[-- 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: idt blue jack patch

[Takashi Iwai]

At Mon, 16 Feb 2009 06:13:35 -0300,
Paulo Cavalcanti wrote:
> 
> Hi,
> 
> I received a patch form Fengguang that
> made my Intel DG45ID (snd-hda-intel, codec IDT 92HD73E1X5)
> behave the way it should, in my opinion.
> 
> It just makes the blue jack behave as an input source by default (in alsa
> 1.0.19 it is
> an output jack).
> 
> It is widespread that the green jack is output, the blue input and the pink
> is mic.
> Some cards allow reconfiguring the jacks in alsamixer, but the DG45ID
> already has
> an orange and black jacks for rear and center speakers, and a digital
> output.
> 
> Other people have also raised this problem some time ago:
> 
> https://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=threaded&order=ASC&topic_id=62855&forum=12&move=prev&topic_time=1224179600
> 
> Fengguang suggested me to direct my request to the development list,
> so the other developers could decide what to do.
> 
> I would like to add that I can use the input source and the mic just fine
> now
> (the mic could be a bit louder, but it works fine with skype).
> 
> The patch is very simple and is attached. This would conclude the fix
> for this card, Takashi started with me some time ago (I just made the
> tests).

It's fine to put a quirk there.  But, you'd need to create a "model"
for your device so that it won't interfere other devices.  That is,
define a new model type, and call stac92xx_set_config_reg() with the
check of spec->board_config.


Takashi

Re: idt blue jack patch

[Paulo Cavalcanti]

On Mon, Feb 16, 2009 at 7:55 AM, Takashi Iwai <tiwai@suse.de> wrote:

> At Mon, 16 Feb 2009 06:13:35 -0300,
> Paulo Cavalcanti wrote:
> >
> > Hi,
> >
> > I received a patch form Fengguang that
> > made my Intel DG45ID (snd-hda-intel, codec IDT 92HD73E1X5)
> > behave the way it should, in my opinion.
> >
> > It just makes the blue jack behave as an input source by default (in alsa
> > 1.0.19 it is
> > an output jack).
> >
> > It is widespread that the green jack is output, the blue input and the
> pink
> > is mic.
> > Some cards allow reconfiguring the jacks in alsamixer, but the DG45ID
> > already has
> > an orange and black jacks for rear and center speakers, and a digital
> > output.
> >
> > Other people have also raised this problem some time ago:
> >
> >
> https://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=threaded&order=ASC&topic_id=62855&forum=12&move=prev&topic_time=1224179600
> >
> > Fengguang suggested me to direct my request to the development list,
> > so the other developers could decide what to do.
> >
> > I would like to add that I can use the input source and the mic just fine
> > now
> > (the mic could be a bit louder, but it works fine with skype).
> >
> > The patch is very simple and is attached. This would conclude the fix
> > for this card, Takashi started with me some time ago (I just made the
> > tests).
>
> It's fine to put a quirk there.  But, you'd need to create a "model"
> for your device so that it won't interfere other devices.  That is,
> define a new model type, and call stac92xx_set_config_reg() with the
> check of spec->board_config.
>
>
This is easy. The problem is that I am already using model "no-jd",
remember?
In this case, if I used

        /* was 0x01113014 */
        if (spec->board_config > STAC_92HD73XX_NO_JD ) {
            stac92xx_set_config_reg(codec, 0x0c, 0x01813021);
        }

would be fine to me.

However, there is a possibility that all "stac92hd73xx" family needs
this quirk. In this case, no additional code is needed.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ

Re: idt blue jack patch

[Takashi Iwai]

At Tue, 17 Feb 2009 23:04:31 -0300,
Paulo Cavalcanti wrote:
> 
> On Mon, Feb 16, 2009 at 7:55 AM, Takashi Iwai <tiwai@suse.de> wrote:
> 
>     At Mon, 16 Feb 2009 06:13:35 -0300,
>     Paulo Cavalcanti wrote:
>     >
>     > Hi,
>     >
>     > I received a patch form Fengguang that
>     > made my Intel DG45ID (snd-hda-intel, codec IDT 92HD73E1X5)
>     > behave the way it should, in my opinion.
>     >
>     > It just makes the blue jack behave as an input source by default (in
>     alsa
>     > 1.0.19 it is
>     > an output jack).
>     >
>     > It is widespread that the green jack is output, the blue input and the
>     pink
>     > is mic.
>     > Some cards allow reconfiguring the jacks in alsamixer, but the DG45ID
>     > already has
>     > an orange and black jacks for rear and center speakers, and a digital
>     > output.
>     >
>     > Other people have also raised this problem some time ago:
>     >
>     > https://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=threaded&
>     order=ASC&topic_id=62855&forum=12&move=prev&topic_time=1224179600
>     >
>     > Fengguang suggested me to direct my request to the development list,
>     > so the other developers could decide what to do.
>     >
>     > I would like to add that I can use the input source and the mic just
>     fine
>     > now
>     > (the mic could be a bit louder, but it works fine with skype).
>     >
>     > The patch is very simple and is attached. This would conclude the fix
>     > for this card, Takashi started with me some time ago (I just made the
>     > tests).
>    
>     It's fine to put a quirk there.  But, you'd need to create a "model"
>     for your device so that it won't interfere other devices.  That is,
>     define a new model type, and call stac92xx_set_config_reg() with the
>     check of spec->board_config.
> 
> This is easy. The problem is that I am already using model "no-jd", remember?
> In this case, if I used
> 
>         /* was 0x01113014 */
>         if (spec->board_config > STAC_92HD73XX_NO_JD ) {
>             stac92xx_set_config_reg(codec, 0x0c, 0x01813021);
>         }
> 
> would be fine to me.

Hm, now the question is why it's wrong.  This patch changes the
port-C.  My concern is whether it's a cabling problem or if it's a
BIOS thing.  If it's a cabling problem (i.e. the cables don't match
with the box), it's not a problem that the driver needs to fix in it.
OTOH, if the cabling is OK but just the port-C is mislabeled by BIOS,
it's an issue to be fixed as a quirk in the driver.

> However, there is a possibility that all "stac92hd73xx" family needs
> this quirk. In this case, no additional code is needed.

Very unlikely.
The pins can be freely assigned, and the port-C is a very basic port.
The position, color, association, etc must be different from machine
to machine.


thanks,

Takashi

Re: idt blue jack patch

[Paulo Cavalcanti]

On Wed, Feb 18, 2009 at 3:50 AM, Takashi Iwai <tiwai@suse.de> wrote:

> At Tue, 17 Feb 2009 23:04:31 -0300,
> Paulo Cavalcanti wrote:
> >
> > On Mon, Feb 16, 2009 at 7:55 AM, Takashi Iwai <tiwai@suse.de> wrote:
> >
> >     At Mon, 16 Feb 2009 06:13:35 -0300,
> >     Paulo Cavalcanti wrote:
> >     >
> >     > Hi,
> >     >
> >     > I received a patch form Fengguang that
> >     > made my Intel DG45ID (snd-hda-intel, codec IDT 92HD73E1X5)
> >     > behave the way it should, in my opinion.
> >     >
> >     > It just makes the blue jack behave as an input source by default
> (in
> >     alsa
> >     > 1.0.19 it is
> >     > an output jack).
> >     >
> >     > It is widespread that the green jack is output, the blue input and
> the
> >     pink
> >     > is mic.
> >     > Some cards allow reconfiguring the jacks in alsamixer, but the
> DG45ID
> >     > already has
> >     > an orange and black jacks for rear and center speakers, and a
> digital
> >     > output.
> >     >
> >     > Other people have also raised this problem some time ago:
> >     >
> >     >
> https://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=threaded&
> >     order=ASC&topic_id=62855&forum=12&move=prev&topic_time=1224179600
> >     >
> >     > Fengguang suggested me to direct my request to the development
> list,
> >     > so the other developers could decide what to do.
> >     >
> >     > I would like to add that I can use the input source and the mic
> just
> >     fine
> >     > now
> >     > (the mic could be a bit louder, but it works fine with skype).
> >     >
> >     > The patch is very simple and is attached. This would conclude the
> fix
> >     > for this card, Takashi started with me some time ago (I just made
> the
> >     > tests).
> >
> >     It's fine to put a quirk there.  But, you'd need to create a "model"
> >     for your device so that it won't interfere other devices.  That is,
> >     define a new model type, and call stac92xx_set_config_reg() with the
> >     check of spec->board_config.
> >
> > This is easy. The problem is that I am already using model "no-jd",
> remember?
> > In this case, if I used
> >
> >         /* was 0x01113014 */
> >         if (spec->board_config > STAC_92HD73XX_NO_JD ) {
> >             stac92xx_set_config_reg(codec, 0x0c, 0x01813021);
> >         }
> >
> > would be fine to me.
>
> Hm, now the question is why it's wrong.  This patch changes the
> port-C.  My concern is whether it's a cabling problem or if it's a
> BIOS thing.  If it's a cabling problem (i.e. the cables don't match
> with the box), it's not a problem that the driver needs to fix in it.
> OTOH, if the cabling is OK but just the port-C is mislabeled by BIOS,
> it's an issue to be fixed as a quirk in the driver.
>
> > However, there is a possibility that all "stac92hd73xx" family needs
> > this quirk. In this case, no additional code is needed.
>
> Very unlikely.
> The pins can be freely assigned, and the port-C is a very basic port.
> The position, color, association, etc must be different from machine
> to machine.
>
>
>
Takashi,

Fengguang got the same board I have (DG45ID)
and he confirmed that the blue jack was output.
The only difference between his computer and mine
was that his had an older bios.

This is what he said to me before sending me the patch:

"OK, so it's in fact a general issue. I'll look into it. But I'm afraid
I have difficulty in allocating time for it in the near future..."

Therefore, I think we need another quirk.

Thanks.


-- 
Paulo Roma Cavalcanti
LCG - UFRJ

Re: idt blue jack patch

[Vedran Miletić]

On Wed, Feb 18, 2009 at 10:04 AM, Paulo Cavalcanti <promac@gmail.com> wrote:
> Takashi,
>
> Fengguang got the same board I have (DG45ID)
> and he confirmed that the blue jack was output.
> The only difference between his computer and mine
> was that his had an older bios.
>
> This is what he said to me before sending me the patch:
>
> "OK, so it's in fact a general issue. I'll look into it. But I'm afraid
> I have difficulty in allocating time for it in the near future..."
>
> Therefore, I think we need another quirk.
>
> Thanks.
>
>
> --
> Paulo Roma Cavalcanti
> LCG - UFRJ
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Can you find someone who has different board with same codec to verify
how general issue this really is?

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

Re: idt blue jack patch

[Takashi Iwai]

At Wed, 18 Feb 2009 10:44:26 +0100,
Vedran Miletić wrote:
> 
> On Wed, Feb 18, 2009 at 10:04 AM, Paulo Cavalcanti <promac@gmail.com> wrote:
> > Takashi,
> >
> > Fengguang got the same board I have (DG45ID)
> > and he confirmed that the blue jack was output.
> > The only difference between his computer and mine
> > was that his had an older bios.
> >
> > This is what he said to me before sending me the patch:
> >
> > "OK, so it's in fact a general issue. I'll look into it. But I'm afraid
> > I have difficulty in allocating time for it in the near future..."
> >
> > Therefore, I think we need another quirk.
> >
> > Thanks.
> >
> >
> > --
> > Paulo Roma Cavalcanti
> > LCG - UFRJ
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >
> 
> Can you find someone who has different board with same codec to verify
> how general issue this really is?

In general, the pin config value can't be generic.
As port-C is a multi-purpose jack, I don't think this can be applied
to all cases.

So, now the question is when to apply -- under which condition.
Apparently, the BIOS of Paulo is broken.  And, Wu Fengguang's case
is unclear, whether it comes from BIOS or from a static pin cfg
table in patch_sigmatel.c.


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

Re: idt blue jack patch

[Wu Fengguang]

On Wed, Feb 18, 2009 at 04:24:58PM +0100, Takashi Iwai wrote:
> At Wed, 18 Feb 2009 10:44:26 +0100,
> Vedran Miletić wrote:
> > 
> > On Wed, Feb 18, 2009 at 10:04 AM, Paulo Cavalcanti <promac@gmail.com> wrote:
> > > Takashi,
> > >
> > > Fengguang got the same board I have (DG45ID)
> > > and he confirmed that the blue jack was output.
> > > The only difference between his computer and mine
> > > was that his had an older bios.
> > >
> > > This is what he said to me before sending me the patch:
> > >
> > > "OK, so it's in fact a general issue. I'll look into it. But I'm afraid
> > > I have difficulty in allocating time for it in the near future..."
> > >
> > > Therefore, I think we need another quirk.
> > >
> > > Thanks.
> > >
> > >
> > > --
> > > Paulo Roma Cavalcanti
> > > LCG - UFRJ
> > > _______________________________________________
> > > Alsa-devel mailing list
> > > Alsa-devel@alsa-project.org
> > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > >

[sorry for being late]

> > 
> > Can you find someone who has different board with same codec to verify
> > how general issue this really is?
>
> In general, the pin config value can't be generic.
> As port-C is a multi-purpose jack, I don't think this can be applied
> to all cases.

I made that hacking patch based on IDT's spec. The value I wrote is in
fact the default value listed in the spec. So it's the Intel BIOS that
changed the default value and make it an output pin.

> So, now the question is when to apply -- under which condition.
> Apparently, the BIOS of Paulo is broken.  And, Wu Fengguang's case
> is unclear, whether it comes from BIOS or from a static pin cfg
> table in patch_sigmatel.c.

After rebooting and force using the generic codec, the 0x0c node still
shows "Pin Default 0x01113014: [Jack] Speaker at Ext Rear". So the
value is from the BIOS.

The only problem is that the pin color is Blue both logically and
physically, which should be input instead of output according to the
convention of color codes.

If you think it's OK, I can refine that patch for submitting.  The
possible regression could be that users connecting speakers to that
pin will find it no longer producing sound after upgrading kernel.

Thanks,
Fengguang

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

Re: idt blue jack patch

[Tobin Davis]

Thought I'd add my $.02 here.  Traditionally, 5-stack boards have output
on Green (front), Black (rear), and Orange (Center/LFE) channels, and
Input on Pink (Mic) and Blue (Line).  But Blue is also reversable for
side output channels giving the user 7.1 surround sound.

Since these boards are designed to be used more for multimedia than
recording, the default of Blue being output in bios kind of makes sense.
Of course, it could also be a bios bug (it's been known to happen).

If you want to see what the codec is set for in Windows, download the
windows drivers from support.intel.com and look for the PCI subsysytem
id in the STHDA.inf file.  It will point to another inf file with the
default pin configs along with a ton of registry settings.

Hope this helps.

Tobin Davis
P.S. I've been monitoring development while finishing my degree.  I hope
to return to the fold here soon.

On Thu, 2009-02-19 at 11:02 +0800, Wu Fengguang wrote:

> On Wed, Feb 18, 2009 at 04:24:58PM +0100, Takashi Iwai wrote:
> > At Wed, 18 Feb 2009 10:44:26 +0100,
> > Vedran Miletić wrote:
> > > 
> > > On Wed, Feb 18, 2009 at 10:04 AM, Paulo Cavalcanti <promac@gmail.com> wrote:
> > > > Takashi,
> > > >
> > > > Fengguang got the same board I have (DG45ID)
> > > > and he confirmed that the blue jack was output.
> > > > The only difference between his computer and mine
> > > > was that his had an older bios.
> > > >
> > > > This is what he said to me before sending me the patch:
> > > >
> > > > "OK, so it's in fact a general issue. I'll look into it. But I'm afraid
> > > > I have difficulty in allocating time for it in the near future..."
> > > >
> > > > Therefore, I think we need another quirk.
> > > >
> > > > Thanks.
> > > >
> > > >
> > > > --
> > > > Paulo Roma Cavalcanti
> > > > LCG - UFRJ
> > > > _______________________________________________
> > > > Alsa-devel mailing list
> > > > Alsa-devel@alsa-project.org
> > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > > >
> 
> [sorry for being late]
> 
> > > 
> > > Can you find someone who has different board with same codec to verify
> > > how general issue this really is?
> >
> > In general, the pin config value can't be generic.
> > As port-C is a multi-purpose jack, I don't think this can be applied
> > to all cases.
> 
> I made that hacking patch based on IDT's spec. The value I wrote is in
> fact the default value listed in the spec. So it's the Intel BIOS that
> changed the default value and make it an output pin.
> 
> > So, now the question is when to apply -- under which condition.
> > Apparently, the BIOS of Paulo is broken.  And, Wu Fengguang's case
> > is unclear, whether it comes from BIOS or from a static pin cfg
> > table in patch_sigmatel.c.
> 
> After rebooting and force using the generic codec, the 0x0c node still
> shows "Pin Default 0x01113014: [Jack] Speaker at Ext Rear". So the
> value is from the BIOS.
> 
> The only problem is that the pin color is Blue both logically and
> physically, which should be input instead of output according to the
> convention of color codes.
> 
> If you think it's OK, I can refine that patch for submitting.  The
> possible regression could be that users connecting speakers to that
> pin will find it no longer producing sound after upgrading kernel.
> 
> Thanks,
> Fengguang
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- 
Tobin Davis 


Don't go surfing in South Dakota for a while.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: idt blue jack patch

[Takashi Iwai]

At Wed, 18 Feb 2009 19:22:52 -0800,
Tobin Davis wrote:
> 
> 
> [2  <text/html; utf-8 (7bit)>]
> Thought I'd add my $.02 here.  Traditionally, 5-stack boards have output on
> Green (front), Black (rear), and Orange (Center/LFE) channels, and Input on
> Pink (Mic) and Blue (Line).  But Blue is also reversable for side output
> channels giving the user 7.1 surround sound.
> 
> Since these boards are designed to be used more for multimedia than recording,
> the default of Blue being output in bios kind of makes sense.  Of course, it
> could also be a bios bug (it's been known to happen).

It's a good point.  Of course, it's possible that the Windows driver
takes rather the color than the device type as the primary role.
Or, its combination is considered as the multi-pin.

Maybe this would be another solution...


Takashi

> If you want to see what the codec is set for in Windows, download the windows
> drivers from support.intel.com and look for the PCI subsysytem id in the
> STHDA.inf file.  It will point to another inf file with the default pin
> configs along with a ton of registry settings.
> 
> Hope this helps.
> 
> Tobin Davis
> P.S. I've been monitoring development while finishing my degree.  I hope to
> return to the fold here soon.
> 
> On Thu, 2009-02-19 at 11:02 +0800, Wu Fengguang wrote:
> 
>     On Wed, Feb 18, 2009 at 04:24:58PM +0100, Takashi Iwai wrote:
>     > At Wed, 18 Feb 2009 10:44:26 +0100,
>     > Vedran Miletić wrote:
>     > > 
>     > > On Wed, Feb 18, 2009 at 10:04 AM, Paulo Cavalcanti <promac@gmail.com> wrote:
>     > > > Takashi,
>     > > >
>     > > > Fengguang got the same board I have (DG45ID)
>     > > > and he confirmed that the blue jack was output.
>     > > > The only difference between his computer and mine
>     > > > was that his had an older bios.
>     > > >
>     > > > This is what he said to me before sending me the patch:
>     > > >
>     > > > "OK, so it's in fact a general issue. I'll look into it. But I'm afraid
>     > > > I have difficulty in allocating time for it in the near future..."
>     > > >
>     > > > Therefore, I think we need another quirk.
>     > > >
>     > > > Thanks.
>     > > >
>     > > >
>     > > > --
>     > > > Paulo Roma Cavalcanti
>     > > > LCG - UFRJ
>     > > > _______________________________________________
>     > > > Alsa-devel mailing list
>     > > > Alsa-devel@alsa-project.org
>     > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>     > > >
>     
>     [sorry for being late]
>     
>     > > 
>     > > Can you find someone who has different board with same codec to verify
>     > > how general issue this really is?
>     >
>     > In general, the pin config value can't be generic.
>     > As port-C is a multi-purpose jack, I don't think this can be applied
>     > to all cases.
>     
>     I made that hacking patch based on IDT's spec. The value I wrote is in
>     fact the default value listed in the spec. So it's the Intel BIOS that
>     changed the default value and make it an output pin.
>     
>     > So, now the question is when to apply -- under which condition.
>     > Apparently, the BIOS of Paulo is broken.  And, Wu Fengguang's case
>     > is unclear, whether it comes from BIOS or from a static pin cfg
>     > table in patch_sigmatel.c.
>     
>     After rebooting and force using the generic codec, the 0x0c node still
>     shows "Pin Default 0x01113014: [Jack] Speaker at Ext Rear". So the
>     value is from the BIOS.
>     
>     The only problem is that the pin color is Blue both logically and
>     physically, which should be input instead of output according to the
>     convention of color codes.
>     
>     If you think it's OK, I can refine that patch for submitting.  The
>     possible regression could be that users connecting speakers to that
>     pin will find it no longer producing sound after upgrading kernel.
>     
>     Thanks,
>     Fengguang
>     
>     _______________________________________________
>     Alsa-devel mailing list
>     Alsa-devel@alsa-project.org
>     http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>     
> -- Tobin Davis                                                                
> 
> Don't go surfing in South Dakota for a while.                                 
> 
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: idt blue jack patch

[Wu Fengguang]

Hi Tobin,

Here are the Linux and WinXP pin configurations.
Both Linux and WinXP configure node 0x0c as an output pin.

However the driver seems to be offering three schemes:

        scheme desc             0xC dev
------------------------------------------------------
        IDS_CONFIG_OPEN         Speaker_Side/LineIn
        IDS_CONFIG_51           LineIn
        IDS_CONFIG_71           Speaker_Side

Paulo, maybe you can run these commands to switch between
linein/lineout modes:

        # wget http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2

        # set PIN_IN mode
        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20

        # set PIN_OUT mode
        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40

Thanks,
Fengguang
---

/proc/asound/card0/codec\#2

        Codec: IDT 92HD73E1X5
        Address: 2
        Vendor Id: 0x111d7676
        Subsystem Id: 0x80865002
        Revision Id: 0x100202


AUD_allOS_6033.2_PV_IDTGUI_v124/WDM/WinXP/Sthda.ini

        # sthda.INI
        [Models]
        ...
        HDAUDIO\FUNC_01&VEN_111D&DEV_7676&SUBSYS_80865002=I73E-EL2.INI                                                            
        ...


AUD_allOS_6033.2_PV_IDTGUI_v124/WDM/WinXP/I73E-EL2.INI

        [HKR\Settings\Pin\0C]
        CfgDflt                         = dword: 0x01113214
        AltCfg                          = hex: 5E,32,81,01
        AssignedDAC     = hex: 0x18


/proc/asound/card0/codec\#2

        Node 0x0c [Pin Complex] wcaps 0x400183: Stereo Amp-In
          Amp-In caps: N/A
          Amp-In vals:  [0x00 0x00]
          Pincap 0x00001737: IN OUT Detect Trigger ImpSense
            Vref caps: HIZ 50 GRD 80
          Pin Default 0x01113014: [Jack] Speaker at Ext Rear
            Conn = 1/8, Color = Blue
            DefAssociation = 0x1, Sequence = 0x4
          Pin-ctls: 0x40: OUT VREF_HIZ
          Unsolicited: tag=04, enabled=1
          Connection: 6
             0x15 0x16 0x17 0x18* 0x19 0x1e

On Thu, Feb 19, 2009 at 05:22:52AM +0200, Tobin Davis wrote:
> Thought I'd add my $.02 here.  Traditionally, 5-stack boards have output on Green (front), Black (rear), and Orange (Center/LFE) channels, and Input on Pink (Mic) and Blue (Line).  But Blue is also reversable for side output channels giving the user 7.1 surround sound.
> 
> Since these boards are designed to be used more for multimedia than recording, the default of Blue being output in bios kind of makes sense.  Of course, it could also be a bios bug (it's been known to happen).
> 
> If you want to see what the codec is set for in Windows, download the windows drivers from support.intel.com and look for the PCI subsysytem id in the STHDA.inf file.  It will point to another inf file with the default pin configs along with a ton of registry settings.
> 
> Hope this helps.
> 
> Tobin Davis
> P.S. I've been monitoring development while finishing my degree.  I hope to return to the fold here soon.
> 
> On Thu, 2009-02-19 at 11:02 +0800, Wu Fengguang wrote:
> 
> 
> On Wed, Feb 18, 2009 at 04:24:58PM +0100, Takashi Iwai wrote:
> > At Wed, 18 Feb 2009 10:44:26 +0100,
> > Vedran Miletić wrote:
> > >
> > > On Wed, Feb 18, 2009 at 10:04 AM, Paulo Cavalcanti <promac@gmail.com<mailto:promac@gmail.com>> wrote:
> > > > Takashi,
> > > >
> > > > Fengguang got the same board I have (DG45ID)
> > > > and he confirmed that the blue jack was output.
> > > > The only difference between his computer and mine
> > > > was that his had an older bios.
> > > >
> > > > This is what he said to me before sending me the patch:
> > > >
> > > > "OK, so it's in fact a general issue. I'll look into it. But I'm afraid
> > > > I have difficulty in allocating time for it in the near future..."
> > > >
> > > > Therefore, I think we need another quirk.
> > > >
> > > > Thanks.
> > > >
> > > >
> > > > --
> > > > Paulo Roma Cavalcanti
> > > > LCG - UFRJ
> > > > _______________________________________________
> > > > Alsa-devel mailing list
> > > > Alsa-devel@alsa-project.org<mailto:Alsa-devel@alsa-project.org>
> > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > > >
> 
> [sorry for being late]
> 
> > >
> > > Can you find someone who has different board with same codec to verify
> > > how general issue this really is?
> >
> > In general, the pin config value can't be generic.
> > As port-C is a multi-purpose jack, I don't think this can be applied
> > to all cases.
> 
> I made that hacking patch based on IDT's spec. The value I wrote is in
> fact the default value listed in the spec. So it's the Intel BIOS that
> changed the default value and make it an output pin.
> 
> > So, now the question is when to apply -- under which condition.
> > Apparently, the BIOS of Paulo is broken.  And, Wu Fengguang's case
> > is unclear, whether it comes from BIOS or from a static pin cfg
> > table in patch_sigmatel.c.
> 
> After rebooting and force using the generic codec, the 0x0c node still
> shows "Pin Default 0x01113014: [Jack] Speaker at Ext Rear". So the
> value is from the BIOS.
> 
> The only problem is that the pin color is Blue both logically and
> physically, which should be input instead of output according to the
> convention of color codes.
> 
> If you think it's OK, I can refine that patch for submitting.  The
> possible regression could be that users connecting speakers to that
> pin will find it no longer producing sound after upgrading kernel.
> 
> Thanks,
> Fengguang
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org<mailto:Alsa-devel@alsa-project.org>
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 
> 
> -- Tobin Davis
> 
> 
> 
> Don't go surfing in South Dakota for a while.
> 
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: idt blue jack patch

[Paulo Cavalcanti]

On Thu, Feb 19, 2009 at 10:00 PM, Wu Fengguang <fengguang.wu@intel.com>wrote:

> Hi Tobin,
>
> Here are the Linux and WinXP pin configurations.
> Both Linux and WinXP configure node 0x0c as an output pin.
>
> However the driver seems to be offering three schemes:
>
>        scheme desc             0xC dev
> ------------------------------------------------------
>        IDS_CONFIG_OPEN         Speaker_Side/LineIn
>        IDS_CONFIG_51           LineIn
>        IDS_CONFIG_71           Speaker_Side
>
> Paulo, maybe you can run these commands to switch between
> linein/lineout modes:
>
>        # wget
> http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2
>
>        # set PIN_IN mode
>        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
>
>        # set PIN_OUT mode
>        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
>
> Thanks,
> Fengguang
> ---
>
> /proc/asound/card0/codec\#2
>
>        Codec: IDT 92HD73E1X5
>        Address: 2
>        Vendor Id: 0x111d7676
>        Subsystem Id: 0x80865002
>        Revision Id: 0x100202
>
>
> AUD_allOS_6033.2_PV_IDTGUI_v124/WDM/WinXP/Sthda.ini
>
>        # sthda.INI
>        [Models]
>        ...
>        HDAUDIO\FUNC_01&VEN_111D&DEV_7676&SUBSYS_80865002=I73E-EL2.INI
>        ...
>
>
> AUD_allOS_6033.2_PV_IDTGUI_v124/WDM/WinXP/I73E-EL2.INI
>
>        [HKR\Settings\Pin\0C]
>        CfgDflt                         = dword: 0x01113214
>        AltCfg                          = hex: 5E,32,81,01
>        AssignedDAC     = hex: 0x18
>
>
> /proc/asound/card0/codec\#2
>
>        Node 0x0c [Pin Complex] wcaps 0x400183: Stereo Amp-In
>          Amp-In caps: N/A
>          Amp-In vals:  [0x00 0x00]
>          Pincap 0x00001737: IN OUT Detect Trigger ImpSense
>            Vref caps: HIZ 50 GRD 80
>           Pin Default 0x01113014: [Jack] Speaker at Ext Rear
>             Conn = 1/8, Color = Blue
>            DefAssociation = 0x1, Sequence = 0x4
>          Pin-ctls: 0x40: OUT VREF_HIZ
>          Unsolicited: tag=04, enabled=1
>          Connection: 6
>             0x15 0x16 0x17 0x18* 0x19 0x1e



Thanks a lot, Fengguang.

The other models for this codec are for Dell computers.
Probably, all of then will behave the same way, right?

I still have a question. I see that you  changed Pin Default 0x01113014,
for 0x01813021, in the driver for having LineIn.
Also, Pin-ctls: 0x40 should provide the pin as an output. The Node is 0x0c.

Therefore,

# set PIN_OUT mode
       hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40

 makes sense.

But how would I know that 0x20 would turn the pin 0x0c into LineIn?

  # set PIN_IN mode
       hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20

I am asking because I have a Dell laptop (Vostro 1400) where the external
mic
works when I use model=ref (and I loose the speakers in this case), but not
when I use model=dell-3stack. If I could figure out how to switch
the pin using hda-verb in this case, would solve my problems when using
skype.


-- 
Paulo Roma Cavalcanti
LCG - UFRJ

Re: idt blue jack patch

[Wu Fengguang]

On Fri, Feb 20, 2009 at 12:15:16PM +0200, Paulo Cavalcanti wrote:
> 
> 
> On Thu, Feb 19, 2009 at 10:00 PM, Wu Fengguang <fengguang.wu@intel.com<mailto:fengguang.wu@intel.com>> wrote:
> Hi Tobin,
> 
> Here are the Linux and WinXP pin configurations.
> Both Linux and WinXP configure node 0x0c as an output pin.
> 
> However the driver seems to be offering three schemes:
> 
>        scheme desc             0xC dev
> ------------------------------------------------------
>        IDS_CONFIG_OPEN         Speaker_Side/LineIn
>        IDS_CONFIG_51           LineIn
>        IDS_CONFIG_71           Speaker_Side
> 
> Paulo, maybe you can run these commands to switch between
> linein/lineout modes:
> 
>        # wget http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2
> 
>        # set PIN_IN mode
>        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> 
>        # set PIN_OUT mode
>        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> 
> Thanks,
> Fengguang
> ---
> 
> /proc/asound/card0/codec\#2
> 
>        Codec: IDT 92HD73E1X5
>        Address: 2
>        Vendor Id: 0x111d7676
>        Subsystem Id: 0x80865002
>        Revision Id: 0x100202
> 
> 
> AUD_allOS_6033.2_PV_IDTGUI_v124/WDM/WinXP/Sthda.ini
> 
>        # sthda.INI
>        [Models]
>        ...
>        HDAUDIO\FUNC_01&VEN_111D&DEV_7676&SUBSYS_80865002=I73E-EL2.INI
>        ...
> 
> 
> AUD_allOS_6033.2_PV_IDTGUI_v124/WDM/WinXP/I73E-EL2.INI
> 
>        [HKR\Settings\Pin\0C]
>        CfgDflt                         = dword: 0x01113214
>        AltCfg                          = hex: 5E,32,81,01
>        AssignedDAC     = hex: 0x18
> 
> 
> /proc/asound/card0/codec\#2
> 
>        Node 0x0c [Pin Complex] wcaps 0x400183: Stereo Amp-In
>          Amp-In caps: N/A
>          Amp-In vals:  [0x00 0x00]
>          Pincap 0x00001737: IN OUT Detect Trigger ImpSense
>            Vref caps: HIZ 50 GRD 80
>          Pin Default 0x01113014: [Jack] Speaker at Ext Rear
>            Conn = 1/8, Color = Blue
>            DefAssociation = 0x1, Sequence = 0x4
>          Pin-ctls: 0x40: OUT VREF_HIZ
>          Unsolicited: tag=04, enabled=1
>          Connection: 6
>             0x15 0x16 0x17 0x18* 0x19 0x1e
> 
> 
> Thanks a lot, Fengguang.
> 
> The other models for this codec are for Dell computers.
> Probably, all of then will behave the same way, right?

I guess the hda-verb commands will work for all IN/OUT configurable pins.

> I still have a question. I see that you  changed Pin Default 0x01113014,
> for 0x01813021, in the driver for having LineIn.
> Also, Pin-ctls: 0x40 should provide the pin as an output. The Node is 0x0c.
> 
> Therefore,
> 
> # set PIN_OUT mode
>        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> 
>  makes sense.
> 
> But how would I know that 0x20 would turn the pin 0x0c into LineIn?
> 
>   # set PIN_IN mode
>        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20

ALSA defined the following values according to the HDA spec:

        /* Pin widget control - 8bit */
        #define AC_PINCTL_IN_EN                 (1<<5)
        #define AC_PINCTL_OUT_EN                (1<<6)
        #define AC_PINCTL_HP_EN                 (1<<7)

        #define PIN_IN                  (AC_PINCTL_IN_EN)
        #define PIN_OUT                 (AC_PINCTL_OUT_EN)
        #define PIN_HP                  (AC_PINCTL_OUT_EN | AC_PINCTL_HP_EN)

So PIN_OUT=0x40 and PIN_IN=0x20.

> I am asking because I have a Dell laptop (Vostro 1400) where the external mic
> works when I use model=ref (and I loose the speakers in this case), but not
> when I use model=dell-3stack. If I could figure out how to switch
> the pin using hda-verb in this case, would solve my problems when using skype.

You can locate the external mic pin in /proc/asound/card0/codec#* and
feed its node id to the hda-verb command. It should work the same way.

Thanks,
Fengguang

Re: idt blue jack patch

[Paulo Cavalcanti]

On Fri, Feb 20, 2009 at 8:20 AM, Wu Fengguang <fengguang.wu@intel.com>wrote:

> On Fri, Feb 20, 2009 at 12:15:16PM +0200, Paulo Cavalcanti wrote:
> >
> >
> > On Thu, Feb 19, 2009 at 10:00 PM, Wu Fengguang <fengguang.wu@intel.com
> <mailto:fengguang.wu@intel.com>> wrote:
> > Hi Tobin,
> >
> > Here are the Linux and WinXP pin configurations.
> > Both Linux and WinXP configure node 0x0c as an output pin.
> >
> > However the driver seems to be offering three schemes:
> >
> >        scheme desc             0xC dev
> > ------------------------------------------------------
> >        IDS_CONFIG_OPEN         Speaker_Side/LineIn
> >        IDS_CONFIG_51           LineIn
> >        IDS_CONFIG_71           Speaker_Side
> >
> > Paulo, maybe you can run these commands to switch between
> > linein/lineout modes:
> >
> >        # wget
> http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2
> >
> >        # set PIN_IN mode
> >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> >
> >        # set PIN_OUT mode
> >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> >
> > Thanks,
> > Fengguang
> > ---
> >
> > /proc/asound/card0/codec\#2
> >
> >        Codec: IDT 92HD73E1X5
> >        Address: 2
> >        Vendor Id: 0x111d7676
> >        Subsystem Id: 0x80865002
> >        Revision Id: 0x100202
> >
> >
> > AUD_allOS_6033.2_PV_IDTGUI_v124/WDM/WinXP/Sthda.ini
> >
> >        # sthda.INI
> >        [Models]
> >        ...
> >        HDAUDIO\FUNC_01&VEN_111D&DEV_7676&SUBSYS_80865002=I73E-EL2.INI
> >        ...
> >
> >
> > AUD_allOS_6033.2_PV_IDTGUI_v124/WDM/WinXP/I73E-EL2.INI
> >
> >        [HKR\Settings\Pin\0C]
> >        CfgDflt                         = dword: 0x01113214
> >        AltCfg                          = hex: 5E,32,81,01
> >        AssignedDAC     = hex: 0x18
> >
> >
> > /proc/asound/card0/codec\#2
> >
> >        Node 0x0c [Pin Complex] wcaps 0x400183: Stereo Amp-In
> >          Amp-In caps: N/A
> >          Amp-In vals:  [0x00 0x00]
> >          Pincap 0x00001737: IN OUT Detect Trigger ImpSense
> >            Vref caps: HIZ 50 GRD 80
> >          Pin Default 0x01113014: [Jack] Speaker at Ext Rear
> >            Conn = 1/8, Color = Blue
> >            DefAssociation = 0x1, Sequence = 0x4
> >          Pin-ctls: 0x40: OUT VREF_HIZ
> >          Unsolicited: tag=04, enabled=1
> >          Connection: 6
> >             0x15 0x16 0x17 0x18* 0x19 0x1e
> >
> >
> > Thanks a lot, Fengguang.
> >
> > The other models for this codec are for Dell computers.
> > Probably, all of then will behave the same way, right?
>
> I guess the hda-verb commands will work for all IN/OUT configurable pins.
>
> > I still have a question. I see that you  changed Pin Default 0x01113014,
> > for 0x01813021, in the driver for having LineIn.
> > Also, Pin-ctls: 0x40 should provide the pin as an output. The Node is
> 0x0c.
> >
> > Therefore,
> >
> > # set PIN_OUT mode
> >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> >
> >  makes sense.
> >
> > But how would I know that 0x20 would turn the pin 0x0c into LineIn?
> >
> >   # set PIN_IN mode
> >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
>
> ALSA defined the following values according to the HDA spec:
>
>        /* Pin widget control - 8bit */
>        #define AC_PINCTL_IN_EN                 (1<<5)
>        #define AC_PINCTL_OUT_EN                (1<<6)
>        #define AC_PINCTL_HP_EN                 (1<<7)
>
>        #define PIN_IN                  (AC_PINCTL_IN_EN)
>        #define PIN_OUT                 (AC_PINCTL_OUT_EN)
>        #define PIN_HP                  (AC_PINCTL_OUT_EN | AC_PINCTL_HP_EN)
>
> So PIN_OUT=0x40 and PIN_IN=0x20.
>
> > I am asking because I have a Dell laptop (Vostro 1400) where the external
> mic
> > works when I use model=ref (and I loose the speakers in this case), but
> not
> > when I use model=dell-3stack. If I could figure out how to switch
> > the pin using hda-verb in this case, would solve my problems when using
> skype.
>
> You can locate the external mic pin in /proc/asound/card0/codec#* and
> feed its node id to the hda-verb command. It should work the same way.


This is from model=ref. I can see it defines Line In as the
pin 0xe (exactly the jack marked as mic in the Vostro 1400).
This is how it should be.

Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x00001737: IN OUT Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x0181304e: [Jack] Line In at Ext Rear
    Conn = 1/8, Color = Blue
    DefAssociation = 0x4, Sequence = 0xe
  Pin-ctls: 0x20: IN VREF_HIZ
  Unsolicited: tag=04, enabled=1
  Connection: 1
     0x03

----------------------------------

This is from model=dell-3stack. There is no Line In defined. This
is the problem....


Node 0x10 [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x00000037: IN OUT Detect Trigger ImpSense
  Pin Default 0x01813050: [Jack] Line In at Ext Rear
    Conn = 1/8, Color = Blue
    DefAssociation = 0x5, Sequence = 0x0
  Pin-ctls: 0x20: IN
  Unsolicited: tag=04, enabled=1
  Connection: 1
     0x04


The question is: how can I use hda-verb to make pin 0xe
be an input pin (0x20), the way it were when using model = ref?

set PIN_IN mode:
        hda-verb /dev/snd/hwC0D0 0x0c SET_PIN_WIDGET_CONTROL 0x20

The node is 0x0c, but I am not sure if it is that simple.

Thanks.



-- 
Paulo Roma Cavalcanti
LCG - UFRJ

Re: idt blue jack patch

[Wu Fengguang]

On Fri, Feb 20, 2009 at 04:16:52PM +0200, Paulo Cavalcanti wrote:
> 
> 
> On Fri, Feb 20, 2009 at 8:20 AM, Wu Fengguang <fengguang.wu@intel.com<mailto:fengguang.wu@intel.com>> wrote:
> On Fri, Feb 20, 2009 at 12:15:16PM +0200, Paulo Cavalcanti wrote:
> >
> >
> > On Thu, Feb 19, 2009 at 10:00 PM, Wu Fengguang <fengguang.wu@intel.com<mailto:fengguang.wu@intel.com><mailto:fengguang.wu@intel.com<mailto:fengguang.wu@intel.com>>> wrote:
> > Hi Tobin,
> >
> > Here are the Linux and WinXP pin configurations.
> > Both Linux and WinXP configure node 0x0c as an output pin.
> >
> > However the driver seems to be offering three schemes:
> >
> >        scheme desc             0xC dev
> > ------------------------------------------------------
> >        IDS_CONFIG_OPEN         Speaker_Side/LineIn
> >        IDS_CONFIG_51           LineIn
> >        IDS_CONFIG_71           Speaker_Side
> >
> > Paulo, maybe you can run these commands to switch between
> > linein/lineout modes:
> >
> >        # wget http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2
> >
> >        # set PIN_IN mode
> >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> >
> >        # set PIN_OUT mode
> >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> >
> > Thanks,
> > Fengguang
> > ---
> >
> > /proc/asound/card0/codec\#2
> >
> >        Codec: IDT 92HD73E1X5
> >        Address: 2
> >        Vendor Id: 0x111d7676
> >        Subsystem Id: 0x80865002
> >        Revision Id: 0x100202
> >
> >
> > AUD_allOS_6033.2_PV_IDTGUI_v124/WDM/WinXP/Sthda.ini
> >
> >        # sthda.INI
> >        [Models]
> >        ...
> >        HDAUDIO\FUNC_01&VEN_111D&DEV_7676&SUBSYS_80865002=I73E-EL2.INI
> >        ...
> >
> >
> > AUD_allOS_6033.2_PV_IDTGUI_v124/WDM/WinXP/I73E-EL2.INI
> >
> >        [HKR\Settings\Pin\0C]
> >        CfgDflt                         = dword: 0x01113214
> >        AltCfg                          = hex: 5E,32,81,01
> >        AssignedDAC     = hex: 0x18
> >
> >
> > /proc/asound/card0/codec\#2
> >
> >        Node 0x0c [Pin Complex] wcaps 0x400183: Stereo Amp-In
> >          Amp-In caps: N/A
> >          Amp-In vals:  [0x00 0x00]
> >          Pincap 0x00001737: IN OUT Detect Trigger ImpSense
> >            Vref caps: HIZ 50 GRD 80
> >          Pin Default 0x01113014: [Jack] Speaker at Ext Rear
> >            Conn = 1/8, Color = Blue
> >            DefAssociation = 0x1, Sequence = 0x4
> >          Pin-ctls: 0x40: OUT VREF_HIZ
> >          Unsolicited: tag=04, enabled=1
> >          Connection: 6
> >             0x15 0x16 0x17 0x18* 0x19 0x1e
> >
> >
> > Thanks a lot, Fengguang.
> >
> > The other models for this codec are for Dell computers.
> > Probably, all of then will behave the same way, right?
> 
> I guess the hda-verb commands will work for all IN/OUT configurable pins.
> 
> > I still have a question. I see that you  changed Pin Default 0x01113014,
> > for 0x01813021, in the driver for having LineIn.
> > Also, Pin-ctls: 0x40 should provide the pin as an output. The Node is 0x0c.
> >
> > Therefore,
> >
> > # set PIN_OUT mode
> >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> >
> >  makes sense.
> >
> > But how would I know that 0x20 would turn the pin 0x0c into LineIn?
> >
> >   # set PIN_IN mode
> >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> 
> ALSA defined the following values according to the HDA spec:
> 
>        /* Pin widget control - 8bit */
>        #define AC_PINCTL_IN_EN                 (1<<5)
>        #define AC_PINCTL_OUT_EN                (1<<6)
>        #define AC_PINCTL_HP_EN                 (1<<7)
> 
>        #define PIN_IN                  (AC_PINCTL_IN_EN)
>        #define PIN_OUT                 (AC_PINCTL_OUT_EN)
>        #define PIN_HP                  (AC_PINCTL_OUT_EN | AC_PINCTL_HP_EN)
> 
> So PIN_OUT=0x40 and PIN_IN=0x20.
> 
> > I am asking because I have a Dell laptop (Vostro 1400) where the external mic
> > works when I use model=ref (and I loose the speakers in this case), but not
> > when I use model=dell-3stack. If I could figure out how to switch
> > the pin using hda-verb in this case, would solve my problems when using skype.
> 
> You can locate the external mic pin in /proc/asound/card0/codec#* and
> feed its node id to the hda-verb command. It should work the same way.
> 
> This is from model=ref. I can see it defines Line In as the
> pin 0xe (exactly the jack marked as mic in the Vostro 1400).
> This is how it should be.
> 

But you pasted info for 0x0c instead of 0xe below...
Would you provide the full codec file?

> Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
>   Pincap 0x00001737: IN OUT Detect Trigger ImpSense
>     Vref caps: HIZ 50 GRD 80
>   Pin Default 0x0181304e: [Jack] Line In at Ext Rear
>     Conn = 1/8, Color = Blue
>     DefAssociation = 0x4, Sequence = 0xe
>   Pin-ctls: 0x20: IN VREF_HIZ
>   Unsolicited: tag=04, enabled=1
>   Connection: 1
>      0x03
> 
> ----------------------------------
> 
> This is from model=dell-3stack. There is no Line In defined. This
> is the problem....
> 
> 
> Node 0x10 [Pin Complex] wcaps 0x400181: Stereo
>   Pincap 0x00000037: IN OUT Detect Trigger ImpSense
>   Pin Default 0x01813050: [Jack] Line In at Ext Rear
>     Conn = 1/8, Color = Blue
>     DefAssociation = 0x5, Sequence = 0x0
>   Pin-ctls: 0x20: IN
>   Unsolicited: tag=04, enabled=1
>   Connection: 1
>      0x04
> 
> 
> The question is: how can I use hda-verb to make pin 0xe
> be an input pin (0x20), the way it were when using model = ref?

Where is Node 0x0e? You didn't paste Node 0x0e info, but 0x0c and 0x10.

> set PIN_IN mode:
>         hda-verb /dev/snd/hwC0D0 0x0c SET_PIN_WIDGET_CONTROL 0x20
> 
> The node is 0x0c, but I am not sure if it is that simple.

It's trivial to try it out, its harmless anyway :)
You only have to replace 0x0c with your mic node.

Thanks,
Fengguang

Re: idt blue jack patch

[Paulo Cavalcanti]

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

On Fri, Feb 20, 2009 at 11:31 AM, Wu Fengguang <fengguang.wu@intel.com>wrote:

> On Fri, Feb 20, 2009 at 04:16:52PM +0200, Paulo Cavalcanti wrote:
> >
> >
> > On Fri, Feb 20, 2009 at 8:20 AM, Wu Fengguang <fengguang.wu@intel.com
> <mailto:fengguang.wu@intel.com>> wrote:
> > On Fri, Feb 20, 2009 at 12:15:16PM +0200, Paulo Cavalcanti wrote:
> > >
> > >
> > > On Thu, Feb 19, 2009 at 10:00 PM, Wu Fengguang <fengguang.wu@intel.com
> <mailto:fengguang.wu@intel.com><mailto:fengguang.wu@intel.com<mailto:
> fengguang.wu@intel.com>>> wrote:
> > > Hi Tobin,
> > >
> > > Here are the Linux and WinXP pin configurations.
> > > Both Linux and WinXP configure node 0x0c as an output pin.
> > >
> > > However the driver seems to be offering three schemes:
> > >
> > >        scheme desc             0xC dev
> > > ------------------------------------------------------
> > >        IDS_CONFIG_OPEN         Speaker_Side/LineIn
> > >        IDS_CONFIG_51           LineIn
> > >        IDS_CONFIG_71           Speaker_Side
> > >
> > > Paulo, maybe you can run these commands to switch between
> > > linein/lineout modes:
> > >
> > >        # wget
> http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2
> > >
> > >        # set PIN_IN mode
> > >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> > >
> > >        # set PIN_OUT mode
> > >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> > >
> > > Thanks,
> > > Fengguang
> > > ---
> > >
> > > /proc/asound/card0/codec\#2
> > >
> > >        Codec: IDT 92HD73E1X5
> > >        Address: 2
> > >        Vendor Id: 0x111d7676
> > >        Subsystem Id: 0x80865002
> > >        Revision Id: 0x100202
> > >
> > >
> > > AUD_allOS_6033.2_PV_IDTGUI_v124/WDM/WinXP/Sthda.ini
> > >
> > >        # sthda.INI
> > >        [Models]
> > >        ...
> > >        HDAUDIO\FUNC_01&VEN_111D&DEV_7676&SUBSYS_80865002=I73E-EL2.INI
> > >        ...
> > >
> > >
> > > AUD_allOS_6033.2_PV_IDTGUI_v124/WDM/WinXP/I73E-EL2.INI
> > >
> > >        [HKR\Settings\Pin\0C]
> > >        CfgDflt                         = dword: 0x01113214
> > >        AltCfg                          = hex: 5E,32,81,01
> > >        AssignedDAC     = hex: 0x18
> > >
> > >
> > > /proc/asound/card0/codec\#2
> > >
> > >        Node 0x0c [Pin Complex] wcaps 0x400183: Stereo Amp-In
> > >          Amp-In caps: N/A
> > >          Amp-In vals:  [0x00 0x00]
> > >          Pincap 0x00001737: IN OUT Detect Trigger ImpSense
> > >            Vref caps: HIZ 50 GRD 80
> > >          Pin Default 0x01113014: [Jack] Speaker at Ext Rear
> > >            Conn = 1/8, Color = Blue
> > >            DefAssociation = 0x1, Sequence = 0x4
> > >          Pin-ctls: 0x40: OUT VREF_HIZ
> > >          Unsolicited: tag=04, enabled=1
> > >          Connection: 6
> > >             0x15 0x16 0x17 0x18* 0x19 0x1e
> > >
> > >
> > > Thanks a lot, Fengguang.
> > >
> > > The other models for this codec are for Dell computers.
> > > Probably, all of then will behave the same way, right?
> >
> > I guess the hda-verb commands will work for all IN/OUT configurable pins.
> >
> > > I still have a question. I see that you  changed Pin Default
> 0x01113014,
> > > for 0x01813021, in the driver for having LineIn.
> > > Also, Pin-ctls: 0x40 should provide the pin as an output. The Node is
> 0x0c.
> > >
> > > Therefore,
> > >
> > > # set PIN_OUT mode
> > >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> > >
> > >  makes sense.
> > >
> > > But how would I know that 0x20 would turn the pin 0x0c into LineIn?
> > >
> > >   # set PIN_IN mode
> > >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> >
> > ALSA defined the following values according to the HDA spec:
> >
> >        /* Pin widget control - 8bit */
> >        #define AC_PINCTL_IN_EN                 (1<<5)
> >        #define AC_PINCTL_OUT_EN                (1<<6)
> >        #define AC_PINCTL_HP_EN                 (1<<7)
> >
> >        #define PIN_IN                  (AC_PINCTL_IN_EN)
> >        #define PIN_OUT                 (AC_PINCTL_OUT_EN)
> >        #define PIN_HP                  (AC_PINCTL_OUT_EN |
> AC_PINCTL_HP_EN)
> >
> > So PIN_OUT=0x40 and PIN_IN=0x20.
> >
> > > I am asking because I have a Dell laptop (Vostro 1400) where the
> external mic
> > > works when I use model=ref (and I loose the speakers in this case), but
> not
> > > when I use model=dell-3stack. If I could figure out how to switch
> > > the pin using hda-verb in this case, would solve my problems when using
> skype.
> >
> > You can locate the external mic pin in /proc/asound/card0/codec#* and
> > feed its node id to the hda-verb command. It should work the same way.
> >
> > This is from model=ref. I can see it defines Line In as the
> > pin 0xe (exactly the jack marked as mic in the Vostro 1400).
> > This is how it should be.
> >
>
> But you pasted info for 0x0c instead of 0xe below...
> Would you provide the full codec file?
>
> > Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
> >   Pincap 0x00001737: IN OUT Detect Trigger ImpSense
> >     Vref caps: HIZ 50 GRD 80
> >   Pin Default 0x0181304e: [Jack] Line In at Ext Rear
> >     Conn = 1/8, Color = Blue
> >     DefAssociation = 0x4, Sequence = 0xe
> >   Pin-ctls: 0x20: IN VREF_HIZ
> >   Unsolicited: tag=04, enabled=1
> >   Connection: 1
> >      0x03
> >
> > ----------------------------------
> >
> > This is from model=dell-3stack. There is no Line In defined. This
> > is the problem....
> >
> >
> > Node 0x10 [Pin Complex] wcaps 0x400181: Stereo
> >   Pincap 0x00000037: IN OUT Detect Trigger ImpSense
> >   Pin Default 0x01813050: [Jack] Line In at Ext Rear
> >     Conn = 1/8, Color = Blue
> >     DefAssociation = 0x5, Sequence = 0x0
> >   Pin-ctls: 0x20: IN
> >   Unsolicited: tag=04, enabled=1
> >   Connection: 1
> >      0x04
> >
> >
> > The question is: how can I use hda-verb to make pin 0xe
> > be an input pin (0x20), the way it were when using model = ref?
>
> Where is Node 0x0e? You didn't paste Node 0x0e info, but 0x0c and 0x10.
>
> > set PIN_IN mode:
> >         hda-verb /dev/snd/hwC0D0 0x0c SET_PIN_WIDGET_CONTROL 0x20
> >
> > The node is 0x0c, but I am not sure if it is that simple.
>
> It's trivial to try it out, its harmless anyway :)
> You only have to replace 0x0c with your mic node.
>
>
Using hda-verb-0.3, the pins are:

0xa - headphones (first connector - the one which works)
0xf - headphones (second connector  - no output)
0xe - analog mic

I am attaching the dell-3stack codec and the ref codec.

This laptop has a digital Mic and a jack for connecting an analog
mic, ehich I am supposing it is the "Line In" in the "model=ref" codec.

The dell-3tack model works well, but I have no analog mic, and the
digital mic sounds too low to be usable.

If you could give me a hand with this matter, I would
be very grateful.

Thanks.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ

[-- Attachment #2: dell-3stack.txt --]
[-- Type: text/plain, Size: 8709 bytes --]

Codec: SigmaTel STAC9228
Address: 0
Vendor Id: 0x83847616
Subsystem Id: 0x10280227
Revision Id: 0x100201
No Modem Function Group found
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=0x0e, stepsize=0x05, mute=0
Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1
GPIO: io=3, o=0, i=0, unsolicited=1, wake=1
  IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[2]: enable=1, dir=1, wake=0, sticky=0, data=1, unsol=0
Analog Loopback: 0x00
Node 0x02 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
  Amp-Out caps: N/A
  Amp-Out vals:  [0x5b 0x5b]
  Converter: stream=5, channel=0
  Power: setting=D0, actual=D0
  Delay: 13 samples
Node 0x03 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
  Amp-Out caps: N/A
  Amp-Out vals:  [0xdc 0xdc]
  Converter: stream=5, channel=0
  Power: setting=D0, actual=D0
  Delay: 13 samples
Node 0x04 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
  Amp-Out caps: N/A
  Amp-Out vals:  [0xdc 0xdc]
  Converter: stream=5, channel=0
  Power: setting=D0, actual=D0
  Delay: 13 samples
Node 0x05 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
  Amp-Out caps: N/A
  Amp-Out vals:  [0xdc 0xdc]
  Converter: stream=5, channel=0
  Power: setting=D0, actual=D0
  Delay: 13 samples
Node 0x06 [Vendor Defined Widget] wcaps 0xfd0c05: Stereo Amp-Out R/L
  Amp-Out caps: N/A
  Amp-Out vals:  [0xff 0xff]
  Power: setting=D3, actual=D3
  Delay: 13 samples
Node 0x07 [Audio Input] wcaps 0x1d0541: Stereo
  Converter: stream=1, channel=0
  SDI-Select: 0
  Power: setting=D0, actual=D0
  Delay: 13 samples
  Connection: 1
     0x1b
  Processing caps: benign=0, ncoeff=0
Node 0x08 [Audio Input] wcaps 0x1d0541: Stereo
  Converter: stream=0, channel=0
  SDI-Select: 0
  Power: setting=D0, actual=D0
  Delay: 13 samples
  Connection: 1
     0x1c
  Processing caps: benign=0, ncoeff=0
Node 0x09 [Audio Input] wcaps 0x1d0541: Stereo
  Converter: stream=0, channel=0
  SDI-Select: 0
  Power: setting=D0, actual=D0
  Delay: 13 samples
  Connection: 1
     0x1d
  Processing caps: benign=0, ncoeff=0
Node 0x0a [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x0000173f: IN OUT HP Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x02211230: [Jack] HP Out at Ext Front
    Conn = 1/8, Color = Black
    DefAssociation = 0x3, Sequence = 0x0
  Pin-ctls: 0x00: VREF_HIZ
  Unsolicited: tag=01, enabled=1
  Connection: 2
     0x02* 0x03
Node 0x0b [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x0000173f: IN OUT HP Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x02a11220: [Jack] Mic at Ext Front
    Conn = 1/8, Color = Black
    DefAssociation = 0x2, Sequence = 0x0
  Pin-ctls: 0x24: IN VREF_80
  Unsolicited: tag=03, enabled=1
  Connection: 2
     0x02 0x03*
Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x00001737: IN OUT Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x01a19040: [Jack] Mic at Ext Rear
    Conn = 1/8, Color = Pink
    DefAssociation = 0x4, Sequence = 0x0
  Pin-ctls: 0x24: IN VREF_80
  Unsolicited: tag=02, enabled=1
  Connection: 1
     0x03
Node 0x0d [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x0000173f: IN OUT HP Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x01114210: [Jack] Speaker at Ext Rear
    Conn = 1/8, Color = Green
    DefAssociation = 0x1, Sequence = 0x0
  Pin-ctls: 0x40: OUT VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x02
Node 0x0e [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x00001737: IN OUT Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x01111212: [Jack] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0x1, Sequence = 0x2
  Pin-ctls: 0x40: OUT VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x04
Node 0x0f [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x00001737: IN OUT Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x01116211: [Jack] Speaker at Ext Rear
    Conn = 1/8, Color = Orange
    DefAssociation = 0x1, Sequence = 0x1
  Pin-ctls: 0x40: OUT VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x05
Node 0x10 [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x00000037: IN OUT Detect Trigger ImpSense
  Pin Default 0x01813050: [Jack] Line In at Ext Rear
    Conn = 1/8, Color = Blue
    DefAssociation = 0x5, Sequence = 0x0
  Pin-ctls: 0x20: IN
  Unsolicited: tag=04, enabled=1
  Connection: 1
     0x04
Node 0x11 [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x00000037: IN OUT Detect Trigger ImpSense
  Pin Default 0x01112214: [Jack] Speaker at Ext Rear
    Conn = 1/8, Color = Grey
    DefAssociation = 0x1, Sequence = 0x4
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x03
Node 0x12 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x00000020: IN
  Pin Default 0x403003fa: [N/A] CD at Ext N/A
    Conn = Unknown, Color = Unknown
    DefAssociation = 0xf, Sequence = 0xa
    Misc = NO_PRESENCE
  Pin-ctls: 0x00:
Node 0x13 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x00000020: IN
  Pin Default 0x90a60040: [Fixed] Mic at Int N/A
    Conn = Digital, Color = Unknown
    DefAssociation = 0x4, Sequence = 0x0
  Pin-ctls: 0x20: IN
Node 0x14 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x00000020: IN
  Pin Default 0x90a60040: [Fixed] Mic at Int N/A
    Conn = Digital, Color = Unknown
    DefAssociation = 0x4, Sequence = 0x0
  Pin-ctls: 0x20: IN
Node 0x15 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x04 0x04]
  Connection: 9
     0x0e 0x12 0x0f 0x0b 0x0c* 0x0d 0x0a 0x10 0x11
Node 0x16 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 9
     0x0e 0x12 0x0f 0x0b 0x0c* 0x0d 0x0a 0x10 0x11
Node 0x17 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 9
     0x0e 0x12 0x0f 0x0b 0x0c* 0x0d 0x0a 0x10 0x11
Node 0x18 [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Amp-In caps: N/A
  Amp-In vals:  [0x06 0x06]
  Connection: 1
     0x15
Node 0x19 [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Amp-In caps: N/A
  Amp-In vals:  [0x00 0x00]
  Connection: 1
     0x16
Node 0x1a [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Amp-In caps: N/A
  Amp-In vals:  [0x00 0x00]
  Connection: 1
     0x17
Node 0x1b [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Connection: 3
     0x18 0x13* 0x14
Node 0x1c [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Connection: 3
     0x19* 0x13 0x14
Node 0x1d [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Connection: 3
     0x1a* 0x13 0x14
Node 0x1e [Audio Output] wcaps 0x40211: Stereo Digital
  Converter: stream=0, channel=0
  Digital:
  Digital category: 0x0
  PCM:
    rates [0x7e0]: 44100 48000 88200 96000 176400 192000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
  Delay: 4 samples
Node 0x1f [Vendor Defined Widget] wcaps 0xf30201: Stereo Digital
  Delay: 3 samples
Node 0x20 [Audio Input] wcaps 0x140311: Stereo Digital
  Converter: stream=0, channel=0
  SDI-Select: 0
  Digital:
  Digital category: 0x0
  PCM:
    rates [0x160]: 44100 48000 96000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
  Delay: 4 samples
  Connection: 1
     0x22
Node 0x21 [Pin Complex] wcaps 0x400301: Stereo Digital
  Pincap 0x00000010: OUT
  Pin Default 0x404003fb: [N/A] SPDIF Out at Ext N/A
    Conn = Unknown, Color = Unknown
    DefAssociation = 0xf, Sequence = 0xb
    Misc = NO_PRESENCE
  Pin-ctls: 0x00:
  Connection: 5
     0x1e* 0x1f 0x1b 0x1c 0x1d
Node 0x22 [Pin Complex] wcaps 0x430681: Stereo Digital
  Pincap 0x00010024: IN EAPD Detect
  EAPD 0x0:
  Pin Default 0x40c003fc: [N/A] SPDIF In at Ext N/A
    Conn = Unknown, Color = Unknown
    DefAssociation = 0xf, Sequence = 0xc
    Misc = NO_PRESENCE
  Pin-ctls: 0x00:
  Unsolicited: tag=00, enabled=0
  Power: setting=D0, actual=D0
  Delay: 3 samples
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
  Volume-Knob: delta=1, steps=127, direct=1, val=127
  Connection: 4
     0x02* 0x03 0x04 0x05

[-- Attachment #3: ref.txt --]
[-- Type: text/plain, Size: 8729 bytes --]

Codec: SigmaTel STAC9228
Address: 0
Vendor Id: 0x83847616
Subsystem Id: 0x10280227
Revision Id: 0x100201
No Modem Function Group found
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=0x0e, stepsize=0x05, mute=0
Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1
GPIO: io=3, o=0, i=0, unsolicited=1, wake=1
  IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
Analog Loopback: 0x00
Node 0x02 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
  Amp-Out caps: N/A
  Amp-Out vals:  [0x49 0x49]
  Converter: stream=0, channel=0
  Power: setting=D0, actual=D0
  Delay: 13 samples
Node 0x03 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
  Amp-Out caps: N/A
  Amp-Out vals:  [0xe4 0xe4]
  Converter: stream=0, channel=0
  Power: setting=D0, actual=D0
  Delay: 13 samples
Node 0x04 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
  Amp-Out caps: N/A
  Amp-Out vals:  [0xe4 0xe4]
  Converter: stream=0, channel=0
  Power: setting=D0, actual=D0
  Delay: 13 samples
Node 0x05 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
  Amp-Out caps: N/A
  Amp-Out vals:  [0xe4 0xe4]
  Converter: stream=0, channel=0
  Power: setting=D0, actual=D0
  Delay: 13 samples
Node 0x06 [Vendor Defined Widget] wcaps 0xfd0c05: Stereo Amp-Out R/L
  Amp-Out caps: N/A
  Amp-Out vals:  [0xff 0xff]
  Power: setting=D3, actual=D3
  Delay: 13 samples
Node 0x07 [Audio Input] wcaps 0x1d0541: Stereo
  Converter: stream=0, channel=0
  SDI-Select: 0
  Power: setting=D0, actual=D0
  Delay: 13 samples
  Connection: 1
     0x1b
  Processing caps: benign=0, ncoeff=0
Node 0x08 [Audio Input] wcaps 0x1d0541: Stereo
  Converter: stream=0, channel=0
  SDI-Select: 0
  Power: setting=D0, actual=D0
  Delay: 13 samples
  Connection: 1
     0x1c
  Processing caps: benign=0, ncoeff=0
Node 0x09 [Audio Input] wcaps 0x1d0541: Stereo
  Converter: stream=0, channel=0
  SDI-Select: 0
  Power: setting=D0, actual=D0
  Delay: 13 samples
  Connection: 1
     0x1d
  Processing caps: benign=0, ncoeff=0
Node 0x0a [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x0000173f: IN OUT HP Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x02214020: [Jack] HP Out at Ext Front
    Conn = 1/8, Color = Green
    DefAssociation = 0x2, Sequence = 0x0
  Pin-ctls: 0x00: VREF_HIZ
  Unsolicited: tag=01, enabled=1
  Connection: 2
     0x02* 0x03
Node 0x0b [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x0000173f: IN OUT HP Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x02a19080: [Jack] Mic at Ext Front
    Conn = 1/8, Color = Pink
    DefAssociation = 0x8, Sequence = 0x0
  Pin-ctls: 0x24: IN VREF_80
  Unsolicited: tag=03, enabled=1
  Connection: 2
     0x02* 0x03
Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x00001737: IN OUT Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x0181304e: [Jack] Line In at Ext Rear
    Conn = 1/8, Color = Blue
    DefAssociation = 0x4, Sequence = 0xe
  Pin-ctls: 0x20: IN VREF_HIZ
  Unsolicited: tag=04, enabled=1
  Connection: 1
     0x03
Node 0x0d [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x0000173f: IN OUT HP Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x01014010: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Green
    DefAssociation = 0x1, Sequence = 0x0
  Pin-ctls: 0x40: OUT VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x02
Node 0x0e [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x00001737: IN OUT Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x01a19040: [Jack] Mic at Ext Rear
    Conn = 1/8, Color = Pink
    DefAssociation = 0x4, Sequence = 0x0
  Pin-ctls: 0x24: IN VREF_80
  Unsolicited: tag=02, enabled=1
  Connection: 1
     0x04
Node 0x0f [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x00001737: IN OUT Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x01011012: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0x1, Sequence = 0x2
  Pin-ctls: 0x40: OUT VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x05
Node 0x10 [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x00000037: IN OUT Detect Trigger ImpSense
  Pin Default 0x01016011: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Orange
    DefAssociation = 0x1, Sequence = 0x1
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x04
Node 0x11 [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x00000037: IN OUT Detect Trigger ImpSense
  Pin Default 0x0101201f: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Grey
    DefAssociation = 0x1, Sequence = 0xf
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x03
Node 0x12 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x00000020: IN
  Pin Default 0x183301f0: [Jack] CD at Int HDMI
    Conn = ATAPI, Color = Unknown
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN
Node 0x13 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x00000020: IN
  Pin Default 0x18a001f0: [Jack] Mic at Int HDMI
    Conn = Unknown, Color = Unknown
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x00:
Node 0x14 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x00000020: IN
  Pin Default 0x18a001f0: [Jack] Mic at Int HDMI
    Conn = Unknown, Color = Unknown
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x00:
Node 0x15 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 9
     0x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11
Node 0x16 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 9
     0x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11
Node 0x17 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 9
     0x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11
Node 0x18 [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Amp-In caps: N/A
  Amp-In vals:  [0x0d 0x0d]
  Connection: 1
     0x15
Node 0x19 [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Amp-In caps: N/A
  Amp-In vals:  [0x00 0x00]
  Connection: 1
     0x16
Node 0x1a [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Amp-In caps: N/A
  Amp-In vals:  [0x00 0x00]
  Connection: 1
     0x17
Node 0x1b [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Connection: 3
     0x18* 0x13 0x14
Node 0x1c [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Connection: 3
     0x19* 0x13 0x14
Node 0x1d [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Connection: 3
     0x1a* 0x13 0x14
Node 0x1e [Audio Output] wcaps 0x40211: Stereo Digital
  Converter: stream=0, channel=0
  Digital:
  Digital category: 0x0
  PCM:
    rates [0x7e0]: 44100 48000 88200 96000 176400 192000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
  Delay: 4 samples
Node 0x1f [Vendor Defined Widget] wcaps 0xf30201: Stereo Digital
  Delay: 3 samples
Node 0x20 [Audio Input] wcaps 0x140311: Stereo Digital
  Converter: stream=0, channel=0
  SDI-Select: 0
  Digital:
  Digital category: 0x0
  PCM:
    rates [0x160]: 44100 48000 96000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
  Delay: 4 samples
  Connection: 1
     0x22
Node 0x21 [Pin Complex] wcaps 0x400301: Stereo Digital
  Pincap 0x00000010: OUT
  Pin Default 0x01442070: [Jack] SPDIF Out at Ext Rear
    Conn = RCA, Color = Grey
    DefAssociation = 0x7, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Connection: 5
     0x1e* 0x1f 0x1b 0x1c 0x1d
Node 0x22 [Pin Complex] wcaps 0x430681: Stereo Digital
  Pincap 0x00010024: IN EAPD Detect
  EAPD 0x0:
  Pin Default 0x01c42190: [Jack] SPDIF In at Ext Rear
    Conn = RCA, Color = Grey
    DefAssociation = 0x9, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN
  Unsolicited: tag=00, enabled=0
  Power: setting=D0, actual=D0
  Delay: 3 samples
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
  Volume-Knob: delta=1, steps=127, direct=1, val=127
  Connection: 4
     0x02* 0x03 0x04 0x05

[-- Attachment #4: 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: idt blue jack patch

[Wu Fengguang]

On Fri, Feb 20, 2009 at 06:07:03PM +0200, Paulo Cavalcanti wrote:
> 
> 
> On Fri, Feb 20, 2009 at 11:31 AM, Wu Fengguang <fengguang.wu@intel.com<mailto:fengguang.wu@intel.com>> wrote:
> On Fri, Feb 20, 2009 at 04:16:52PM +0200, Paulo Cavalcanti wrote:
> >
> >
> > On Fri, Feb 20, 2009 at 8:20 AM, Wu Fengguang <fengguang.wu@intel.com<mailto:fengguang.wu@intel.com><mailto:fengguang.wu@intel.com<mailto:fengguang.wu@intel.com>>> wrote:
> > On Fri, Feb 20, 2009 at 12:15:16PM +0200, Paulo Cavalcanti wrote:
> > >
> > >
> > > On Thu, Feb 19, 2009 at 10:00 PM, Wu Fengguang <fengguang.wu@intel.com<mailto:fengguang.wu@intel.com><mailto:fengguang.wu@intel.com<mailto:fengguang.wu@intel.com>><mailto:fengguang.wu@intel.com<mailto:fengguang.wu@intel.com><mailto:fengguang.wu@intel.com<mailto:fengguang.wu@intel.com>>>> wrote:
> > > Hi Tobin,
> > >
> > > Here are the Linux and WinXP pin configurations.
> > > Both Linux and WinXP configure node 0x0c as an output pin.
> > >
> > > However the driver seems to be offering three schemes:
> > >
> > >        scheme desc             0xC dev
> > > ------------------------------------------------------
> > >        IDS_CONFIG_OPEN         Speaker_Side/LineIn
> > >        IDS_CONFIG_51           LineIn
> > >        IDS_CONFIG_71           Speaker_Side
> > >
> > > Paulo, maybe you can run these commands to switch between
> > > linein/lineout modes:
> > >
> > >        # wget http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2
> > >
> > >        # set PIN_IN mode
> > >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> > >
> > >        # set PIN_OUT mode
> > >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> > >
> > > Thanks,
> > > Fengguang
> > > ---
> > >
> > > /proc/asound/card0/codec\#2
> > >
> > >        Codec: IDT 92HD73E1X5
> > >        Address: 2
> > >        Vendor Id: 0x111d7676
> > >        Subsystem Id: 0x80865002
> > >        Revision Id: 0x100202
> > >
> > >
> > > AUD_allOS_6033.2_PV_IDTGUI_v124/WDM/WinXP/Sthda.ini
> > >
> > >        # sthda.INI
> > >        [Models]
> > >        ...
> > >        HDAUDIO\FUNC_01&VEN_111D&DEV_7676&SUBSYS_80865002=I73E-EL2.INI
> > >        ...
> > >
> > >
> > > AUD_allOS_6033.2_PV_IDTGUI_v124/WDM/WinXP/I73E-EL2.INI
> > >
> > >        [HKR\Settings\Pin\0C]
> > >        CfgDflt                         = dword: 0x01113214
> > >        AltCfg                          = hex: 5E,32,81,01
> > >        AssignedDAC     = hex: 0x18
> > >
> > >
> > > /proc/asound/card0/codec\#2
> > >
> > >        Node 0x0c [Pin Complex] wcaps 0x400183: Stereo Amp-In
> > >          Amp-In caps: N/A
> > >          Amp-In vals:  [0x00 0x00]
> > >          Pincap 0x00001737: IN OUT Detect Trigger ImpSense
> > >            Vref caps: HIZ 50 GRD 80
> > >          Pin Default 0x01113014: [Jack] Speaker at Ext Rear
> > >            Conn = 1/8, Color = Blue
> > >            DefAssociation = 0x1, Sequence = 0x4
> > >          Pin-ctls: 0x40: OUT VREF_HIZ
> > >          Unsolicited: tag=04, enabled=1
> > >          Connection: 6
> > >             0x15 0x16 0x17 0x18* 0x19 0x1e
> > >
> > >
> > > Thanks a lot, Fengguang.
> > >
> > > The other models for this codec are for Dell computers.
> > > Probably, all of then will behave the same way, right?
> >
> > I guess the hda-verb commands will work for all IN/OUT configurable pins.
> >
> > > I still have a question. I see that you  changed Pin Default 0x01113014,
> > > for 0x01813021, in the driver for having LineIn.
> > > Also, Pin-ctls: 0x40 should provide the pin as an output. The Node is 0x0c.
> > >
> > > Therefore,
> > >
> > > # set PIN_OUT mode
> > >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> > >
> > >  makes sense.
> > >
> > > But how would I know that 0x20 would turn the pin 0x0c into LineIn?
> > >
> > >   # set PIN_IN mode
> > >        hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> >
> > ALSA defined the following values according to the HDA spec:
> >
> >        /* Pin widget control - 8bit */
> >        #define AC_PINCTL_IN_EN                 (1<<5)
> >        #define AC_PINCTL_OUT_EN                (1<<6)
> >        #define AC_PINCTL_HP_EN                 (1<<7)
> >
> >        #define PIN_IN                  (AC_PINCTL_IN_EN)
> >        #define PIN_OUT                 (AC_PINCTL_OUT_EN)
> >        #define PIN_HP                  (AC_PINCTL_OUT_EN | AC_PINCTL_HP_EN)
> >
> > So PIN_OUT=0x40 and PIN_IN=0x20.
> >
> > > I am asking because I have a Dell laptop (Vostro 1400) where the external mic
> > > works when I use model=ref (and I loose the speakers in this case), but not
> > > when I use model=dell-3stack. If I could figure out how to switch
> > > the pin using hda-verb in this case, would solve my problems when using skype.
> >
> > You can locate the external mic pin in /proc/asound/card0/codec#* and
> > feed its node id to the hda-verb command. It should work the same way.
> >
> > This is from model=ref. I can see it defines Line In as the
> > pin 0xe (exactly the jack marked as mic in the Vostro 1400).
> > This is how it should be.
> >
> 
> But you pasted info for 0x0c instead of 0xe below...
> Would you provide the full codec file?
> 
> > Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
> >   Pincap 0x00001737: IN OUT Detect Trigger ImpSense
> >     Vref caps: HIZ 50 GRD 80
> >   Pin Default 0x0181304e: [Jack] Line In at Ext Rear
> >     Conn = 1/8, Color = Blue
> >     DefAssociation = 0x4, Sequence = 0xe
> >   Pin-ctls: 0x20: IN VREF_HIZ
> >   Unsolicited: tag=04, enabled=1
> >   Connection: 1
> >      0x03
> >
> > ----------------------------------
> >
> > This is from model=dell-3stack. There is no Line In defined. This
> > is the problem....
> >
> >
> > Node 0x10 [Pin Complex] wcaps 0x400181: Stereo
> >   Pincap 0x00000037: IN OUT Detect Trigger ImpSense
> >   Pin Default 0x01813050: [Jack] Line In at Ext Rear
> >     Conn = 1/8, Color = Blue
> >     DefAssociation = 0x5, Sequence = 0x0
> >   Pin-ctls: 0x20: IN
> >   Unsolicited: tag=04, enabled=1
> >   Connection: 1
> >      0x04
> >
> >
> > The question is: how can I use hda-verb to make pin 0xe
> > be an input pin (0x20), the way it were when using model = ref?
> 
> Where is Node 0x0e? You didn't paste Node 0x0e info, but 0x0c and 0x10.
> 
> > set PIN_IN mode:
> >         hda-verb /dev/snd/hwC0D0 0x0c SET_PIN_WIDGET_CONTROL 0x20
> >
> > The node is 0x0c, but I am not sure if it is that simple.
> 
> It's trivial to try it out, its harmless anyway :)
> You only have to replace 0x0c with your mic node.
> 
> 
> Using hda-verb-0.3, the pins are:
> 
> 0xa - headphones (first connector - the one which works)
> 0xf - headphones (second connector  - no output)
> 0xe - analog mic
> 
> I am attaching the dell-3stack codec and the ref codec.
> 
> This laptop has a digital Mic and a jack for connecting an analog
> mic, ehich I am supposing it is the "Line In" in the "model=ref" codec.
> 
> The dell-3tack model works well, but I have no analog mic, and the
> digital mic sounds too low to be usable.

So you want the analog mic function of node 0x0e to be usable for model
dell-3tack, as it has worked in model ref? 

--- ref.txt
+++ dell-3stack.txt
 Node 0x0e [Pin Complex] wcaps 0x400181: Stereo
   Pincap 0x00001737: IN OUT Detect Trigger ImpSense
     Vref caps: HIZ 50 GRD 80
-  Pin Default 0x01a19040: [Jack] Mic at Ext Rear
+  Pin Default 0x01111212: [Jack] Speaker at Ext Rear
-    Conn = 1/8, Color = Pink
+    Conn = 1/8, Color = Black
-    DefAssociation = 0x4, Sequence = 0x0
+    DefAssociation = 0x1, Sequence = 0x2
-  Pin-ctls: 0x24: IN VREF_80
+  Pin-ctls: 0x40: OUT VREF_HIZ
-  Unsolicited: tag=02, enabled=1
+  Unsolicited: tag=00, enabled=0
   Connection: 1
      0x04
 
 From the above info I'd suggest to try this command to make node 0x0e
 a port for mic instead of speaker:

         hda-verb /dev/snd/hwC0D0 0x0e SET_PIN_WIDGET_CONTROL 0x20

Thanks,
Fengguang

Re: idt blue jack patch

[Takashi Iwai]

At Fri, 20 Feb 2009 09:00:01 +0800,
Wu Fengguang wrote:
> 
> Hi Tobin,
> 
> Here are the Linux and WinXP pin configurations.
> Both Linux and WinXP configure node 0x0c as an output pin.
> 
> However the driver seems to be offering three schemes:
> 
>         scheme desc             0xC dev
> ------------------------------------------------------
>         IDS_CONFIG_OPEN         Speaker_Side/LineIn
>         IDS_CONFIG_51           LineIn
>         IDS_CONFIG_71           Speaker_Side
> 
> Paulo, maybe you can run these commands to switch between
> linein/lineout modes:
> 
>         # wget http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2
> 
>         # set PIN_IN mode
>         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> 
>         # set PIN_OUT mode
>         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40


Regarding the default pin configurations.
I made a series of patches to add the interface to change the default
pincfg values dynamically via hwdep sysfs.  The patches are found in
test/hda-pincfg branch of sound git tree
    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git

and included in the very latest alsa-driver-unstable snapshot
    ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz

Basically, you can get / set the default pincfg values on the fly, and
trigger the codec reconfiguration after that.

The init_pin_configs file shows the initial default pincfgs set by BIOS.

	# cat /sys/class/sound/hwC0D0/init_pin_configs
	0x14 0x9993013f
	0x15 0x01014c10
	0x16 0x99030120
	0x18 0x01a19c30
	0x19 0x02a11c31
	0x1a 0x01813c32
	0x1b 0x02211c1f
	0x1c 0x99330133
	0x1d 0x411111f0
	0x1e 0x411111f0
	0x1f 0x411111f0

Then, you can override the default value by writing to
override_pin_configs sysfs file.

	# cat /sys/class/sound/hwC0D0/override_pin_configs
	# echo 0x1d 0x02a11c30 > /sys/class/sound/hwC0D0/override_pin_configs
	# cat /sys/class/sound/hwC0D0/override_pin_configs
	0x1d 0x02a11c30

Note that this value won't appear in init_pin_configs.

Also, there is another file, cur_pin_configs.  This contains the
pincfgs that are set by the driver explicitly.  For example,
the static pincfg table in patch_sigmatel.c appears here.

Then you can trigger the codec reconfiguration by

	# echo 1 > /sys/class/sound/hwC0D0/reconfig

This will re-setup the driver based on the given pin configs.

Unfortunately, in the current scenario, it can't override the static
pincfg table in the driver like in patch_sigmatel.c.  It's just for
fixing and BIOS setup.


Takashi

Re: idt blue jack patch

[Wu Fengguang]

On Fri, Feb 20, 2009 at 07:18:31PM +0200, Takashi Iwai wrote:
> At Fri, 20 Feb 2009 09:00:01 +0800,
> Wu Fengguang wrote:
> > 
> > Hi Tobin,
> > 
> > Here are the Linux and WinXP pin configurations.
> > Both Linux and WinXP configure node 0x0c as an output pin.
> > 
> > However the driver seems to be offering three schemes:
> > 
> >         scheme desc             0xC dev
> > ------------------------------------------------------
> >         IDS_CONFIG_OPEN         Speaker_Side/LineIn
> >         IDS_CONFIG_51           LineIn
> >         IDS_CONFIG_71           Speaker_Side
> > 
> > Paulo, maybe you can run these commands to switch between
> > linein/lineout modes:
> > 
> >         # wget http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2
> > 
> >         # set PIN_IN mode
> >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> > 
> >         # set PIN_OUT mode
> >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> 
> 
> Regarding the default pin configurations.
> I made a series of patches to add the interface to change the default
> pincfg values dynamically via hwdep sysfs.  The patches are found in
> test/hda-pincfg branch of sound git tree
>     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> 
> and included in the very latest alsa-driver-unstable snapshot
>     ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
> 
> Basically, you can get / set the default pincfg values on the fly, and
> trigger the codec reconfiguration after that.
> 
> The init_pin_configs file shows the initial default pincfgs set by BIOS.
> 
> 	# cat /sys/class/sound/hwC0D0/init_pin_configs
> 	0x14 0x9993013f
> 	0x15 0x01014c10
> 	0x16 0x99030120
> 	0x18 0x01a19c30
> 	0x19 0x02a11c31
> 	0x1a 0x01813c32
> 	0x1b 0x02211c1f
> 	0x1c 0x99330133
> 	0x1d 0x411111f0
> 	0x1e 0x411111f0
> 	0x1f 0x411111f0
> 
> Then, you can override the default value by writing to
> override_pin_configs sysfs file.
> 
> 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> 	# echo 0x1d 0x02a11c30 > /sys/class/sound/hwC0D0/override_pin_configs
> 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> 	0x1d 0x02a11c30
> 
> Note that this value won't appear in init_pin_configs.
> 
> Also, there is another file, cur_pin_configs.  This contains the
> pincfgs that are set by the driver explicitly.  For example,
> the static pincfg table in patch_sigmatel.c appears here.
> 
> Then you can trigger the codec reconfiguration by
> 
> 	# echo 1 > /sys/class/sound/hwC0D0/reconfig
> 
> This will re-setup the driver based on the given pin configs.

Cool!  This interface will greatly ease the developer-user interactions.

Without knowing this feature, I had to write a patch for Paulo,
and compile/verify it before sending it to him. Paulo also have to
pull the kernel source, apply the patch, compile and run it...

Now you turned that tedious process into two simple echo commands :-)

> Unfortunately, in the current scenario, it can't override the static
> pincfg table in the driver like in patch_sigmatel.c.  It's just for
> fixing and BIOS setup.

Unfortunately patch_sigmatel has a long list of static pincfgs, i.e.:

        static unsigned int ref927x_pin_configs[14] = {
                0x02214020, 0x02a19080, 0x0181304e, 0x01014010,
                0x01a19040, 0x01011012, 0x01016011, 0x0101201f,
                0x183301f0, 0x18a001f0, 0x18a001f0, 0x01442070,
                0x01c42190, 0x40000100,
        };

This effectively prohibits itself from being dynamically reconfigured
via the override_pin_configs interface... 

Thanks,
Fengguang

Re: idt blue jack patch

[Takashi Iwai]

At Sat, 21 Feb 2009 09:42:14 +0800,
Wu Fengguang wrote:
> 
> On Fri, Feb 20, 2009 at 07:18:31PM +0200, Takashi Iwai wrote:
> > At Fri, 20 Feb 2009 09:00:01 +0800,
> > Wu Fengguang wrote:
> > > 
> > > Hi Tobin,
> > > 
> > > Here are the Linux and WinXP pin configurations.
> > > Both Linux and WinXP configure node 0x0c as an output pin.
> > > 
> > > However the driver seems to be offering three schemes:
> > > 
> > >         scheme desc             0xC dev
> > > ------------------------------------------------------
> > >         IDS_CONFIG_OPEN         Speaker_Side/LineIn
> > >         IDS_CONFIG_51           LineIn
> > >         IDS_CONFIG_71           Speaker_Side
> > > 
> > > Paulo, maybe you can run these commands to switch between
> > > linein/lineout modes:
> > > 
> > >         # wget http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2
> > > 
> > >         # set PIN_IN mode
> > >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> > > 
> > >         # set PIN_OUT mode
> > >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> > 
> > 
> > Regarding the default pin configurations.
> > I made a series of patches to add the interface to change the default
> > pincfg values dynamically via hwdep sysfs.  The patches are found in
> > test/hda-pincfg branch of sound git tree
> >     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> > 
> > and included in the very latest alsa-driver-unstable snapshot
> >     ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
> > 
> > Basically, you can get / set the default pincfg values on the fly, and
> > trigger the codec reconfiguration after that.
> > 
> > The init_pin_configs file shows the initial default pincfgs set by BIOS.
> > 
> > 	# cat /sys/class/sound/hwC0D0/init_pin_configs
> > 	0x14 0x9993013f
> > 	0x15 0x01014c10
> > 	0x16 0x99030120
> > 	0x18 0x01a19c30
> > 	0x19 0x02a11c31
> > 	0x1a 0x01813c32
> > 	0x1b 0x02211c1f
> > 	0x1c 0x99330133
> > 	0x1d 0x411111f0
> > 	0x1e 0x411111f0
> > 	0x1f 0x411111f0
> > 
> > Then, you can override the default value by writing to
> > override_pin_configs sysfs file.
> > 
> > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > 	# echo 0x1d 0x02a11c30 > /sys/class/sound/hwC0D0/override_pin_configs
> > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > 	0x1d 0x02a11c30
> > 
> > Note that this value won't appear in init_pin_configs.
> > 
> > Also, there is another file, cur_pin_configs.  This contains the
> > pincfgs that are set by the driver explicitly.  For example,
> > the static pincfg table in patch_sigmatel.c appears here.
> > 
> > Then you can trigger the codec reconfiguration by
> > 
> > 	# echo 1 > /sys/class/sound/hwC0D0/reconfig
> > 
> > This will re-setup the driver based on the given pin configs.
> 
> Cool!  This interface will greatly ease the developer-user interactions.
> 
> Without knowing this feature, I had to write a patch for Paulo,
> and compile/verify it before sending it to him. Paulo also have to
> pull the kernel source, apply the patch, compile and run it...
> 
> Now you turned that tedious process into two simple echo commands :-)
> 
> > Unfortunately, in the current scenario, it can't override the static
> > pincfg table in the driver like in patch_sigmatel.c.  It's just for
> > fixing and BIOS setup.
> 
> Unfortunately patch_sigmatel has a long list of static pincfgs, i.e.:
> 
>         static unsigned int ref927x_pin_configs[14] = {
>                 0x02214020, 0x02a19080, 0x0181304e, 0x01014010,
>                 0x01a19040, 0x01011012, 0x01016011, 0x0101201f,
>                 0x183301f0, 0x18a001f0, 0x18a001f0, 0x01442070,
>                 0x01c42190, 0x40000100,
>         };
> 
> This effectively prohibits itself from being dynamically reconfigured
> via the override_pin_configs interface... 

Right.  Considering the implementation again, I think it must be
relatively easy to fix that.  Just changing the order of the evaluation
of pincfg, and add the check not to overwrite the value.

I'll work on it in the next week.


Takashi

Re: idt blue jack patch

[Takashi Iwai]

At Sat, 21 Feb 2009 17:28:21 +0100,
I wrote:
> 
> At Sat, 21 Feb 2009 09:42:14 +0800,
> Wu Fengguang wrote:
> > 
> > On Fri, Feb 20, 2009 at 07:18:31PM +0200, Takashi Iwai wrote:
> > > At Fri, 20 Feb 2009 09:00:01 +0800,
> > > Wu Fengguang wrote:
> > > > 
> > > > Hi Tobin,
> > > > 
> > > > Here are the Linux and WinXP pin configurations.
> > > > Both Linux and WinXP configure node 0x0c as an output pin.
> > > > 
> > > > However the driver seems to be offering three schemes:
> > > > 
> > > >         scheme desc             0xC dev
> > > > ------------------------------------------------------
> > > >         IDS_CONFIG_OPEN         Speaker_Side/LineIn
> > > >         IDS_CONFIG_51           LineIn
> > > >         IDS_CONFIG_71           Speaker_Side
> > > > 
> > > > Paulo, maybe you can run these commands to switch between
> > > > linein/lineout modes:
> > > > 
> > > >         # wget http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2
> > > > 
> > > >         # set PIN_IN mode
> > > >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> > > > 
> > > >         # set PIN_OUT mode
> > > >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> > > 
> > > 
> > > Regarding the default pin configurations.
> > > I made a series of patches to add the interface to change the default
> > > pincfg values dynamically via hwdep sysfs.  The patches are found in
> > > test/hda-pincfg branch of sound git tree
> > >     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> > > 
> > > and included in the very latest alsa-driver-unstable snapshot
> > >     ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
> > > 
> > > Basically, you can get / set the default pincfg values on the fly, and
> > > trigger the codec reconfiguration after that.
> > > 
> > > The init_pin_configs file shows the initial default pincfgs set by BIOS.
> > > 
> > > 	# cat /sys/class/sound/hwC0D0/init_pin_configs
> > > 	0x14 0x9993013f
> > > 	0x15 0x01014c10
> > > 	0x16 0x99030120
> > > 	0x18 0x01a19c30
> > > 	0x19 0x02a11c31
> > > 	0x1a 0x01813c32
> > > 	0x1b 0x02211c1f
> > > 	0x1c 0x99330133
> > > 	0x1d 0x411111f0
> > > 	0x1e 0x411111f0
> > > 	0x1f 0x411111f0
> > > 
> > > Then, you can override the default value by writing to
> > > override_pin_configs sysfs file.
> > > 
> > > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > > 	# echo 0x1d 0x02a11c30 > /sys/class/sound/hwC0D0/override_pin_configs
> > > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > > 	0x1d 0x02a11c30
> > > 
> > > Note that this value won't appear in init_pin_configs.
> > > 
> > > Also, there is another file, cur_pin_configs.  This contains the
> > > pincfgs that are set by the driver explicitly.  For example,
> > > the static pincfg table in patch_sigmatel.c appears here.
> > > 
> > > Then you can trigger the codec reconfiguration by
> > > 
> > > 	# echo 1 > /sys/class/sound/hwC0D0/reconfig
> > > 
> > > This will re-setup the driver based on the given pin configs.
> > 
> > Cool!  This interface will greatly ease the developer-user interactions.
> > 
> > Without knowing this feature, I had to write a patch for Paulo,
> > and compile/verify it before sending it to him. Paulo also have to
> > pull the kernel source, apply the patch, compile and run it...
> > 
> > Now you turned that tedious process into two simple echo commands :-)
> > 
> > > Unfortunately, in the current scenario, it can't override the static
> > > pincfg table in the driver like in patch_sigmatel.c.  It's just for
> > > fixing and BIOS setup.
> > 
> > Unfortunately patch_sigmatel has a long list of static pincfgs, i.e.:
> > 
> >         static unsigned int ref927x_pin_configs[14] = {
> >                 0x02214020, 0x02a19080, 0x0181304e, 0x01014010,
> >                 0x01a19040, 0x01011012, 0x01016011, 0x0101201f,
> >                 0x183301f0, 0x18a001f0, 0x18a001f0, 0x01442070,
> >                 0x01c42190, 0x40000100,
> >         };
> > 
> > This effectively prohibits itself from being dynamically reconfigured
> > via the override_pin_configs interface... 
> 
> Right.  Considering the implementation again, I think it must be
> relatively easy to fix that.  Just changing the order of the evaluation
> of pincfg, and add the check not to overwrite the value.
> 
> I'll work on it in the next week.

Fixed now on sound-unstable tree, together with renaming of override_pin
and cur_pin to user_pin and driver_pin.

It'd be appreciated if someone can test it with a device with
Sigmatel/IDT (as I have no such hardware)...


thanks,

Takashi

Re: idt blue jack patch

[Wu Fengguang]

On Mon, Feb 23, 2009 at 10:54:36AM +0200, Takashi Iwai wrote:
> At Sat, 21 Feb 2009 17:28:21 +0100,
> I wrote:
> > > > Regarding the default pin configurations.
> > > > I made a series of patches to add the interface to change the default
> > > > pincfg values dynamically via hwdep sysfs.  The patches are found in
> > > > test/hda-pincfg branch of sound git tree
> > > >     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> > > > 
> > > > and included in the very latest alsa-driver-unstable snapshot
> > > >     ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
> > > > 
> > > > Basically, you can get / set the default pincfg values on the fly, and
> > > > trigger the codec reconfiguration after that.
> > > > 
> > > > The init_pin_configs file shows the initial default pincfgs set by BIOS.
> > > > 
> > > > 	# cat /sys/class/sound/hwC0D0/init_pin_configs
> > > > 	0x14 0x9993013f
> > > > 	0x15 0x01014c10
> > > > 	0x16 0x99030120
> > > > 	0x18 0x01a19c30
> > > > 	0x19 0x02a11c31
> > > > 	0x1a 0x01813c32
> > > > 	0x1b 0x02211c1f
> > > > 	0x1c 0x99330133
> > > > 	0x1d 0x411111f0
> > > > 	0x1e 0x411111f0
> > > > 	0x1f 0x411111f0
> > > > 
> > > > Then, you can override the default value by writing to
> > > > override_pin_configs sysfs file.
> > > > 
> > > > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > > > 	# echo 0x1d 0x02a11c30 > /sys/class/sound/hwC0D0/override_pin_configs
> > > > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > > > 	0x1d 0x02a11c30
> > > > 
> > > > Note that this value won't appear in init_pin_configs.
> > > > 
> > > > Also, there is another file, cur_pin_configs.  This contains the
> > > > pincfgs that are set by the driver explicitly.  For example,
> > > > the static pincfg table in patch_sigmatel.c appears here.
> > > > 
> > > > Then you can trigger the codec reconfiguration by
> > > > 
> > > > 	# echo 1 > /sys/class/sound/hwC0D0/reconfig
> > > > 
> > > > This will re-setup the driver based on the given pin configs.
> > > 
> > > Cool!  This interface will greatly ease the developer-user interactions.
> > > 
> > > Without knowing this feature, I had to write a patch for Paulo,
> > > and compile/verify it before sending it to him. Paulo also have to
> > > pull the kernel source, apply the patch, compile and run it...
> > > 
> > > Now you turned that tedious process into two simple echo commands :-)
> > > 
> > > > Unfortunately, in the current scenario, it can't override the static
> > > > pincfg table in the driver like in patch_sigmatel.c.  It's just for
> > > > fixing and BIOS setup.
> > > 
> > > Unfortunately patch_sigmatel has a long list of static pincfgs, i.e.:
> > > 
> > >         static unsigned int ref927x_pin_configs[14] = {
> > >                 0x02214020, 0x02a19080, 0x0181304e, 0x01014010,
> > >                 0x01a19040, 0x01011012, 0x01016011, 0x0101201f,
> > >                 0x183301f0, 0x18a001f0, 0x18a001f0, 0x01442070,
> > >                 0x01c42190, 0x40000100,
> > >         };
> > > 
> > > This effectively prohibits itself from being dynamically reconfigured
> > > via the override_pin_configs interface... 
> > 
> > Right.  Considering the implementation again, I think it must be
> > relatively easy to fix that.  Just changing the order of the evaluation
> > of pincfg, and add the check not to overwrite the value.
> > 
> > I'll work on it in the next week.
> 
> Fixed now on sound-unstable tree, together with renaming of override_pin
> and cur_pin to user_pin and driver_pin.
> 
> It'd be appreciated if someone can test it with a device with
> Sigmatel/IDT (as I have no such hardware)...

Hi Takashi,

Here are the good behaviors:

- the driver_pin_configs matches the numbers defined in source code
- the init_pin_configs/user_pin_configs will be exactly restored between module reloading
- setting user_pin_configs and doing reconfig did changed the 0x0c pin from output to input.

However,

- after reconfig, Surround, Center and LFE channels are muted and have to be
  turned on again in alsamixer.
- if reconfig while playing audio, it will trigger a panic:

[  355.810682] ALSA sound/pci/hda/hda_hwdep.c:167: hda-codec: reconfiguring
[  355.817969] ALSA sound/core/timer.c:809: timer ffff88003a8038b8 is busy?
[  355.825058] ALSA sound/core/device.c:102: device free ffff88003a620160 (from stac92xx_free+0x62/0xa0 [snd_hda_codec_idt]), not found
[  355.833556] general protection fault: 0000 [#1] SMP
[  355.833559] last sysfs file: /sys/devices/pci0000:00/0000:00:1b.0/sound/card0/hwC0D2/reconfig
[  355.833561] CPU 3
[  355.833563] Modules linked in: snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc [last unloaded: snd_hda_codec]
[  355.833572] Pid: 0, comm: swapper Not tainted 2.6.29-rc3 #5
[  355.833574] RIP: 0010:[<ffffffffa0052588>]  [<ffffffffa0052588>] snd_pcm_period_elapsed+0x38/0x410 [snd_pcm]
[  355.833584] RSP: 0018:ffff88003b4cfe80  EFLAGS: 00010002
[  355.833586] RAX: 0000000000000003 RBX: ffff88003a591458 RCX: ffffffff81a90210
[  355.833588] RDX: 0000000000009d9c RSI: ffff8800041699a0 RDI: ffff8800396af098
[  355.833589] RBP: ffff88003b4cfec0 R08: 0000000000000001 R09: 0000000000000001
[  355.833591] R10: 0000000000000000 R11: 0000000000000001 R12: 00000000000001a0
[  355.833592] R13: ffff8800396af098 R14: 6b6b6b6b6b6b6b6b R15: 0000000080000010
[  355.833594] FS:  0000000000000000(0000) GS:ffff88003bbfe210(0000) knlGS:0000000000000000
[  355.833596] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[  355.833598] CR2: 00007fb7ea522558 CR3: 0000000039856000 CR4: 00000000000406e0
[  355.833600] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  355.833601] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  355.833603] Process swapper (pid: 0, threadinfo ffff88003b4c8000, task ffff88003b4c4440)
[  355.833604] Stack:
[  355.833605]  ffff88003b4cfea0 ffffffff811a38af ffff88003a5f92b8 ffff88003a591458
[  355.833609]  00000000000001a0 0000000000000004 ffff88003a5f92b8 0000000080000010
[  355.833612]  ffff88003b4cff10 ffffffffa00ba63e ffff88003b4c4440 ffff88003a5f9300
[  355.833615] Call Trace:
[  355.833617]  <IRQ> <0> [<ffffffff811a38af>] ? _raw_spin_unlock+0x7f/0xb0
[  355.833623]  [<ffffffffa00ba63e>] azx_interrupt+0x18e/0x1a0 [snd_hda_intel]
[  355.833629]  [<ffffffff8108ead5>] handle_IRQ_event+0x35/0x80
[  355.833633]  [<ffffffff810905b2>] handle_fasteoi_irq+0x82/0x100
[  355.833636]  [<ffffffff8100f175>] do_IRQ+0xb5/0x1b0
[  355.833639]  [<ffffffff8100d193>] ret_from_intr+0x0/0x2e
[  355.833642]  <EOI> <0>Code: 89 5d d8 4c 89 65 e0 4c 89 75 f0 4c 89 7d f8 49 89 fd 48 85 ff 0f 84 c8 02 00 00 4c 8b b7 a8 00 00 00 4d 85 f6 0f 84 b8 02 00 00 <49> 8b 86 a8 02 00 00 48 85 c0 74 02 ff d0 48 c7 c7 80 c9 05 a0
[  355.833665] RIP  [<ffffffffa0052588>] snd_pcm_period_elapsed+0x38/0x410 [snd_pcm]
[  355.833672]  RSP <ffff88003b4cfe80>
[  355.833676] ---[ end trace 5c74b30f4153ef47 ]---
[  355.833677] Kernel panic - not syncing: Fatal exception in interrupt
[  355.833681] ------------[ cut here ]------------
[  355.833682] WARNING: at kernel/smp.c:299 smp_call_function_many+0x219/0x280()
[  355.833684] Hardware name:
[  355.833685] Modules linked in: snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc [last unloaded: snd_hda_codec]
[  355.833693] Pid: 0, comm: swapper Tainted: G      D    2.6.29-rc3 #5
[  355.833694] Call Trace:
[  355.833695]  <IRQ>  [<ffffffff81044b10>] warn_slowpath+0xd0/0x130
[  355.833702]  [<ffffffff8106ce0d>] ? trace_hardirqs_off+0xd/0x10
[  355.833706]  [<ffffffff814437cf>] ? _spin_lock_irqsave+0x2f/0x90
[  355.833708]  [<ffffffff81443488>] ? _spin_unlock_irqrestore+0x68/0x70
[  355.833711]  [<ffffffff8106cd59>] ? trace_hardirqs_off_caller+0x29/0xd0
[  355.833714]  [<ffffffff811a38af>] ? _raw_spin_unlock+0x7f/0xb0
[  355.833716]  [<ffffffff814434b6>] ? _spin_unlock+0x26/0x30
[  355.833719]  [<ffffffff8106ce0d>] ? trace_hardirqs_off+0xd/0x10
[  355.833722]  [<ffffffff81440c50>] ? __mutex_unlock_slowpath+0x130/0x1a0
[  355.833725]  [<ffffffff8106ce0d>] ? trace_hardirqs_off+0xd/0x10
[  355.833727]  [<ffffffff81440c50>] ? __mutex_unlock_slowpath+0x130/0x1a0
[  355.833729]  [<ffffffff81440cc9>] ? mutex_unlock+0x9/0x10
[  355.833732]  [<ffffffff8107f934>] ? crash_kexec+0x74/0x100
[  355.833735]  [<ffffffff81443488>] ? _spin_unlock_irqrestore+0x68/0x70
[  355.833738]  [<ffffffff81078ad9>] smp_call_function_many+0x219/0x280
[  355.833741]  [<ffffffff81013f10>] ? stop_this_cpu+0x0/0x40
[  355.833743]  [<ffffffff81443488>] ? _spin_unlock_irqrestore+0x68/0x70
[  355.833746]  [<ffffffff81078b60>] smp_call_function+0x20/0x30
[  355.833749]  [<ffffffff8101f5e0>] native_smp_send_stop+0x30/0x90
[  355.833753]  [<ffffffff8143f50a>] panic+0xaf/0x16f
[  355.833755]  [<ffffffff81443488>] ? _spin_unlock_irqrestore+0x68/0x70
[  355.833758]  [<ffffffff8106ce0d>] ? trace_hardirqs_off+0xd/0x10
[  355.833760]  [<ffffffff81443488>] ? _spin_unlock_irqrestore+0x68/0x70
[  355.833763]  [<ffffffff81061147>] ? down_trylock+0x37/0x50
[  355.833765]  [<ffffffff810456d1>] ? console_unblank+0x21/0x90
[  355.833768]  [<ffffffff81444dcc>] oops_end+0xec/0x100
[  355.833771]  [<ffffffff810103f6>] die+0x56/0x90
[  355.833773]  [<ffffffff81444928>] do_general_protection+0x158/0x180
[  355.833775]  [<ffffffff81443ea5>] general_protection+0x25/0x30
[  355.833782]  [<ffffffffa0052588>] ? snd_pcm_period_elapsed+0x38/0x410 [snd_pcm]
[  355.833785]  [<ffffffff811a38af>] ? _raw_spin_unlock+0x7f/0xb0
[  355.833789]  [<ffffffffa00ba63e>] azx_interrupt+0x18e/0x1a0 [snd_hda_intel]
[  355.833792]  [<ffffffff8108ead5>] handle_IRQ_event+0x35/0x80
[  355.833795]  [<ffffffff810905b2>] handle_fasteoi_irq+0x82/0x100
[  355.833798]  [<ffffffff8100f175>] do_IRQ+0xb5/0x1b0
[  355.833800]  [<ffffffff8100d193>] ret_from_intr+0x0/0x2e
[  355.833801]  <EOI> <4>---[ end trace 5c74b30f4153ef48 ]---
[  355.833807] Rebooting in 10 seconds..

Thanks,
Fengguang
---

wfg@hp ~% cat /sys/class/sound/hwC0D2/init_pin_configs 
0x0a 0x0221401f
0x0b 0x02a19020
0x0c 0x01113014
0x0d 0x01114010
0x0e 0x01a19030
0x0f 0x01111012
0x10 0x01116011
0x11 0x40f000f0
0x12 0x40f000f0
0x13 0x40f000f0
0x14 0x40f000f0
0x22 0x40f000f0
0x23 0x01451140
0x24 0x40f000f0
wfg@hp ~% cat /sys/class/sound/hwC0D2/driver_pin_configs 
wfg@hp ~% cat /sys/class/sound/hwC0D2/user_pin_configs 
wfg@hp ~% head /proc/asound/card0/codec\#2
Codec: IDT 92HD73E1X5
Address: 2
Vendor Id: 0x111d7676
Subsystem Id: 0x80865002
Revision Id: 0x100202
No Modem Function Group found
Default PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM


root@hp /home/wfg# modprobe snd-hda-intel model=ref
root@hp /home/wfg# cat /sys/class/sound/hwC0D2/init_pin_configs                                                           [ 1 ]  :-(
0x0a 0x0221401f
0x0b 0x02a19020
0x0c 0x01113014
0x0d 0x01114010
0x0e 0x01a19030
0x0f 0x01111012
0x10 0x01116011
0x11 0x40f000f0
0x12 0x40f000f0
0x13 0x40f000f0
0x14 0x40f000f0
0x22 0x40f000f0
0x23 0x01451140
0x24 0x40f000f0
root@hp /home/wfg# cat /sys/class/sound/hwC0D2/driver_pin_configs
0x0a 0x02214030
0x0b 0x02a19040
0x0c 0x01a19020
0x0d 0x02214030
0x0e 0x0181302e
0x0f 0x01014010
0x10 0x01014020
0x11 0x01014030
0x12 0x02319040
0x13 0x90a000f0
0x14 0x90a000f0
0x22 0x01452050
0x23 0x01452050
root@hp /home/wfg# cat /sys/class/sound/hwC0D2/user_pin_configs
root@hp /home/wfg# echo 0x0a 0x02214030 > /sys/class/sound/hwC0D2/user_pin_configs
root@hp /home/wfg# cat /sys/class/sound/hwC0D2/user_pin_configs
0x0a 0x02214030
root@hp /home/wfg# echo 1 > /sys/class/sound/hwC0D2/reconfig
root@hp /home/wfg# cat /sys/class/sound/hwC0D2/user_pin_configs
0x0a 0x02214030
root@hp /home/wfg# cat /sys/class/sound/hwC0D2/driver_pin_configs
0x0a 0x02214030
0x0b 0x02a19040
0x0c 0x01a19020
0x0d 0x02214030
0x0e 0x0181302e
0x0f 0x01014010
0x10 0x01014020
0x11 0x01014030
0x12 0x02319040
0x13 0x90a000f0
0x14 0x90a000f0
0x22 0x01452050
0x23 0x01452050
root@hp /home/wfg# cat /sys/class/sound/hwC0D2/init_pin_configs
0x0a 0x0221401f
0x0b 0x02a19020
0x0c 0x01113014
0x0d 0x01114010
0x0e 0x01a19030
0x0f 0x01111012
0x10 0x01116011
0x11 0x40f000f0
0x12 0x40f000f0
0x13 0x40f000f0
0x14 0x40f000f0
0x22 0x40f000f0
0x23 0x01451140
0x24 0x40f000f0


root@hp /home/wfg# rmmod snd_hda_intel snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_codec
root@hp /home/wfg# modprobe snd-hda-intel          
root@hp /home/wfg# echo 0x0c 0x01813021 > /sys/class/sound/hwC0D2/user_pin_configs
root@hp /home/wfg# echo 1 > /sys/class/sound/hwC0D2/reconfig                      
root@hp /home/wfg# alsamixer 

Re: idt blue jack patch

[Takashi Iwai]

At Mon, 23 Feb 2009 17:53:51 +0800,
Wu Fengguang wrote:
> 
> On Mon, Feb 23, 2009 at 10:54:36AM +0200, Takashi Iwai wrote:
> > At Sat, 21 Feb 2009 17:28:21 +0100,
> > I wrote:
> > > > > Regarding the default pin configurations.
> > > > > I made a series of patches to add the interface to change the default
> > > > > pincfg values dynamically via hwdep sysfs.  The patches are found in
> > > > > test/hda-pincfg branch of sound git tree
> > > > >     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> > > > > 
> > > > > and included in the very latest alsa-driver-unstable snapshot
> > > > >     ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
> > > > > 
> > > > > Basically, you can get / set the default pincfg values on the fly, and
> > > > > trigger the codec reconfiguration after that.
> > > > > 
> > > > > The init_pin_configs file shows the initial default pincfgs set by BIOS.
> > > > > 
> > > > > 	# cat /sys/class/sound/hwC0D0/init_pin_configs
> > > > > 	0x14 0x9993013f
> > > > > 	0x15 0x01014c10
> > > > > 	0x16 0x99030120
> > > > > 	0x18 0x01a19c30
> > > > > 	0x19 0x02a11c31
> > > > > 	0x1a 0x01813c32
> > > > > 	0x1b 0x02211c1f
> > > > > 	0x1c 0x99330133
> > > > > 	0x1d 0x411111f0
> > > > > 	0x1e 0x411111f0
> > > > > 	0x1f 0x411111f0
> > > > > 
> > > > > Then, you can override the default value by writing to
> > > > > override_pin_configs sysfs file.
> > > > > 
> > > > > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > > > > 	# echo 0x1d 0x02a11c30 > /sys/class/sound/hwC0D0/override_pin_configs
> > > > > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > > > > 	0x1d 0x02a11c30
> > > > > 
> > > > > Note that this value won't appear in init_pin_configs.
> > > > > 
> > > > > Also, there is another file, cur_pin_configs.  This contains the
> > > > > pincfgs that are set by the driver explicitly.  For example,
> > > > > the static pincfg table in patch_sigmatel.c appears here.
> > > > > 
> > > > > Then you can trigger the codec reconfiguration by
> > > > > 
> > > > > 	# echo 1 > /sys/class/sound/hwC0D0/reconfig
> > > > > 
> > > > > This will re-setup the driver based on the given pin configs.
> > > > 
> > > > Cool!  This interface will greatly ease the developer-user interactions.
> > > > 
> > > > Without knowing this feature, I had to write a patch for Paulo,
> > > > and compile/verify it before sending it to him. Paulo also have to
> > > > pull the kernel source, apply the patch, compile and run it...
> > > > 
> > > > Now you turned that tedious process into two simple echo commands :-)
> > > > 
> > > > > Unfortunately, in the current scenario, it can't override the static
> > > > > pincfg table in the driver like in patch_sigmatel.c.  It's just for
> > > > > fixing and BIOS setup.
> > > > 
> > > > Unfortunately patch_sigmatel has a long list of static pincfgs, i.e.:
> > > > 
> > > >         static unsigned int ref927x_pin_configs[14] = {
> > > >                 0x02214020, 0x02a19080, 0x0181304e, 0x01014010,
> > > >                 0x01a19040, 0x01011012, 0x01016011, 0x0101201f,
> > > >                 0x183301f0, 0x18a001f0, 0x18a001f0, 0x01442070,
> > > >                 0x01c42190, 0x40000100,
> > > >         };
> > > > 
> > > > This effectively prohibits itself from being dynamically reconfigured
> > > > via the override_pin_configs interface... 
> > > 
> > > Right.  Considering the implementation again, I think it must be
> > > relatively easy to fix that.  Just changing the order of the evaluation
> > > of pincfg, and add the check not to overwrite the value.
> > > 
> > > I'll work on it in the next week.
> > 
> > Fixed now on sound-unstable tree, together with renaming of override_pin
> > and cur_pin to user_pin and driver_pin.
> > 
> > It'd be appreciated if someone can test it with a device with
> > Sigmatel/IDT (as I have no such hardware)...
> 
> Hi Takashi,
> 
> Here are the good behaviors:
> 
> - the driver_pin_configs matches the numbers defined in source code
> - the init_pin_configs/user_pin_configs will be exactly restored between module reloading
> - setting user_pin_configs and doing reconfig did changed the 0x0c pin from output to input.
> 
> However,
> 
> - after reconfig, Surround, Center and LFE channels are muted and have to be
>   turned on again in alsamixer.

That's a feature.  You can restore via "alsactl restore"

> - if reconfig while playing audio, it will trigger a panic:

Ah, that's bad.  I know this can be a problem (and thus is marked as
EXPERIMENTAL :)

We need some mutex and/or flag to disable the reconfig during the
critical operation.


thanks,

Takashi

Re: idt blue jack patch

[Wu Fengguang]

On Mon, Feb 23, 2009 at 12:21:18PM +0200, Takashi Iwai wrote:
> At Mon, 23 Feb 2009 17:53:51 +0800,
> Wu Fengguang wrote:
> > 
> > On Mon, Feb 23, 2009 at 10:54:36AM +0200, Takashi Iwai wrote:
> > > At Sat, 21 Feb 2009 17:28:21 +0100,
> > > I wrote:
> > > > > > Regarding the default pin configurations.
> > > > > > I made a series of patches to add the interface to change the default
> > > > > > pincfg values dynamically via hwdep sysfs.  The patches are found in
> > > > > > test/hda-pincfg branch of sound git tree
> > > > > >     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> > > > > > 
> > > > > > and included in the very latest alsa-driver-unstable snapshot
> > > > > >     ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
> > > > > > 
> > > > > > Basically, you can get / set the default pincfg values on the fly, and
> > > > > > trigger the codec reconfiguration after that.
> > > > > > 
> > > > > > The init_pin_configs file shows the initial default pincfgs set by BIOS.
> > > > > > 
> > > > > > 	# cat /sys/class/sound/hwC0D0/init_pin_configs
> > > > > > 	0x14 0x9993013f
> > > > > > 	0x15 0x01014c10
> > > > > > 	0x16 0x99030120
> > > > > > 	0x18 0x01a19c30
> > > > > > 	0x19 0x02a11c31
> > > > > > 	0x1a 0x01813c32
> > > > > > 	0x1b 0x02211c1f
> > > > > > 	0x1c 0x99330133
> > > > > > 	0x1d 0x411111f0
> > > > > > 	0x1e 0x411111f0
> > > > > > 	0x1f 0x411111f0
> > > > > > 
> > > > > > Then, you can override the default value by writing to
> > > > > > override_pin_configs sysfs file.
> > > > > > 
> > > > > > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > > > > > 	# echo 0x1d 0x02a11c30 > /sys/class/sound/hwC0D0/override_pin_configs
> > > > > > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > > > > > 	0x1d 0x02a11c30
> > > > > > 
> > > > > > Note that this value won't appear in init_pin_configs.
> > > > > > 
> > > > > > Also, there is another file, cur_pin_configs.  This contains the
> > > > > > pincfgs that are set by the driver explicitly.  For example,
> > > > > > the static pincfg table in patch_sigmatel.c appears here.
> > > > > > 
> > > > > > Then you can trigger the codec reconfiguration by
> > > > > > 
> > > > > > 	# echo 1 > /sys/class/sound/hwC0D0/reconfig
> > > > > > 
> > > > > > This will re-setup the driver based on the given pin configs.
> > > > > 
> > > > > Cool!  This interface will greatly ease the developer-user interactions.
> > > > > 
> > > > > Without knowing this feature, I had to write a patch for Paulo,
> > > > > and compile/verify it before sending it to him. Paulo also have to
> > > > > pull the kernel source, apply the patch, compile and run it...
> > > > > 
> > > > > Now you turned that tedious process into two simple echo commands :-)
> > > > > 
> > > > > > Unfortunately, in the current scenario, it can't override the static
> > > > > > pincfg table in the driver like in patch_sigmatel.c.  It's just for
> > > > > > fixing and BIOS setup.
> > > > > 
> > > > > Unfortunately patch_sigmatel has a long list of static pincfgs, i.e.:
> > > > > 
> > > > >         static unsigned int ref927x_pin_configs[14] = {
> > > > >                 0x02214020, 0x02a19080, 0x0181304e, 0x01014010,
> > > > >                 0x01a19040, 0x01011012, 0x01016011, 0x0101201f,
> > > > >                 0x183301f0, 0x18a001f0, 0x18a001f0, 0x01442070,
> > > > >                 0x01c42190, 0x40000100,
> > > > >         };
> > > > > 
> > > > > This effectively prohibits itself from being dynamically reconfigured
> > > > > via the override_pin_configs interface... 
> > > > 
> > > > Right.  Considering the implementation again, I think it must be
> > > > relatively easy to fix that.  Just changing the order of the evaluation
> > > > of pincfg, and add the check not to overwrite the value.
> > > > 
> > > > I'll work on it in the next week.
> > > 
> > > Fixed now on sound-unstable tree, together with renaming of override_pin
> > > and cur_pin to user_pin and driver_pin.
> > > 
> > > It'd be appreciated if someone can test it with a device with
> > > Sigmatel/IDT (as I have no such hardware)...
> > 
> > Hi Takashi,
> > 
> > Here are the good behaviors:
> > 
> > - the driver_pin_configs matches the numbers defined in source code
> > - the init_pin_configs/user_pin_configs will be exactly restored between module reloading
> > - setting user_pin_configs and doing reconfig did changed the 0x0c pin from output to input.
> > 
> > However,
> > 
> > - after reconfig, Surround, Center and LFE channels are muted and have to be
> >   turned on again in alsamixer.
> 
> That's a feature.  You can restore via "alsactl restore"

Ah OK, I'd take it as a workaround ;-)

> > - if reconfig while playing audio, it will trigger a panic:
> 
> Ah, that's bad.  I know this can be a problem (and thus is marked as
> EXPERIMENTAL :)
> 
> We need some mutex and/or flag to disable the reconfig during the
> critical operation.

It won't be a trivial work. The reset/rebuild is a long and complex process.
For the moment I'd suggest to simply fail reconfig if there are active streams,
so as to let this useful feature go upstream ASAP.

Thanks,
Fengguang

Re: idt blue jack patch

[Takashi Iwai]

At Mon, 23 Feb 2009 20:58:20 +0800,
Wu Fengguang wrote:
> 
> On Mon, Feb 23, 2009 at 12:21:18PM +0200, Takashi Iwai wrote:
> > At Mon, 23 Feb 2009 17:53:51 +0800,
> > Wu Fengguang wrote:
> > > 
> > > On Mon, Feb 23, 2009 at 10:54:36AM +0200, Takashi Iwai wrote:
> > > > At Sat, 21 Feb 2009 17:28:21 +0100,
> > > > I wrote:
> > > > > > > Regarding the default pin configurations.
> > > > > > > I made a series of patches to add the interface to change the default
> > > > > > > pincfg values dynamically via hwdep sysfs.  The patches are found in
> > > > > > > test/hda-pincfg branch of sound git tree
> > > > > > >     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> > > > > > > 
> > > > > > > and included in the very latest alsa-driver-unstable snapshot
> > > > > > >     ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
> > > > > > > 
> > > > > > > Basically, you can get / set the default pincfg values on the fly, and
> > > > > > > trigger the codec reconfiguration after that.
> > > > > > > 
> > > > > > > The init_pin_configs file shows the initial default pincfgs set by BIOS.
> > > > > > > 
> > > > > > > 	# cat /sys/class/sound/hwC0D0/init_pin_configs
> > > > > > > 	0x14 0x9993013f
> > > > > > > 	0x15 0x01014c10
> > > > > > > 	0x16 0x99030120
> > > > > > > 	0x18 0x01a19c30
> > > > > > > 	0x19 0x02a11c31
> > > > > > > 	0x1a 0x01813c32
> > > > > > > 	0x1b 0x02211c1f
> > > > > > > 	0x1c 0x99330133
> > > > > > > 	0x1d 0x411111f0
> > > > > > > 	0x1e 0x411111f0
> > > > > > > 	0x1f 0x411111f0
> > > > > > > 
> > > > > > > Then, you can override the default value by writing to
> > > > > > > override_pin_configs sysfs file.
> > > > > > > 
> > > > > > > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > > > > > > 	# echo 0x1d 0x02a11c30 > /sys/class/sound/hwC0D0/override_pin_configs
> > > > > > > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > > > > > > 	0x1d 0x02a11c30
> > > > > > > 
> > > > > > > Note that this value won't appear in init_pin_configs.
> > > > > > > 
> > > > > > > Also, there is another file, cur_pin_configs.  This contains the
> > > > > > > pincfgs that are set by the driver explicitly.  For example,
> > > > > > > the static pincfg table in patch_sigmatel.c appears here.
> > > > > > > 
> > > > > > > Then you can trigger the codec reconfiguration by
> > > > > > > 
> > > > > > > 	# echo 1 > /sys/class/sound/hwC0D0/reconfig
> > > > > > > 
> > > > > > > This will re-setup the driver based on the given pin configs.
> > > > > > 
> > > > > > Cool!  This interface will greatly ease the developer-user interactions.
> > > > > > 
> > > > > > Without knowing this feature, I had to write a patch for Paulo,
> > > > > > and compile/verify it before sending it to him. Paulo also have to
> > > > > > pull the kernel source, apply the patch, compile and run it...
> > > > > > 
> > > > > > Now you turned that tedious process into two simple echo commands :-)
> > > > > > 
> > > > > > > Unfortunately, in the current scenario, it can't override the static
> > > > > > > pincfg table in the driver like in patch_sigmatel.c.  It's just for
> > > > > > > fixing and BIOS setup.
> > > > > > 
> > > > > > Unfortunately patch_sigmatel has a long list of static pincfgs, i.e.:
> > > > > > 
> > > > > >         static unsigned int ref927x_pin_configs[14] = {
> > > > > >                 0x02214020, 0x02a19080, 0x0181304e, 0x01014010,
> > > > > >                 0x01a19040, 0x01011012, 0x01016011, 0x0101201f,
> > > > > >                 0x183301f0, 0x18a001f0, 0x18a001f0, 0x01442070,
> > > > > >                 0x01c42190, 0x40000100,
> > > > > >         };
> > > > > > 
> > > > > > This effectively prohibits itself from being dynamically reconfigured
> > > > > > via the override_pin_configs interface... 
> > > > > 
> > > > > Right.  Considering the implementation again, I think it must be
> > > > > relatively easy to fix that.  Just changing the order of the evaluation
> > > > > of pincfg, and add the check not to overwrite the value.
> > > > > 
> > > > > I'll work on it in the next week.
> > > > 
> > > > Fixed now on sound-unstable tree, together with renaming of override_pin
> > > > and cur_pin to user_pin and driver_pin.
> > > > 
> > > > It'd be appreciated if someone can test it with a device with
> > > > Sigmatel/IDT (as I have no such hardware)...
> > > 
> > > Hi Takashi,
> > > 
> > > Here are the good behaviors:
> > > 
> > > - the driver_pin_configs matches the numbers defined in source code
> > > - the init_pin_configs/user_pin_configs will be exactly restored between module reloading
> > > - setting user_pin_configs and doing reconfig did changed the 0x0c pin from output to input.
> > > 
> > > However,
> > > 
> > > - after reconfig, Surround, Center and LFE channels are muted and have to be
> > >   turned on again in alsamixer.
> > 
> > That's a feature.  You can restore via "alsactl restore"
> 
> Ah OK, I'd take it as a workaround ;-)
> 
> > > - if reconfig while playing audio, it will trigger a panic:
> > 
> > Ah, that's bad.  I know this can be a problem (and thus is marked as
> > EXPERIMENTAL :)
> > 
> > We need some mutex and/or flag to disable the reconfig during the
> > critical operation.
> 
> It won't be a trivial work. The reset/rebuild is a long and complex process.
> For the moment I'd suggest to simply fail reconfig if there are active streams,

Yep, that's what I thought of, too.

> so as to let this useful feature go upstream ASAP.

I'll merge the branch soon later.


thanks,

Takashi

Re: idt blue jack patch

[Takashi Iwai]

At Mon, 23 Feb 2009 14:00:43 +0100,
I wrote:
> 
> At Mon, 23 Feb 2009 20:58:20 +0800,
> Wu Fengguang wrote:
> > 
> > On Mon, Feb 23, 2009 at 12:21:18PM +0200, Takashi Iwai wrote:
> > > At Mon, 23 Feb 2009 17:53:51 +0800,
> > > Wu Fengguang wrote:
> > > > 
> > > > On Mon, Feb 23, 2009 at 10:54:36AM +0200, Takashi Iwai wrote:
> > > > > At Sat, 21 Feb 2009 17:28:21 +0100,
> > > > > I wrote:
> > > > > > > > Regarding the default pin configurations.
> > > > > > > > I made a series of patches to add the interface to change the default
> > > > > > > > pincfg values dynamically via hwdep sysfs.  The patches are found in
> > > > > > > > test/hda-pincfg branch of sound git tree
> > > > > > > >     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> > > > > > > > 
> > > > > > > > and included in the very latest alsa-driver-unstable snapshot
> > > > > > > >     ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
> > > > > > > > 
> > > > > > > > Basically, you can get / set the default pincfg values on the fly, and
> > > > > > > > trigger the codec reconfiguration after that.
> > > > > > > > 
> > > > > > > > The init_pin_configs file shows the initial default pincfgs set by BIOS.
> > > > > > > > 
> > > > > > > > 	# cat /sys/class/sound/hwC0D0/init_pin_configs
> > > > > > > > 	0x14 0x9993013f
> > > > > > > > 	0x15 0x01014c10
> > > > > > > > 	0x16 0x99030120
> > > > > > > > 	0x18 0x01a19c30
> > > > > > > > 	0x19 0x02a11c31
> > > > > > > > 	0x1a 0x01813c32
> > > > > > > > 	0x1b 0x02211c1f
> > > > > > > > 	0x1c 0x99330133
> > > > > > > > 	0x1d 0x411111f0
> > > > > > > > 	0x1e 0x411111f0
> > > > > > > > 	0x1f 0x411111f0
> > > > > > > > 
> > > > > > > > Then, you can override the default value by writing to
> > > > > > > > override_pin_configs sysfs file.
> > > > > > > > 
> > > > > > > > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > > > > > > > 	# echo 0x1d 0x02a11c30 > /sys/class/sound/hwC0D0/override_pin_configs
> > > > > > > > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > > > > > > > 	0x1d 0x02a11c30
> > > > > > > > 
> > > > > > > > Note that this value won't appear in init_pin_configs.
> > > > > > > > 
> > > > > > > > Also, there is another file, cur_pin_configs.  This contains the
> > > > > > > > pincfgs that are set by the driver explicitly.  For example,
> > > > > > > > the static pincfg table in patch_sigmatel.c appears here.
> > > > > > > > 
> > > > > > > > Then you can trigger the codec reconfiguration by
> > > > > > > > 
> > > > > > > > 	# echo 1 > /sys/class/sound/hwC0D0/reconfig
> > > > > > > > 
> > > > > > > > This will re-setup the driver based on the given pin configs.
> > > > > > > 
> > > > > > > Cool!  This interface will greatly ease the developer-user interactions.
> > > > > > > 
> > > > > > > Without knowing this feature, I had to write a patch for Paulo,
> > > > > > > and compile/verify it before sending it to him. Paulo also have to
> > > > > > > pull the kernel source, apply the patch, compile and run it...
> > > > > > > 
> > > > > > > Now you turned that tedious process into two simple echo commands :-)
> > > > > > > 
> > > > > > > > Unfortunately, in the current scenario, it can't override the static
> > > > > > > > pincfg table in the driver like in patch_sigmatel.c.  It's just for
> > > > > > > > fixing and BIOS setup.
> > > > > > > 
> > > > > > > Unfortunately patch_sigmatel has a long list of static pincfgs, i.e.:
> > > > > > > 
> > > > > > >         static unsigned int ref927x_pin_configs[14] = {
> > > > > > >                 0x02214020, 0x02a19080, 0x0181304e, 0x01014010,
> > > > > > >                 0x01a19040, 0x01011012, 0x01016011, 0x0101201f,
> > > > > > >                 0x183301f0, 0x18a001f0, 0x18a001f0, 0x01442070,
> > > > > > >                 0x01c42190, 0x40000100,
> > > > > > >         };
> > > > > > > 
> > > > > > > This effectively prohibits itself from being dynamically reconfigured
> > > > > > > via the override_pin_configs interface... 
> > > > > > 
> > > > > > Right.  Considering the implementation again, I think it must be
> > > > > > relatively easy to fix that.  Just changing the order of the evaluation
> > > > > > of pincfg, and add the check not to overwrite the value.
> > > > > > 
> > > > > > I'll work on it in the next week.
> > > > > 
> > > > > Fixed now on sound-unstable tree, together with renaming of override_pin
> > > > > and cur_pin to user_pin and driver_pin.
> > > > > 
> > > > > It'd be appreciated if someone can test it with a device with
> > > > > Sigmatel/IDT (as I have no such hardware)...
> > > > 
> > > > Hi Takashi,
> > > > 
> > > > Here are the good behaviors:
> > > > 
> > > > - the driver_pin_configs matches the numbers defined in source code
> > > > - the init_pin_configs/user_pin_configs will be exactly restored between module reloading
> > > > - setting user_pin_configs and doing reconfig did changed the 0x0c pin from output to input.
> > > > 
> > > > However,
> > > > 
> > > > - after reconfig, Surround, Center and LFE channels are muted and have to be
> > > >   turned on again in alsamixer.
> > > 
> > > That's a feature.  You can restore via "alsactl restore"
> > 
> > Ah OK, I'd take it as a workaround ;-)
> > 
> > > > - if reconfig while playing audio, it will trigger a panic:
> > > 
> > > Ah, that's bad.  I know this can be a problem (and thus is marked as
> > > EXPERIMENTAL :)
> > > 
> > > We need some mutex and/or flag to disable the reconfig during the
> > > critical operation.
> > 
> > It won't be a trivial work. The reset/rebuild is a long and complex process.
> > For the moment I'd suggest to simply fail reconfig if there are active streams,
> 
> Yep, that's what I thought of, too.
> 
> > so as to let this useful feature go upstream ASAP.
> 
> I'll merge the branch soon later.

FYI, now the branch is merged to master.
The dynamic pincfg feature is available on alsa-driver snapshot, too.

Also, I added the check of opened streams before doing clear/reconfig
work so that the kernel panic won't happen so easily.


Takashi

Re: idt blue jack patch

[Wu Fengguang]

On Mon, Feb 23, 2009 at 06:15:18PM +0200, Takashi Iwai wrote:
> At Mon, 23 Feb 2009 14:00:43 +0100,
> I wrote:
> > > > > - if reconfig while playing audio, it will trigger a panic:
> > > > 
> > > > Ah, that's bad.  I know this can be a problem (and thus is marked as
> > > > EXPERIMENTAL :)
> > > > 
> > > > We need some mutex and/or flag to disable the reconfig during the
> > > > critical operation.
> > > 
> > > It won't be a trivial work. The reset/rebuild is a long and complex process.
> > > For the moment I'd suggest to simply fail reconfig if there are active streams,
> > 
> > Yep, that's what I thought of, too.
> > 
> > > so as to let this useful feature go upstream ASAP.
> > 
> > I'll merge the branch soon later.
> 
> FYI, now the branch is merged to master.
> The dynamic pincfg feature is available on alsa-driver snapshot, too.
> 
> Also, I added the check of opened streams before doing clear/reconfig
> work so that the kernel panic won't happen so easily.

That's great, thank you!

Regards,
Fengguang

Re: idt blue jack patch

[Wu Fengguang]

On Fri, Feb 20, 2009 at 07:18:31PM +0200, Takashi Iwai wrote:
> At Fri, 20 Feb 2009 09:00:01 +0800,
> Wu Fengguang wrote:
> > 
> > Hi Tobin,
> > 
> > Here are the Linux and WinXP pin configurations.
> > Both Linux and WinXP configure node 0x0c as an output pin.
> > 
> > However the driver seems to be offering three schemes:
> > 
> >         scheme desc             0xC dev
> > ------------------------------------------------------
> >         IDS_CONFIG_OPEN         Speaker_Side/LineIn
> >         IDS_CONFIG_51           LineIn
> >         IDS_CONFIG_71           Speaker_Side
> > 
> > Paulo, maybe you can run these commands to switch between
> > linein/lineout modes:
> > 
> >         # wget http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2
> > 
> >         # set PIN_IN mode
> >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> > 
> >         # set PIN_OUT mode
> >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> 
> 
> Regarding the default pin configurations.
> I made a series of patches to add the interface to change the default
> pincfg values dynamically via hwdep sysfs.  The patches are found in
> test/hda-pincfg branch of sound git tree
>     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> 
> and included in the very latest alsa-driver-unstable snapshot
>     ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
> 
> Basically, you can get / set the default pincfg values on the fly, and
> trigger the codec reconfiguration after that.
> 
> The init_pin_configs file shows the initial default pincfgs set by BIOS.
> 
> 	# cat /sys/class/sound/hwC0D0/init_pin_configs
> 	0x14 0x9993013f
> 	0x15 0x01014c10
> 	0x16 0x99030120
> 	0x18 0x01a19c30
> 	0x19 0x02a11c31
> 	0x1a 0x01813c32
> 	0x1b 0x02211c1f
> 	0x1c 0x99330133
> 	0x1d 0x411111f0
> 	0x1e 0x411111f0
> 	0x1f 0x411111f0
> 
> Then, you can override the default value by writing to
> override_pin_configs sysfs file.
> 
> 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> 	# echo 0x1d 0x02a11c30 > /sys/class/sound/hwC0D0/override_pin_configs
> 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> 	0x1d 0x02a11c30
> 
> Note that this value won't appear in init_pin_configs.
> 
> Also, there is another file, cur_pin_configs.  This contains the
> pincfgs that are set by the driver explicitly.  For example,
> the static pincfg table in patch_sigmatel.c appears here.
> 
> Then you can trigger the codec reconfiguration by
> 
> 	# echo 1 > /sys/class/sound/hwC0D0/reconfig
> 
> This will re-setup the driver based on the given pin configs.
> 
> Unfortunately, in the current scenario, it can't override the static
> pincfg table in the driver like in patch_sigmatel.c.  It's just for
> fixing and BIOS setup.

If override_pin_configs cannot override the values in cur_pin_configs
(or will it later?), then the name is kind of misleading.

How about the names bios_pin_configs, driver_pin_configs and user_pin_configs?

Thanks,
Fengguang

Re: idt blue jack patch

[Paulo Cavalcanti]

On Fri, Feb 20, 2009 at 10:55 PM, Wu Fengguang <fengguang.wu@intel.com>wrote:

> On Fri, Feb 20, 2009 at 07:18:31PM +0200, Takashi Iwai wrote:
> > At Fri, 20 Feb 2009 09:00:01 +0800,
> > Wu Fengguang wrote:
> > >
> > > Hi Tobin,
> > >
> > > Here are the Linux and WinXP pin configurations.
> > > Both Linux and WinXP configure node 0x0c as an output pin.
> > >
> > > However the driver seems to be offering three schemes:
> > >
> > >         scheme desc             0xC dev
> > > ------------------------------------------------------
> > >         IDS_CONFIG_OPEN         Speaker_Side/LineIn
> > >         IDS_CONFIG_51           LineIn
> > >         IDS_CONFIG_71           Speaker_Side
> > >
> > > Paulo, maybe you can run these commands to switch between
> > > linein/lineout modes:
> > >
> > >         # wget
> http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2
> > >
> > >         # set PIN_IN mode
> > >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> > >
> > >         # set PIN_OUT mode
> > >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> >
> >
> > Regarding the default pin configurations.
> > I made a series of patches to add the interface to change the default
> > pincfg values dynamically via hwdep sysfs.  The patches are found in
> > test/hda-pincfg branch of sound git tree
> >     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> >
> > and included in the very latest alsa-driver-unstable snapshot
> >
> ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
> >
> > Basically, you can get / set the default pincfg values on the fly, and
> > trigger the codec reconfiguration after that.
> >
> > The init_pin_configs file shows the initial default pincfgs set by BIOS.
> >
> >       # cat /sys/class/sound/hwC0D0/init_pin_configs
> >       0x14 0x9993013f
> >       0x15 0x01014c10
> >       0x16 0x99030120
> >       0x18 0x01a19c30
> >       0x19 0x02a11c31
> >       0x1a 0x01813c32
> >       0x1b 0x02211c1f
> >       0x1c 0x99330133
> >       0x1d 0x411111f0
> >       0x1e 0x411111f0
> >       0x1f 0x411111f0
> >
> > Then, you can override the default value by writing to
> > override_pin_configs sysfs file.
> >
> >       # cat /sys/class/sound/hwC0D0/override_pin_configs
> >       # echo 0x1d 0x02a11c30 >
> /sys/class/sound/hwC0D0/override_pin_configs
> >       # cat /sys/class/sound/hwC0D0/override_pin_configs
> >       0x1d 0x02a11c30
> >
> > Note that this value won't appear in init_pin_configs.
> >
> > Also, there is another file, cur_pin_configs.  This contains the
> > pincfgs that are set by the driver explicitly.  For example,
> > the static pincfg table in patch_sigmatel.c appears here.
> >
> > Then you can trigger the codec reconfiguration by
> >
> >       # echo 1 > /sys/class/sound/hwC0D0/reconfig
> >
> > This will re-setup the driver based on the given pin configs.
> >
> > Unfortunately, in the current scenario, it can't override the static
> > pincfg table in the driver like in patch_sigmatel.c.  It's just for
> > fixing and BIOS setup.
>
> If override_pin_configs cannot override the values in cur_pin_configs
> (or will it later?), then the name is kind of misleading.
>
> How about the names bios_pin_configs, driver_pin_configs and
> user_pin_configs?
>
>

Having a tool for reconfiguring the pins seems to be the only hope
for fixing the problems of all cards available out there.

However, I fixed my problem. The Dell Vostro 1400 (STAC9228) uses the model
"dell-bios" by default. The problem is that plugging the headphones does not
mute the speakers, and the digital mic does not work at all.

The model that works better is the "dell-3stack". But in this case there is
no analog mic available (the digital mic works, but it is too low).

Comparing the codecs I realizaded that the problem was that
the pin/node 0x0e (mic) was 0x01a19040 in the ref model and 0x01111212 in
the del-3stack. Then I just switched their positions in the initialization,
and voilá,
I have an analog mic using the model I want, that is, del-3stack.

Unfortunately, I know I did not contribute to anything. I just changed a
codec
to fit my needs, and maybe created a lot of noise tn the process.

Cheers,

and thanks for all the guidance I received.


--- alsa-driver-1.0.19/alsa-kernel/pci/hda/patch_sigmatel.c     2009-01-19
09:08:58.000000000 -0200
+++ alsa-driver-1.0.19-new/alsa-kernel/pci/hda/patch_sigmatel.c 2009-02-20
19:08:18.000000000 -0300
@@ -2113,8 +2113,8 @@
 };

 static unsigned int dell_3st_pin_configs[14] = {
-       0x02211230, 0x02a11220, 0x01a19040, 0x01114210,
-       0x01111212, 0x01116211, 0x01813050, 0x01112214,
+       0x02211230, 0x02a11220, 0x01111212, 0x01114210,
+       0x01a19040, 0x01116211, 0x01813050, 0x01112214,
        0x403003fa, 0x90a60040, 0x90a60040, 0x404003fb,
        0x40c003fc, 0x40000100
 };




-- 
Paulo Roma Cavalcanti
LCG - UFRJ

Re: idt blue jack patch

[Wu Fengguang]

On Sat, Feb 21, 2009 at 04:42:00AM +0200, Paulo Cavalcanti wrote:
> 
> 
> On Fri, Feb 20, 2009 at 10:55 PM, Wu Fengguang <fengguang.wu@intel.com<mailto:fengguang.wu@intel.com>> wrote:
> On Fri, Feb 20, 2009 at 07:18:31PM +0200, Takashi Iwai wrote:
> > At Fri, 20 Feb 2009 09:00:01 +0800,
> > Wu Fengguang wrote:
> > >
> > > Hi Tobin,
> > >
> > > Here are the Linux and WinXP pin configurations.
> > > Both Linux and WinXP configure node 0x0c as an output pin.
> > >
> > > However the driver seems to be offering three schemes:
> > >
> > >         scheme desc             0xC dev
> > > ------------------------------------------------------
> > >         IDS_CONFIG_OPEN         Speaker_Side/LineIn
> > >         IDS_CONFIG_51           LineIn
> > >         IDS_CONFIG_71           Speaker_Side
> > >
> > > Paulo, maybe you can run these commands to switch between
> > > linein/lineout modes:
> > >
> > >         # wget http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2
> > >
> > >         # set PIN_IN mode
> > >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> > >
> > >         # set PIN_OUT mode
> > >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> >
> >
> > Regarding the default pin configurations.
> > I made a series of patches to add the interface to change the default
> > pincfg values dynamically via hwdep sysfs.  The patches are found in
> > test/hda-pincfg branch of sound git tree
> >     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git<http://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git>
> >
> > and included in the very latest alsa-driver-unstable snapshot
> >     ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
> >
> > Basically, you can get / set the default pincfg values on the fly, and
> > trigger the codec reconfiguration after that.
> >
> > The init_pin_configs file shows the initial default pincfgs set by BIOS.
> >
> >       # cat /sys/class/sound/hwC0D0/init_pin_configs
> >       0x14 0x9993013f
> >       0x15 0x01014c10
> >       0x16 0x99030120
> >       0x18 0x01a19c30
> >       0x19 0x02a11c31
> >       0x1a 0x01813c32
> >       0x1b 0x02211c1f
> >       0x1c 0x99330133
> >       0x1d 0x411111f0
> >       0x1e 0x411111f0
> >       0x1f 0x411111f0
> >
> > Then, you can override the default value by writing to
> > override_pin_configs sysfs file.
> >
> >       # cat /sys/class/sound/hwC0D0/override_pin_configs
> >       # echo 0x1d 0x02a11c30 > /sys/class/sound/hwC0D0/override_pin_configs
> >       # cat /sys/class/sound/hwC0D0/override_pin_configs
> >       0x1d 0x02a11c30
> >
> > Note that this value won't appear in init_pin_configs.
> >
> > Also, there is another file, cur_pin_configs.  This contains the
> > pincfgs that are set by the driver explicitly.  For example,
> > the static pincfg table in patch_sigmatel.c appears here.
> >
> > Then you can trigger the codec reconfiguration by
> >
> >       # echo 1 > /sys/class/sound/hwC0D0/reconfig
> >
> > This will re-setup the driver based on the given pin configs.
> >
> > Unfortunately, in the current scenario, it can't override the static
> > pincfg table in the driver like in patch_sigmatel.c.  It's just for
> > fixing and BIOS setup.
> 
> If override_pin_configs cannot override the values in cur_pin_configs
> (or will it later?), then the name is kind of misleading.
> 
> How about the names bios_pin_configs, driver_pin_configs and user_pin_configs?
> 
> 
> 
> Having a tool for reconfiguring the pins seems to be the only hope
> for fixing the problems of all cards available out there.
> 
> However, I fixed my problem. The Dell Vostro 1400 (STAC9228) uses the model "dell-bios" by default. The problem is that plugging the headphones does not mute the speakers, and the digital mic does not work at all.
> 
> The model that works better is the "dell-3stack". But in this case there is no analog mic available (the digital mic works, but it is too low).
> 
> Comparing the codecs I realizaded that the problem was that
> the pin/node 0x0e (mic) was 0x01a19040 in the ref model and 0x01111212 in the del-3stack. Then I just switched their positions in the initialization, and voilá,
> I have an analog mic using the model I want, that is, del-3stack.

Paulo, have you tried the hda-verb? Or it won't work for you, so have
to modify the source code?

Thanks,
Fengguang

> Unfortunately, I know I did not contribute to anything. I just changed a codec
> to fit my needs, and maybe created a lot of noise tn the process.
> 
> Cheers,
> 
> and thanks for all the guidance I received.
> 
> 
> --- alsa-driver-1.0.19/alsa-kernel/pci/hda/patch_sigmatel.c     2009-01-19 09:08:58.000000000 -0200
> +++ alsa-driver-1.0.19-new/alsa-kernel/pci/hda/patch_sigmatel.c 2009-02-20 19:08:18.000000000 -0300
> @@ -2113,8 +2113,8 @@
>  };
> 
>  static unsigned int dell_3st_pin_configs[14] = {
> -       0x02211230, 0x02a11220, 0x01a19040, 0x01114210,
> -       0x01111212, 0x01116211, 0x01813050, 0x01112214,
> +       0x02211230, 0x02a11220, 0x01111212, 0x01114210,
> +       0x01a19040, 0x01116211, 0x01813050, 0x01112214,
>         0x403003fa, 0x90a60040, 0x90a60040, 0x404003fb,
>         0x40c003fc, 0x40000100
>  };
> 
> 
> 
> 
> --
> Paulo Roma Cavalcanti
> LCG - UFRJ
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: idt blue jack patch

[Paulo Cavalcanti]

On Fri, Feb 20, 2009 at 11:56 PM, Wu Fengguang <fengguang.wu@intel.com>wrote:

> On Sat, Feb 21, 2009 at 04:42:00AM +0200, Paulo Cavalcanti wrote:
> >
> >
> > On Fri, Feb 20, 2009 at 10:55 PM, Wu Fengguang <fengguang.wu@intel.com
> <mailto:fengguang.wu@intel.com>> wrote:
> > On Fri, Feb 20, 2009 at 07:18:31PM +0200, Takashi Iwai wrote:
> > > At Fri, 20 Feb 2009 09:00:01 +0800,
> > > Wu Fengguang wrote:
> > > >
> > > > Hi Tobin,
> > > >
> > > > Here are the Linux and WinXP pin configurations.
> > > > Both Linux and WinXP configure node 0x0c as an output pin.
> > > >
> > > > However the driver seems to be offering three schemes:
> > > >
> > > >         scheme desc             0xC dev
> > > > ------------------------------------------------------
> > > >         IDS_CONFIG_OPEN         Speaker_Side/LineIn
> > > >         IDS_CONFIG_51           LineIn
> > > >         IDS_CONFIG_71           Speaker_Side
> > > >
> > > > Paulo, maybe you can run these commands to switch between
> > > > linein/lineout modes:
> > > >
> > > >         # wget
> http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2
> > > >
> > > >         # set PIN_IN mode
> > > >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> > > >
> > > >         # set PIN_OUT mode
> > > >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> > >
> > >
> > > Regarding the default pin configurations.
> > > I made a series of patches to add the interface to change the default
> > > pincfg values dynamically via hwdep sysfs.  The patches are found in
> > > test/hda-pincfg branch of sound git tree
> > >     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git<
> http://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git>
> > >
> > > and included in the very latest alsa-driver-unstable snapshot
> > >
> ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
> > >
> > > Basically, you can get / set the default pincfg values on the fly, and
> > > trigger the codec reconfiguration after that.
> > >
> > > The init_pin_configs file shows the initial default pincfgs set by
> BIOS.
> > >
> > >       # cat /sys/class/sound/hwC0D0/init_pin_configs
> > >       0x14 0x9993013f
> > >       0x15 0x01014c10
> > >       0x16 0x99030120
> > >       0x18 0x01a19c30
> > >       0x19 0x02a11c31
> > >       0x1a 0x01813c32
> > >       0x1b 0x02211c1f
> > >       0x1c 0x99330133
> > >       0x1d 0x411111f0
> > >       0x1e 0x411111f0
> > >       0x1f 0x411111f0
> > >
> > > Then, you can override the default value by writing to
> > > override_pin_configs sysfs file.
> > >
> > >       # cat /sys/class/sound/hwC0D0/override_pin_configs
> > >       # echo 0x1d 0x02a11c30 >
> /sys/class/sound/hwC0D0/override_pin_configs
> > >       # cat /sys/class/sound/hwC0D0/override_pin_configs
> > >       0x1d 0x02a11c30
> > >
> > > Note that this value won't appear in init_pin_configs.
> > >
> > > Also, there is another file, cur_pin_configs.  This contains the
> > > pincfgs that are set by the driver explicitly.  For example,
> > > the static pincfg table in patch_sigmatel.c appears here.
> > >
> > > Then you can trigger the codec reconfiguration by
> > >
> > >       # echo 1 > /sys/class/sound/hwC0D0/reconfig
> > >
> > > This will re-setup the driver based on the given pin configs.
> > >
> > > Unfortunately, in the current scenario, it can't override the static
> > > pincfg table in the driver like in patch_sigmatel.c.  It's just for
> > > fixing and BIOS setup.
> >
> > If override_pin_configs cannot override the values in cur_pin_configs
> > (or will it later?), then the name is kind of misleading.
> >
> > How about the names bios_pin_configs, driver_pin_configs and
> user_pin_configs?
> >
> >
> >
> > Having a tool for reconfiguring the pins seems to be the only hope
> > for fixing the problems of all cards available out there.
> >
> > However, I fixed my problem. The Dell Vostro 1400 (STAC9228) uses the
> model "dell-bios" by default. The problem is that plugging the headphones
> does not mute the speakers, and the digital mic does not work at all.
> >
> > The model that works better is the "dell-3stack". But in this case there
> is no analog mic available (the digital mic works, but it is too low).
> >
> > Comparing the codecs I realizaded that the problem was that
> > the pin/node 0x0e (mic) was 0x01a19040 in the ref model and 0x01111212 in
> the del-3stack. Then I just switched their positions in the initialization,
> and voilá,
> > I have an analog mic using the model I want, that is, del-3stack.
>
> Paulo, have you tried the hda-verb? Or it won't work for you, so have
> to modify the source code?
>
>
No. I did not try hda-verb yet.

I'll do it tomorrow.

Thanks.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ

Re: idt blue jack patch

[Takashi Iwai]

At Sat, 21 Feb 2009 09:55:29 +0800,
Wu Fengguang wrote:
> 
> On Fri, Feb 20, 2009 at 07:18:31PM +0200, Takashi Iwai wrote:
> > At Fri, 20 Feb 2009 09:00:01 +0800,
> > Wu Fengguang wrote:
> > > 
> > > Hi Tobin,
> > > 
> > > Here are the Linux and WinXP pin configurations.
> > > Both Linux and WinXP configure node 0x0c as an output pin.
> > > 
> > > However the driver seems to be offering three schemes:
> > > 
> > >         scheme desc             0xC dev
> > > ------------------------------------------------------
> > >         IDS_CONFIG_OPEN         Speaker_Side/LineIn
> > >         IDS_CONFIG_51           LineIn
> > >         IDS_CONFIG_71           Speaker_Side
> > > 
> > > Paulo, maybe you can run these commands to switch between
> > > linein/lineout modes:
> > > 
> > >         # wget http://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz2
> > > 
> > >         # set PIN_IN mode
> > >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x20
> > > 
> > >         # set PIN_OUT mode
> > >         hda-verb /dev/snd/hwC0D2 0x0c SET_PIN_WIDGET_CONTROL 0x40
> > 
> > 
> > Regarding the default pin configurations.
> > I made a series of patches to add the interface to change the default
> > pincfg values dynamically via hwdep sysfs.  The patches are found in
> > test/hda-pincfg branch of sound git tree
> >     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> > 
> > and included in the very latest alsa-driver-unstable snapshot
> >     ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
> > 
> > Basically, you can get / set the default pincfg values on the fly, and
> > trigger the codec reconfiguration after that.
> > 
> > The init_pin_configs file shows the initial default pincfgs set by BIOS.
> > 
> > 	# cat /sys/class/sound/hwC0D0/init_pin_configs
> > 	0x14 0x9993013f
> > 	0x15 0x01014c10
> > 	0x16 0x99030120
> > 	0x18 0x01a19c30
> > 	0x19 0x02a11c31
> > 	0x1a 0x01813c32
> > 	0x1b 0x02211c1f
> > 	0x1c 0x99330133
> > 	0x1d 0x411111f0
> > 	0x1e 0x411111f0
> > 	0x1f 0x411111f0
> > 
> > Then, you can override the default value by writing to
> > override_pin_configs sysfs file.
> > 
> > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > 	# echo 0x1d 0x02a11c30 > /sys/class/sound/hwC0D0/override_pin_configs
> > 	# cat /sys/class/sound/hwC0D0/override_pin_configs
> > 	0x1d 0x02a11c30
> > 
> > Note that this value won't appear in init_pin_configs.
> > 
> > Also, there is another file, cur_pin_configs.  This contains the
> > pincfgs that are set by the driver explicitly.  For example,
> > the static pincfg table in patch_sigmatel.c appears here.
> > 
> > Then you can trigger the codec reconfiguration by
> > 
> > 	# echo 1 > /sys/class/sound/hwC0D0/reconfig
> > 
> > This will re-setup the driver based on the given pin configs.
> > 
> > Unfortunately, in the current scenario, it can't override the static
> > pincfg table in the driver like in patch_sigmatel.c.  It's just for
> > fixing and BIOS setup.
> 
> If override_pin_configs cannot override the values in cur_pin_configs
> (or will it later?), then the name is kind of misleading.
> 
> How about the names bios_pin_configs, driver_pin_configs and user_pin_configs?

Yep, they sound better.  Will change them.

Thanks!

Takashi