[lkml]   [2003]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: Updated MSI Patches
If the platform_irq thing is the issue, we can remove it by having like

static struct hw_interrupt_type ioapic_edge_vector_type = {
.typename = "IO-APIC-edge",
.startup = startup_edge_ioapic_vector,
.shutdown = shutdown_edge_ioapic_vector,
.enable = enable_edge_ioapic_vector,
.disable = disable_edge_ioapic_vector,
.ack = ack_edge_ioapic_vector,
.end = end_edge_ioapic_vector,
.set_affinity = set_ioapic_affinity,

static struct hw_interrupt_type ioapic_level_vector_type = {


They (startup_edge_ioapic_vector, etc.) convert the vector to IRQ when
needed. Note that we need that because interrupt controller(s) still
needs IRQ info for the conventional interrupts when we use vector-based

For example, startup_edge_ioapic_vector() looks like this:

static unsigned int startup_edge_ioapic_vector(unsigned int vector)
int was_pending = 0;
unsigned long flags;
int irq = vector_to_irq (vector);

spin_lock_irqsave(&ioapic_lock, flags);
if (irq < 16) {
if (i8259A_irq_pending(irq))
was_pending = 1;
spin_unlock_irqrestore(&ioapic_lock, flags);

return was_pending;


> -----Original Message-----
> From: Jeff Garzik []
> Sent: Tuesday, August 12, 2003 12:45 PM
> To: Zwane Mwaikambo
> Cc: Nakajima, Jun; Nguyen, Tom L; Linux Kernel; long
> Subject: Re: Updated MSI Patches
> Zwane Mwaikambo wrote:
> > On Tue, 12 Aug 2003, Jeff Garzik wrote:
> >
> >
> >>So, IMO, do_IRQ is one special case where copying code may be
> >>over common code.
> >>
> >>And I also feel the same way about do_MSI(). However, I have not
> >>at non-ia32 MSI implementations to know what sort of issues exist.
> >
> >
> > The main reason i have a preference for a seperate MSI handling path
> so
> > that we don't have to do the platform_irq thing in do_IRQ and we
> > what to expect wrt irq or vector. If platform_irq stays we should at
> > least try and pick up on what the IA64 folks have done, But that
> be
> > even harder to get done right now.
> Oh, I definitely prefer a separate MSI handling path too.
> In the future we'll be writing drivers that _require_ MSI interrupt
> handling, and we'll be optimizing the various MSI hot paths to reclaim
> even the most minute amount of CPU cycles. And we want to escape any
> shackles the evil phrase "legacy interrupts" dares to try to lay upon
> But there is a flip side to that: do_IRQ is not solely hardware
> interrupts. That area of code is central dispatcher for
> softirq/tasklet/timer delivery as well. So a separate do_MSI() needs
> take that stuff into account.
> Overall, I'm pretty happy with how Tom's MSI patches are going so far,
> and he seems to be responding to feedback. So, we'll get there.
> Jeff

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.032 / U:1.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site