lkml.org 
[lkml]   [2004]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.042 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site