drivertut6.html

What is this ``device driver stuff anyway? Here s a very short introduction to the concept.

<a href="#ModTypeChar"><img src="drivertut6_files/NEXT.GIF" alt="[Next Section]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/drivertut7.html"><img src="drivertut6_files/FF.GIF" alt="[Next Chapter]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/INDEX.html"><img src="drivertut6_files/INDEX.GIF" alt="[Index]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/HELP.html"><img src="drivertut6_files/HELP.GIF" alt="[Help]" border="0"></a>
</p><p></p><hr><p>
</p><h3>
3.1.5.6牋牋Using NULL and Zero Values
</h3>
<p>
<a name="nx_id_139"></a>
Using the value zero (0) where you should use the value NULL
means that you get a 32-bit constant.
On Alpha systems, this usage could mean the value zero (0)
in the low 32 bits and indeterminate bit values in the high 32 bits.
Using NULL from the
<tt>types.h</tt>
file allows you to obtain the correct value for both the 32-bit CPUs and
the 64-bit Alpha CPUs.
<a name="ModTypeChar"></a>
</p><p></p><hr><p align="center">
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/Digital_UNIX_Bookshelf.html"><img src="drivertut6_files/BOOKSHELF.GIF" alt="[Return to Library]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/TOC.html"><img src="drivertut6_files/TOC.GIF" alt="[Contents]" border="0"></a>
<a href="#CPUandBusIssues"><img src="drivertut6_files/REW.GIF" alt="[Previous Chapter]" border="0"></a>
<a href="#UsingNullZeroVals"><img src="drivertut6_files/PREV.GIF" alt="[Previous Section]" border="0"></a>
<a href="#DeclBitFields"><img src="drivertut6_files/NEXT.GIF" alt="[Next Section]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/drivertut7.html"><img src="drivertut6_files/FF.GIF" alt="[Next Chapter]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/INDEX.html"><img src="drivertut6_files/INDEX.GIF" alt="[Index]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/HELP.html"><img src="drivertut6_files/HELP.GIF" alt="[Help]" border="0"></a>
</p><p></p><hr><p>
</p><h3>
3.1.5.7牋牋Modifying Type char
</h3>
<p>
<a name="nx_id_140"></a>
Modifying a variable declared as type
<tt>char</tt>
is not atomic on Alpha systems.
You will get a load of 32 or 64 bits and then byte operations to
extract, mask, and shift the byte, followed by a store of 32 or 64 bits.
<a name="DeclBitFields"></a>
</p><p></p><hr><p align="center">
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/Digital_UNIX_Bookshelf.html"><img src="drivertut6_files/BOOKSHELF.GIF" alt="[Return to Library]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/TOC.html"><img src="drivertut6_files/TOC.GIF" alt="[Contents]" border="0"></a>
<a href="#CPUandBusIssues"><img src="drivertut6_files/REW.GIF" alt="[Previous Chapter]" border="0"></a>
<a href="#ModTypeChar"><img src="drivertut6_files/PREV.GIF" alt="[Previous Section]" border="0"></a>
<a href="#UsingprintfFormats"><img src="drivertut6_files/NEXT.GIF" alt="[Next Section]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/drivertut7.html"><img src="drivertut6_files/FF.GIF" alt="[Next Chapter]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/INDEX.html"><img src="drivertut6_files/INDEX.GIF" alt="[Index]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/HELP.html"><img src="drivertut6_files/HELP.GIF" alt="[Help]" border="0"></a>
</p><p></p><hr><p>
</p><h3>
3.1.5.8牋牋Declaring Bit Fields
</h3>
<p>
<a name="nx_id_141"></a>
Bit fields declared as type
<tt>int</tt>
on Alpha systems generate a load/store of longword (32 bits).
Bit fields declared as type
<tt>long</tt>
on Alpha systems generate a load/store of quadword (64 bits).
<a name="UsingprintfFormats"></a>
</p><p></p><hr><p align="center">
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/Digital_UNIX_Bookshelf.html"><img src="drivertut6_files/BOOKSHELF.GIF" alt="[Return to Library]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/TOC.html"><img src="drivertut6_files/TOC.GIF" alt="[Contents]" border="0"></a>
<a href="#CPUandBusIssues"><img src="drivertut6_files/REW.GIF" alt="[Previous Chapter]" border="0"></a>
<a href="#DeclBitFields"><img src="drivertut6_files/PREV.GIF" alt="[Previous Section]" border="0"></a>
<a href="#Usingwbflush"><img src="drivertut6_files/NEXT.GIF" alt="[Next Section]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/drivertut7.html"><img src="drivertut6_files/FF.GIF" alt="[Next Chapter]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/INDEX.html"><img src="drivertut6_files/INDEX.GIF" alt="[Index]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/HELP.html"><img src="drivertut6_files/HELP.GIF" alt="[Help]" border="0"></a>
</p><p></p><hr><p>
</p><h3>
3.1.5.9牋牋Using printf Formats
</h3>
<p>
<a name="nx_id_142"></a>
The
<tt>printf</tt>
formats
%d and %x will print 32 bits of data.
To obtain 64 bits of data, use
%ld and %lx.
<a name="Usingwbflush"></a>
</p><p></p><hr><p align="center">
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/Digital_UNIX_Bookshelf.html"><img src="drivertut6_files/BOOKSHELF.GIF" alt="[Return to Library]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/TOC.html"><img src="drivertut6_files/TOC.GIF" alt="[Contents]" border="0"></a>
<a href="#CPUandBusIssues"><img src="drivertut6_files/REW.GIF" alt="[Previous Chapter]" border="0"></a>
<a href="#UsingprintfFormats"><img src="drivertut6_files/PREV.GIF" alt="[Previous Section]" border="0"></a>
<a href="#Usingvolatile"><img src="drivertut6_files/NEXT.GIF" alt="[Next Section]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/drivertut7.html"><img src="drivertut6_files/FF.GIF" alt="[Next Chapter]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/INDEX.html"><img src="drivertut6_files/INDEX.GIF" alt="[Index]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/HELP.html"><img src="drivertut6_files/HELP.GIF" alt="[Help]" border="0"></a>
</p><p></p><hr><p>
</p><h3>
3.1.5.10牋牋Using mb and wbflush
</h3>
<p>
<a name="nx_id_143"></a>
Device drivers used the
<tt>wbflush</tt>
interface with ULTRIX systems on MIPS CPUs.
Although
<tt>wbflush</tt>
is aliased to the
<tt>mb</tt>
(memory barrier) interface for Alpha CPUs,
Digital recommends that all new device drivers call
the
<tt>mb</tt>
interface.
The remainder of this section discusses when to call the
<tt>mb</tt>
interface on Alpha CPUs.
</p><p>
In most situations that would require a cache flush on other CPU
architectures, you should call the
<tt>mb</tt>
interface on Digital UNIX Alpha systems.
The reason is not that
<tt>mb</tt>
is equivalent to a cache flush (as it is not).
Rather, a common reason for doing a cache flush is to make data
that the host CPU wrote available in main memory for access by the DMA
device or to access from the host CPU data that was put in main memory
by a DMA device.
In each case, on an Alpha CPU you should use a memory barrier to
synchronize with that event.
<a name="nx_id_144"></a>
<a name="nx_id_145"></a>
<a name="nx_id_146"></a>
</p><p>
A call to
<tt>mb</tt>
is occasionally needed even where a call to
<tt>wbflush</tt>
was not needed.
In general, a memory barrier causes loads/stores to be serialized
(not out-of-order), empties memory pipelines and write buffers, and
ensures that the data cache is coherent.
</p><p>
You should use the
<tt>mb</tt>
interface to synchronize DMA buffers.
<a name="nx_id_147"></a>
Use it before the host releases the buffer to the device and before the
host accesses a buffer filled by the device.
</p><p>
Alpha CPUs do not guarantee to preserve write ordering, so
memory barriers are required between multiple writes to I/O registers
where order is important.
The same is also true for read ordering.
</p><p>
Use the memory barrier to prevent writes from being collapsed in the
write buffer, that is, to prevent bytes, shorts, and ints from being
merged into one 64-bit write.
</p><p>
Alpha CPUs require that data caches be transparent. 
Because there is no way to explicitly flush the data cache on an
Alpha platform, you need not call
<tt>mb</tt>
before or after.
The following code fragment illustrates the use of a memory barrier:
</p><p>
</p><pre><br>.<br>.<br>.<br>
        bcopy (data, DMA_buffer, nbytes);
        mb();
        device-&gt;csr = GO;
        mb();
