[alsa-devel] idt blue jack patch
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&o...
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.
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&o...
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
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&o...
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.
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
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 andthe
pink > is mic. > Some cards allow reconfiguring the jacks in alsamixer, but theDG45ID
> already has > an orange and black jacks for rear and center speakers, and adigital
> 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 developmentlist,
> so the other developers could decide what to do. > > I would like to add that I can use the input source and the micjust
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 thefix
> for this card, Takashi started with me some time ago (I just madethe
> 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.
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ć
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
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
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
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.
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.bz...
# 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.commailto: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.orgmailto: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.orgmailto: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.
On Thu, Feb 19, 2009 at 10:00 PM, Wu Fengguang fengguang.wu@intel.comwrote:
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_SidePaulo, maybe you can run these commands to switch between linein/lineout modes:
# wgethttp://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz...
# 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 0x40Thanks, Fengguang
/proc/asound/card0/codec#2
Codec: IDT 92HD73E1X5 Address: 2 Vendor Id: 0x111d7676 Subsystem Id: 0x80865002 Revision Id: 0x100202AUD_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.
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.commailto: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_SidePaulo, 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 0x40Thanks, Fengguang
/proc/asound/card0/codec#2
Codec: IDT 92HD73E1X5 Address: 2 Vendor Id: 0x111d7676 Subsystem Id: 0x80865002 Revision Id: 0x100202AUD_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 0x1eThanks 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
On Fri, Feb 20, 2009 at 8:20 AM, Wu Fengguang fengguang.wu@intel.comwrote:
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_SidePaulo, maybe you can run these commands to switch between linein/lineout modes:
# wgethttp://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz...
# 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 0x40Thanks, Fengguang
/proc/asound/card0/codec#2
Codec: IDT 92HD73E1X5 Address: 2 Vendor Id: 0x111d7676 Subsystem Id: 0x80865002 Revision Id: 0x100202AUD_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 0x1eThanks 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.
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.commailto: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.commailto:fengguang.wu@intel.com<mailto:fengguang.wu@intel.commailto: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_SidePaulo, 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 0x40Thanks, Fengguang
/proc/asound/card0/codec#2
Codec: IDT 92HD73E1X5 Address: 2 Vendor Id: 0x111d7676 Subsystem Id: 0x80865002 Revision Id: 0x100202AUD_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 0x1eThanks 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
On Fri, Feb 20, 2009 at 11:31 AM, Wu Fengguang fengguang.wu@intel.comwrote:
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.commailto: 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_SidePaulo, maybe you can run these commands to switch between linein/lineout modes:
# wgethttp://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz...
# 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 0x40Thanks, Fengguang
/proc/asound/card0/codec#2
Codec: IDT 92HD73E1X5 Address: 2 Vendor Id: 0x111d7676 Subsystem Id: 0x80865002 Revision Id: 0x100202AUD_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 0x1eThanks 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.
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.commailto: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.commailto:fengguang.wu@intel.com<mailto:fengguang.wu@intel.commailto: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.commailto:fengguang.wu@intel.com<mailto:fengguang.wu@intel.commailto:fengguang.wu@intel.com><mailto:fengguang.wu@intel.commailto:fengguang.wu@intel.com<mailto:fengguang.wu@intel.commailto: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_SidePaulo, 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 0x40Thanks, Fengguang
/proc/asound/card0/codec#2
Codec: IDT 92HD73E1X5 Address: 2 Vendor Id: 0x111d7676 Subsystem Id: 0x80865002 Revision Id: 0x100202AUD_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 0x1eThanks 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
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_SidePaulo, 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
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_SidePaulo, 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 0x40Regarding 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
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_SidePaulo, 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 0x40Regarding 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
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_SidePaulo, 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 0x40Regarding 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
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
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
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
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
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
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
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_SidePaulo, 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 0x40Regarding 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
On Fri, Feb 20, 2009 at 10:55 PM, Wu Fengguang fengguang.wu@intel.comwrote:
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_SidePaulo, maybe you can run these commands to switch between linein/lineout modes:
# wgethttp://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz...
# 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 0x40Regarding 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 0x411111f0Then, 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 0x02a11c30Note 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/reconfigThis 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 };
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.commailto: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_SidePaulo, 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 0x40Regarding 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.githttp://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 0x411111f0Then, 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 0x02a11c30Note 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/reconfigThis 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
On Fri, Feb 20, 2009 at 11:56 PM, Wu Fengguang fengguang.wu@intel.comwrote:
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_SidePaulo, maybe you can run these commands to switch between linein/lineout modes:
# wgethttp://www.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb-0.3.tar.bz...
# 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 0x40Regarding 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%3E
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 0x411111f0Then, 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 0x02a11c30Note 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/reconfigThis 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.
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_SidePaulo, 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 0x40Regarding 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
participants (5)
-
Paulo Cavalcanti -
Takashi Iwai -
Tobin Davis -
Vedran Miletić -
Wu Fengguang