Messages in this thread | | | From | Bret Indrelee <> | Subject | RE: [Q]: Linux and real device drivers | Date | Tue, 21 Sep 1999 18:00:20 -0500 |
| |
> > Actually, drivers should be structured as high priority > tasks, at least from > > the scheduling point of view. The interrupt handler itself > should only do > > enough to stop the card from interrupting and then pass control to a > > software handler. > > There are very good reasons for not doing this in a typical > real world OS > environment.
All of my experience is in producing production drivers for commercial operating systems.
> If I take an interrupt and schedule a task, then > the following > sequence occurs > > irq > copy data > clear irq > end of irq > > <-- Things pass --> > at some point schedule task > run stuff >
Instead you should:
irq poll device (assuming PCI or similiar) if your device, disable device irq (clears the IRQ) and post to semaphore for deferred processing end of irq
<-- Things pass --> schedule processing that was waiting on semaphore
copy data enable device interrupt run stuff
go back to waiting for next IRQ, which may have already happened.
On an SMP machine with high activity, you could have the task (actually I believe Linux would use task queues, but same difference) constantly running on a CPU while new IRQs come in on the other processor. It can be better for cache as well, since interrupts do less work and are therefore less disruptive of the instruction and data cache. This would help cache on both SMP and UP systems.
When you structure things this way, it also tends to minimize the amount of driver code requiring that you disable interrupts. No data structures other than the semaphore that are accessed from interrupt, so you don't have to block interrupts when doing mutual exclusion.
-Bret
------------------------------------------------------------- SBS Technologies, Connectivity Products ... solutions for real-time connectivity
Bret Indrelee, Engineer SBS Technologies, Inc., Connectivity Products 1284 Corporate Center Drive, St. Paul MN 55121 Direct: (651) 905-4731 Main: (651) 905-4700 Fax: (651) 905-4701 E-mail: bindrelee@sbs-cp.com http://www.sbs.com -------------------------------------------------------------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |