Re: ncr53c8xx + tulip IRQ sharing

Doug Ledford (dledford@dialnet.net)
Tue, 17 Feb 1998 06:35:33 -0600

Jon Lewis wrote:
>
> On Mon, 16 Feb 1998, Rogier Wolff wrote:
>
> > No. Linux guarantees that YOUR interrupt will not occur. This means
> > that you have free reign about your own device (the ncr8xx). However
> > if you cannot tolerate being interrupted for a few microseconds, (e.g.
> > if the device has a microsecond timeout after writing a "low word")
> > you can opt for running the whole interrupt routine with interrupts
> > off to keep things "consistent".
>
> I didn't realize my question and lame BIOS would spark such a lively
> debate. Anyone care to guess which is the best way to procede? Make the
> NCR driver use slow interrupts? Make the Tulip driver use fast ones? Try
> to somehow force them onto different IRQ's without the BIOS's help?
>
> Note...I'm looking for a solution usable with 2.0.x. A possible solution
> requiring 2.1.x has already been suggested, but I'd rather not go there
> yet.

I'm not sure about Rogier's comments in regards to 2.1.z, but in regards to
2.0.x, your interrupt handler will never get called more than once
regardless of the flags in use. The difference is that with the
SA_INTERRUPT flag, your handler is called with global interrupts disabled
(cli() state) and upon return the sti() state is restored and the irq is
ended without any further activity. This means that there is no bottom half
handler run after an SA_INTERRUPT interrupt completes. This isn't a problem
for SCSI devices because the SCSI subsystem in 2.0.x doesn't have a bottom
half handler. For network cards however, the story is different. Since
network cards make extensive use of the net_bh for packet completion
(essentially it can be called that), I could see performance problems if you
set the SA_INTERRUPT flag on NIC drivers. In that case, the bottom half
couldn't get run at the end of the interrupt, it would always have to wait
for the scheduler to run the net_bh, which would increase latencies.
Typically, there isn't a problem with running a SCSI interrupt handler
without the SA_INTERRUPT flag, and by default the aic7xxx driver doesn't use
that flag anyway. The trick then is that if your interrupt handler needs
protection from other things, such as timer interrupts that could trigger a
packet queue at the same time as your interrupt handler, then you need the
global cli() protection in your interrupt handler. The aic7xxx driver in
2.0.33 is written to accomodate either protection mechanism. If we are
registered with SA_INTERRUPT, then interrupts will be off the whole time we
are running. If we are registered without SA_INTERRUPT, then we turn
interrupts off. However, note that there isn't any real need to test for
which way you are registered, just use the save_flags(); cli();
restore_flags(); functions around critical areas and then if you are called
with interrupts enabled, this will disable then where they need to be, and
if you are called with interrupts disabled(SA_INTERRUPT) then this will not
unset that state when you call restore_flags(). Check the aic7xxx_isr()
function and it should be fairly easy to adopt the same mechanism into the
ncr driver's isr funciton and then change the flags it requests the
interrupt with.

-- 


 Doug Ledford  <dledford@dialnet.net>
  Opinions expressed are my own, but
     they should be everybody's.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu