-Original Message-
From: Linus Torvalds [mailto:[EMAIL PROTECTED]
>Eventually, MSI will hopefully be the more robust of the two methods.
>Maybe it will take a year. And maybe we'll end up not using MSI on a
lot
>of the _current_ crop of motherboards. We don't want to carry the "fall
>b
On Fri, 17 Nov 2006, Yinghai Lu wrote:
>
> the fallback path from MSI test to ioapic still not look good.
I don't think there should be a fallback at all.
Let's just:
- keep MSI disabled by default for now, until we know what's really going
on (and we can try enabling it every once in a w
the fallback path from MSI test to ioapic still not look good.
I think you could seperate azx_interrupt_test later.
It seems on C51+MCP55 has problem to use MSI for hda.
and I have tried two MCP55 only systems, the MSI for hda works well.
YH
-
To unsubscribe from this list: send the line "unsub
At Fri, 17 Nov 2006 00:01:25 +0100,
Olivier Nicolas wrote:
>
> Takashi Iwai wrote:
> > At Wed, 15 Nov 2006 14:15:45 -0500,
> > Jeff Garzik wrote:
> >> ACK the pci_intx() calls, NAK the obviously overweight spinlock changes.
> >> The spinlock changes are completely unnecessary. Just look at any
Lu, Yinghai wrote:
-Original Message-
From: Olivier Nicolas [mailto:[EMAIL PROTECTED]
IRQ 22 is disabled but snd_hda_intel seems to get a MSI interrupt! (It
cannot be reproduced)
313: 0 1 PCI-MSI-edge HDA Intel
Please try attached one, also build hda_int
-Original Message-
From: Olivier Nicolas [mailto:[EMAIL PROTECTED]
>IRQ 22 is disabled but snd_hda_intel seems to get a MSI interrupt! (It
>cannot be reproduced)
>313: 0 1 PCI-MSI-edge HDA Intel
Please try attached one, also build hda_intel into kernel directl
Lu, Yinghai wrote:
Add pci_intx to diable intx could make MSI work with pci.
Olivier, Please test it attached patch with latest git ... I hardcode to
make enable_msi=1.
YH
The kernel boots only with pci=routeirq, no IRQ get disabled but the
sound driver does not work.
http://olivn.trollp
Yinghai Lu wrote:
Please try the patch about using pci_intx.
it could use msi.
It can't cold boot with this one (with pci=routeirq or not)
The last visible boot messages are
Interrupt Link [AAZA] enabled at IRQ 20
Interrupt :00:0e.1[B]->Link [AAZA] -> GSI 20 (level,low) -> IRQ 20
Olivi
Takashi Iwai wrote:
At Wed, 15 Nov 2006 14:15:45 -0500,
Jeff Garzik wrote:
ACK the pci_intx() calls, NAK the obviously overweight spinlock changes.
The spinlock changes are completely unnecessary. Just look at any
other (non-ALSA) PCI driver. Existing "spin_lock()" is fine for both
PCI sha
On Wednesday 15 November 2006 23:25, Lu, Yinghai wrote:
> I think the root cause in hda_intel driver's self.
>
> It gets io-apic irq initialized at first, and it will use
> azx_acquire_irq to install handler after check if MSI can be enabled.
> And when it try to enable the MSI, that will start the
> Most interrupt-driven devices have an interrupt mask register of some
> sort. The nice thing about PCI_COMMAND_INTX_DISABLE is that it is
> standardized.
You all got on me about quoting the spec about not generating INTx
interrupts after MSI is enabled. What makes you think that setting
som
On Wed, 15 Nov 2006, [EMAIL PROTECTED] wrote:
>
> Er... why can't you test it?
Because if it is level-triggered kind of thing and comes in on the wrong
IRQ, and that IRQ is already used by something else, you're basically
dead.
IRQ probing is essentially unworkable. We support it for ISA card
Krzysztof Halasa wrote:
OTOH many devices have "interrupt disable" bit somewhere else, in
their specific PCI config registers or in regular config registers
(accessible with normal Memory Read/Write cycles).
Most interrupt-driven devices have an interrupt mask register of some
sort. The nice
Jeff Garzik <[EMAIL PROTECTED]> writes:
>>> We are referring to the standard PCI 2.2 bit, PCI_COMMAND_INTX_DISABLE.
>> Yeah, I figured it, I somewhat forgot about it ... it got introduced
>> in
>> 2.3 though, no ?
>
> It's pretty new. 2.2 or 2.3.
2.3.
PCI 2.2 defines bits 0-9 only (bit 7 = Step
On Wednesday 15 November 2006 22:10, Mws wrote:
> On Wednesday 15 November 2006 21:14, Linus Torvalds wrote:
> >
> > On Wed, 15 Nov 2006, Mws wrote:
> > >
> > > after some small discussions on alsa-user ml i recognised this
> > > thread today.
> > > i thought my problem could also exist on this
On 15 Nov 2006 23:24:32 -0500
[EMAIL PROTECTED] wrote:
> Well, before giving up entirely, assume that *some* device owns that
> interrupt, it's just mis-routed.
>
> So start calling the IRQ handlers for *every* PCI device until the
> damn interrupt goes away, or you've really proved that it can't
At Wed, 15 Nov 2006 14:15:45 -0500,
Jeff Garzik wrote:
>
> ACK the pci_intx() calls, NAK the obviously overweight spinlock changes.
> The spinlock changes are completely unnecessary. Just look at any
> other (non-ALSA) PCI driver. Existing "spin_lock()" is fine for both
> PCI shared irq han
(forgot to cc: LKML)
Roland Dreier wrote:
> > A whitelist is an awkward solution, the problem is the number of
> > chipsets available with MSI will continue to grow. And the assumption
> > is that after Microsoft OS supports MSI, that newer chipsets will work.
>
> Maybe a whitelist for older sy
18 matches
Mail list logo
