Skip Navigation Links | |
Exit Print View | |
Writing Device Drivers Oracle Solaris 11.1 Information Library |
Part I Designing Device Drivers for the Oracle Solaris Platform
1. Overview of Oracle Solaris Device Drivers
2. Oracle Solaris Kernel and Device Tree
5. Managing Events and Queueing Tasks
7. Device Access: Programmed I/O
10. Mapping Device and Kernel Memory
13. Hardening Oracle Solaris Drivers
14. Layered Driver Interface (LDI)
Part II Designing Specific Kinds of Device Drivers
15. Drivers for Character Devices
18. SCSI Host Bus Adapter Drivers
19. Drivers for Network Devices
How USB Devices Appear to the System
USB Devices and the Oracle Solaris Device Tree
Devices With Multiple Interfaces
Devices With Interface-Association Descriptors
Checking Device Driver Bindings
Before the Client Driver Is Attached
Registering Drivers to Gain Device Access
Synchronous and Asynchronous Transfers and Callbacks
Device Configuration Facilities
Multiple-Configuration Devices
Modifying or Getting the Alternate Setting
Retrieving a String Descriptor
Getting Device, Interface, or Endpoint Status
Getting the Bus Address of a Device
Part III Building a Device Driver
22. Compiling, Loading, Packaging, and Testing Drivers
23. Debugging, Testing, and Tuning Device Drivers
24. Recommended Coding Practices
B. Summary of Oracle Solaris DDI/DKI Services
C. Making a Device Driver 64-Bit Ready
The Oracle Solaris USB architecture includes the USBA 2.0 framework and USB client drivers.
The USBA 2.0 framework is a service layer that presents an abstract view of USB devices to USBA-compliant client drivers. The framework enables USBA-compliant client drivers to manage their USB devices. The USBA 2.0 framework supports the USB 2.0 specification except for high speed isochronous pipes. For information on the USB 2.0 specification, see http://www.usb.org/home.
The USBA 2.0 framework is platform-independent. The Oracle Solaris USB architecture is shown in the following figure. The USBA 2.0 framework is the USBA layer in the figure. This layer interfaces through a hardware-independent host controller driver interface to hardware-specific host controller drivers. The host controller drivers access the USB physical devices through the host controllers they manage.
Figure 20-1 Oracle Solaris USB Architecture
The USBA 2.0 framework is not a device driver itself. This chapter describes the client drivers shown in Figure 20-1 and Figure 20-2. The client drivers interact with various kinds of USB devices such as mass storage devices, printers, and human interface devices. The hub driver is a client driver that is also a nexus driver. The hub driver enumerates devices on its ports and creates devinfo nodes for those devices and then attaches the client drivers. This chapter does not describe how to write a hub driver.
USB drivers have the same structure as any other Oracle Solaris driver. USB drivers can be block drivers, character drivers, or STREAMS drivers. USB drivers follow the calling conventions and use the data structures and routines described in the Oracle Solaris OS section 9 man pages. See Intro(9E), Intro(9F), and Intro(9S).
The difference between USB drivers and other Oracle Solaris drivers is that USB drivers call USBA 2.0 framework functions to access the device instead of directly accessing the device. The USBA 2.0 framework supplements the standard Oracle Solaris DDI routines. See the following figure.
Figure 20-2 Driver and Controller Interfaces
Figure 20-2 shows interfaces in more detail than Figure 20-1 does. Figure 20-2 shows that the USBA is a kernel subsystem into which a client driver can call, just as a client driver can call DDI functions.
Not all systems have all of the host controller interfaces shown in Figure 20-2. OHCI (Open Host Controller Interface) hardware is most prevalent on SPARC systems and third-party USB PCI cards. UHCI (Universal Host Controller Interface) hardware is most prevalent on x86 systems. However, both OHCI and UHCI hardware can be used on any system. When EHCI (Enhanced Host Controller Interface) hardware is present, the EHCI hardware is on the same card and shares the same ports with either OHCI or UHCI.
The host controllers, host controller drivers, and HCDI make up a transport layer that is commanded by the USBA. You cannot directly call into the OHCI, EHCI, or UHCI. You call into them indirectly through the platform-independent USBA interface.