NCR53C815 vs Tulip: sharing IRQ fails

[B. James Phillippe]

On Mon, 22 Mar 1999, Donald Becker wrote:

> On Mon, 22 Mar 1999, Gerard Roudier wrote:
> 
> > > Read the instructions in
> > >    http://cesdis.gsfc.nasa.gov/linux/misc/irq-conflict.html
> > > for info on how to fix the SCSI driver -- it's using the wrong flags for
> > > requesting the interrupt.
> > 
> > What wrong flags?
...
> Just to clarify, since some readers might be confused:
>     ****  Using SA_INTERRUPT is broken.  ***
> 
> It's semantically incompatible with sharing an interrupt line.
> It was never intended to be used in the way that the SCSI drivers use it.

Hello Donald et al,

At least one reader is still confused. :/  My understanding of the
interrupt flags is as follows:

For 2.0 kernels:

  SA_SHIRQ indicates capability of sharing interrupt with another driver.
  SA_INTERRUPT indicates use of a "fast" handler (as opposed to "slow").

  To share an interrupt, each driver must specify both SA_SHIRQ and must
  be of same type eg. fast or slow.  dev_id must be unique.

  Fast handlers run atomically WRT all new interrupts, and bh's are not
  serviced upon completion.

  Slow handlers run with all other interrupts enabled, and bh's are
  serviced upon completion.  Extra overhead is involved in saving
  registers.

  Fast and slow handlers may not share an interrupt.

For 2.1 kernels:

  Flags have same meaning as 2.0.

  To share an interrupt, all that is required between drivers is that
  they specify SA_SHIRQ and dev_id must be unique.

  Fast and slow handlers only differ in that fast handlers run atomically
  WRT all new interrupts; bh servicing and register saving is done for
  both.

  Fast and slow handlers may share an interrupt.

If this understanding is correct, in what way is SA_INTERRUPT or usage of
it is broken?

cheers,
-bp
--
B. James Phillippe		. bryan@terran.org
Software Engineer, WGT Inc.	. http://www.terran.org/~bryan