Comtrol eCos - Manual (Page 390)

Chapter 18. Device Driver Interface to the Kernel
chronization, this mechanism should be used sparingly. Only DSRs and threads may use this synchronization
mechanism, ISRs are not allowed to do this.
3. Synchronization with threads. This is implemented with mutexes and condition variables. Only threads may
lock the mutexes and wait on the condition variables, although DSRs may signal condition variables.
Any data that is accessed from more than one level must be protected against concurrent access. Data that is
accessed by ISRs must be protected with the ISR lock, or a spinlock at all times, even in ISRs. Data that is shared
between DSRs and threads should be protected with the DSR lock. Data that is only accessed by threads must be
protected with mutexes.
SMP Support
Some eCos targets contain support for Symmetric Multi-Processing (SMP) configurations, where more than one
CPU may be present. This option has a number of ramifications for the way in which device drivers must be written
if they are to be SMP-compatible.
Since it is possible for the ISR, DSR and thread components of a device driver to execute on different CPUs, it is
important that SMP-compatible device drivers use the driver API routines correctly.
Synchronization between threads and DSRs continues to require that the thread-side code use
cyg_drv_dsr_lock() and cyg_drv_dsr_unlock() to protect access to shared data. While it is not strictly
necessary for DSR code to claim the DSR lock, since DSRs are run with it claimed already, it is good practice to
do so.
Synchronization between ISRs and DSRs or threads requires that access to sensitive data be protected, in all places,
by calls to
cyg_drv_isr_lock() and cyg_drv_isr_unlock() . Disabling or masking interrupts is not adequate,
since the thread or DSR may be running on a different CPU and interrupt enable/disable only work on the current
CPU.
The ISR lock, for SMP systems, not only disables local interrupts, but also acquires a spinlock to protect against
concurrent access from other CPUs. This is necessary because ISRs are not run with the scheduler lock claimed.
Hence they can run in parallel with the other components of the device driver.
The ISR lock provided by the driver API is just a shared spinlock that is available for use by all drivers. If a driver
needs to implement a finer grain of locking, it can use private spinlocks, accessed via the
cyg_drv_spinlock_*()
functions.
Device Driver Models
There are several ways in which device drivers may be built. The exact model chosen will depend on the properties
of the device and the behavior desired. There are three basic models that may be adopted.
The first model is to do all device processing in the ISR. When it is invoked the ISR programs the device
hardware directly and accesses data to be transferred directly in memory. The ISR should also call
cyg_drv_interrupt_acknowledge() . When it is finished it may optionally request that its DSR be invoked.
The DSR does nothing but call cyg_drv_cond_signal() to cause a thread to be woken up. Thread level code
must call cyg_drv_isr_lock() , or cyg_drv_interrupt_mask() to prevent ISRs running while it manipulates
shared memory.
286