Date: Mon, 17 Jul 2000 10:04:59 -0700 From: Joe Eykholt <jre@iprg.nokia.com> To: Steve Passe <smp@csn.net> Cc: Greg Lehey <grog@lemis.com>, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process Message-ID: <39733CBB.7147BA74@iprg.nokia.com> References: <200007171553.JAA24715@Ilsa.StevesCafe.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Steve's correct about the fast interrupt being needed to prevent
overflow of the serial FIFOs. So, FAST interrupts haven't been blocked
by spl (even splhigh) and the lower half of the driver has to disable
interrupts in order to blcok the FAST interrupt.
Just one more thing to consider: its pretty nice when using a serial
console to be able to break into the debugger even when at splhigh(),
and the FAST_INTR setup allows this. If serial interrupts were
threads, then this probably wouldn't be possible.
Solaris 2.5 (and probably the more recent versions also) uses the
equivalent of fast interrupts for serial also.
Joe
Steve Passe wrote:
>
> Hi,
>
> > I think I now understand how drivers register interrupts with newbus,
> > and it seems that some tidying up is in order.
> > ...
> > About fast interrupts, which currently seem to be used only by the sio
> > driver: they perform their entire work before reenabling interrupts,
> > and it's possible that we can keep them like that, though I haven't
> > looked at the code yet. Does anybody know any reason why we should
> > convert them to threaded interrupts?
>
> Its been quite awhile since I looked at this code, so forgive any inaccuracies
> on my part... I believe the sio FAST_INTR gets away with "they perform their
> entire work before reenabling interrupts" because it defers much of the work
> to the tty soft INTR level. In the ISR itself, it drains the hardware ASAP,
> then lets the soft INTR process the queues, etc. This method is used to
> prevent overflowing the sio fifos, which would otherwise occur if the INT were
> defered till spl() said it could proceed. If the new kernel model allows
> INTR threads to preempt, I would favor eliminating this sio 'special case',
> and use high priority for the sio ISR to get the same effect. I am a great
> fan of ISRs that look something like:
>
> sio_intr( struct threadStuff * s )
> {
> ssignal( &(s->intrSem) );
> }
>
> --
> Steve Passe | powered by
> smp@csn.net | Symmetric MultiProcessor FreeBSD
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-smp" in the body of the message
--
Joe Eykholt jre@iprg.nokia.com +1 650 625 2041
Nokia Internet Communications http://www.iprg.nokia.com
313 Fairchild Drive, Mountain View, CA 94043
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39733CBB.7147BA74>