Subject: Re: SCN driver
To: None <Ian.Dall@dsto.defence.gov.au>
From: Phil Budne <budd@cs.bu.edu>
List: port-pc532
Date: 12/02/1996 22:40:08
It sounds like you're making good progress!

Ian wrote;

>	There are a couple of problems. One is that for some reason
>	the scn driver establishes the rx interrupts at IPL_ZERO.

Hmm... What WAS I thinking....  I think I used it because I didn't
want to create a new IPL level at the time, and ZERO had the
properties I wanted (interrupts NOT added to iplmask[level] (or ANY
iplmask), since I never wanted rxintr masked out).

My original comment read;
	/*
	 * NOTE: IPL_ZERO is a hack, but since we NEVER want to
	 * disable rxintr's this seems "ok" (the whole idea is to
	 * allow them at all times, even during tty processing code)
	 */
#define IPL_TTY_RX IPL_ZERO
        intr_establish(rxints[duart], (void (*)(void *))scnrxintr,
                       (void *)(unit + 1), "scnrx", IPL_TTY_RX, FALLING_EDGE);


>	I thought, "wow, there must be some counter intuitive meaning
>	to IPL_ZERO", but looking at intr_establish, IPL_ZERO is
>	exactly what one would expect. *All* interrupts which have
>	ever been intr_established are enabled.  So, I created
>	IPL_RTTY at slightly higher than IPL_TTY.

Now *I'm* confused; Since there are no places where the interrupt is
ever masked out (ie; splttyrx()) why would it matter?  I thought the
only way you could make an interrupt higher priority than another
(other than the ordering of signals comming into the ICU) would be if
there was an interrupt mask associated with each ISR, so that the ISR
could run without dealing with interrupts from "lower" priority ISR's.
Last I looked, that was not the case.

-phil