Messages in this thread | | | Date | Wed, 20 Oct 2004 11:20:17 +0200 | From | Ingo Molnar <> | Subject | Re: New consolidate irqs vs . probe_irq_*() |
| |
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Wed, 2004-10-20 at 18:48, Ingo Molnar wrote: > > > yeah. I've put it into a separate autoprobe.c file specifically for that > > reason, you can exclude it in the Makefile and can provide your own > > architecture version. Or should we make the no-autoprobing choice > > generic perhaps? > > I like this later option... How may archs actually had autoprobing > implemented and actually used ? > > Well, I'll do some grep'ing around tonight as I do the NO_IRQ stuff > and see what makes more sense. I don't think an arch that didn't have > autoprobing needs it now, besides, it's not exactly a reliable > mecanism...
btw., auto-detection of interrupt sources is not _necessarily_ broken. Especially with level-triggered interrupts (where no active irq source can get lost) it can be doable and reliable. (Here i dont mean the probe_irq_on/off interface, but the concept of auto-detection.)
Alan has a very neat hack that fixes laptop BIOS breakage in associating a screaming interrupt with the driver that responds to it with IRQ_HANDLED, by probing through all the SHIRQ handlers and checking whether the return code is IRQ_HANDLED. (this patch was in -mm but has not been integrated into the generic irq subsystem yet.) This patch turned a broken-under-Linux into a working laptop so we cannot ignore it.
In theory, as long as all drivers involved are shared-irq-capable, and all interrupts are level-triggered and get repeated if unhandled, we can always do this kinds of driver-feedback-based irq vector discovery.
Think about the positive effects: in theory we could even boot into a box without _any_ BIOS interrupt info whatsoever, assuming only a few architecture basics like the identity of the timer interrupt. Furthermore, if the BIOS reports _bad_ interrupt information, we can detect & redirect that interrupt to the driver that responds to it.
this is not a concept that would be too useful for the server space, but it sure could be useful for the produce-and-forget PC mass-market. We are playing a constant and mostly losing catchup game with BIOS quirks.
what can never work fully reliably is of course what the feature was used for primarily: ISA :-) One-time edge-triggered interrupts that get lost are nasty ...
so i thought autodetect.c could survive in the generic code - maybe we can make something really nice out of it, based on Alan's patch.
Ingo - 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/
| |