> > 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
39 matches
Mail list logo