1 <!-- Copyright (C) 2003 Red Hat, Inc. -->
2 <!-- This material may be distributed only subject to the terms -->
3 <!-- and conditions set forth in the Open Publication License, v1.0 -->
4 <!-- or later (the latest version is presently available at -->
5 <!-- http://www.opencontent.org/openpub/). -->
6 <!-- Distribution of the work or derivative of the work in any -->
7 <!-- standard (paper) book form is prohibited unless prior -->
8 <!-- permission is obtained from the copyright holder. -->
12 >Device Driver Models</TITLE
13 ><meta name="MSSmartTagsPreventParsing" content="TRUE">
16 CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
19 TITLE="eCos Reference Manual"
20 HREF="ecos-ref.html"><LINK
22 TITLE="Device Driver Interface to the Kernel"
23 HREF="devapi-device-driver-interface-to-the-kernel.html"><LINK
26 HREF="devapi-smp-support.html"><LINK
28 TITLE="Synchronization Levels"
29 HREF="devapi-synchronization-levels.html"></HEAD
40 SUMMARY="Header navigation table"
49 >eCos Reference Manual</TH
57 HREF="devapi-smp-support.html"
65 >Chapter 18. Device Driver Interface to the Kernel</TD
71 HREF="devapi-synchronization-levels.html"
85 NAME="DEVAPI-DEVICE-DRIVER-MODELS">Device Driver Models</H1
87 >There are several ways in which device drivers
88 may be built. The exact model chosen will depend on the properties of
89 the device and the behavior desired. There are three basic models that
92 >The first model is to do all device processing in the ISR. When it is
93 invoked the ISR programs the device hardware directly and accesses
94 data to be transferred directly in memory. The ISR should also call
97 >cyg_drv_interrupt_acknowledge()</TT
99 finished it may optionally request that its DSR be invoked. The DSR
100 does nothing but call <TT
102 >cyg_drv_cond_signal()</TT
104 cause a thread to be woken up. Thread level code must call
107 >cyg_drv_isr_lock()</TT
111 >cyg_drv_interrupt_mask()</TT
112 > to prevent ISRs running
113 while it manipulates shared memory.</P
115 >The second model is to defer device processing to the DSR. The ISR
116 simply prevents further delivery of interrupts by either programming
117 the device, or by calling
120 >cyg_drv_interrupt_mask()</TT
124 >cyg_drv_interrupt_acknowledge()</TT
126 interrupts to be delivered and then request that its DSR be
127 called. When the DSR runs it does the majority of the device handling,
128 optionally signals a condition variable to wake a thread, and finishes
131 >cyg_drv_interrupt_unmask()</TT
133 device interrupts. Thread level code uses
136 >cyg_drv_dsr_lock()</TT
137 > to prevent DSRs running while
138 it manipulates shared memory. The eCos serial device drivers use this
141 >The third model is to defer device processing even further to a
142 thread. The ISR behaves exactly as in the previous model and simply
143 blocks and acknowledges the interrupt before request that the DSR
144 run. The DSR itself only calls
147 >cyg_drv_cond_signal()</TT
148 > to wake the thread. When
149 the thread awakens it performs all device processing, and has full
150 access to all kernel facilities while it does so. It should finish by
153 >cyg_drv_interrupt_unmask()</TT
155 device interrupts. The eCos ethernet device drivers are written to
158 >The first model is good for devices that need immediate processing and
159 interact infrequently with thread level. The second model trades a
160 little latency in dealing with the device for a less intrusive
161 synchronization mechanism. The last model allows device processing to
162 be scheduled with other threads and permits more complex device
170 SUMMARY="Footer navigation table"
181 HREF="devapi-smp-support.html"
199 HREF="devapi-synchronization-levels.html"
215 HREF="devapi-device-driver-interface-to-the-kernel.html"
223 >Synchronization Levels</TD