Re: [alsa-devel] No jack sense on Intel 82801I / IDT 92HD71B7X in a HP dv4
At Sat, 18 Apr 2009 21:36:35 -0300, Gustavo Vieira wrote:
Em Sáb, 2009-04-18 às 10:57 +0200, Takashi Iwai escreveu:
The jack sense is still broken, though. I'm attaching the alsa-info
with
the snapshot loaded.
Could you attach alsa-info.sh output at both HP plugged / unplugged states?
Now things got really interesting. :)
When trying to get the output you requested I discovered that running alsa-info with the headphones plugged made them work and silenced the speakers. Then, removing the HP do not make the sound come back to the speakers, but running alsa-info again does. That is, I can force the jack sense by running alsa-info.
I'm attaching the following files: * alsa-info-snapshot.txt: The output when the system is turned on, without HP. When I plug the HP and run alsa-info, the HP work and the out is the same as this file. * alsa-info-snapshot-hp-1.txt: The output when HP work. * alsa-info-snapshot-hp-out.txt: The output of the execution of alsa-info that makes the speakers work when HP are removed.
Hm, what happens if you pass model=hp-dv5 option?
Takashi
Em Seg, 2009-04-20 às 10:57 +0200, Takashi Iwai escreveu:
Now things got really interesting. :)
When trying to get the output you requested I discovered that running alsa-info with the headphones plugged made them work and silenced the speakers. Then, removing the HP do not make the sound come back to the speakers, but running alsa-info again does. That is, I can force the jack sense by running alsa-info.
Hm, what happens if you pass model=hp-dv5 option?
It behaves exactly like it did with no model, including all mixer controls. Still no headphones sense. Still works after alsa-info is run.
I'm attaching the alsa-info with the model selected.
Abraços, Gustavo
At Tue, 28 Apr 2009 16:11:24 -0300, Gustavo Vieira wrote:
Em Seg, 2009-04-20 às 10:57 +0200, Takashi Iwai escreveu:
Now things got really interesting. :)
When trying to get the output you requested I discovered that running alsa-info with the headphones plugged made them work and silenced the speakers. Then, removing the HP do not make the sound come back to the speakers, but running alsa-info again does. That is, I can force the jack sense by running alsa-info.
Hm, what happens if you pass model=hp-dv5 option?
It behaves exactly like it did with no model, including all mixer controls. Still no headphones sense. Still works after alsa-info is run.
OK, it means that the unsolicited event isn't processed properly at jack plugging. But still strange why alsa-info.sh can trigger it.
Could you put some debug print to the unsol even handler to see whether you get any even when you plug the jack?
thanks,
Takashi
Em Qua, 2009-04-29 às 08:37 +0200, Takashi Iwai escreveu:
It behaves exactly like it did with no model, including all mixer controls. Still no headphones sense. Still works after alsa-info is
run.
OK, it means that the unsolicited event isn't processed properly at jack plugging. But still strange why alsa-info.sh can trigger it.
Could you put some debug print to the unsol even handler to see whether you get any even when you plug the jack?
Can you point me to the correct function? Just tell me how the function is called and I can grep it.
BTW, there is some document describing general ALSA organization for clueless newbies?
Also, is printf() enough or there is a specific debug function.
Abraços, Gustavo
At Mon, 18 May 2009 17:20:54 -0300, Gustavo Maciel Dias Vieira wrote:
Em Qua, 2009-04-29 às 08:37 +0200, Takashi Iwai escreveu:
It behaves exactly like it did with no model, including all mixer controls. Still no headphones sense. Still works after alsa-info is
run.
OK, it means that the unsolicited event isn't processed properly at jack plugging. But still strange why alsa-info.sh can trigger it.
Could you put some debug print to the unsol even handler to see whether you get any even when you plug the jack?
Can you point me to the correct function? Just tell me how the function is called and I can grep it.
It's stac92xx_unsol_event().
BTW, there is some document describing general ALSA organization for clueless newbies?
A clueless newbie should read the general linux driver documentation at first :) After that, he can check a document like "writing an alsa driver", or $LINUX/Documentation/sound/alsa/HD-Audio.txt for hd-audio specific information.
Also, is printf() enough or there is a specific debug function.
To see the event flow, it should be enough.
Takashi
Em Qua, 2009-04-29 às 08:37 +0200, Takashi Iwai escreveu:
When trying to get the output you requested I discovered that
running
alsa-info with the headphones plugged made them work and
silenced the
speakers. Then, removing the HP do not make the sound come back
to the
speakers, but running alsa-info again does. That is, I can force
the
jack sense by running alsa-info.
OK, it means that the unsolicited event isn't processed properly at jack plugging. But still strange why alsa-info.sh can trigger it.
Could you put some debug print to the unsol even handler to see whether you get any even when you plug the jack?
The stac92xx_unsol_event() isn't called when the jack is plugged. It is called twice at kernel boot (HP_EVENT and then INSERT_EVENT), and it is called three times when running alsa-info (all HP_EVENT, regardless if the HP is plugged or not).
These results may not be entirely accurate as the current snapshot isn't working correctly. It just plays the first second of audio and keeps looping, locking the application (with and without pulseaudio).
If it would help you, I could try to debug stac92xx_unsol_event() in the current Fedora kernel (2.6.29.4), as the sound works with it and the jack sensing don't.
Abraços, Gustavo
Em Ter, 2009-06-02 às 14:10 -0300, Gustavo Maciel Dias Vieira escreveu:
Em Qua, 2009-04-29 às 08:37 +0200, Takashi Iwai escreveu:
OK, it means that the unsolicited event isn't processed properly at jack plugging. But still strange why alsa-info.sh can trigger it.
Could you put some debug print to the unsol even handler to see whether you get any even when you plug the jack?
The stac92xx_unsol_event() isn't called when the jack is plugged. It is called twice at kernel boot (HP_EVENT and then INSERT_EVENT), and it is called three times when running alsa-info (all HP_EVENT, regardless if the HP is plugged or not).
These results may not be entirely accurate as the current snapshot isn't working correctly. It just plays the first second of audio and keeps looping, locking the application (with and without pulseaudio).
If it would help you, I could try to debug stac92xx_unsol_event() in the current Fedora kernel (2.6.29.4), as the sound works with it and the jack sensing don't.
I repeated the experiment with the Fedora kernel 2.6.29.4. The results are exactly the same. stac92xx_unsol_event() isn't called when the jack is plugged or unplugged, and alsa-info triggers a number of HP_EVENTs.
However, this time I made an interesting observation. alsa-info does not generate spurious events. It generates exactly the number of events that should be generated before the execution of alsa-info. For example: if I plug and unplug the HP and run alsa-info, two HP_EVENTs are generated. This explains the three events I observed earlier (plug, unplug, plug, alsa-info).
It seems the events are getting "stuck" somewhere and alsa-info "releases" them.
Abraços, Gustavo
At Fri, 05 Jun 2009 14:48:41 -0300, Gustavo Maciel Dias Vieira wrote:
Em Ter, 2009-06-02 às 14:10 -0300, Gustavo Maciel Dias Vieira escreveu:
Em Qua, 2009-04-29 às 08:37 +0200, Takashi Iwai escreveu:
OK, it means that the unsolicited event isn't processed properly at jack plugging. But still strange why alsa-info.sh can trigger it.
Could you put some debug print to the unsol even handler to see whether you get any even when you plug the jack?
The stac92xx_unsol_event() isn't called when the jack is plugged. It is called twice at kernel boot (HP_EVENT and then INSERT_EVENT), and it is called three times when running alsa-info (all HP_EVENT, regardless if the HP is plugged or not).
These results may not be entirely accurate as the current snapshot isn't working correctly. It just plays the first second of audio and keeps looping, locking the application (with and without pulseaudio).
If it would help you, I could try to debug stac92xx_unsol_event() in the current Fedora kernel (2.6.29.4), as the sound works with it and the jack sensing don't.
I repeated the experiment with the Fedora kernel 2.6.29.4. The results are exactly the same. stac92xx_unsol_event() isn't called when the jack is plugged or unplugged, and alsa-info triggers a number of HP_EVENTs.
However, this time I made an interesting observation. alsa-info does not generate spurious events. It generates exactly the number of events that should be generated before the execution of alsa-info. For example: if I plug and unplug the HP and run alsa-info, two HP_EVENTs are generated. This explains the three events I observed earlier (plug, unplug, plug, alsa-info).
It seems the events are getting "stuck" somewhere and alsa-info "releases" them.
Check /proc/interrupts whether you get an interrupt when you plug / unplug the jack. I guess you don't get an interrupt there. If so, then it's a problem of ACPI or BIOS. If you get a proper interrupt but still no unsol event is passed, something wrong in the sound driver side.
BTW, I guess the similar effect could be achieved instead of alsa-info but by just changing the mixer volume once. The unsol verbs were delivered, but they aren't fed until any sync operation is done.
Takashi
Em Sex, 2009-06-05 às 21:40 +0200, Takashi Iwai escreveu:
However, this time I made an interesting observation. alsa-info does
not
generate spurious events. It generates exactly the number of events
that
should be generated before the execution of alsa-info. For example:
if I
plug and unplug the HP and run alsa-info, two HP_EVENTs are
generated.
This explains the three events I observed earlier (plug, unplug,
plug,
alsa-info).
It seems the events are getting "stuck" somewhere and alsa-info "releases" them.
Check /proc/interrupts whether you get an interrupt when you plug / unplug the jack. I guess you don't get an interrupt there. If so, then it's a problem of ACPI or BIOS. If you get a proper interrupt but still no unsol event is passed, something wrong in the sound driver side.
I'm not sure what interrupt I should be monitoring, but the line with "HDA Intel" always stays with 0 interrupts. Also, only timer, i915 and rescheduling interrupts are generated.
Oh, boy. If this is so, what can I do now? If it is a BIOS problem, I may try to file a bug report with HP, but as Vista works perfectly they probably won't be interested. If it is a ACPI bug, what exactly should I report to the Linux ACPI guys?
BTW, I guess the similar effect could be achieved instead of alsa-info but by just changing the mixer volume once. The unsol verbs were delivered, but they aren't fed until any sync operation is done.
Changing mixer levels wont release the events.
Abraços, Gustavo
At Fri, 05 Jun 2009 17:13:25 -0300, Gustavo Maciel Dias Vieira wrote:
Em Sex, 2009-06-05 às 21:40 +0200, Takashi Iwai escreveu:
However, this time I made an interesting observation. alsa-info does
not
generate spurious events. It generates exactly the number of events
that
should be generated before the execution of alsa-info. For example:
if I
plug and unplug the HP and run alsa-info, two HP_EVENTs are
generated.
This explains the three events I observed earlier (plug, unplug,
plug,
alsa-info).
It seems the events are getting "stuck" somewhere and alsa-info "releases" them.
Check /proc/interrupts whether you get an interrupt when you plug / unplug the jack. I guess you don't get an interrupt there. If so, then it's a problem of ACPI or BIOS. If you get a proper interrupt but still no unsol event is passed, something wrong in the sound driver side.
I'm not sure what interrupt I should be monitoring, but the line with "HDA Intel" always stays with 0 interrupts. Also, only timer, i915 and rescheduling interrupts are generated.
Hm, but when you play or record something, interrupts must be generated, right?
Oh, boy. If this is so, what can I do now? If it is a BIOS problem, I may try to file a bug report with HP, but as Vista works perfectly they probably won't be interested. If it is a ACPI bug, what exactly should I report to the Linux ACPI guys?
Basically the same thing. They'll certainly want the ACPI dump, etc, in addition. Just ask them.
BTW, I guess the similar effect could be achieved instead of alsa-info but by just changing the mixer volume once. The unsol verbs were delivered, but they aren't fed until any sync operation is done.
Changing mixer levels wont release the events.
Hrm... then the unsol events aren't reached at that timing? With the latest code, you can set bus->sync_write = 1, as done for STAC_HP_DV5 model in patch_sigmatel.c. This will make the codec read and write always synchronized.
Takashi
Em Sáb, 2009-06-06 às 11:04 +0200, Takashi Iwai escreveu:
I'm not sure what interrupt I should be monitoring, but the line
with
"HDA Intel" always stays with 0 interrupts. Also, only timer, i915
and
rescheduling interrupts are generated.
Hm, but when you play or record something, interrupts must be generated, right?
No. Not at all. Here is the output of /proc/interrupts
CPU0 CPU1 0: 37864 38144 IO-APIC-edge timer 1: 5 511 IO-APIC-edge i8042 8: 7 9 IO-APIC-edge rtc0 9: 1048 652 IO-APIC-fasteoi acpi 12: 51 57 IO-APIC-edge i8042 16: 53 80 IO-APIC-fasteoi uhci_hcd:usb3, mmc0, jmb38x_ms:slot0 17: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 18: 0 3 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb7 20: 30 2628 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb5 22: 0 0 IO-APIC-fasteoi uhci_hcd:usb6, HDA Intel 29: 13017 1545 PCI-MSI-edge ahci 30: 1 3502 PCI-MSI-edge i915 31: 0 2894 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC: 46690 47341 Local timer interrupts RES: 14957 15044 Rescheduling interrupts CAL: 73 64 Function call interrupts TLB: 193 119 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts SPU: 0 0 Spurious interrupts ERR: 0 MIS: 0
Interrupt 22 stays always with 0. Even when correctly playing sounds. I tested this on another machine with HD-Audio, and the equivalent interrupt increased when playing. Also, in this other system interrupt 0 (timer) is hardly issued, but in this laptop it is firing all the time.
How can the driver be working without interrupts?
Abraços, Gustavo
At Thu, 11 Jun 2009 14:57:52 -0300, Gustavo Vieira wrote:
Em Sáb, 2009-06-06 às 11:04 +0200, Takashi Iwai escreveu:
I'm not sure what interrupt I should be monitoring, but the line
with
"HDA Intel" always stays with 0 interrupts. Also, only timer, i915
and
rescheduling interrupts are generated.
Hm, but when you play or record something, interrupts must be generated, right?
No. Not at all. Here is the output of /proc/interrupts
CPU0 CPU10: 37864 38144 IO-APIC-edge timer 1: 5 511 IO-APIC-edge i8042 8: 7 9 IO-APIC-edge rtc0 9: 1048 652 IO-APIC-fasteoi acpi 12: 51 57 IO-APIC-edge i8042 16: 53 80 IO-APIC-fasteoi uhci_hcd:usb3, mmc0, jmb38x_ms:slot0 17: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 18: 0 3 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb7 20: 30 2628 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb5 22: 0 0 IO-APIC-fasteoi uhci_hcd:usb6, HDA Intel 29: 13017 1545 PCI-MSI-edge ahci 30: 1 3502 PCI-MSI-edge i915 31: 0 2894 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC: 46690 47341 Local timer interrupts RES: 14957 15044 Rescheduling interrupts CAL: 73 64 Function call interrupts TLB: 193 119 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts SPU: 0 0 Spurious interrupts ERR: 0 MIS: 0
Interrupt 22 stays always with 0. Even when correctly playing sounds. I tested this on another machine with HD-Audio, and the equivalent interrupt increased when playing. Also, in this other system interrupt 0 (timer) is hardly issued, but in this laptop it is firing all the time.
How can the driver be working without interrupts?
That's weird.
Did you try enable_msi=1 module option, BTW?
Takashi
Em Qui, 2009-06-11 às 21:27 +0200, Takashi Iwai escreveu:
Interrupt 22 stays always with 0. Even when correctly playing
sounds. I
tested this on another machine with HD-Audio, and the equivalent interrupt increased when playing. Also, in this other system
interrupt 0
(timer) is hardly issued, but in this laptop it is firing all the
time.
How can the driver be working without interrupts?
That's weird.
Did you try enable_msi=1 module option, BTW?
Just tried now. The interrupts started flowing and, tada, jack sense works!
Thanks, Takashi, that solves it for me. Is there a way to automate this in the driver for the other less technically inclined users?
Abraços, Gustavo
At Fri, 12 Jun 2009 15:01:09 -0300, Gustavo Maciel Dias Vieira wrote:
Em Qui, 2009-06-11 às 21:27 +0200, Takashi Iwai escreveu:
Interrupt 22 stays always with 0. Even when correctly playing
sounds. I
tested this on another machine with HD-Audio, and the equivalent interrupt increased when playing. Also, in this other system
interrupt 0
(timer) is hardly issued, but in this laptop it is firing all the
time.
How can the driver be working without interrupts?
That's weird.
Did you try enable_msi=1 module option, BTW?
Just tried now. The interrupts started flowing and, tada, jack sense works!
Thanks, Takashi, that solves it for me. Is there a way to automate this in the driver for the other less technically inclined users?
Well, as I mentioned, it's basically a bug in the lower layer like ACPI or BIOS. So, the best is to fix them. Using MSI is a kind of workaround, and I'm wondering whether this is specific to your device or in general with other HP dv4, since I didn't hear of the similar bug reports.
Takashi
participants (3)
-
Gustavo Maciel Dias Vieira -
Gustavo Vieira
-
Takashi Iwai