[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200901140848.08531.bjorn.helgaas@hp.com>
Date: Wed, 14 Jan 2009 08:48:07 -0700
From: Bjorn Helgaas <bjorn.helgaas@...com>
To: Stefan Assmann <sassmann@...e.de>
Cc: Shaohua Li <shaohua.li@...el.com>, Len Brown <lenb@...nel.org>,
Ingo Molnar <mingo@...e.hu>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Olaf Dabrunz <od@...e.de>,
Thomas Gleixner <tglx@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
Sven Dietrich <sdietrich@...ell.com>
Subject: Re: PCI, ACPI, IRQ, IOAPIC: reroute PCI interrupt to legacy boot interrupt equivalent
On Wednesday 14 January 2009 02:57:22 am Stefan Assmann wrote:
> Shaohua Li wrote:
> > So a device can generate interrupt from two irqs. And we can get the irq
> > number for the routing table. Can we extend the irq mechanism and
> > automatically register the interrupt handler for the two irqs?
>
> This would not solve the problem of asserting 2 different interrupt
> lines, in the masked interrupt handling case, for 1 interrupt request.
> The result would be that the ISR is called twice and at the second call
> you can't be sure that the device hasn't already been serviced.
Calling the ISR twice isn't a problem, is it? We're talking about
PCI interrupts, which are shareable, so ISRs have to handle being
called extra times.
There's still the problem that the core will disable an IRQ if we
take it too many times without any ISR that cares about it. But that's
a core issue, not an ISR issue.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists