《Understanding the Linux kernel》学习笔记 Chapter 13: I/O Architecture and Device Drivers

13.1 I/O Architecture

Any I/O device is hosted by one, and only one, bus.

The data path that connects a CPU to an I/O device is generically called an I/O bus.

The I/O device by means of a hierarchy of hardware components including up to three elements: I/O ports, interfaces, and device controllers.

13.1.1 I/O Ports

Each device connected to the I/O bus has its own set of I/O addresses, which are usually called I/O ports.

Four special assembly language instructions called in, ins, out, and outs allow the CPU to read from and write into an I/O port.

Accessing I/O ports

inb(), inw(), inl()

inb_p(), inw_p(), inl_p()

outb(), outw(), outl()

outb_p(), outw_p(), outl_p()

insb(), insw(), insl()

outsb(), outsw(), outsl()

13.1.2 I/O Interfaces

An I/O interface is a hardware circuit inserted between a group of I/O ports and the corresponding device controller.

There are two types of interfaces:

• Custom I/O interfaces (Keyboard interface, Graphic interface, Disk interface, Bus mouse interface, Network interface)
• General-purpose I/O interfaces (Parallel port, Serial port, PCMCIA interface, SCSI interface, Universal serial bus)

13.1.3 Device Controllers

A complex device may require a device controller to drive it. Essentially, the controller plays two important roles:

• It interprets the high-level commands received from the I/O interface and forces the device to execute specific actions by sending proper sequences of electrical signals to it.
• It converts and properly interprets the electrical signals received from the device and modifies (through the I/O interface) the value of the status register.

13.2 The Device Driver Model

13.2.1 The sysfs Filesystem

The sysfs filesystem is a special filesystem similar to /proc that is usually mounted on the /sys directory.

A goal of the sysfs filesystem is to expose the hierarchical relationships among the components of the device driver model. The related top-level directories of this filesystem are:

• block
• devices
• bus
• drivers
• class
• power
• firmware

Relationships between components of the device driver models are expressed in the sysfs filesystem as symbolic links between directories and files.

The main role of regular files in the sysfs filesystem is to represent attributes of drivers and devices.

13.2.2 Kobjects

Kobjects, ksets, and subsystems

Registering kobjects, kests, and subsystems

13.2.3 Components of the Device Driver Model

Devices

Each device in the device driver model is represented by adevice object.

The device objects are globally collected in the devices_subsys subsystem, which is associated with the /sys/devices directory. The devices are organized hierarchically: a device is the "parent" of some "children" devices if the children devices cannot work properly without the parent device.

The device_register() function inserts a new device object in the device driver model, and automatically creates a new directory for it under /sys/devices. Conversely, the device_unregister() function removes a device from the device driver model.

Drivers

Each driver in the device driver model is described by adevice_driver object.

The driver_register() function inserts a new device_driver object in the device driver model, and automatically creates a new directory for it in the sysfs filesystem. Conversely, the driver_unregister() function removes a driver from the device driver model.

Buses

Each bus type supported by the kernel is described by abus_type object.

Classes

Each class is described by a class object.

13.3 Device Files

The mknod() system call is used to create device files. It receives the name of the device file, its type, and the major and minor numbers as its parameters. Device files are usually included in the /dev directory.

13.3.1 User Mode handling of Device Files

Dynamic device number assignment

Dynamic device file creation

13.3.2 VFS Handling of Device Files

13.4 Device Drivers

A device driver is the set of kernel routines that makes a hardware device respond to the programming interface defined by the canonical set of VFS functions (open, read, lseek, ioctl, and so forth) that control a device.

13.4.1 Device Driver Registration

Registering a device driver means allocating a newdevice_driver descriptor, inserting it in the data structures of the device driver model, and linking it to the corresponding device file(s).

If a hardware device that can be handled by the driver is discovered, the kernel allocates a device object and invokes device_register() to insert the device in the device driver model.

13.4.2 Device Driver Initialization

Initializing a driver means allocating precious resources of the system, which are therefore not available to other drivers.

13.4.3 Monitoring I/O Operations

Polling mode

According to this technique, the CPU checks (polls) the device's status register repeatedly until its value signals that the I/O operation has been completed.

Interrupt mode

Interrupt mode can be used only if the I/O controller is capable of signalling, via an IRQ line, the end of an I/O operation.

13.4.4 Accessing the I/O Shared Memory

13.4.5 Direct Memory Access (DMA)

Synchronous and asynchronous DMA

A device driver can use the DMA in two different ways called synchronous DMA and asynchronous DMA. In the case, the data transfers are triggered by processes; in the second case, the date transfers are triggered by hardware devices.

Helper functions for DMA transfers

Bus addresses

Cache coherency

Helper functions for coherent DMA mappings

Helper functions for streaming DMA mappings

13.4.6 Levels of Kernel Support

There are three possible kinds of support for a hardware device:

• No support at all
• Minimal support
• Extended support

13.5 Character Device Drivers

13.5.1 Assigning Device Numbers

13.5.2 Accessing a Character Device Driver

13.5.3 Buffering Strategies for Character Devices