Linux Usb overview
- 1. Linux USB drivers by Satyam
- 2. USB drivers USB core drivers Architecture independent kernel subsystem. Implements the USB bus specification. USB host drivers Different drivers for each USB control hardware. Usually available in the Board Support Package. Architecture and platform dependent. USB device drivers Drivers for devices on the USB bus. USB device controller drivers For Linux systems with just a USB device controller
- 3. USB gadget drivers PLATFORM DEPENDENT Supports the chip connecting to the USB bus. PLATFORM INDEPENDENT Ethernet gadget: implements networking through USB Storage gadget: makes the host see a USB storage device
- 4. USB SUPPORT ARCHITECTURE SUPPORT USB device driver USB Core USB host controller SYSTEM CALL INTERFACE Other drivers Hardware (USB DEVICE) USER APPLICATION USERSPACE KERNAL
- 5. TYPES OF USB HOST CONTROLLER 1. OHCI (Open Host Controller Interface): ->Compaqs implementation for USB 1.0 and USB 1.1 ->Also used for some firmware devices 2.UHCI (Universal Host Controller Interface): ->Intel implementation for USB 2.0 3.EHCI (Extended Host Controller Interface): ->Only one to provide high speed transfer (USB 2.0) 4.SL811 ->host controller, manufactured by Cypress. ->It has 256MB of internal SRAM buffer.
- 6. USB transfer speed LowSpeed: up to 1.5 Mbps Since USB 1.0 FullSpeed: up to 12 Mbps Since USB 1.1 HiSpeed: up to 480 Mbps Since USB 2.0
- 7. USB descriptors Device Represent the devices connected to the USB bus. Example: USB speaker with volume control buttons. Configurations Represent the state of the device. Examples: Active, Standby, Initialization Interfaces Logical devices. Examples: speaker, volume control buttons. Endpoints Unidirectional communication pipes. Either IN (device to computer) or OUT (computer to device).
- 8. TYPES OF ENDPOINTS Control endpoints: device control, accessing information, small transfers. Guaranteed bandwidth. Interrupt endpoints: data transfer at a fixed rate. Guaranteed bandwidth. Bulk endpoints: use all remaining bandwidth. No bandwidth or latency guarantee. Isochronous endpoints:guaranteed speed. Possible data loss.
- 9. USB Request Blocks(URB) An URB consists of all relevant information to execute any USB transaction Any communication between the host and device is done asynchronously using USB Request Blocks (urbs). They are similar to packets in network communications. Every endpoint can handle a queue of urbs. Every urb has a completion handler. A driver may allocate many urbs for a single endpoint, or reuse the same urb for different endpoints.
- 11. PIPES FOR URBs Control pipes usb_sndctrlpipe(), usb_rcvctrlpipe() Bulk pipes usb_sndbulkpipe(), usb_rcvbulkpipe() Interrupt pipes usb_sndintpipe(), usb_rcvintpipe() Isochronous pipes usb_sndisocpipe(), usb_rcvisocpipe()
- 12. Creating an URBs struct urb *usb_alloc_urb(int isoframes, int mem_flags) Allocating URBs isoframes->for isochronous transfer,0 for others mem_flags->holds the memory allocation flag which allows to control the block Note: we must do the error handling if allocation fails it returns NULL Eg:urb = usb_alloc_urb(0, GFP_KERNEL); if(urb!=0) printk(KERN_ALERT Allocation failed);
- 13. Freeing URB void usb_free_urb(struct urb *urb); Note : if the allocation dint return a completion call back or not been use it can deallocate by itself .
- 14. Initializing urbs interrupt urbs bulk urbs control urbs isochronous urbs(has to be done manually by driver,no function available).
- 15. Function for Initilizing URBs void usb_fill_int_urb ( struct urb *urb, // urb to be initialized struct usb_device *dev, // device to send the urb to unsigned int pipe, // pipe (endpoint and device specific) void*transfer_buffer, //transferbuffer int buffer_length, // transfer buffer size usb_complete_t complete, // completion handler void *context, // context (for handler) int interval // Scheduling interval (for interrupt URBs) unsigned char *setup_packet;//for control urbs interval->low speed in ms/high speed in (1/8)ms
- 16. SUBMITTING URBs int usb_submit_urb(struct urb *urb, int mem_flags) mem_flags is used for internal allocations performed by usb_submit_urb(). Settings that should be used: GFP_ATOMIC: called from code which cannot sleep: a urb completion handler, hard or soft interrupts. Or called when the caller holds a spinlock. GPF_NOIO: in some cases when block storage is used. GFP_KERNEL: in other cases.
- 17. Return Values-usb_sumit_urb Out of memory (-ENOMEM) Unplugged device (-ENODEV) Stalled endpoint (-EPIPE) Too many queued ISO transfers (-EAGAIN) Too many requested ISO frames (-EFBIG) Invalid INT interval (-EINVAL) More than one packet for INT (-EINVAL) however on submissmision urb->status will be -EINPROGRESS,it is suggested that we should not lookinto unless we get a completion call.
- 18. Cancelling URBs There are two ways ->asynchronous cancel: int usb_unlink_urb(struct urb *urb); ->synchronously cancel: void usb_kill_urb(struct urb *urb);
- 19. Completion Handlers After the data transfer successfully completed. urb->status == 0 Error(s) happened during the transfer. The urb was unlinked by the USB core. urb>status should only be checked from the completion handler
- 20. Some of the Transfer Status ECONNRESET: The urb was unlinked by usb_unlink_urb(). ENOENT: The urb was stopped by usb_kill_urb(). ENODEV: Device removed. Often preceded by a burst of other errors, since the hub driver doesn't detect device removal events immediately. EINPROGRESS:Urb not completed yet.
- 21. Writing USB drivers checking which device support which driver. passing the information from the user space to find the right driver during hot-plug event. driver needs to call right probe function and disconnect function. All these information can be derived from usb_device_id structure. (include/linux/mod_devicetable.h)
- 22. Declaring supported devices USB_DEVICE(vendor, product) Creates a usb_device_id structure which can be used to match only the specified vendor and product ids. Created usb_device_id structures are declared with the MODULE_DEVICE_TABLE() macro Drivers need to announce the devices they support in usb_device_id structures.
- 23. Driver Registration usb_register() to register our driver static struct usb_driver mtouchusb_driver = { .name = "mtouchusb", .probe = mtouchusb_probe, .disconnect = mtouchusb_disconnect, .id_table = mtouchusb_devices, }; static int __init mtouchusb_init(void) { return usb_register(&mtouchusb_driver); }
- 24. Driver unregistration usb_deregister() to register your driver static void __exit mtouchusb_cleanup(void) { usb_deregister(&mtouchusb_driver); }
- 25. probe() and disconnect() functions The probe() function is called by the USB core to see if the driver is willing to manage a particular interface on a device. The driver should then make checks on the information passed to it about the device. If it decides to manage the interface, the probe() function will return 0. Otherwise, it will return a negative value. The disconnect() function is called by the USB core when a driver should no longer control the device (even if the driver is still loaded), and should do some cleanup.
- 26. Transfering without URBs The kernel provides two usb_bulk_msg() and usb_control_msg() helper functions that make it possible to transfer simple bulk and control messages
- 27. Constrains of transfering without URBs These functions are synchronous and will make our code sleep We cannot cancel our requests, as we have no handle on the URB used internally
- 28. Thank you