BSP Developer's Guide

5
Driver Guidelines
The level of cache library support designed into a driver must be well documented
in the code. This is an important issue that must not be neglected.
Many of the routines and macros in cacheLib are designed to hide the details of
the underlying hardware. The macros might actually call routines within
cacheLib, or they might do nothing at all. Their action depends on how certain
function pointers are initialized at run-time. The run-time initialization of the
cacheLib is determined by the code in the BSP modules, which are where the
actual details of the caching hardware are known. This hiding of details allows
drivers to be broadly targeted, which increases portability.
Good driver design includes portability. The following subsections assume
portability is a goal and discuss target-specific applications only minimally.
5
Flush and Invalidate Macros
Generally, you need to add the flush and invalidate macros to your driver. The
macro set you implement depends on the type of memory you need to control (see
Shared Memory Types, p.104). The flush macro is used on memory locations that are
given to the device for subsequent reading by the device. The invalidate macro is
used before the driver reads from memory locations that were written by the
device.
Portable drivers use flush and invalidate macros wherever needed. The macros are
written to perform null operations if they are not needed on the particular target.
WRITE_PIPING Attribute
The cacheLib macro CACHE_PIPE_FLUSH flushes the write pipeline of the CPU.
Typically, you add this macro to appropriate locations throughout your driver.
Appropriate locations are after one or more commands have been written to the
device. Device commands that require immediate delivery are most important.
These commands are commonly found in initialization sequences or in interrupt
handlers (where an interrupt condition requires clearing).
Deciding when this macro needs to be used requires in-depth knowledge of the
device you are programming. Some devices are not affected by the delays caused
by a write pipeline. Such devices do not require the pipeline flush macro in the
driver. Other devices do not function correctly without a tight synchronization
with the driver. Such devices require liberal use of the pipeline flush macro
throughout the driver.
107