BSP Developer's Guide

5
Driver Guidelines
Per-Device Data Structure
As part of an object-oriented design, each device should be represented in the
system by a single structure with all the state information included. The object
methods (subroutines) perform operations on objects using an object handle (a
pointer to the data structure representing the object).
New instances of a device object would be created by calling a device create
function in the driver library (xxxDevCreate). During device creation time the
driver should probe to verify that the device is actually present. If not present, the
device creation operation should fail and return a null pointer.
5
Per-Driver Data Structure
In keeping with an object oriented design methodology, there should be a structure
to represent the driver itself. This structure would include all the driver state
information (class variables). From a practical standpoint, having all the driver
data in a single structure makes it easy to display from the CrossWind debugging
tool.
Driver Interrupt Service Routines
Because there may be bus issues related to interrupts, drivers should not call
intConnect( ) directly. The driver should define a macro that can be changed by the
customer to call the correct interrupt connection routine, which may not be
intConnect( ).
#ifndef FOO_INT_CONNECT
#define FOO_INT_CONNECT(vec, rtn, arg)
#endif
intConnect(vec, rtn, arg)
Device driver ISRs must exit immediately if the device is not asserting interrupt.
Do not assume that there is a one-to-one mapping between interrupt vectors and
interrupt handlers. With PCI systems, it is quite likely that interrupt lines are used
to service more then one device. Interrupt routines must examine the device and
determine if it is actually generating an interrupt condition. If not, the interrupt
handling code should exit as quickly as possible.
97