Re: [alsa-devel] Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series
At Wed, 15 Feb 2012 17:08:45 +0800, joey.jiaojg wrote:
Well, now I have fully fixed the speaker/headphone issue for HP COMPAQ B1900 by adding a new model=b1900 into patch_realtek.c which also can automute by detect HP state.
That's great.
As I cannot compile alsa-driver-1.0.25 on my ubuntu 11.10, so I modified based on kernel-3.0.13 (alsa version 1.0.24) from ubuntu src. Attached with stocked source and my updated one, please consider adding into next alsa-driver.
Could you simply give a patch file (with "diff -up")? Then I can check your changes more easily.
thanks,
Takashi
Here is the diff file.
On 2012年02月15日 17:22, Takashi Iwai wrote:
At Wed, 15 Feb 2012 17:08:45 +0800, joey.jiaojg wrote:
Well, now I have fully fixed the speaker/headphone issue for HP COMPAQ B1900 by adding a new model=b1900 into patch_realtek.c which also can automute by detect HP state.
That's great.
As I cannot compile alsa-driver-1.0.25 on my ubuntu 11.10, so I modified based on kernel-3.0.13 (alsa version 1.0.24) from ubuntu src. Attached with stocked source and my updated one, please consider adding into next alsa-driver.
Could you simply give a patch file (with "diff -up")? Then I can check your changes more easily.
thanks,
Takashi
At Wed, 15 Feb 2012 17:31:44 +0800, joey.jiaojg wrote:
Here is the diff file.
Thanks.
+/* toggle speaker-output according to the hp-jack state */ +static void alc260_b1900_automute(struct hda_codec *codec) +{
unsigned int present;- present = snd_hda_jack_detect(codec, 0x0f);
- if (present) {
snd_hda_codec_write_cache(codec, 0x01, 0,AC_VERB_SET_GPIO_MASK, 0);snd_hda_codec_write_cache(codec, 0x01, 0,AC_VERB_SET_GPIO_DIRECTION,0);
What actually this GPIO bit does on your device? To mute/unmute the speaker?
If so, doesn't the speaker toggle work with just changing the pin-control of the corresponding pin?
Takashi
I have tried to enable each one of them separately, and the speaker doesn't work. I have to use these 3 write_cache to make switch and auto-detect work smoothly.
On 2012年02月15日 17:40, Takashi Iwai wrote:
At Wed, 15 Feb 2012 17:31:44 +0800, joey.jiaojg wrote:
Here is the diff file.
Thanks.
+/* toggle speaker-output according to the hp-jack state */ +static void alc260_b1900_automute(struct hda_codec *codec) +{
unsigned int present;- present = snd_hda_jack_detect(codec, 0x0f);
- if (present) {
snd_hda_codec_write_cache(codec, 0x01, 0,AC_VERB_SET_GPIO_MASK, 0);snd_hda_codec_write_cache(codec, 0x01, 0,AC_VERB_SET_GPIO_DIRECTION,0);What actually this GPIO bit does on your device? To mute/unmute the speaker?
If so, doesn't the speaker toggle work with just changing the pin-control of the corresponding pin?
Takashi
At Wed, 15 Feb 2012 17:45:37 +0800, joey.jiaojg wrote:
I have tried to enable each one of them separately, and the speaker doesn't work.
Sorry, it's not clear what you meant. Each of what separately? And what does GPIO do exactly?
I have to use these 3 write_cache to make switch and auto-detect work smoothly.
We need to know the reason why these must be needed.
Takashi
On 2012年02月15日 17:40, Takashi Iwai wrote:
At Wed, 15 Feb 2012 17:31:44 +0800, joey.jiaojg wrote:
Here is the diff file.
Thanks.
+/* toggle speaker-output according to the hp-jack state */ +static void alc260_b1900_automute(struct hda_codec *codec) +{
unsigned int present;- present = snd_hda_jack_detect(codec, 0x0f);
- if (present) {
snd_hda_codec_write_cache(codec, 0x01, 0,AC_VERB_SET_GPIO_MASK, 0);snd_hda_codec_write_cache(codec, 0x01, 0,AC_VERB_SET_GPIO_DIRECTION,0);What actually this GPIO bit does on your device? To mute/unmute the speaker?
If so, doesn't the speaker toggle work with just changing the pin-control of the corresponding pin?
Takashi
OK, the situation is 0x01 is to control GPIO0: 1. if I write (codec,0x01,0,AC_VERB_SET_GPIO_MASK,1) only; the result is speaker not work.
2. if I write (codec,0x01,0,AC_VERB_SET_GPIO_DIRECTION,1) only; the result is speaker not work.
3. If I write step 1 & 2 together, speaker works when I reboot.
4. Then If I plugged in the headphone, the headphone doesn't work. It only works when I write (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_HP).
5. From step 3 & 4, it's similar for cases that I reboot with headphone plugged in. That is, if I remove headphone, speaker doesn't work automatically. If I write (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_OUT), the auto-detection function works well can switch speaker/headphone automatically.
I don't know why it's this case, and from alsa document, it seems only enable GPIO0 will work but actually not.
On 2012年02月15日 17:58, Takashi Iwai wrote:
At Wed, 15 Feb 2012 17:45:37 +0800, joey.jiaojg wrote:
I have tried to enable each one of them separately, and the speaker doesn't work.
Sorry, it's not clear what you meant. Each of what separately? And what does GPIO do exactly?
I have to use these 3 write_cache to make switch and auto-detect work smoothly.
We need to know the reason why these must be needed.
Takashi
On 2012年02月15日 17:40, Takashi Iwai wrote:
At Wed, 15 Feb 2012 17:31:44 +0800, joey.jiaojg wrote:
Here is the diff file.
Thanks.
+/* toggle speaker-output according to the hp-jack state */ +static void alc260_b1900_automute(struct hda_codec *codec) +{
unsigned int present;- present = snd_hda_jack_detect(codec, 0x0f);
- if (present) {
snd_hda_codec_write_cache(codec, 0x01, 0,AC_VERB_SET_GPIO_MASK, 0);snd_hda_codec_write_cache(codec, 0x01, 0,AC_VERB_SET_GPIO_DIRECTION,0);What actually this GPIO bit does on your device? To mute/unmute the speaker?
If so, doesn't the speaker toggle work with just changing the pin-control of the corresponding pin?
Takashi
At Wed, 15 Feb 2012 18:06:39 +0800, joey.jiaojg wrote:
OK, the situation is 0x01 is to control GPIO0:
- if I write (codec,0x01,0,AC_VERB_SET_GPIO_MASK,1) only; the result is
speaker not work.
- if I write (codec,0x01,0,AC_VERB_SET_GPIO_DIRECTION,1) only; the
result is speaker not work.
Sure, GPIO must be always set mask, direction and data all together. The question is, when you set GPIO mask/dir/data, the speaker starts playing, and if set to zero (e.g. only data), the speaker is muted?
- If I write step 1 & 2 together, speaker works when I reboot.
Then GPIO is likely an external amp control.
- Then If I plugged in the headphone, the headphone doesn't work. It
only works when I write (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_HP).
This is normal.
- From step 3 & 4, it's similar for cases that I reboot with headphone
plugged in. That is, if I remove headphone, speaker doesn't work automatically. If I write (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_OUT), the auto-detection function works well can switch speaker/headphone automatically.
That's odd. If you don't change from PIN_HP, doesn't the unsolicited event work?
Another question is, when you set PIN_WIDGET_CONTROL on the speaker pin (not sure which one is) to 0x00, does it mute the speaker, too?
Takashi
I don't know why it's this case, and from alsa document, it seems only enable GPIO0 will work but actually not.
On 2012年02月15日 17:58, Takashi Iwai wrote:
At Wed, 15 Feb 2012 17:45:37 +0800, joey.jiaojg wrote:
I have tried to enable each one of them separately, and the speaker doesn't work.
Sorry, it's not clear what you meant. Each of what separately? And what does GPIO do exactly?
I have to use these 3 write_cache to make switch and auto-detect work smoothly.
We need to know the reason why these must be needed.
Takashi
On 2012年02月15日 17:40, Takashi Iwai wrote:
At Wed, 15 Feb 2012 17:31:44 +0800, joey.jiaojg wrote:
Here is the diff file.
Thanks.
+/* toggle speaker-output according to the hp-jack state */ +static void alc260_b1900_automute(struct hda_codec *codec) +{
unsigned int present;- present = snd_hda_jack_detect(codec, 0x0f);
- if (present) {
snd_hda_codec_write_cache(codec, 0x01, 0,AC_VERB_SET_GPIO_MASK, 0);snd_hda_codec_write_cache(codec, 0x01, 0,AC_VERB_SET_GPIO_DIRECTION,0);What actually this GPIO bit does on your device? To mute/unmute the speaker?
If so, doesn't the speaker toggle work with just changing the pin-control of the corresponding pin?
Takashi
Please check my reply below.
On 2012年02月15日 18:11, Takashi Iwai wrote:
At Wed, 15 Feb 2012 18:06:39 +0800, joey.jiaojg wrote:
OK, the situation is 0x01 is to control GPIO0:
- if I write (codec,0x01,0,AC_VERB_SET_GPIO_MASK,1) only; the result is
speaker not work.
- if I write (codec,0x01,0,AC_VERB_SET_GPIO_DIRECTION,1) only; the
result is speaker not work.
Sure, GPIO must be always set mask, direction and data all together. The question is, when you set GPIO mask/dir/data, the speaker starts playing, and if set to zero (e.g. only data), the speaker is muted?
JOEY: I tried set data to 0 or 1 doesn't influence. when I set mask & dir to 1, speaker starts to work and to 0 speaker muted while headphone works if headphone plugged in.
- If I write step 1& 2 together, speaker works when I reboot.
Then GPIO is likely an external amp control.
JOEY: YES.
- Then If I plugged in the headphone, the headphone doesn't work. It
only works when I write (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_HP).
This is normal.
JOEY: If I don't modify model=will. And headphone can play even without set AC_VERB_SET_PIN_WIDGET_CONTROL to PIN_HP. Of course, automute doesn't work as there is function implemented.
- From step 3& 4, it's similar for cases that I reboot with headphone
plugged in. That is, if I remove headphone, speaker doesn't work automatically. If I write (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_OUT), the auto-detection function works well can switch speaker/headphone automatically.
That's odd. If you don't change from PIN_HP, doesn't the unsolicited event work?
JOEY: the unsolicited works from the register I read also from the printk I previous added. But the audio path doesn't switch between speaker and headphone. I don't know why. It can works manually if I send any hda-verb command to codec, like hda-verb /dev/snd/hwC0D0 0x0F 0xF09 0x0; I think perhaps there needs to be some delay. But I wait seconds and it doesn't switch. Then if I run any hda-verb command, it will then switch. Then after I change from PIN_HP or from PIN_OUT, the automute (actually audio path switch) works.
Another question is, when you set PIN_WIDGET_CONTROL on the speaker pin (not sure which one is) to 0x00, does it mute the speaker, too?
JOEY: No, it doesn't mute the speaker. To mute the speaker, I just need to set 0 to dir or mask. Then audio path is to headphone.
Takashi
I don't know why it's this case, and from alsa document, it seems only enable GPIO0 will work but actually not.
On 2012年02月15日 17:58, Takashi Iwai wrote:
At Wed, 15 Feb 2012 17:45:37 +0800, joey.jiaojg wrote:
I have tried to enable each one of them separately, and the speaker doesn't work.
Sorry, it's not clear what you meant. Each of what separately? And what does GPIO do exactly?
I have to use these 3 write_cache to make switch and auto-detect work smoothly.
We need to know the reason why these must be needed.
Takashi
On 2012年02月15日 17:40, Takashi Iwai wrote:
At Wed, 15 Feb 2012 17:31:44 +0800, joey.jiaojg wrote:
Here is the diff file.
Thanks.
+/* toggle speaker-output according to the hp-jack state */ +static void alc260_b1900_automute(struct hda_codec *codec) +{
unsigned int present;- present = snd_hda_jack_detect(codec, 0x0f);
- if (present) {
snd_hda_codec_write_cache(codec, 0x01, 0,AC_VERB_SET_GPIO_MASK, 0);snd_hda_codec_write_cache(codec, 0x01, 0,AC_VERB_SET_GPIO_DIRECTION,0);What actually this GPIO bit does on your device? To mute/unmute the speaker?
If so, doesn't the speaker toggle work with just changing the pin-control of the corresponding pin?
Takashi
At Wed, 15 Feb 2012 21:14:48 +0800, joey.jiaojg wrote:
Please check my reply below.
On 2012年02月15日 18:11, Takashi Iwai wrote:
At Wed, 15 Feb 2012 18:06:39 +0800, joey.jiaojg wrote:
OK, the situation is 0x01 is to control GPIO0:
- if I write (codec,0x01,0,AC_VERB_SET_GPIO_MASK,1) only; the result is
speaker not work.
- if I write (codec,0x01,0,AC_VERB_SET_GPIO_DIRECTION,1) only; the
result is speaker not work.
Sure, GPIO must be always set mask, direction and data all together. The question is, when you set GPIO mask/dir/data, the speaker starts playing, and if set to zero (e.g. only data), the speaker is muted?
JOEY: I tried set data to 0 or 1 doesn't influence. when I set mask & dir to 1, speaker starts to work and to 0 speaker muted while headphone works if headphone plugged in.
There is something wrong in tests. The direction bit controls only the direction, so yes, it must match with the value the hardware expected. Otherwise it won't work, thus it's turned off.
- If I write step 1& 2 together, speaker works when I reboot.
Then GPIO is likely an external amp control.
JOEY: YES.
- Then If I plugged in the headphone, the headphone doesn't work. It
only works when I write (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_HP).
This is normal.
JOEY: If I don't modify model=will. And headphone can play even without set AC_VERB_SET_PIN_WIDGET_CONTROL to PIN_HP. Of course, automute doesn't work as there is function implemented.
OK, this is because of model=will strange things.
- From step 3& 4, it's similar for cases that I reboot with headphone
plugged in. That is, if I remove headphone, speaker doesn't work automatically. If I write (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_OUT), the auto-detection function works well can switch speaker/headphone automatically.
That's odd. If you don't change from PIN_HP, doesn't the unsolicited event work?
JOEY: the unsolicited works from the register I read also from the printk I previous added. But the audio path doesn't switch between speaker and headphone. I don't know why. It can works manually if I send any hda-verb command to codec, like hda-verb /dev/snd/hwC0D0 0x0F 0xF09 0x0; I think perhaps there needs to be some delay. But I wait seconds and it doesn't switch. Then if I run any hda-verb command, it will then switch. Then after I change from PIN_HP or from PIN_OUT, the automute (actually audio path switch) works.
Is the effect only with this pin? In other words, if you change the pin control value of other pin, no similar effect?
Another question is, when you set PIN_WIDGET_CONTROL on the speaker pin (not sure which one is) to 0x00, does it mute the speaker, too?
JOEY: No, it doesn't mute the speaker. To mute the speaker, I just need to set 0 to dir or mask. Then audio path is to headphone.
And you are sure that it's the right pin? Which pin did you test?
The pin-control doesn't always turn off the output in some cases. But, we'd need to be sure whether we are looking at the right one.
thanks,
Takashi
I think the only question below is about the automute, right? Then I did another test by modifying like below (so the result is same as sending any hda-verb cmd) -- The result is the auto-mute works too: if (present) { snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_MASK, 0); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DIRECTION, 0); /*snd_hda_codec_write_cache(codec, 0x0f, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP);*/ snd_hda_codec_read(codec, 0x01, 0, AC_VERB_GET_GPIO_MASK, 0); } else { snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_MASK, 1); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DIRECTION, 1); /*snd_hda_codec_write_cache(codec, 0x0f, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT);*/ snd_hda_codec_read(codec, 0x01, 0, AC_VERB_GET_GPIO_MASK, 0); }
On 2012年02月15日 21:21, Takashi Iwai wrote:
At Wed, 15 Feb 2012 21:14:48 +0800, joey.jiaojg wrote:
Please check my reply below.
On 2012年02月15日 18:11, Takashi Iwai wrote:
At Wed, 15 Feb 2012 18:06:39 +0800, joey.jiaojg wrote:
OK, the situation is 0x01 is to control GPIO0:
- if I write (codec,0x01,0,AC_VERB_SET_GPIO_MASK,1) only; the result is
speaker not work.
- if I write (codec,0x01,0,AC_VERB_SET_GPIO_DIRECTION,1) only; the
result is speaker not work.
Sure, GPIO must be always set mask, direction and data all together. The question is, when you set GPIO mask/dir/data, the speaker starts playing, and if set to zero (e.g. only data), the speaker is muted?
JOEY: I tried set data to 0 or 1 doesn't influence. when I set mask& dir to 1, speaker starts to work and to 0 speaker muted while headphone works if headphone plugged in.
There is something wrong in tests. The direction bit controls only the direction, so yes, it must match with the value the hardware expected. Otherwise it won't work, thus it's turned off.
- If I write step 1& 2 together, speaker works when I reboot.
Then GPIO is likely an external amp control.
JOEY: YES.
- Then If I plugged in the headphone, the headphone doesn't work. It
only works when I write (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_HP).
This is normal.
JOEY: If I don't modify model=will. And headphone can play even without set AC_VERB_SET_PIN_WIDGET_CONTROL to PIN_HP. Of course, automute doesn't work as there is function implemented.
OK, this is because of model=will strange things.
- From step 3& 4, it's similar for cases that I reboot with headphone
plugged in. That is, if I remove headphone, speaker doesn't work automatically. If I write (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_OUT), the auto-detection function works well can switch speaker/headphone automatically.
That's odd. If you don't change from PIN_HP, doesn't the unsolicited event work?
JOEY: the unsolicited works from the register I read also from the printk I previous added. But the audio path doesn't switch between speaker and headphone. I don't know why. It can works manually if I send any hda-verb command to codec, like hda-verb /dev/snd/hwC0D0 0x0F 0xF09 0x0; I think perhaps there needs to be some delay. But I wait seconds and it doesn't switch. Then if I run any hda-verb command, it will then switch. Then after I change from PIN_HP or from PIN_OUT, the automute (actually audio path switch) works.
Is the effect only with this pin? In other words, if you change the pin control value of other pin, no similar effect?
Another question is, when you set PIN_WIDGET_CONTROL on the speaker pin (not sure which one is) to 0x00, does it mute the speaker, too?
JOEY: No, it doesn't mute the speaker. To mute the speaker, I just need to set 0 to dir or mask. Then audio path is to headphone.
And you are sure that it's the right pin? Which pin did you test?
The pin-control doesn't always turn off the output in some cases. But, we'd need to be sure whether we are looking at the right one.
thanks,
Takashi
At Wed, 15 Feb 2012 22:45:27 +0800, joey.jiaojg wrote:
I think the only question below is about the automute, right?
Not really. The most important thing is to understand what's doing what. Since your code can't be applied any longer at all to the latest code tree because of the fundamental code rewrite, we need to do it right.
So, please check the following:
1. Does any pin correspond to the speaker output? Try to change the pin control of each pin between 0x10 and 0x19 via hda-verb while the speaker output is active. Does any pin change the speaker output?
2. Plug your headphone. Now the speaker is muted with your patch. What happens when you run like below?
hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_MASK 1 hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DIR 1 hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 1
Does the speaker starts playing again? Then, what happens now with:
hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 0
??
Takashi
1. I changed to model=will to test without headphone hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 [NID=0x0F, 0x10~0x19, 0x1B] Result: for sure not work as GPIO not open 2. I changed to model=b1900 to test without headphone hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 Result: speaker still works. It's for sure. 3. Then same condition as step 2 but change 0xC0 to 0x0 hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0x0 Result: speaker doesn't work only when NID=0x0F; then I tried param=0x40 and 0x80, when param=0x40, speaker works while param=0x80, speaker doesn't work. 4. Then I plugged in headphone. Now the param =0x40 for NID=0x0F. Result: Headphone works while speaker muted. Then I changed param=0x80. (same result when param=0xC0) Result: Headphone still works while speaker muted. 5. Then I reboot with headphone plugged in to test your step 2. YES, now the speaker muted while headphone works. Then I do your cmds: hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 1 Result: headphone works, speaker muted hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 1 Result: headphone muted, speaker works hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 Result: headphone works, speaker muted hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0 Result: headphone muted, speaker works. Please noted the last two cmds, it's strange but it's true.
Any additional tests?
在 2012年2月15日 下午11:04，Takashi Iwai tiwai@suse.de 写道：
At Wed, 15 Feb 2012 22:45:27 +0800, joey.jiaojg wrote:
I think the only question below is about the automute, right?
Not really. The most important thing is to understand what's doing what. Since your code can't be applied any longer at all to the latest code tree because of the fundamental code rewrite, we need to do it right.
So, please check the following:
- Does any pin correspond to the speaker output? Try to change the
pin control of each pin between 0x10 and 0x19 via hda-verb while the speaker output is active. Does any pin change the speaker output?
- Plug your headphone. Now the speaker is muted with your patch.
What happens when you run like below?
hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_MASK 1 hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DIR 1 hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 1
Does the speaker starts playing again? Then, what happens now with:
hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 0
??
Takashi
And now this code works: /* toggle speaker-output according to the hp-jack state */ static void alc260_b1900_automute(struct hda_codec *codec) { unsigned int present;
present = snd_hda_jack_detect(codec, 0x0f); if (present) { snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_MASK, 0); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DIRECTION, 0); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DATA, 1); } else { snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_MASK, 1); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DIRECTION, 1); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DATA, 0); } }
On 2012年02月16日 10:04, Joey Jiao wrote:
- I changed to model=will to test without headphone
hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 [NID=0x0F, 0x10~0x19, 0x1B] Result: for sure not work as GPIO not open 2. I changed to model=b1900 to test without headphone hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 Result: speaker still works. It's for sure. 3. Then same condition as step 2 but change 0xC0 to 0x0 hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0x0 Result: speaker doesn't work only when NID=0x0F; then I tried param=0x40 and 0x80, when param=0x40, speaker works while param=0x80, speaker doesn't work. 4. Then I plugged in headphone. Now the param =0x40 for NID=0x0F. Result: Headphone works while speaker muted. Then I changed param=0x80. (same result when param=0xC0) Result: Headphone still works while speaker muted. 5. Then I reboot with headphone plugged in to test your step 2. YES, now the speaker muted while headphone works. Then I do your cmds: hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 1 Result: headphone works, speaker muted hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 1 Result: headphone muted, speaker works hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 Result: headphone works, speaker muted hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0 Result: headphone muted, speaker works. Please noted the last two cmds, it's strange but it's true.
Any additional tests?
在 2012年2月15日 下午11:04，Takashi Iwaitiwai@suse.de 写道：
At Wed, 15 Feb 2012 22:45:27 +0800, joey.jiaojg wrote:
I think the only question below is about the automute, right?
Not really. The most important thing is to understand what's doing what. Since your code can't be applied any longer at all to the latest code tree because of the fundamental code rewrite, we need to do it right.
So, please check the following:
Does any pin correspond to the speaker output? Try to change the pin control of each pin between 0x10 and 0x19 via hda-verb while the speaker output is active. Does any pin change the speaker output?
Plug your headphone. Now the speaker is muted with your patch. What happens when you run like below?
hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_MASK 1 hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DIR 1 hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 1Does the speaker starts playing again? Then, what happens now with:
hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 0??
Takashi
At Thu, 16 Feb 2012 11:41:10 +0800, joey.jiaojg wrote:
And now this code works: /* toggle speaker-output according to the hp-jack state */ static void alc260_b1900_automute(struct hda_codec *codec) { unsigned int present;
present = snd_hda_jack_detect(codec, 0x0f); if (present) { snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_MASK, 0); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DIRECTION, 0); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DATA, 1); } else { snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_MASK, 1); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DIRECTION, 1); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DATA, 0); }}
The GPIO_MASK and GPIO_DIRECTION need to be set only once in the init verbs, both to 1. Then you just need to flip GPIO_DATA between 0 and 1 in the unsol event handler.
Takashi
At Thu, 16 Feb 2012 10:04:09 +0800, Joey Jiao wrote:
- I changed to model=will to test without headphone
hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 [NID=0x0F, 0x10~0x19, 0x1B] Result: for sure not work as GPIO not open 2. I changed to model=b1900 to test without headphone hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 Result: speaker still works. It's for sure. 3. Then same condition as step 2 but change 0xC0 to 0x0 hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0x0 Result: speaker doesn't work only when NID=0x0F; then I tried param=0x40 and 0x80, when param=0x40, speaker works while param=0x80, speaker doesn't work. 4. Then I plugged in headphone. Now the param =0x40 for NID=0x0F. Result: Headphone works while speaker muted. Then I changed param=0x80. (same result when param=0xC0) Result: Headphone still works while speaker muted. 5. Then I reboot with headphone plugged in to test your step 2. YES, now the speaker muted while headphone works. Then I do your cmds: hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 1 Result: headphone works, speaker muted hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 1 Result: headphone muted, speaker works hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 Result: headphone works, speaker muted hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0 Result: headphone muted, speaker works.
And, if you run again hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 I guess the speaker will be muted and the headphone start working again, right?
Please noted the last two cmds, it's strange but it's true.
If my guess is correct, it's not strange at all. Your machine shares the same pin for both the headphone and the speaker outputs, but switches between them just by GPIO-out bit 0. It's _not_ the master amp.
In addition, the HP-amp bit (0x80) of 0x0f seems controlling the speaker amp.
Takashi
Any additional tests?
在 2012年2月15日 下午11:04，Takashi Iwai tiwai@suse.de 写道：
At Wed, 15 Feb 2012 22:45:27 +0800, joey.jiaojg wrote:
I think the only question below is about the automute, right?
Not really. The most important thing is to understand what's doing what. Since your code can't be applied any longer at all to the latest code tree because of the fundamental code rewrite, we need to do it right.
So, please check the following:
- Does any pin correspond to the speaker output? Try to change the
pin control of each pin between 0x10 and 0x19 via hda-verb while the speaker output is active. Does any pin change the speaker output?
- Plug your headphone. Now the speaker is muted with your patch.
What happens when you run like below?
hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_MASK 1 hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DIR 1 hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 1
Does the speaker starts playing again? Then, what happens now with:
hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 0
??
Takashi
-- -Joey Jiao
YES, you are right on the assumption. I tried again many times of SET_GPIO_DATA between 0/1, speaker/headphone switches. So is possible to merge into next ALSA release?
On 2012年02月16日 17:35, Takashi Iwai wrote:
At Thu, 16 Feb 2012 10:04:09 +0800, Joey Jiao wrote:
- I changed to model=will to test without headphone
hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 [NID=0x0F, 0x10~0x19, 0x1B] Result: for sure not work as GPIO not open 2. I changed to model=b1900 to test without headphone hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 Result: speaker still works. It's for sure. 3. Then same condition as step 2 but change 0xC0 to 0x0 hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0x0 Result: speaker doesn't work only when NID=0x0F; then I tried param=0x40 and 0x80, when param=0x40, speaker works while param=0x80, speaker doesn't work. 4. Then I plugged in headphone. Now the param =0x40 for NID=0x0F. Result: Headphone works while speaker muted. Then I changed param=0x80. (same result when param=0xC0) Result: Headphone still works while speaker muted. 5. Then I reboot with headphone plugged in to test your step 2. YES, now the speaker muted while headphone works. Then I do your cmds: hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 1 Result: headphone works, speaker muted hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 1 Result: headphone muted, speaker works hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 Result: headphone works, speaker muted hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0 Result: headphone muted, speaker works.
And, if you run again hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 I guess the speaker will be muted and the headphone start working again, right?
Please noted the last two cmds, it's strange but it's true.
If my guess is correct, it's not strange at all. Your machine shares the same pin for both the headphone and the speaker outputs, but switches between them just by GPIO-out bit 0. It's _not_ the master amp.
In addition, the HP-amp bit (0x80) of 0x0f seems controlling the speaker amp.
Takashi
Any additional tests?
在 2012年2月15日 下午11:04，Takashi Iwaitiwai@suse.de 写道：
At Wed, 15 Feb 2012 22:45:27 +0800, joey.jiaojg wrote:
I think the only question below is about the automute, right?
Not really. The most important thing is to understand what's doing what. Since your code can't be applied any longer at all to the latest code tree because of the fundamental code rewrite, we need to do it right.
So, please check the following:
Does any pin correspond to the speaker output? Try to change the pin control of each pin between 0x10 and 0x19 via hda-verb while the speaker output is active. Does any pin change the speaker output?
Plug your headphone. Now the speaker is muted with your patch. What happens when you run like below?
hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_MASK 1 hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DIR 1 hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 1Does the speaker starts playing again? Then, what happens now with:
hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 0??
Takashi
-- -Joey Jiao
At Thu, 16 Feb 2012 17:38:33 +0800, joey.jiaojg wrote:
YES, you are right on the assumption. I tried again many times of SET_GPIO_DATA between 0/1, speaker/headphone switches. So is possible to merge into next ALSA release?
Not ready for "merge". As mentioned, your patch can't be applied to the latest tree.
I'll work on the better implementation of a quirk for the auto-parser later.
Takashi
On 2012年02月16日 17:35, Takashi Iwai wrote:
At Thu, 16 Feb 2012 10:04:09 +0800, Joey Jiao wrote:
- I changed to model=will to test without headphone
hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 [NID=0x0F, 0x10~0x19, 0x1B] Result: for sure not work as GPIO not open 2. I changed to model=b1900 to test without headphone hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 Result: speaker still works. It's for sure. 3. Then same condition as step 2 but change 0xC0 to 0x0 hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0x0 Result: speaker doesn't work only when NID=0x0F; then I tried param=0x40 and 0x80, when param=0x40, speaker works while param=0x80, speaker doesn't work. 4. Then I plugged in headphone. Now the param =0x40 for NID=0x0F. Result: Headphone works while speaker muted. Then I changed param=0x80. (same result when param=0xC0) Result: Headphone still works while speaker muted. 5. Then I reboot with headphone plugged in to test your step 2. YES, now the speaker muted while headphone works. Then I do your cmds: hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 1 Result: headphone works, speaker muted hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 1 Result: headphone muted, speaker works hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 Result: headphone works, speaker muted hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0 Result: headphone muted, speaker works.
And, if you run again hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 I guess the speaker will be muted and the headphone start working again, right?
Please noted the last two cmds, it's strange but it's true.
If my guess is correct, it's not strange at all. Your machine shares the same pin for both the headphone and the speaker outputs, but switches between them just by GPIO-out bit 0. It's _not_ the master amp.
In addition, the HP-amp bit (0x80) of 0x0f seems controlling the speaker amp.
Takashi
Any additional tests?
在 2012年2月15日 下午11:04，Takashi Iwaitiwai@suse.de 写道：
At Wed, 15 Feb 2012 22:45:27 +0800, joey.jiaojg wrote:
I think the only question below is about the automute, right?
Not really. The most important thing is to understand what's doing what. Since your code can't be applied any longer at all to the latest code tree because of the fundamental code rewrite, we need to do it right.
So, please check the following:
Does any pin correspond to the speaker output? Try to change the pin control of each pin between 0x10 and 0x19 via hda-verb while the speaker output is active. Does any pin change the speaker output?
Plug your headphone. Now the speaker is muted with your patch. What happens when you run like below?
hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_MASK 1 hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DIR 1 hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 1Does the speaker starts playing again? Then, what happens now with:
hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 0??
Takashi
-- -Joey Jiao
At Thu, 16 Feb 2012 10:41:32 +0100, Takashi Iwai wrote:
At Thu, 16 Feb 2012 17:38:33 +0800, joey.jiaojg wrote:
YES, you are right on the assumption. I tried again many times of SET_GPIO_DATA between 0/1, speaker/headphone switches. So is possible to merge into next ALSA release?
Not ready for "merge". As mentioned, your patch can't be applied to the latest tree.
I'll work on the better implementation of a quirk for the auto-parser later.
Oh, for that, could you give alsa-info.sh output? Attach the output file (don't paste) obtained with --no-upload option.
thanks,
Takashi
Good news, anyway. Attached alsa-info.txt with model=b1900.
And I followed to use only data for automute while set_gpio inside init_verb; which works. Below is the code (attached diff):
/* toggle speaker-output according to the hp-jack state */ static void alc260_b1900_automute(struct hda_codec *codec) { unsigned int present;
present = snd_hda_jack_detect(codec, 0x0f); if (present) { snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DATA, 1); } else { snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DATA, 0); } }
static const struct hda_verb alc260_b1900_verbs[] = { {0x0f, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP}, {0x0b, AC_VERB_SET_CONNECT_SEL, 0x00}, {0x0d, AC_VERB_SET_CONNECT_SEL, 0x00}, {0x0f, AC_VERB_SET_EAPD_BTLENABLE, 0x02}, {0x1a, AC_VERB_SET_COEF_INDEX, 0x07}, {0x1a, AC_VERB_SET_PROC_COEF, 0x3040}, {0x01, AC_VERB_SET_GPIO_MASK, 0x01}, {0x01, AC_VERB_SET_GPIO_DIRECTION, 0x01}, {0x0f, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN | ALC880_HP_EVENT}, {} };
On 2012年02月16日 17:42, Takashi Iwai wrote:
At Thu, 16 Feb 2012 10:41:32 +0100, Takashi Iwai wrote:
At Thu, 16 Feb 2012 17:38:33 +0800, joey.jiaojg wrote:
YES, you are right on the assumption. I tried again many times of SET_GPIO_DATA between 0/1, speaker/headphone switches. So is possible to merge into next ALSA release?
Not ready for "merge". As mentioned, your patch can't be applied to the latest tree.
I'll work on the better implementation of a quirk for the auto-parser later.
Oh, for that, could you give alsa-info.sh output? Attach the output file (don't paste) obtained with --no-upload option.
thanks,
Takashi
participants (3)
-
Joey Jiao -
joey.jiaojg
-
Takashi Iwai