> > Similarly, in a pci device, one could imagine that the
> > struct pci_driver contains a irq_handler_t member that
> > is registered from the pci_device_probe() function
> > if present.
>
> Yes. There is some potential there. Although we would have to go
> through an extra hoop to make it a
Arnd Bergmann <[EMAIL PROTECTED]> writes:
>
> I have to admit I still don't really understand how this works
> at all. Can a driver that uses msi-x have different handlers
> for each of those interrupts registered simultaneously?
Yes, and the irqs can be routed at different cpus independently.
Ho
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>> What I really object to is not the irq numbers. As an arbitrary number
>> does not impose limits. What I object to is drivers that can't handle the
>> full range of numbers, and the limits imposed upon those numbers when
>> you require them t
pci: each device/function has a unique irq, drivers need not know
about it afaics.
Then there is msi and with msi-x you can have up to 4K irqs.
I have to admit I still don't really understand how this works
at all. Can a driver that uses msi-x have different handlers
for each of those inte
On Wednesday 28 February 2007, Eric W. Biederman wrote:
> Arnd Bergmann <[EMAIL PROTECTED]> writes:
>
> >
> > Introducing the irq_request() etc. functions that take a struct irq*
> > instead of an int sounds good, but I'd hope we can avoid using those
> > in device drivers and do a separate abstra
> What I really object to is not the irq numbers. As an arbitrary number
> does not impose limits. What I object to is drivers that can't handle the
> full range of numbers, and the limits imposed upon those numbers when
> you require them to be indexes into an array.
>
> For talking to user spa
Arnd Bergmann <[EMAIL PROTECTED]> writes:
>
> Introducing the irq_request() etc. functions that take a struct irq*
> instead of an int sounds good, but I'd hope we can avoid using those
> in device drivers and do a separate abstraction for each bus_type
> that deals with interrupts. I'm not sure i
On Tuesday 27 February 2007, Eric W. Biederman wrote:
> * Add a variation of the API in interrupt.h that uses
> "struct irq *irq" instead of "unsigned int irq"
>
> Probably replacing request_irq with irq_request or something
> trivial like that.
>
> This will need to touch all of differ
A quick update. I did some work on this and have some observations.
- Every back end irq implementation seems to have a different name for
the structure that describes irqs. So picking struct irq which is
different from everything seems to make sense. At the very least
a empty struct irq
On Sun, 2007-02-18 at 22:24 +0100, Arjan van de Ven wrote:
> On Fri, 2007-02-16 at 13:41 +0100, Ingo Molnar wrote:
> > * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >
> > > So I propose we remove all assumptions from the code that we actually
> > > have an array of irqs. That will allow for i
On Fri, 2007-02-16 at 13:41 +0100, Ingo Molnar wrote:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> > So I propose we remove all assumptions from the code that we actually
> > have an array of irqs. That will allow for irq_desc to be dynamically
> > allocated instead of statically alloca
> Except for the what appears to be instability of the irq numbers on
> simpler configurations I don't have a problem with it.
I agree that's a bit annoying and I beleive it can be fixed. In
additionm I'd like to look into exposing the domain/HW number -> virq
mapping somewhere in sysfs maybe.
>
> Because I don't have something better to replace them with.
>
> We need names for irqs, currently the kernel/user space interface
> is a unsigned number.
.../...
Ok, as long as it's strictly a userspace issue, I understand.
> The model can be made to work if you force it but it isn't really
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> On Sat, 2007-02-17 at 02:06 -0700, Eric W. Biederman wrote:
> However, PowerPC is a good example because it has such a diversity of
> very different hardware setups to deal with, ranging from the multiple
> layers of cascading controllers all o
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>> The only time it really makes sense to me to let the irq number vary
>> arbitrary are when things are truly dynamic, like with MSI, a
>> hypervisor, or hot plug interrupt controllers.
>
> I don't understand why you would go to all that lenght t
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
>> We might need this. But I don't think we need reference counting in
>> the traditional sense. For all practical purpose we already have
>> dynamic irq allocation and it hasn't proven necessary. I would
>> prefer to go to lengths to avoid h
> > #define NO_IRQ
>
> When did you need a magic constant NO_IRQ in generic code.
> One of the reasons I want to convert the drivers is so we can
> kill the NO_IRQ nonsense.
>
> As for struct irq. Instead of struct irq_desc I really don't
> care, although the C++ camp hasn't not yet weigh
On Sat, 2007-02-17 at 02:06 -0700, Eric W. Biederman wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > In addition, if we remove the numbers, archs will need basically the
> > exact same services provided by the powerpc irq core for reverse mapping
> > (going from a HW irq number o
> No. I don't think we should make your irq_hwnumber_t thingy general
> because it is not general. I don't understand why you need it to be
> an unsigned long, that still puzzles me. But for the rest it actually
> appears that ppc has a simpler model to deal with.
I think you might have misund
Russell King <[EMAIL PROTECTED]> writes:
> On Fri, Feb 16, 2007 at 08:45:58PM +0100, Arnd Bergmann wrote:
>> On Friday 16 February 2007 13:10, Eric W. Biederman wrote:
>> > To do this I believe will require a s/unsigned int irq/struct irq_desc
>> > *irq/
>> > throughout the entire kernel. Gettin
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> In addition, if we remove the numbers, archs will need basically the
> exact same services provided by the powerpc irq core for reverse mapping
> (going from a HW irq number on a given PIC back to an irq_desc *).
Ben you seem to be under misapp
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> On Fri, 2007-02-16 at 05:10 -0700, Eric W. Biederman wrote:
>
>> Getting the drivers changed actually looks to be pretty straight
>> forward it will just be a very large mechanical change. We change the
>> type where of variables where appropri
On Sat, 2007-02-17 at 02:37 +0100, Arnd Bergmann wrote:
> On Friday 16 February 2007 23:37, Benjamin Herrenschmidt wrote:
> > You might want to have a look at the powerpc API with it's remaping
> > capabilities. It's very nice for handling multiple domain spaces. It
> > might be of some use for you
On Friday 16 February 2007 23:37, Benjamin Herrenschmidt wrote:
> You might want to have a look at the powerpc API with it's remaping
> capabilities. It's very nice for handling multiple domain spaces. It
> might be of some use for you.
I don't consider the powerpc virtual IRQs a solution for the
> > Rather than having the job of rewriting this code during 2.6, I'd much
> > prefer to get something sorted, even if it is ARM only before 2.6.
> >
> > I believe that there are some common problems with the existing API
> > which have been hinted at over the last few days, such as large
> > NR_
On Fri, 2007-02-16 at 13:41 +0100, Ingo Molnar wrote:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> > So I propose we remove all assumptions from the code that we actually
> > have an array of irqs. That will allow for irq_desc to be dynamically
> > allocated instead of statically alloca
On Fri, 2007-02-16 at 05:10 -0700, Eric W. Biederman wrote:
> Getting the drivers changed actually looks to be pretty straight
> forward it will just be a very large mechanical change. We change the
> type where of variables where appropriate and every once in a while
> introduce an irq_nr(irq) t
On Fri, Feb 16, 2007 at 09:43:24PM +0100, Arnd Bergmann wrote:
> On Friday 16 February 2007 20:52, Russell King wrote:
> > On Fri, Feb 16, 2007 at 08:45:58PM +0100, Arnd Bergmann wrote:
> > > We did something like this a few years back on the s390 architecture,
> > > which
> > > happens to be luck
On Friday 16 February 2007 20:52, Russell King wrote:
> On Fri, Feb 16, 2007 at 08:45:58PM +0100, Arnd Bergmann wrote:
> > We did something like this a few years back on the s390 architecture, which
> > happens to be lucky enough not to share any interrupt based drivers with
> > any of the other ar
On Fri, Feb 16, 2007 at 08:45:58PM +0100, Arnd Bergmann wrote:
> On Friday 16 February 2007 13:10, Eric W. Biederman wrote:
> > To do this I believe will require a s/unsigned int irq/struct irq_desc *irq/
> > throughout the entire kernel. Getting the arch specific code and the
> > generic kernel i
On Friday 16 February 2007 13:10, Eric W. Biederman wrote:
> To do this I believe will require a s/unsigned int irq/struct irq_desc *irq/
> throughout the entire kernel. Getting the arch specific code and the
> generic kernel infrastructure fixed and ready for that change looks
> like a pain but p
Eric W. Biederman wrote:
> Well you shouldn't need to wait just run with a kernel with NR_IRQS >= 1024.
> 1024 is stretch but it isn't to bad. There are already x86 boxes that have
> more pins on their ioapics then that. So x86_64 and with this latest
> round of patches from Len Brown and I i386 s
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> So I propose we remove all assumptions from the code that we actually
>> have an array of irqs. That will allow for irq_desc to be dynamically
>> allocated instead of statically allocated saving memory and reducing
>> k
Eric W. Biederman wrote:
> So I propose we remove all assumptions from the code that we actually
> have an array of irqs. That will allow for irq_desc to be dynamically
> allocated instead of statically allocated saving memory and reducing
> kernel complexity.
>
Sounds good to me. In Xen we h
Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> or am i missing something fundamental?
One piece.
At the driver level this not a big scary change.
This is just a change with widespread effect.
It should be no worse than enabling a very revealing new compiler
warning.
Every fix should be purely me
Andi Kleen <[EMAIL PROTECTED]> writes:
>> I expect the most it makes sense to aim for 2.6.22 are the genirq
>> changes so the internal arch code is passing struct irq_desc
>> everywhere internally.
>
> Are there any livetime issues with passing pointers around?
> e.g. what happens on APIC hotunp
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> So I propose we remove all assumptions from the code that we actually
>> have an array of irqs. That will allow for irq_desc to be dynamically
>> allocated instead of statically allocated saving memory
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> So I propose we remove all assumptions from the code that we actually
> have an array of irqs. That will allow for irq_desc to be dynamically
> allocated instead of statically allocated saving memory and reducing
> kernel complexity.
hm. I'd s
> I expect the most it makes sense to aim for 2.6.22 are the genirq
> changes so the internal arch code is passing struct irq_desc
> everywhere internally.
Are there any livetime issues with passing pointers around?
e.g. what happens on APIC hotunplug etc.? We don't necessarily
support that yet
Looking at irq handling in the kernel from a generic perspective I
see two problems.
- There are a huge number of possible interrupt sources but in
practice very few of them are used. So we need a large
irq_desc[NR_IRQS] array that mostly goes unused. If we try for
tighter pacing we get i
40 matches
Mail list logo
