RE: Updated MSI Patches

Nakajima, Jun
2003-08-12T23:59:31Z

If the platform_irq thing is the issue, we can remove it by having like

#ifdef PCI_USE_VECTOR
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 = {
...

#else
...

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
do_IRQ().

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) {
disable_8259A_irq(irq);
if (i8259A_irq_pending(irq))
was_pending = 1;
}
__unmask_IO_APIC_irq(irq);
spin_unlock_irqrestore(&ioapic_lock, flags);

return was_pending;
}

Thanks,
Jun

> -----Original Message-----
> From: Jeff Garzik [mailto:jgarzik@pobox.com]
> 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
preferred
> >>over common code.
> >>
> >>And I also feel the same way about do_MSI(). However, I have not
looked
> >>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
is
> so
> > that we don't have to do the platform_irq thing in do_IRQ and we
know
> > 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
would
> 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
us.
>
> 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
to
> 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
>
>