Features and Mode of Operation

There are three versions of the USB standard. The most important are the first version (1.0) and its successor (1.1), as most hardware has adopted this standard. The more recent version (2.0) is designed to eliminate the speed disadvantages of USB as compared with other external buses (primarily FireWire), and is nowadays in widespread use. Kernel support is available for both protocols. The in-kernel data structures employed to manage devices are identical for all versions, and since I will concentrate on these in the following, I will not be much concerned with the technical differences between the different versions of the standard.

What are the special features of USB as compared to other buses? In addition to ease of use for end-users, mention must be made of the topological structure used to sort attached devices, which is reminiscent of network structures. Starting from a single root controller, devices are connected via hubs in a tree-like structure, as illustrated in Figure 6-24. Up to 127 terminal devices can be attached to a system in this manner.

Figure 6-24: Topology of a USB system.

A device is never connected directly to the host controller but always via a hub. To ensure that drivers have a uniform view of the situation, the kernel replaces the root controller with a small emulation layer so that the rest of the system sees the controller as a virtual hub; this simplifies the development of drivers.

The fact that the devices in a USB system are physically arranged in a tree structure is only of relevance to specific parts of the USB subsystem. The drivers for terminal devices need not concern themselves with whether a device is connected directly to the root hub or via five intervening hubs. Each device on the bus is assigned a unique number for communication purposes, and, as a result, the USB driver sees all devices as being connected directly to the root hub. The right-hand part of Figure 6-24 shows the logical view of the structure as seen by a device driver.

USB is not explicitly tied to a specific processor or system architecture but can, in principle, be used on all platforms — even if, as usual, the PC platform is primarily responsible for the popularity of the bus. Because USB interfaces are also available as PCI plug-in cards (which, as standard, use a motherboard chip connected to the PCI system bus via a bridge), all architectures that support PCI cards (in the main, Sparc64, Alpha, etc.) are automatically able to support USB.

Due care should be exercised when using the term device in the context of USB because it splits into three levels.

□ A device is anything that the user can connect to the USB bus — for example, a videocamera with integrated microphone or the like. As this example shows, a device may consist of several function units that can be controlled by different drivers.

□ Each device is made up of one or more configurations that govern the global characteristics of the device. For instance, a device may feature two interfaces, one of which is used if power is supplied from the bus, the other if an external power supply is used.

□ In turn, each configuration consists of one or more interfaces, each of which provides different setting options. Three interfaces are conceivable for a videocamera — microphone only enabled, camera only enabled, or both enabled. The bandwidth requirements of the device may differ according to the interface selected.

□ And finally, each interface may have one or more end points that are controlled by a driver. There are situations in which a driver controls all end points of a device but each end point may require a different driver. In our example above, the end points are the imaging video unit and the microphone. Another common example of a device with two different end points is a USB keyboard that integrates a USB hub to permit the connection of other devices (a hub is ultimately a special kind of USB device).

All USB devices are classified in categories; this is reflected in the fact that the source code for the individual drivers is kept separate in the kernel sources. drivers/usb/ contains a number of subdirectories with the following contents:

□ image for graphics and video devices such as digital cameras, scanners, and the like.

□ input for input and output devices for communication with computer users. Classic representatives of this category include not only keyboards and mice but also touch screens, data gloves, and the like.

□ media for the numerous multimedia devices that have come to the fore in the last few years.

□ net for network cards that are attached to the computer by means of USB and are therefore often referred to as adapters that bridge the gap between Ethernet and USB.

□ storage for all mass storage devices such as hard disks and the like.

□ class includes all drivers support devices of one of the standard classes defined for USB.

□ core contains drivers for host adapters to which a USB chain is attached.

Roughly speaking, the driver sources originate from the following three areas: standard devices such as keyboards, mice, and the like that can always be supported by the same driver, regardless of device vendor; proprietary hardware such as MP3 players and other gadgets that require special drivers; and drivers for host adapters that are attached to the rest of the system via a different bus system (typically PCI) and that establish the connection (also physical) to the USB device chain.

The USB standard defines four different transfer modes, each of which must be explicitly catered for by the kernel.

□ Control transfer involves the transfer of control information needed (primarily) for the initial configuration of a device. This type of communication must be safe and reliable but requires only a narrow bandwidth. The various control commands are transferred by means of pre-defined tokens whose symbolic names such as get_status, set_interface, and so on have been defined and documented in the USB standard. In the kernel sources they can all be found in <usb.h>, where they are prefixed with usq_req_ — to prevent namespace problems — and declared as pre-processor constants. The standard mandates a minimum set of commands that all devices must understand. However, vendors are free to add further device-specific commands that must be used and understood by their own drivers.

□ Bulk transfers send individual data packets that can take up the full bus bandwidth. In this mode, data transfer takes place with the security guaranteed by the bus; in other words, data sent always reach their destination unchanged.24 Devices such as scanners or mass storage expansions use this mode.

□ Interrupt transfers are similar to bulk transfers but are repeated at periodic intervals. The interval length can be freely defined (within certain limits) by the driver. This transfer mode is used by preference by network cards and similar devices.

□ A special role is played by isochronous transfer as this is the only way of setting up a transfer that although unreliable makes use of a fixed, pre-defined bandwidth (in certain respects, this mode can be compared with the datagram technique for network cards as discussed in Chapter 12). This transfer mode is best used in situations where it is important to guarantee a continuous data stream and where the occasional loss of data is acceptable. A prime example of where this mode is used are Webcams that send video data via the USB bus.

Continue reading here: Management of Drivers

Was this article helpful?

0 0