content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: Updated MSI Patches
Date: Tue, 12 Aug 2003 16:59:21 -0700
Message-ID: <7F740D512C7C1046AB53446D3720017304AE9A@scsmsx402.sc.intel.com>
Thread-Topic: Updated MSI Patches
Thread-Index: AcNhCkV9no52QJ/iQ4Kcsv5CURLBfAADWmBg
From: "Nakajima, Jun" <jun.nakajima@intel.com>
To: "Jeff Garzik" <jgarzik@pobox.com>, "Zwane Mwaikambo" <zwane@linuxpower.ca>
Cc: "Nguyen, Tom L" <tom.l.nguyen@intel.com>,
       "Linux Kernel" <linux-kernel@vger.kernel.org>,
       "long" <tlnguyen@snoqualmie.dp.intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3242
Lines: 106

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
> 
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/