Configuring the vba_vipvic Subsystem

This section describes how to configure the vba_vipvic kernel
subsystem in order to prepare VIP/VIC-based AXPvme and Alpha VME
systems for use on the VMEbus.

You configure the VIP/VIC adapter by examining the default attributes
that Compaq supplies for the vba_vipvic subsystem, determining
which attributes (if any) you want to change, then modifying the
/etc/sysconfigtab file on your machine. After modifying
/etc/sysconfigtab, you must shut down the system and reboot.

Note

You should not directly edit /etc/sysconfigtab. Instead you
should use the sysconfigdb facility, as described in the
sysconfigdb(8) reference page. Compaq recommends that you
maintain private sysconfigtab file fragments for vba_vipvic
attributes and use sysconfigdb switches to add (-a -f),
delete (-d), or merge (-m -f) vba_vipvic attribute
values. The Examples section of vb(7) illustrates this approach.
Additional guidelines for editing kernel subsystem attributes are
provided in the sys_attrs(5) reference page. You must always
reboot after changing vba_vipvic subsystem attributes.

Common modifications to the vba_vipvic subsystem default
attributes are to reconfigure the A32, A24, and A16 address spaces.
For example, you could use sysconfigdb to edit the following
modifications into /etc/sysconfigtab:
vba_vipvic:
A32_Base = 0x10000000
A32_Size = 0x08000000
A24_Base = 0x00A00000
A24_Size = 0x200000
A16_Base = 0x00000000
In this example, the A24 inbound DMA window base address is modified
from the default 0x00C00000 to 0x00A0000; the A24 window size from the default
4 MB to 2 MB; and the A16 interprocessor communication base address from
the default 0x00000100 to 0x00000000.

You can modify values for the following VIP/VIC adapter attributes;
each list item corresponds to a section later in this reference
page:

The defaults that Compaq supplies for various VMEbus parameters are listed
below. The default values specified should provide proper VMEbus operation
for most applications. Be careful when modifying these values; not all
adapters support all fields.
Parameter Default Meaning
--------------------------------------------------------------------
VME_Br_Lev 0x03 Bus request level 3 for master cycles

Specifying the VIC Arbitration Mode

You can specify one of the following values
for the VMEbus arbitration mode (parameter
VIC_Arb_Mode). The VMEbus arbitration mode is stored in
the VIC64 Arbiter/Requester Configuration Register (ARCR). This parameter is
applicable only when the VMEbus adapter is configured to be the system
controller.
VIC performs round-robin VMEbus arbitration (default)
VIC performs priority VMEbus arbitration

Specifying Bus Timeout Periods

You can specify one of the following values
for the local bus timeout period (parameter
VIC_Loc_Bus_To) and for the VMEbus timeout period
(parameter VME_Bus_To). Each value is stored in the
VIC64 Transfer Timeout Register (TTR). The local bus timeout period must be
shorter than the VMEbus timeout period.
Timeout = 4 microseconds
Timeout = 16 microseconds
Timeout = 32 microseconds
Timeout = 64 microseconds
Timeout = 128 microseconds
Timeout = 256 microseconds (default for local bus)
Timeout = 512 microseconds (default for VMEbus)
Timeouts disabled

Specifying the VMEbus Release Mode

You can specify one of the following values
for the release mode (parameter
VIC_Rel_Mode). The release mode value is stored in the
VIC64 Release Control Register (RCR).
Release on request, ROR (default)
Release when done, RWD

Specifying System Controller VMEbus Resets

You can specify one of the following values
to indicate whether or not the adapter
should issue VMEbus resets if it
is the system controller (parameter VIC_Syscon).

For DIGITAL AXPvme SBCs and DIGITAL Alpha VME
4/nnn and 5/nnn SBCs,
in addition to specifying a value from this list,
the configuration switches must be set accordingly to indicate whether or
not the SBC is the VMEbus system controller. See the SBC's installation guide
for information on setting the module configuration switches.

The DIGITAL Alpha VME 2100 adapter is always the VMEbus system controller.
There are no module configuration switches to disable it from being the system
controller.

There must be one and only one system controller in the VMEbus backplane.
The system controller must be electrically the first module in the VMEbus
backplane and in most systems must be in the first VMEbus slot.
Do not issue VMEbus resets if system controller
Issue VMEbus resets if system controller (default)

The values specified interact with the VMEbus initialization code to
determine whether a VMEbus reset is issued when the VMEbus adapter is being
configured. If the value is set to 1 and the system being booted is the
system controller, as determined by the VMEbus initialization code, a VMEbus
reset is issued. If you do not want a VMEbus reset issued during VMEbus
adapter configuration, set the value to zero (0). These values pertain only
to the system controller.

If the system controller is configured to issue a VMEbus reset during
adapter initialization, and other processor modules are installed in the VMEbus
backplane, boot the system controller first to allow devices and processor
modules to perform their bus reset actions.

Special Considerations for VMEbus Resets

The system controller should always be the initiator of VMEbus resets.
However, under certain error conditions, other VMEbus adapter modules may
invoke a VMEbus reset. Modules installed in the VMEbus backplane react to
bus resets differently. Some modules, if configured, perform a module reset.
Some VMEbus adapters may have their VMEbus interface reset to a powerup
state without notification to the operating system. This could leave the
VMEbus adapter in an unconfigured state, cause unwanted effects to the
operating system and its device drivers, and cause VMEbus errors to occur.
Other VMEbus adapters on the VMEbus may accept VMEbus resets and attempt to
reconfigure the VMEbus adapter to the hardware context it was running before
the bus reset occurred. However, device drivers expecting interrupts may not
receive them and I/O hardware operations may be canceled by the VMEbus reset
without notification to the device driver. There is also a potential for
data corruption to occur when the VMEbus adapter is reset during an I/O
operation.

Compaq recommends that the system controller be the initiator of
VMEbus resets during adapter initialization. If the system controller is not
controlled by a processor, then a powerup sequence should cause all VMEbus
adapters and devices to be reset. All modules on the VMEbus should perform a
module reset upon detection of a bus reset. VMEbus adapters that are not the
system controller and that are running an operating system should be shut
down in an orderly fashion prior to the system controller being booted.
These VMEbus adapters should be rebooted after the system controller has
been booted, providing the system controller is to be utilized and
controlled by a processor.

For DIGITAL Alpha VME 2100 systems, the VMEbus adapter can be the
initiator of VMEbus resets only. Upon receipt of a bus reset, its VMEbus
interface (VIC64) is reset. The reset state of the VMEbus interface (VIC64)
is not the VMEbus adapter's configured state. The operating system and
device drivers are not notified that a bus reset has occurred. If accessed
or an I/O operation is invoked following a bus reset, the access may result
in an adapter error, misoperation, or a system crash.

For DIGITAL AXPvme SBCs and DIGITAL Alpha VME
4/nnn and 5/nnn SBCs,
Compaq recommends that nodes that are not the system controller have their
module configuration switch 3 set to Closed (resets the SBC module on VMEbus
reset signal). When the VMEbus is reset, and the module switch is set to
accept a VMEbus reset, nonsystem controller modules take a boot action and
are reset to a powered state.

If the SBC module configuration switch 3 is set to Open (does not
reset the SBC module on VMEbus reset signal), the VMEbus adapter software
will receive a VMEbus reset interrupt upon detection of a bus reset. The
VMEbus reset signal initializes the VMEbus adapter (VIC64) to its powerup
state. The VMEbus reset interrupt service interface displays the following
message on the console terminal:
vba0 reset_inter: VMEbus reset detected
The interrupt service interface then initializes the VMEbus adapter to
its defaults and enables any previously enabled interrupt enable
bits.

Do not set the SBC
module configuration switch 3 to Open without considering the following side
effects of receiving a VMEbus reset: device drivers expecting interrupts may
not receive them and I/O hardware operations may be canceled by the VMEbus
reset without notification to the device drivers. There is potential risk of
data corruption depending upon I/O activity at the time a bus reset
occurred.

Specifying VMEbus Master Write Posting

Master write posting is not currently supported. Do not change the
value from the default of zero (0) or unpredictable results may occur.

You must not specify the value zero (0) if D64
master block transfers are to be performed. Unpredictable errors and
possible data corruption may result if you specify zero (0) with D64
transfers.

During the DMA interleave gap, stalled or new programmed I/O (PIO),
VMEbus IACK cycles, or slave DMAs may obtain the bus to perform the required
I/O operation. The VIC64 is enabled for dual paths to allow these I/O
operations to occur during the DMA interleave gap. Changing this parameter
arbitrarily may cause unwanted side effects.

Decreasing the value from the default increases DMA throughput.
However, as the number approaches zero (0), outstanding PIO operations,
VMEbus IACKs, and slave DMAs may be held off from obtaining the bus until
the DMA in progress is completed. These operations might have occurred
during the DMA interleave gaps if the default value had been used.

Specifying a small DMA interleave gap may result in PCI retry timeouts,
poor PIO performance, increased interrupt response time, other PCI transactions
being held off, and possible system time loss. Beware of these side effects
when specifying a new value for the DMA interleave gap.

Specifying Limits on VMEbus DMA Reads

You can specify one of the following values
to enable or disable an
8 KB limit on DMA read operations (parameter Lmt_DMA_Rd).
Placing an 8 KB limit on DMA reads can enhance throughput when the bus is busy.
Transfers relinquish the bus after each 8 KB or less.
No DMA read limit (default)
Limit DMA reads to 8 KB or less

Specifying Limits on VMEbus DMA Writes

You can specify one of the following values
to enable or disable an
8 KB limit on DMA write operations (parameter Lmt_DMA_Wrt).
Placing an 8 KB limit on DMA writes can enhance throughput when the bus is
busy. Transfers relinquish the bus after each 8 KB or less.
No DMA write limit (default)
Limit DMA writes to 8 KB or less

Specifying the DMA Method for SMP

You can specify one of the following values
to enable or disable use of the hardware DMA
engine on an SMP system (parameter Frce_Hw_DMA). Note
that in an SMP system, you would enable use of the hardware DMA engine only
if the system was known to be quiescent, with no other PIO, DMA, or
interrupt activity occurring on the bus.
Use emulated DMA on SMP system (default)
Force hardware MBLT on SMP system

Configuring VMEbus A32 and A24 Address Spaces

As part of configuring the vba_vipvic kernel subsystem, you can
configure the VMEbus 32-bit address space (A32) and 24-bit address
space (A24) for your system. A32 and A24 space are used for
direct memory access (DMA) inbound windows.

The A32 space has a maximum size of 4 GB and can be partitioned into
32 128 MB windows. You can further partition each 128 MB window in increments
as small as 16 MB. Valid window segments are 16, 32, and 64 MB.

The A24 space has a maximum size of 16 MB, and the base address is
always zero (0x00000000). This means that you can partition the address
space but cannot move it. The default window size is 4 MB and the base
address for a window must be a multiple of the window size. The default
inbound window is the top 4 MB out of the 16 MB space.

You can specify whether the A24 and A32 addresses can reside within
the same addressing range or whether they must be unique.

Specifying A32/A24 Address Space Overlapping

Read this section if the A32 direct memory access (DMA) inbound window
will be configured with a base address of zero (0x00000000), overlapping the
A24 address space. A24 inbound windows are always configured within the first
16 MB of the 4 GB VMEbus address space.

Typically, VMEbus A24 and A32 address spaces overlap each other such
that addresses in each address space are unique to that address space. As
an example, address 0x200 in A32 address space is not the same address as
0x200 in A24 address space. This is the default configuration, selected if
you leave the A24_A32_Ovrlap parameter at its default value
of 1.

You can configure some VMEbus devices to recognize the same VMEbus
address in both A24 and A32 address spaces. These devices treat the two
address spaces as a single entity. Consult the VMEbus hardware device
manuals to determine if any devices installed on the VMEbus follow this
model. If so, the autoconfiguration software must be configured to disallow
A32 direct memory access allocations within the first 16 MB of VMEbus
address space. If this is not done, an A32 direct memory access to the first
16 MB of VMEbus address space by another VMEbus device may not only select
the AXPvme or Alpha VME module but also select the device that treats the
address spaces as a single entity.

Configure the first 16 MB of VMEbus address space as a single entity
by setting the A24_A32_Overlap parameter to zero (0).

The values for overlapping and unique address spaces are listed below. These
values are valid only when the A32 and A24 address spaces are configured to
overlap each other; that is, when the A32 base address equals zero
(0x00000000).
A24 and A32 addresses must be unique
A24 and A32 addresses can overlap each other (default)

Configuring A32 and A24 Window Sizes

You can specify the DMA inbound window size for the A32 address space
(parameter A32_Size) and the A24 address space (parameter
A24_Size).

If you specify an invalid base address in relation to a window size,
the autoconfiguration code adjusts the base address to match the window size.
The base address is adjusted downward to the next appropriate boundary for
the window size.

Configuring the VMEbus A16 Address Space

As part of configuring the vba_vipvic kernel subsystem, you can
configure the VMEbus 16-bit address space (A16) for your system.
A16 space is used for interprocessor communication and to communicate with
A16 VMEbus devices.