<br>.<br>.<br>.<br>
</pre>
<p>
</p><p>
Another example is presented in the following code fragment:
</p><p>
</p><pre><br>.<br>.<br>.<br>
device_intr()
{
     mb();
     bcopy (DMA_buffer, data, nbytes);
    /* If we need to update a device register, do: */
     mb();
     device-&gt;csr = DONE;
     mb();
}
</pre>
<p>
</p><p>
Another way to look at this issue is to recognize that Alpha CPUs maintain
cache coherency for you.
However, Alpha CPUs are free to do the cache coherency in any
manner and time.
The events that cause you to want to read buffers, or the
events you want to trigger to release a buffer you have written, are not
guaranteed to occur at a time consistent with when the hardware
maintains cache coherency.
You need the memory barrier to achieve this synchronization. 
<a name="Usingvolatile"></a>
</p><p></p><hr><p align="center">
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/Digital_UNIX_Bookshelf.html"><img src="drivertut6_files/BOOKSHELF.GIF" alt="[Return to Library]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/TOC.html"><img src="drivertut6_files/TOC.GIF" alt="[Contents]" border="0"></a>
<a href="#CPUandBusIssues"><img src="drivertut6_files/REW.GIF" alt="[Previous Chapter]" border="0"></a>
<a href="#Usingwbflush"><img src="drivertut6_files/PREV.GIF" alt="[Previous Section]" border="0"></a>
<a href="#MemoryBarriers"><img src="drivertut6_files/NEXT.GIF" alt="[Next Section]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/drivertut7.html"><img src="drivertut6_files/FF.GIF" alt="[Next Chapter]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/INDEX.html"><img src="drivertut6_files/INDEX.GIF" alt="[Index]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/HELP.html"><img src="drivertut6_files/HELP.GIF" alt="[Help]" border="0"></a>
</p><p></p><hr><p>
</p><h3>
3.1.5.11牋牋Using the volatile Compiler Keyword
</h3>
<p>
<a name="nx_id_148"></a>
<a name="nx_id_149"></a>
The
<tt>volatile</tt>
keyword prevents compiler optimizations from being performed on
data structures and variables; such actions could result in unexpected
behavior.
The following example shows the use of the
<tt>volatile</tt>
keyword on a device register structure:
</p><p>
</p><pre>typedef volatile struct {
    unsigned adder;
    unsigned pad1;
    unsigned data;
    unsigned pad2;
    unsigned csr;
    unsigned pad3;
    unsigned test;
    unsigned pad4;
} CB_REGISTERS;
</pre>
<p>
The following variables or data structures should be declared as
volatile by device drivers:
</p><ul>
<p></p><li>
Any variable or data structure that can be changed by a controller or
processor other than the system CPU
<p></p></li><li>
Variables that correspond to hardware device registers
<p></p></li><li>
Any variable or data structure shared with a controller or coprocessor
</li></ul><p>
The purpose of using the
<tt>volatile</tt>
keyword on the example data structure is to prevent compiler
optimizations from being performed on it; such actions could
result in unexpected behavior.
<a name="MemoryBarriers"></a>
</p><p></p><hr><p align="center">
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/Digital_UNIX_Bookshelf.html"><img src="drivertut6_files/BOOKSHELF.GIF" alt="[Return to Library]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/TOC.html"><img src="drivertut6_files/TOC.GIF" alt="[Contents]" border="0"></a>
<a href="#CPUandBusIssues"><img src="drivertut6_files/REW.GIF" alt="[Previous Chapter]" border="0"></a>
<a href="#Usingvolatile"><img src="drivertut6_files/PREV.GIF" alt="[Previous Section]" border="0"></a>
<a href="#ForceBarLoadStore"><img src="drivertut6_files/NEXT.GIF" alt="[Next Section]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/drivertut7.html"><img src="drivertut6_files/FF.GIF" alt="[Next Chapter]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-PUBVD-TE_html/INDEX.html"><img src="drivertut6_files/INDEX.GIF" alt="[Index]" border="0"></a>
<a href="http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/HELP.html"><img src="drivertut6_files/HELP.GIF" alt="[Help]" border="0"></a>
</p><p></p><hr><p>
</p><h3>
3.1.6牋牋Memory Barrier Issues
</h3>
<p>
<a name="nx_id_150"></a>
<a name="nx_id_151"></a>
The Alpha architecture does not guarantee read/write ordering.
That is, the memory subsystem is free to complete read and write
operations in any order that is optimal, without regard for the order in
which they were issued.