At Wed, 12 Mar 2003 16:06:15 -0700, Herb Peyerl wrote:
> cgd@broadcom.com  wrote:
>  > hmm, is that a built-in device?  will the "interrupt line" ever be
>  > used for anything else?  if not, it might be The Right Thing to simply
>  > bury the knowledge in the intr controller code.
> 
> yes and no, as answers to the questions.

OK, well, in that case, i'd say that _for that device_ it might be
appropriate to bury the info in the interrupt controller code.


> Jason's suggestion was just to do: 
> 	#define IST_NONE        0       /* none (dummy) */
> 	#define IST_PULSE       1       /* pulsed */
> 	#define IST_EDGE        2       /* edge-triggered */
> 	#define IST_LEVEL       3       /* level-triggered */
> 	#define IST_LEVEL_LOW   4	/* level triggered, active low */
> 	#define IST_LEVEL_HIGH  5	/* level triggered, active high */
> 
> and then just deal with it in the intr code.

Well, that's nice, but there's no reason that edge-triggered or pulsed
interrupts should _have_ to be high or low, either.

(i've know gpios which can be edge or level, high or lo.  8-)

so... if you're gonna do _that_, it makes sense to have it be a flag.
I'd choose IST_ACTIVE_foo, btw.


Alternately, another reasonable way to handle this is on ICUs which
flexible enough to do this type of thing, provide modifiers for the
interrupt number that indicate active high or active low.

really, these modifiers (high or low, or modified interrupt number)
can only be used by MD code which understands the ICU.

actually, if you do it with a special flag on the interrupt number,
you could actually do the right thing and have, say, PCI interrupt
mapping code provide the right values for "special" PCI bridges, even.
(i.e., if your PCI bridge presents device intrs as active low but most
things as active high, then it could DTRT automatically w/o touching
any code).

by tweaking the interrupt number, it stays entirely machine-dependent
and interrupt controller dependent...


cgd