[alsa-devel] HP pavilion dv5 1110ew - no hdmi sound

Jean-Pierre André jean-pierre.andre at wanadoo.fr
Wed Feb 18 09:26:02 CET 2009


Hi all,

> Dnia 2009-02-14, sob o godzinie 11:30 +0100, Takashi Iwai pisze:
>   
>> At Fri, 13 Feb 2009 22:48:26 +0100,
>> Bartłomiej Holdenmayer wrote:
>>     
>>
>
> I did ehat You wrote. Here is my dmesg:
> [   14.729023] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low)
> -> IRQ 2
> 2
> [   14.729028] hda_intel: codec_mask forced to 0xff
> [   14.729054] HDA Intel 0000:00:1b.0: setting latency timer to 64
> [   15.776021]
> ALSA /usr/src/Alsa-1.0.19/alsa-driver-1.0.19/pci/hda/../../alsa-k
> ernel/pci/hda/hda_intel.c:634: hda_intel: azx_get_response timeout,
> switching to
>  polling mode: last cmd=0x100f0000
> [   16.780019]
> ALSA /usr/src/Alsa-1.0.19/alsa-driver-1.0.19/pci/hda/../../alsa-k
> ernel/pci/hda/hda_intel.c:1271: hda_intel: Codec #1 probe error;
> disabling it...
> [   17.816508]
> ALSA /usr/src/Alsa-1.0.19/alsa-driver-1.0.19/pci/hda/../../alsa-k
> ernel/pci/hda/hda_intel.c:1271: hda_intel: Codec #3 probe error;
> disabling it...
> [   17.921600] input: HDA Digital PCBeep
> as /devices/pci0000:00/0000:00:1b.0/inp
> ut/input11
> [   18.052194] input: HDA Intel at 0x9f300000 irq 22 Mic at Ext Front
> Jack as /d
> evices/pci0000:00/0000:00:1b.0/input/input12
> [   18.052587] input: HDA Intel at 0x9f300000 irq 22 Mic at Sep UNKNOWN
> Jack as 
> /devices/pci0000:00/0000:00:1b.0/input/input13
> [   18.052894] input: HDA Intel at 0x9f300000 irq 22 HP Out at Ext Front
> Jack as
>  /devices/pci0000:00/0000:00:1b.0/input/input14

This is very interesting for me, as I have another HP dv4
computer with the same sound chip, and I get roughly
similar results, but with a significant difference (using
Tagashi's snapshot from yesterday) :

HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
HDA Intel 0000:00:1b.0: PCI INT B -> GSI 22 (level, low) -> IRQ 22
hda_intel: codec_mask forced to 0xff
HDA Intel 0000:00:1b.0: setting latency timer to 64
ALSA 
/home/linux/rpmbuild/BUILD/alsa-driver-1.0.19.217/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:634: 
hda_intel: azx_get_response timeout, switching to polling mode: last 
cmd=0x000f0000
ALSA 
/home/linux/rpmbuild/BUILD/alsa-driver-1.0.19.217/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1271: 
hda_intel: Codec #1 probe error; disabling it...
ALSA 
/home/linux/rpmbuild/BUILD/alsa-driver-1.0.19.217/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1271: 
hda_intel: Codec #3 probe error; disabling it...
input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input12
input: HDA Intel at 0xdf300000 irq 22 Line In at Ext Rear Jack as 
/devices/pci0000:00/0000:00:1b.0/input/input13
input: HDA Intel at 0xdf300000 irq 22 Mic at Ext Front Jack as 
/devices/pci0000:00/0000:00:1b.0/input/input14
input: HDA Intel at 0xdf300000 irq 22 HP Out at Ext Front Jack as 
/devices/pci0000:00/0000:00:1b.0/input/input15

The point is I never get an IRQ 22, I get IRQ 20 instead,
so most players do not work unless I boot with irqpoll or
noapic options (mplayer is ok though)

Now, you get the IRQ 22 routed by APIC from PCI INT A,
whereas I have the IRQ 22 routed by APIC from PCI INT B.

And I have the PCI INT A routed to IRQ 20 for USB :

ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
ehci_hcd 0000:00:1d.7: setting latency timer to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller

 From this I conclude that both our sound chips trigger INT A,
but in my case, it is wrongly the INT B that has been connected
to IRQ 22.

So my question to all the techies on this list : how on earth can
I influence on this IRQ routing ?

Regards

Jean-Pierre





More information about the Alsa-devel mailing list