> > 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
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 pci
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.
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
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
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
> 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
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 space I
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 abstraction for
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
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 to be
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.
However
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
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
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
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
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 different irq
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 if
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
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
> 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
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
a
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.
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 allocated
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 irq_desc to
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
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
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
> > #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
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
> 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
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.
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
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
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 appropriate and
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
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. Getting the arch
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
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 on a given
#define NO_IRQ architecture-defined-int-constant
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++
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 having to
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 to replace
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 over
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
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
> >
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
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)
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
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
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
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
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
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
>>
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
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
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
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
* 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
> 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
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
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 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,
* 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
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 and
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 hotunplug etc.?
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
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 have
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
kernel
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
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
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
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
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 lucky enough
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) to
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 allocated
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_IRQS. As
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
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.
I
80 matches
Mail list logo
