![[Return to Library]](BOOKSHELF.GIF)
![[Contents]](TOC.GIF)
![[Previous Chapter]](REW.GIF)
![[Next Section]](NEXT.GIF)
![[Next Chapter]](FF.GIF)
![[Index]](INDEX.GIF)
![[Help]](HELP.GIF)
This chapter discusses the hardware environment from the point of view of the device driver writer. Specifically, the chapter describes the following hardware components:
The chapter also discusses a variety of hardware activities of interest to a device driver writer.
Figure 16-1 shows the following hardware components:
Each of these components is discussed briefly following Figure 16-1.
![[Previous Section]](PREV.GIF)
The central processing unit (CPU) is the main computational unit in a computer and the one that executes instructions. The CPU is of interest to device driver writers because its associated architecture influences the design of the driver. Writing device drivers for OPENbus architectures in an open systems environment means that you may need to become familiar with a variety of CPU architectures, such as Alpha and MIPS. Section 3.1 describes the CPU issues that influence the design of device drivers.
Figure 16-1 shows that both the kernel and device drivers reside in memory, as does the kernel interrupt code that determines what driver will handle each interrupt from a device. The device driver accesses device registers (often referred to as control status register or CSR addresses) as though they were in memory; however, these registers are not really in memory but are located in the device. Figure 16-1 shows this arrangment by identifying a virtual location for the device registers. The hardware manual for the device you are writing the driver for should describe these device register addresses or offsets.
For Digital-implemented buses, the address is encoded in the form of an I/O handle. The data type io_handle_t represents this I/O handle. The I/O handle for the TURBOchannel bus represents an address that is based on the slot. The bus configuration code passes the I/O handle to the device driver through the probe interface.
A device driver that operates on the EISA, PCI, or TURBOchannel bus accesses the device registers by referencing this I/O handle in calls to read_io_port and write_io_port. See the bus-specific book to determine how the bus you are writing the driver for passes this I/O handle to the probe interface.
The bus is the path for all communication among the CPU, memory, and devices. Thus, when a device driver reads from or writes to a device's registers, the information transfer is by way of the bus. If you write device drivers for OPEN systems, you will probably need to know about a variety of buses, including the following:
There are three situations when the bus is of concern to you:
Each of these situations is briefly considered in the following sections.
For the most part, you can think of the bus as a single path, but at kernel configuration time this view is not adequate. The bus, as used in this book, includes:
When adding a device driver, you very well may be adding a device to the system. If you are, you will need to know what bus to attach its device controller to.
Digital UNIX provides the create_controller_struct and create_device_struct interfaces. These interfaces create the controller and device structures associated with your device driver. Section 6.6.4.3 shows you how to use these interfaces.
These interfaces take one argument: a controller_config structure for create_controller_struct and a device_config structure for create_device_struct. When you supply the appropriate information in these structures, the create_controller_struct and create_device_struct interface cause the bus configuration code to correctly attach device controllers to their respective buses.
When writing probe and slave interfaces, you need to consider the bus on which the driver will operate. The bus affects the formal parameters you specify for these interfaces. Section 7.1 and Section 7.4 show you how to set up probe and slave interfaces for the TURBOchannel bus. See the bus-specific driver manual to learn how to set up these interfaces for the bus your driver operates on.
Some devices are capable of directly accessing memory, generally to transfer large blocks of data. Section 16.1.4.5 discusses DMA as it relates to devices.
A device (often referred to as a peripheral device) can be a printer, an acquisition device, terminal, and so forth. Whatever the device is, it has:
Major distinctions between devices are the type of device (block, character, or network) and whether the device is capable of directly accessing memory. A direct memory access (DMA) device is one that can directly access (read from and write to) CPU memory, without CPU intervention. Non-DMA devices cannot directly access CPU memory.
The following sections briefly discuss the device registers, block and character devices, terminal devices, network devices, and DMA and non-DMA devices.
A device register is commonly referred to as a control status register, or CSR. The device register can be used to:
The device register can be in the device or in a separate controller. In most cases, the location of the device register is of no concern to the device driver writer.
The types of device registers can vary widely, depending on the device used. Most devices have multiple registers. A device register can be read-only, such as for device status or the results of an I/O operation; it can be a write-only command/control register; or it can be both readable and writeable.
It is often the case that after writing to a read/write register, the subsequent read from it will return a completely different value. The read value will be defined to be a status or result, while the write value will be command or control information to the device. In many cases, reading a control status register once will clear that register's values. A second read may, in fact, return unexpected or unwanted results. See the documentation for the device to determine if this situation exists.
Digital provides the read_io_port and write_io_port interfaces to read and write data from a device register located in the bus I/O or memory address space. These interfaces make the device driver more portable across different bus architectures, different CPU architectures, and different CPU types within the same CPU architecture.
A block device is one that is designed to operate in terms of the block I/O supported by Digital UNIX. It is accessed through the buffer cache. A block device has an associated block device driver that performs I/O by using file system block-sized buffers from a buffer cache supplied by the kernel. Block device drivers are particularly well-suited for disk drives, the most common block devices.
A character device is any device that can have streams of characters read from or written to it. A character device has a character device driver associated with it that can be used for a device such as a line printer that handles one character at a time. However, character drivers are not limited to performing I/O a single character at a time (despite the name ``character'' driver). For example, tape drivers frequently perform I/O in 10K chunks. A character device driver can also be used where it is necessary to copy data directly to or from a user process. Because of their flexibility in handling I/O, many drivers are character drivers. Line printers, interactive terminals, and graphics displays are examples of devices that require character device drivers.
A terminal device is a special type of character device that can have streams of characters read from or written to it. Terminal devices have terminal (character) device drivers associated with them. A terminal device driver is actually a character device driver that handles I/O character processing for a variety of terminal devices. Like any character device, a terminal device can accept or supply a stream of data based on a request from a user process. It cannot be mounted as a file system and, therefore, does not use data caching.
A network device is any device associated with network activities and is responsible for both transmitting and receiving frames to and from the network medium. Network devices have network device drivers associated with them. A network device driver attaches a network subsystem to a network interface, prepares the network interface for operation, and governs the transmission and reception of network frames over the network interface.
A direct memory access (DMA) device is one that can directly access
(read from and write to) CPU memory, without CPU intervention.
Non-DMA devices cannot directly access CPU memory.
The object of DMA is faster data transfer.
When character drivers perform DMA, they do it to or from the user's
address space.
When block drivers perform DMA, they do it to or from the buffer cache.
When writing device drivers, you need to consider the following hardware-related activities:
The following sections discuss each of these activities as they relate to device drivers.
Alpha CPU platforms vary in the mechanisms available to access device registers. Some platforms, such as the DEC 4000 and DEC 7000 series, use the mailbox mechanism. Other platforms, such as the DEC 3000 series, allow ``direct'' access to device registers through special address spaces. The following discussion applies to those platforms that use special address spaces.
Alpha CPUs can access longwords (32 bits) and quadwords (64 bits) atomically. However, many devices have CSRs that are only 16- or 8-bits wide. Program fragments accessing those CSRs will actually be sequences of Alpha instructions that fetch longwords and mask out bytes. For example, for adjacent 16-bit CSRs this longword access is probably not what is intended. The fetch of the longword may result in the reading of multiple CSRs, with unwanted side effects.
Devices use their registers to report status and to return data. DMA devices can move data to or from memory directly. DMA device drivers typically request this type of data transfer by:
The device requests access to memory and then manages a sequence of data transfers to memory. Upon completion of the transfer, the device:
You do not need to know the details of how the device and the bus interact to handle these transfers of data. However, you do need to know the exact register fields to use to make the request. This information should be in the hardware manual for the device.
The specifics of how interrupts are generated varies from bus to bus and even from CPU architecture to CPU architecture. The following is a general description of how interrupts are processed by the kernel on some systems. The important point to remember is that the end result of an interrupt is the calling of the device driver's interrupt handler.
When a device generates an interrupt, it also provides an interrupt index. This interrupt index is passed by the bus to the kernel assembly language interface that does initial handling of interrupts. That interface uses the interrupt index to determine which entry in the interrupt vector table contains the address of the interrupt handler for the device driver that handles this device. Among other things, the assembly language interface uses that address to transfer control to the appropriate driver. Calling the handler interfaces to dynamically register the interrupt handlers for a driver causes the interrupt handlers to be added to this table. Section 2.4 describes the methods for registering device interrupt handlers.
Only two parts of the system access hardware: