Specifications

Accessing Device Interface Registers
2.2 Platform Independent I/O Bus Mapping
IOC$READ_IO and IOC$WRITE_IO are supported on PCI, EISA,
TURBOchannel, and Futurebus+. These routines are not supported on XMI.
2.3 Accessing Registers Directly
Registers that are mapped into the processors’ virtual address space and accessed
with load and store instructions are said to be accessed directly. This is similar to
VAX-style I/O register access. On an AXP system, registers that are implemented
on hardware directly connected to the processor-memory interconnect are usually
accessed in this manner. Sparse space and swizzle space register access are
examples of direct I/O device register access.
2.4 Accessing Registers Using CRAMS
Hardware I/O mailboxes exist only on DEC4000 Series and DEC7000/DEC10000
Series computers. The CRAM data structure and associated routines and
IOC$READIO and IOC$WRITE_IO hide the underlying hardwarep mechanism
(swizzle space, sparse space, or hardware I/O mailbox) from the programmer.
In addition to the CRAM data structure, OpenVMS AXP provides a set of system
routines and corresponding macros that, on behalf of a device driver, allocate
and initialize CRAMs. Table 2–1 lists these routines and macros. For more
information about each system routine and macro, see OpenVMS AXP Device
Support: Reference. Subsequent sections of this chapter describe driver mailbox
operations in more detail.
Table 2–1 OpenVMS Macros and System Routines That Manage I/O Mailbox Operations
Routine Macro Description
IOC$ALLOCATE_
CRAM
DPTAB idb_crams,
ucb_crams
CRAM_ALLOC
Allocates and initializes a CRAM
IOC$CRAM_CMD CRAM_CMD Generates values for the command, mask, and
remote I/O interconnect address (RBADR) fields of a
CRAM
IOC$CRAM_IO CRAM_IO Issues the I/O space transaction defined by the
CRAM
IOC$DEALLOCATE_
CRAM
CRAM_DEALLOC Deallocates a CRAM
2.5 Allocating CRAMs
A driver can use the following basic CRAM allocation strategies:
• Allocate a CRAM for every register the driver ever needs to access.
• Allocate a CRAM and reuse it.
• A driver can preallocate CRAMs at driver loading, or in a driver controller or
unit initialization routine, linking them to a list connected to a UCB, IDB, or
some driver-specific structure. This strategy is optimal for drivers that use
CRAMs in performance-sensitive code.
• A driver can reuse and rebuild CRAMs as needed. Although fewer CRAMs
suffice for the purposes of such a driver, this strategy is best suited for access
to registers that are not in a performance sensitive code path.
2–4