Portability Issues

A PC Card driver should be written so that it is portable across all Solaris platforms. This leads to easier code maintainability, easier testing, and reduced overall product costs. There are no performance advantages to be gained from writing a nonportable driver. The Solaris PCMCIA software framework makes it possible to write portable drivers without sacrificing performance.

To achieve portability, a driver needs to correctly handle the following:

• Data byte order
• Memory alignment
• Accessing memory windows
• Accessing I/O space
• Interrupts

Byte Ordering

Solaris Card Services provides a set of Common Access I/O and memory functions to insulate a driver from host byte-ordering dependencies. However, the driver writer needs to be aware of the byte ordering on the device itself. This can be specified at mapping time.

PC Card devices normally provide registers and memory interfaces in little-endian byte order. However, it is possible that a vendor may implement a PC Card with a big-endian access mode. A further concern is that a driver for a PC Card may be running on either a little-endian or a big-endian host architecture.

When establishing an I/O or memory mapping, the driver may specify either little-endian, big-endian, or "no swap" access. If, for example, a register set on a PC Card is defined to be little-endian and the driver establishes a little-endian mapping to this register set, then the driver can perform reads from or writes to the registers through the Common Access functions, maintaining proper byte order without regard to the host byte ordering.

A driver writer would normally ensure that memory or registers that represent data are not swapped. For example, data blocks on a disk may be mapped so that no swapping takes place on reads or writes.

Memory Alignment

Some platforms have alignment constraints on data. To be portable, a driver must ensure that the memory objects are properly aligned. For example, objects that are 4 bytes in size need to be aligned on a 4-byte boundary.

SPARC systems require strict alignment. x86 systems do not necessarily require strict alignment, but strict alignment is a more efficient mechanism and is a requirement for portable PC Card drivers.

Accessing Memory Windows

Driver writers should take into account that different architectures may place different restrictions on the amount of PC Card memory that can be mapped into system memory at any one time. In SPARC systems, the current SBus adapter allows mapping two 1 Mbyte windows per socket. In x86 systems, adapters vary considerably in their capabilities, depending on the adapter and

host bus type. Mappings on x86 systems that use PCIC-based adapters vary window sizes from 4 Kbytes to 16 Mbytes. However, that much physical memory may not be present on the machine.

PC Card drivers should inquire about limits and be designed to work in a smaller memory window, remapping as necessary. A driver should also check error returns because it is possible that a window of the requested size is not available. In this case, the driver would need to adjust downward.

The window mapping functions fail if the desired mapping is not possible. To avoid failure, a driver should follow these guidelines:

• Never request a specified physical address.
• Be prepared to deal with different memory window sizes, since requesting a specific memory window size might not succeed. If there are window sizes that the driver can optimize, it could request those sizes first. Typically, the driver should register a window size of 0 and let the framework choose the available window size.
• Never position a window to an arbitrary offset. A window offset must take into account window alignment and size requirements.

To be portable, a driver should access memory through the Common Access functions. Direct memory access may be possible but requires obtaining a mapped address, which some adapters may not support.

Accessing I/O Space

A PC Card driver should only access the PC Card I/O space through the Common Access functions provided by Solaris Card Services.

Despite the fact that obtaining memory-mapped or physical I/O addresses may work in a number of cases, there are many reasons for not using memory mapped or physical I/O addresses. Some architectures do not support a separate I/O address space, and the Common Access functions provide the abstraction necessary for accessing those addresses. Also, the Common Access functions hide some of the more unusual behavior of I/O on PC Cards and adapters.

csx_RequestIO(9F) and csx_RequestWindow(9F) supply a handle that (along with an I/O address offset) is used by the Common Access functions to perform the I/O operation. The Common Access functions are listed in Chapter 3, "Solaris Card Services."

Constraints on Use of I/O and Memory Windows

It is important to use only the necessary number of windows so that the driver can work in a variety of environments. For example, the current SPARC SBus adapter provides only two windows per socket; therefore, a PC Card driver that needs more than two windows will not work on a SPARC platform that uses the SBus PCMCIA adapter. The limits placed on windows also vary considerably across platforms.

Interrupts

A PC Card that needs to use an interrupt must be able to use an above lock-level interrupt to ensure that it can operate in a variety of architectures and environments. A PC Card driver must assume that interrupts are shared with other devices. There is no way to determine if interrupt sharing is possible, nor is there any way to request an exclusive interrupt. The type of interrupt available may change between card insertion and card removal.

Interrupt resources and the necessary mutexes should always be acquired and initialized at card insertion time, and these resources should then be freed at card removal time, so that other drivers may then use them.

For more information on interrupts, see Chapter 7, "PC Card Configuration."