Messages in this thread |  | | | Date | Tue, 17 Feb 1998 06:35:33 -0600 | | From | Doug Ledford <> | | Subject | Re: ncr53c8xx + tulip IRQ sharing |
| |
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
|  |