The A16 space has
a maximum size of 64 KB and runs from VMEbus address 0000 hex to FFFF hex.
You can configure the VMEbus Interprocessor Communication Facilities (ICF)
of the DIGITAL AXPvme SBC, DIGITAL Alpha VME
4/nnn or 5/nnn SBC, or
DIGITAL Alpha VME 2100 system on any 256-byte boundary within the VMEbus A16
address space. The default base address (parameter
A16_Base) is 0x00000100. The mask value (parameter
A16_Mask) must be left at zero (0x00000000).

Configuring VMEbus Interrupts

This section addresses VMEbus interrupt request levels and how to
configure VMEbus interrupts in the software.

As the previous list indicates, DIGITAL AXPvme and Alpha VME SBCs
generate interrupt requests that higher-level interrupt requests can
preempt, while DIGITAL Alpha VME 2100 interrupt requests are all delivered
at the same SPL level and cannot be preempted.

On the DIGITAL AXPvme and Alpha VME SBCs, device drivers must use the
rt_post_callout function for interrupts delivered at
SPLDEVRT. Interrupt requests for which this is needed are VMEbus IRQ7,
Autovector IRQ7, and any of the four module switch interrupts. Device
drivers written for the SBCs that use the rt_post_callout
function will also run on the DIGITAL Alpha VME 2100 system without
modifications.

Note

VMEbus device drivers written for DIGITAL Alpha VME 2100 systems, and
other platforms that deliver VMEbus interrupts at the same SPL level, may be
affected when running these device drivers on the DIGITAL AXPvme or Alpha
VME SBC platforms. If these device drivers are using SPL levels to protect
common resources between thread and interrupt service interfaces, the
preempted interrupts of the SBC systems may have unwanted effects on these
device drivers. If these device drivers are servicing interrupts for VMEbus
IRQ7, Autovector IRQ7, or module switch interrupts, then these device
drivers must be modified to use the rt_post_callout
function. Device drivers cannot invoke normal thread wakeup mechanisms at
SPLDEVRT.

Setting VMEbus Interrupt Vector Parameters

Refer to the Autoconfiguration Support section of Writing VMEbus
Device Drivers for an
example of adding and enabling VMEbus interrupts. Refer to the
vme_handler_info structure in Writing VMEbus Device
Drivers for interrupt
handler information.

You specify vectors and interrupt
requests (IRQs) for a device driver using the
Vector and Bus_Priority fields of a
VBA_Option entry in the
/etc/sysconfigtab file or in a
sysconfigtab file fragment.

Device drivers are passed this information in the controller structure
elements ivnum and bus_priority.

VMEbus interrupt vectors 24 to 255 are available to device drivers.
Vectors 0 to 23 are reserved by the VMEbus adapter. When you specify a vector
to the Vector field of VBA_Option, you
must also use the Bus_Priority field to specify an IRQ.
Valid IRQ specifications are values 1 through 7. These values correspond
to VMEbus levels IRQ1 through IRQ7.

Note that if a VMEbus device uses an IRQ, that same IRQ cannot be used
for autovectored interrupts.

Specifying Autovector Interrupt Vectors

The DIGITAL Alpha VME 4/nnn,
5/nnn, and 2100 platforms do not support
autovectors.

VMEbus devices of the type Release of Register Access (RORA) use
autovectors. RORA devices do not have the capability of presenting a
status/ID vector as do the Release On Acknowledge (ROAK) VMEbus
devices.

RORA devices present an interrupt request to the system at a specified
VMEbus IRQ level. Upon receipt of the interrupt request, the system provides
a system-defined status/ID vector and dispatches it to the interrupt service
interface installed for the autovector. It is the responsibility of the device
driver to dismiss the RORA device's interrupt request by performing a read
or write access to the device. Refer to the hardware manual for the RORA
device to determine what type of access is needed to dismiss the interrupt
request.

To select an autovector, use the Vector and
Bus_Priority fields of VBA_Option.
Specify a vector value of zero (0) and an IRQ value of 1 through 7
corresponding to VMEbus levels IRQ1 through IRQ7.

If an IRQ is used for an autovector, the same IRQ cannot be used for
VMEbus interrupt vectors.

Specifying Module Switch Interrupt Vectors

Specify one of the following vectors
in the Vector
field of VBA_Option to select the module switch interrupt you
want. Use the Bus_Priority field to specify 7 as the IRQ
level.
Vector 0x1140
Vector 0x1150 (default)
Vector 0x1160
Vector 0x1170

