[alsa-devel] snd-hda-intel and MSI
Hi folks,
are there any contradictions to enable-msi=1 by default? There are users with chips like an
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) Subsystem: Hewlett-Packard Company Device 30f7 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 33 Region 0: Memory at dc500000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: HDA Intel
which only works with MSI. And it is somewhat hard to find the appropriate Documantation in HD-Audio.txt. 2nd it will be very hard for Distributers to maintain modul options by chip ID's.
Thanks for cooperation.
Elimar (one of Debian's alsa maintainers)
At Wed, 23 Sep 2009 16:33:06 +0200, Elimar Riesebieter wrote:
Hi folks,
are there any contradictions to enable-msi=1 by default?
MSI is broken on some platforms. IIRC, almost all non-Intel platforms didn't work until the recent ones. So, it can't be enabled blindly as default, unfortunately.
There are users with chips like an
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) Subsystem: Hewlett-Packard Company Device 30f7 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 33 Region 0: Memory at dc500000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: HDA Intel
which only works with MSI. And it is somewhat hard to find the appropriate Documantation in HD-Audio.txt.
A patch is always welcome.
2nd it will be very hard for Distributers to maintain modul options by chip ID's.
It's not a question for distributors but the upstream maintainers to maintain the quirk table :)
thanks,
Takashi
On Wed, 2009-09-23 at 17:43 +0200, Takashi Iwai wrote:
MSI is broken on some platforms. IIRC, almost all non-Intel platforms didn't work until the recent ones. So, it can't be enabled blindly as default, unfortunately.
Most of the "broken" platforms were AMD with integrated northbridges where the required HyperTransport MSI mappings weren't enabled. This is now handled correctly. I've seen graceful reverts where MSI wasn't possible. (I recently submitted a patch for sata_nv to enable MSI)
Regards, Tony V.
At Wed, 23 Sep 2009 16:52:43 +0100, Tony Vroon wrote:
On Wed, 2009-09-23 at 17:43 +0200, Takashi Iwai wrote:
MSI is broken on some platforms. IIRC, almost all non-Intel platforms didn't work until the recent ones. So, it can't be enabled blindly as default, unfortunately.
Most of the "broken" platforms were AMD with integrated northbridges where the required HyperTransport MSI mappings weren't enabled. This is now handled correctly. I've seen graceful reverts where MSI wasn't possible. (I recently submitted a patch for sata_nv to enable MSI)
Hm, a good point. Maybe we can start running toward the wall again in order to check whether it's thin enough to break through. But, this change is unlikely for 2.6.32.
Takashi
On Wed, 2009-09-23 at 17:58 +0200, Takashi Iwai wrote:
But, this change is unlikely for 2.6.32.
I would be in favour of a 2.6.33 experiment though. (Especially to invert behaviour, and make "MSI *will* enable but break" an exception controlled through PCI IDs)
Takashi
Regards, Tony V.
At Wed, 23 Sep 2009 17:00:54 +0100, Tony Vroon wrote:
On Wed, 2009-09-23 at 17:58 +0200, Takashi Iwai wrote:
But, this change is unlikely for 2.6.32.
I would be in favour of a 2.6.33 experiment though. (Especially to invert behaviour, and make "MSI *will* enable but break" an exception controlled through PCI IDs)
Yeah, that's what I meant implicitly :)
Takashi
At Wed, 23 Sep 2009 18:03:14 +0200, I wrote:
At Wed, 23 Sep 2009 17:00:54 +0100, Tony Vroon wrote:
On Wed, 2009-09-23 at 17:58 +0200, Takashi Iwai wrote:
But, this change is unlikely for 2.6.32.
I would be in favour of a 2.6.33 experiment though. (Especially to invert behaviour, and make "MSI *will* enable but break" an exception controlled through PCI IDs)
Yeah, that's what I meant implicitly :)
Meanwhile, MSI still doesn't work with the older kernel, so we need a black-list for the recent kernel in the upstream code and a white-list for the older kernel as hda_intel.patch in alsa-driver tree. Sigh.
Takashi
At Wed, 23 Sep 2009 18:11:33 +0200, I wrote:
At Wed, 23 Sep 2009 18:03:14 +0200, I wrote:
At Wed, 23 Sep 2009 17:00:54 +0100, Tony Vroon wrote:
On Wed, 2009-09-23 at 17:58 +0200, Takashi Iwai wrote:
But, this change is unlikely for 2.6.32.
I would be in favour of a 2.6.33 experiment though. (Especially to invert behaviour, and make "MSI *will* enable but break" an exception controlled through PCI IDs)
Yeah, that's what I meant implicitly :)
Meanwhile, MSI still doesn't work with the older kernel, so we need a black-list for the recent kernel in the upstream code and a white-list for the older kernel as hda_intel.patch in alsa-driver tree. Sigh.
JFYI, now I changed the sound git tree to enable MSI as default. alsa-driver-snapshot tarball is updated as well. Let's see whether the things get settled down with this.
thanks,
Takashi
* Takashi Iwai [090923 17:43 +0200]
At Wed, 23 Sep 2009 16:33:06 +0200, Elimar Riesebieter wrote:
Hi folks,
are there any contradictions to enable-msi=1 by default?
MSI is broken on some platforms. IIRC, almost all non-Intel platforms didn't work until the recent ones. So, it can't be enabled blindly as default, unfortunately.
There are users with chips like an
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) Subsystem: Hewlett-Packard Company Device 30f7 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 33 Region 0: Memory at dc500000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: HDA Intel
which only works with MSI. And it is somewhat hard to find the appropriate Documantation in HD-Audio.txt.
A patch is always welcome.
Which QUIRK Table. What informations from the soundcard ist needed and how to get it?
Elimar
On Wed, Sep 23, 2009 at 1:06 PM, Elimar Riesebieter riesebie@lxtec.de wrote:
There are users with chips like an
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) Subsystem: Hewlett-Packard Company Device 30f7
...
Which QUIRK Table. What informations from the soundcard ist needed and how to get it?
Elimar,
See http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=blob;f=sound...
Use the SSID for an entry, e.g.,
SND_PCI_QUIRK(0x103c, 0x30f7, "HP", 1),
* Daniel Chen [090923 13:11 -0400]
On Wed, Sep 23, 2009 at 1:06 PM, Elimar Riesebieter riesebie@lxtec.de wrote:
There are users with chips like an
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) Subsystem: Hewlett-Packard Company Device 30f7
...
Which QUIRK Table. What informations from the soundcard ist needed and how to get it?
Elimar,
See http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=blob;f=sound...
Use the SSID for an entry, e.g.,
SND_PCI_QUIRK(0x103c, 0x30f7, "HP", 1),
Does an easy QUIRK entry enables msi?
Elimar
On Wed, Sep 23, 2009 at 2:08 PM, Elimar Riesebieter riesebie@lxtec.de wrote:
SND_PCI_QUIRK(0x103c, 0x30f7, "HP", 1),
Does an easy QUIRK entry enables msi?
Yes.
Attached, please find a patch against current sound-2.6.git HEAD resolving this issue.
-Dan
At Wed, 23 Sep 2009 17:28:38 -0700 (PDT), Dan Chen wrote:
Attached, please find a patch against current sound-2.6.git HEAD resolving this issue.
Dan, your from-address and sign-off address are different in the patch. Could you unify?
thanks,
Takashi
At Thu, 24 Sep 2009 03:04:51 -0700 (PDT), Dan Chen wrote:
Dan, your from-address and sign-off address are different in the patch. Could you unify?
Indeed, here's a new patch.
Thanks, applied now.
Takashi
participants (5)
-
Dan Chen -
Daniel Chen -
Elimar Riesebieter -
Takashi Iwai -
Tony Vroon