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:
blockdevicesbusdriversclasspowerfirmware 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 allMinimal supportExtended support13.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