Module switch interrupt vectors allow a module to issue an interrupt
to itself or to another module. The autoconfiguration software provides
control status registers (CSRs) for use in module switch interrupts. You can
specify two CSRs in a VBA_Option entry in the
/etc/sysconfigtab file or in a sysconfigtab
file fragment. At boot time, the system searches for the specified
CSRs.

The autoconfiguration software performs the appropriate bus mapping
and provides io_handle_t values in the
addr and addr2 members of the driver's
controller structure. The addr
argument is passed to the driver's probe interface, while
the addr2 value must be obtained from the addr2
member of the controller structure.

For example, the following VBA_Option entry
specifies a CSR for the base address of the A16 Interprocessor Communication
Facilities (ICF). The module switch 0 CSR is an offset from this A16
address.
VBA_Option = Csr1 - 0x100, ..., Vector - 0x1140, Bus_Priority - 7, ...
The driver structure allows you to specify the
size, address type, and swap mode for the CSRs. For example, the following
members in a driver structure indicate that the first CSR
has a size of 256 bytes, is in the A16 address space, and is set to noswap
mode:
int addr1_size 256
int addr1_atype VME_A16_SUPER_ACC | VME_BS_NOSWAP
For more information, see Writing Device Drivers: Tutorial and Writing
VMEbus Device Drivers, especially the sections on the addr and
addr2 members of the controller structure and on the
addr1_size, addr1_atype, addr2_size, and addr2_atype
members of the driver structure.

In addition, you can use the vba_map_csr function
to provide module switch interrupts. After using the
vba_map_csr function to create an I/O handle, you write
to an address derived from the base address plus an offset. Two write
operations are performed, one signifying a clear and one a set. The
following code fragment shows how the I/O handle is created:
io_handle_t ioh; /* define type of ioh */
vme_addr_t A16base=0x100; /* base CSR address */
ioh = vba_map_csr(ctlr, A16base, 256,
(VME_A16_SUPER_ACC |
VME_BS_NOSWAP));
The following code fragment shows how the module switch interrupts are
issued:
write_io_port(ioh+0x20, 1, 0, 0) /* write to A16 base address
plus the offset to clear
module switch 0 */
mb();
write_io_port(ioh+0x21, 1, 0, 0) /* write to A16 base address
plus the offset to set
module switch 0 */
mb();

Specifying Global Switch Interrupt Vectors

Global switch interrupts are not currently supported.

Using VMEbus Hardware Byte-Swap Modes

Alpha processors are little endian,
while VMEbus is big endian. The default byte-swap mode, VME_BS_NOSWAP,
causes the transfer of bytes between Alpha
processors and VMEbus to be arranged correctly. If, however, a 16-bit or
32-bit number is needed in a VMEbus register, the noswap mode rearranges the
bytes within the transfer such that the bytes are reversed in significance.
Two other modes are provided to handle these situations: VME_BS_BYTE and
VME_BS_LWORD. A third mode for swapping words within longwords,
VME_BS_WORD, is not portable across VMEbus adapters and is provided for
convenience. The definitions for these modes are in the
io/dec/vme/vbareg.h file. The flags for these modes are used in
vba_map_csr, dma_map_alloc or dma_map_load, and the
driver structure.

Sharing Memory Between Big/Little Endian Processors

In a shared memory environment, where packed data structures in common
memory are shared between an Alpha processor (little endian) and a big
endian processor, software byte swapping is required to arrange bytes
properly for 16- or 32-bit quantities (such as 16-bit counter values or
32-bit VMEbus address values).

Compaq recommends the following combination: VME_BS_NOSWAP with
software byte swapping on nonbyte data for the Alpha processor; and no
swapping on the big endian processor.

VMEbus Slave Block Transfers

The DIGITAL AXPvme and Alpha VME platforms are configured to accept
slave block transfers (SBLTs) with data widths of D16, D32, or D64 during
adapter initialization. Once the SBC has mapped its memory onto the VMEbus
by using the dma_map_alloc and
dma_map_load functions, no other user interaction is
needed.

Memory must be mapped to the VMEbus prior to D64 slave access.

Access to memory must coincide with the appropriate access mode. If
you specify supervisory mode access when memory is mapped, memory accesses
must use supervisory mode. If you specify user mode access, both supervisory
and user access are allowed.

VMEbus Master Block Transfers with Local DMA

