Linux USB驱动程序基础.docx

1、Linux USB驱动程序基础Linux USB驱动程序基础来源: ChinaUnix博客 日期： 2008.04.10 23:55(共有条评论) 我要评论 （Linux USB Driver BasicsIntroductionDrivers are software components that operating systems use to providehardware specific services to applications. This webpage attempts to documentthe basics of USB drivers on Linux. The

2、 goal here is to provide you with a basicunderstanding of how USB device drivers on Linux work.The File AbstractionLinux, like other Unix derived operating systems, tries to make applicationssimpler by providing a common hardware abstraction, the File. Essentially,interactions with almost all hardwa

3、re can be abstracted into the same interfacethat the operating system provides for manipulating files. Hence, you can Opena driver, Read a driver, Write to a driver and Close a driver. Thisabstraction extends all the way into the application, who can use the samesystem calls that it uses to open and

4、 manipulate files to talk to hardware.The way this works is that the kernel creates nodes in the file system,typically located in /dev that represent a particular interface to a driver. Totalk to a particular driver an application will open the /dev entry associatedwith that driver. The file descrip

5、tor returned by that open is passed to allfuture system calls (read, write, select), and is eventually passed toclose.Besides drivers, Unix also uses this file paradigm for various differentkinds of IPC, and even for socket communications over a network.It is quite surprising how many completely dif

6、ferent kinds of hardware can bemodeled with just 4 operations (open, close, read and write). That said, theiris another very important system call that unix applications developers commonlyuse, select(). The select() system call allows applications to poll anddetermine whether data could be read fro

7、m, or written to a file descriptorwithout blocking.Sometimes a piece of hardware provides some functionality that doesnt fitwell into this file centric paradigm. To allow for this, unix applicationstypically make use of the ioctl() system call. This call takes a numeric valuethat is essentially an i

8、dentifier for a specific piece of functionality in thedriver.The Job of the Device DriverSimply stated, it is the job of the driver to provide functions that thekernel can use to implement this file programming paradigm. Applications do notdirectly call functions in the driver, instead they call fun

9、ctions in libc thateventually call into the kernel (via the system call interface). The kernelimplementations of these system calls call into your driver.As you might expect, this means that youre going to be implementating open,close, read and write inside your driver. To implement select(), the ke

10、rnelneeds you to implement a method in your driver called poll(). Other than these,their are only a handfull of other functions that need to be implemented, andyou have a driver!Loading a DriverLinux supports essentially two kinds of driver development models: 1)Compiled into the kernel, 2) Dynamica

11、lly loadable driver modules. If configuredproperly, option 2 has the advantage that drivers can be loaded automatically bythe kernel only when they are actually needed to service an application request.Option 1 presents a logically cleaner, and slightly faster scenario.The choice is up to you. That

12、said, we will now cover the basics of loadingand unloading a kernel module into a running kernel.First, understand that a Linux kernel driver cannot be dynamically linkedagainst any librarys (not even libc, which many programmers dont even know theyare linking against). The only code external to you

13、r driver that your allowed tomake use of are functions that are implemented within the kernel. In fact,kernel modules are never Linked, instead they are relocatable object files,.os or sometimes .kos.The following command is used to install a driver into a running kernel:tdobjective $ insmod driver.

14、ko The following command is used to show what drivers are currently loaded intothe kernel:tdobjective $ lsmodModule Size Used bymd5 4033 1ipv6 263105 22ipt_REJECT 5441 1ipt_state 1857 5ip_conntrack 41369 1 ipt_stateiptable_filter 2881 1ip_tables 19521 3 ipt_REJECT,ipt_state,iptable_filtervideo 15685

15、 0button 4033 0battery 9285 0ac 4805 0uhci_hcd 35025 0ehci_hcd 40013 0hw_random 5973 0i2c_i801 8653 0i2c_core 21313 1 i2c_i801snd_intel8x0 34177 0snd_ac97_codec 74937 1 snd_intel8x0snd_pcm_oss 50673 0snd_mixer_oss 17729 1 snd_pcm_osssnd_pcm 98889 3 snd_intel8x0,snd_ac97_codecsnd_timer 32837 1 snd_pc

