Specifications

Accessing Device Interface Registers
2.2 Platform Independent I/O Bus Mapping
2.2.1 Using the IOC$MAP_IO Routine
Drivers that need to use the IOC$MAP_IO routine must call that routine under
specific spinlock restrictions. The driver cannot be holding any spinlocks that
prohibit IOC$MAP_IO from taking out the MMG spinlock.
Most drivers want to call IOC$MAP_IO immediately after they are loaded.
Traditionally, the correct place for a driver to call IOC$MAP_IO would be its
controller or unit initialization routine. However, because the controller and unit
initialization routines are called at IPL$_POWER, IOC$MAP_IO cannot take out
the MMG spinlock in this environment.
The new driver support feature for calling IOC$MAP_IO has two elements. First,
the driver may request preallocated space for any number of I/O Handles (the
output of IOC$MAP_IO). Second, the driver may name a routine that will be
called in an environment suitable for calls to IOC$MAP_IO.
Drivers can specify the number of I/O Handles they need to store using the
IOHANDLES parameter on the DPTAB macro. The default parameter value is
zero. The maximum permitted value is 65,535.
When the IOHANDLES parameter is zero or one, the driver loader does NOT
allocate any additional space for I/O Handles. For these two values, the driver is
expected to store the I/O Handle it needs directly in the IDB$Q_CSR field.
When the IOHANDLES parameter is greater than one, an MCJ data structure
is allocated. The base address of the MCJ is stored in the low-order longword
of IDB$Q_CSR and the IDB$V_MCJ flag is set. MCJ$Q_ENTRIES is the base
address in the MCJ of an array of quadword I/O Handle slots. The number of
slots in the array is exactly the number specified by the drivers dpt$iohandles
value.
Drivers specify a CSR Mapping routine using the CSR_MAPPING parameter
on the DDTAB macro. The driver loading procedure calls the CSR_MAPPING
routine holding the IOLOCK8 spinlock before it calls the controller or unit
initialization routines. In this context, the driver can make all its needed calls to
IOC$MAP_IO and other bus support routines with similar calling requirements.
Note
The CSR mapping routine is not called on power fail recovery.
2.2.2 Platform Independent I/O Access Routines
The platform independent I/O access routines are IOC$READ_IO and
IOC$WRITE_IO. These provide a platform independent way to read and write I/O
space without the overhead of CRAM allocation and initialization. These routines
require that the I/O space that is to be accessed has been previously mapped by a
call to IOC$MAP_IO.
With the new mapping and access routines, we have the following basic model of
I/O bus access:
• Map the device into the processor address space: Do the mapping yourself
based on knowledge of a specific platform and bus OR use the new routine
IOC$MAP_IO.
• Access the device: Do it yourself based on platform details, use CRAMS, or
using the new platform independent access routines.
2–3