lkml.org 
[lkml]   [2006]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/3] msi abstractions and support for altix
On Thu, Dec 22, 2005 at 01:50:23PM -0700, Matthew Wilcox wrote:
> On Thu, Dec 22, 2005 at 02:38:24PM -0600, Mark Maule wrote:
> > Because on ia64 IA64_FIRST_DEVICE_VECTOR and IA64_LAST_DEVICE_VECTOR
> > (from which MSI FIRST_DEVICE_VECTOR/LAST_DEVICE_VECTOR are derived) are not
> > constants. The are now global variables (see change to asm-ia64/hw_irq.h)
> > to allow the platform to override them. Altix uses a reduced range of
> > vectors for devices, and this change was necessary to make assign_irq_vector()
> > to work on altix.
>
> To be honest, I think this is just adding a third layer of paper over
> the crack in the wall. The original code assumed x86; the ia64 port
> added enough emulation to make it look like x86 and now altix fixes a
> couple of assumptions. I say: bleh.
>
> What we actually need is an interface provided by the architecture that
> allocates a new irq. I have a hankering to implement MSI on PA-RISC but
> haven't found the time ...

Matt, Greg, et. al:

Did you guys have something in mind for a vector allocation interface? It
seems to me that assign_irq_vector() more or less does what we want,
but what is missing is a way for the platform to prime which vectors
are available to choose from.

One possibly better solution would be to call something in the init_IRQ path
that would set up the vector pool available to assign_irq_vector().

Any opinions on this? I would maintain that this effort should be done
independently of this patchset.

thanks
Mark
-
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/

\
 
 \ /
  Last update: 2006-01-03 04:26    [W:0.019 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site