Subject: Re: IST_LEVEL in arch/mips
To: None <hpeyerl@beer.org>
From: None <cgd@broadcom.com>
List: tech-kern
Date: 03/12/2003 14:57:17
At Wed, 12 Mar 2003 22:28:32 +0000 (UTC), "Herb Peyerl" wrote:
> In sys/arch/evbmips/include/intr.h, we have:
> 
> 	#define IST_UNUSABLE    -1      /* interrupt cannot be used */
> 	#define IST_NONE        0       /* none (dummy) */
> 	#define IST_PULSE       1       /* pulsed */
> 	#define IST_EDGE        2       /* edge-triggered */
> 	#define IST_LEVEL       3       /* level-triggered */
> 
> which gets used in sys/arch/mips/alchemy/au_icu.c to configure
> an interrupt line as level triggered but it assumes that the
> interrupt is active high.  However, on the Alchemy au1500, the
> USB Host controller is level triggered, active low.  Since 
> IST_LEVEL currently assumes "active high", this screws me.

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.

(generally, other interrupts are active high?)


> So I propose (as per suggestion of Christos):
>  
> -  Add the following:
>         #define IST_HIGH        0       /* active high */
>         #define IST_LOW         0x1000  /* active low */

I would suggest, if you're going to do this, that they be independent
modifiers.

i.e., neither means "whatever is normal for this ICU", and if you
specify one then that's explicitly what the ICU code tries to enable
(and rejects if it can't).

e.g., PCI intrs are normally "active low," right, but by the time they
make it to/through an interrrupt controller, they appear to code
driving the interrupt controller as "active high."

So, a driver might reasonably say "IST_LEVEL | IST_LOW" since that's
what the card will drive... but that might be _horribly_ confusing for
the icu code.



cgd
-- 
Chris Demetriou                                            Broadcom Corporation
Principal Design Engineer                     Broadband Processor Business Unit
  Any opinions expressed in this message are mine, not necessarily Broadcom's.