16、msnd 57285 6 snd_intel8x0,snd_ac97_codecsoundcore 10785 1 sndsnd_page_alloc 9669 2 snd_intel8x0,snd_pcme1000 102573 0dm_snapshot 17413 0dm_zero 2113 0dm_mirror 25645 0ext3 130633 2jbd 83161 1 ext3dm_mod 57333 6 dm_snapshot,dm_zero,dm_mirrorata_piix 9413 0libata 46917 1 ata_piixsd_mod 20289 0scsi_mod

17、 146313 2 libata,sd_mod The following command is used to remove a driver from a running kernel:tdobjective $ rmmod driver.ko Since you never link your driver, you will not know about unresolved symbolsuntil you actually load your driver into the kernel. It is during the insmodprocess that the kernel

18、 binds all of the calls to kernel functions in your codeto their actual current locations in memory. This process is called resolvingsymbol dependancies.Understanding the Universal Serial BusFrom the highest levelAs Im sure you know from your own use of USB, the USB bus, besides offeringcommunicatio

19、ns also offers power to devices connected to it. The USB can offerup to 500mA for the devices connected to it. Devices that need more than thiscan be self powered.Besides this, your probably aware of the fact that the USB can be expandedwith hubs.How hardware is about to make your life easierThankfu

20、lly, your driver will not have to communicate directly on theUniversal Serial Bus. Instead, your driver will communicate to the USB hostcontroller, which will communicate on the bus on your behalf. The USB hostcontroller is a piece of hardware that acts as a focal point for all of theCPUs interactio

21、n with the USB hardware. It hides most of the complexity ofdealing with USB and also protects the USB hardware from potentially badlywritten driver software that might otherwise affect the whole bus.Their are two kinds of host controller hardware commonly in use, UHCI(Universal Host Controller Inter

22、face) and OHCI (Open Host Controller Interface).The good news is that both of these host controllers present the same interfaceto your driver, so you really dont have to care about what kind of hostcontroller hardware is present. As you might expect, UHCI & OHCI hardwarehas its own driver, that than

23、kfully you will not need to touch. It will be thejob of your driver to communicate (indirectly) with the host controller driver,to configure, read from or write to devices on the USB.Types of Communications on the USBUSB devices have the full range of different speed, latency and reliabilityrequirem

24、ents. Things like mice and keyboard transfer only small amounts of data,relatively rarely, but they care a lot about latency. No one like a slowkeyboard.On the other hand, USB webcams often transfer compressed MPEG video, which isextremely high bandwidth, but because MPEG was designed to be transmit

25、ted overlossy communications channels, it is OK if the occasional packet is lost.To support these differing requirements, USB supports a number ofcommunications types.Control Transfers- Control transfers are used when you needreliable (the data MUST get their) communications and you are sending a ve

26、rysmall amount of data. Essentially, these transfers are commands, and their are afew commands that every device is required to support (GET_STATUS,CLEAR_FEATURE, SET_FEATURE, SET_ADDRESS, GET_DESCRIPTOR, SET_DESCRIPTOR,GET_CONFIGURATION, SET_CONFIGURATION, GET_INTERFACE, SET_INTERFACE,SYNCH_FRAME).

27、 Bulk Transfers- Bulk transfers are used when you needreliable (the data MUST get their) communications and you are sending largeamounts of data. Interrupt Transfers- Interrupt transfers are simmilar tobulk transfers except they are configured to occur automatically at someinterval. These types of t

28、ransfers are useful for devices that stream constantdata of the USB. Isochronous Transfers- Isochronous transfers are very fast,and have guaranteed bus bandwidth, but they have no reliability. This transfertype seems to have been designed with MPEG in mind.The code that you write is going to have to

29、 specify to the host controllerwhat types of communcations you want to use. Thankfully, an extremely wide rangeof device types fit nicely into the above types of data transfers.The heirarchical view of the USBIf you think about what I have described so far, it should be fairly apparentthat since you

30、 will be dealing only indirectly with actual USB devices andinstead be communicating through a host controller, that host controller musthave some kind of data model for the devices that are connected to it on the USBbus. It must present some description of the devices connected, and theircapabiliti

31、es.The capabilites of a USB device are modeled heirarchically by the hostcontroller. Your driver will communicate to a USB device by making requests tonodes of this heirarchy. To fully understand the reasoning for all of the layersof the heirarchy I am about to tell you about please consider how generic a hostcontroller must be, given how wide ranging the functionality of USB hardware canbe.When a USB is first plugged into the bus it is detected by the hostcontroller. The host controller sends it the GET_DESCRIPTOR command andretrieves what is called the device descr