Russell,
On Wed, 2005-02-09 at 12:50 +0000, Russell King wrote:
> > > We have done the conversion to the generic irq handling and it works
> > > fine on a couple of machines.
> >
> > great - this would be a much preferred approach indeed.
>
> Well, I remain unconvinced about the generic irq handling.
>
> This caused major changes throughout all the machine support files,
> and I'm _NOT_, repeat _NOT_ going to consider going back to some
> half baked approach which doesn't really fit the needs of the ARM
> architecture, just because "oh, it's generic." If it doesn't work
> reliably, I'm not interested.
Agreed. Doing it just for the sake of a generic solution is not the
point.
> This is especially so when it impacts so many machines in ways
> specific to each machine, and there's no way to get them tested
> in one go.
Ack.
> If this is to be done, doing it in the middle of a stable kernel series
> is NOT the time or place to do it. I have recently had people complaining
> about the "stability" of 2.6, particularly in relation to changes made by
> other people affecting drivers.
>
> Consider these questions in relation to the generic IRQ code:
>
> 1. Does it know the difference between handling level, edge-based and
> "simple" IRQs? ("simple" IRQs are those which are cascaded, but
> don't have their own individual interrupt mask controls.)
The changes we made to the generic layer in order to make it work on ARM
still call the level/edge/simple handlers.
> 2. Does the generic autoprobe code know which IRQs can be autoprobed
> and which can't? (cascade interrupts are just one example of
> interrupts which must not be autoprobed. There may be other
> reasons you wish to avoid probing other interrupts on a particular
> machine, which the machine support code knows about.)
Makes sense to add this to the generic code anyway.
> 3. Does the generic IRQ code know which IRQs can be claimed and
> which can't? (IRQs 0 to NR_IRQS aren't always claimable, even
> when they appear to be available - iow, desc->handler != &no_irq_type.)
There's a check whether a particular irq has been exclusively allocated
or is available for driver use. Not sure, if it does exactly the same
what you are talking about. Needs to be checked.
> 4. Does it allow per "hw type" retriggering of interrupts, even if the
> hardware itself is not capable of such an action? (and running
> these interrupts at the next hardware interrupt?)
I implemented this basically, but it's not fully tested/functional yet.
> 5. Does it allow control of interrupt wakeup sources?
Are you talking about PM wakeup ? If yes, it is not there, but isn't
this functionality useful for other platforms than ARM too ?
> 6. Does it allow architectures to define their own irq_desc_t so that
> all the data for a particular IRQ is localised and contained within
> one data structure?
Having a generic irq_desc_t with an architecture specific member "struct
arch_irq_desc_t bla;" should do the job.
> In essence, I'm opposed to completely rewriting the ARM interrupt
> handling at this stage.
As expected :)
I accept your decision, but I hope that you are not completely opposed
to discuss a conversion at all, especially as other architectures will
benefit from the necessary changes to the generic code too.
Thanks for the pointers so far.
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