The VMEbus interfaces for the DIGITAL AXPvme and Alpha VME platforms
provide a block-mode DMA engine. This DMA engine is capable of transferring
up to 64 KB of data without processor intervention in VMEbus data widths of
D16, D32, or D64.

The DMA engine transfers data from the VMEbus to system memory (read)
or from system memory to the VMEbus (write). The hardware interface handles
the segmentation of the transfer. This ensures that the VMEbus specification
is not violated in relation to crossing VMEbus 256-byte boundaries for D16
and D32 or 2-KB boundaries for D64.

The DMA engine is configured to give up the VMEbus during the transfer
and to rearbitrate for the VMEbus again to continue the DMA. The time between
when the DMA engine gives up the bus and rearbitrates for the bus is called
the interleave period. During the interleave period,
single-cycle VMEbus cycles, receipt of slave block transfers (SBLTs), or other
operations may be performed.

The master block transfer (MBLT) hardware interface presents address
modifiers of user block or supervisory block to the VMEbus, based on parameters
passed in the Tru64 UNIX programming interface. The device or system on
the VMEbus must be able to interpret these address modifiers; otherwise, bus
errors may occur.

You can use the MBLT hardware interface to:
Transfer data to and from those VMEbus devices that do not have their
own DMA engine
Move data between VMEbus device memory and system memory
Transfer data to and from other systems that have their memory mapped
to the VMEbus

The vba_dma interface is used to start up and
monitor the DMA engine. See the vba_dma() reference page
for information on the vba_dma calling interface.

The flag values DMA_IN and DMA_OUT have specific meaning for VMEbus
support with respect to the dma_map_alloc,
dma_map_load, and vba_dma interfaces.
These flags indicate to the low-level VMEbus
dma_map_alloc, dma_map_load, and
vba_dma interfaces that the MBLT hardware DMA engine is
to be used and the direction of the transfer.

Specifying DMA_IN implies a read from the VMEbus to system memory.
Specifying DMA_OUT implies a write from system memory to the VMEbus. You use
the vba_set_dma_addr interface to pass the flag values
and the VMEbus address at which the transfer is to occur.

The VMEbus block-mode DMA engine on the VMEbus adapter is a single entity
that must be shared among various device drivers. Specifying DMA_SLEEP causes
the device driver to block in the vba_dma interface if
the DMA engine is already being utilized. If DMA_SLEEP is not specified and
the DMA engine is being utilized, vba_dma returns an error
indication.

Restrictions on VMEbus Master Block Transfers

Several restrictions apply to using master block transfers (MBLTs) on
the DIGITAL AXPvme and Alpha VME platforms. These restrictions are listed
by data-width selection of D16, D32, and D64.
D08 (unsupported)
D16 restrictions

The VMEbus address must be longword aligned (0, 4, 8, and so forth).
The memory address must be word aligned (0, 2, 4, and so forth). The requested
byte count must be a multiple of 2.
D32 restrictions

The VMEbus address must be longword aligned (0, 4, 8, and so forth).
The memory address must be longword aligned (0, 4, 8, and so forth). The
requested byte count must be a multiple of 4.
D64 restrictions

The VMEbus address must be quadword aligned (0, 8, 16, and so forth).
The memory address must be quadword aligned (0, 8, 16, and so forth). The
requested byte count must be a multiple of 8.

The DIGITAL Alpha VME 2100 system in an SMP environment emulates DMA
transfers via PIO operations in lieu of using the MBLT hardware DMA engine.
The VMEbus adapter on this system requires three I/O accesses to be atomic to
start the DMA engine. These I/O operations cannot be guaranteed to be atomic
in an SMP environment. Uniprocessor systems use the MBLT hardware DMA engine.

Realtime Interrupt-Handling Function rt_post_callout

Interrupt service interfaces (ISIs) executing at SPLDEVRT (SPL 6) must not
call kernel interfaces directly. The rt_post_callout
function allows the calling process to defer execution of a function until a
time when kernel interfaces can be invoked. The function invoked by
rt_post_callout runs at an elevated SPL and is subject to
the same restrictions as an ISI.

The syntax for the rt_post_callout function is as
follows:
int (*function)(),
long arg1,
long arg2 );
The parameters for the rt_post_callout function are
as follows:
Name of the function to be invoked
The first argument passed to the function
The second argument passed to the function

If rt_post_callout is called again with the same
function and arguments specified, then the duplicate invocation is dismissed
before the first invocation has executed.