Linux USB drivers by Satyam

USB driversUSB core driversArchitecture independent kernel subsystem. Implements the USB bus specification.USB host driversDifferent drivers for each USB control hardware. Usually available in the Board Support Package. Architecture and platform dependent.USB device driversDrivers for devices on the USB bus.USB device controller driversFor Linux systems with just a USB device controller

USB gadget driversPLATFORM DEPENDENTSupports the chip connecting to the USB bus.

PLATFORM INDEPENDENTEthernet gadget: implements networking through USBStorage gadget: makes the host see a USB storage device

USB SUPPORT ARCHITECTURE SUPPORT

USB device driverUSB Core

USB host controller

SYSTEM CALL INTERFACE

Other drivers

Hardware (USB DEVICE)

USER APPLICATION USERSPACE

KERNAL

TYPES OF USB HOST CONTROLLER1. OHCI ( Open Host Controller Interface): ->Compaq’s 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.

USB transfer speedLow Speed: up to 1.5 Mbps Since USB 1.0

Full Speed: up to 12 Mbps Since USB 1.1

Hi Speed: up to 480 Mbps Since USB 2.0

USB descriptorsDevice 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).

TYPES OF ENDPOINTSControl 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.

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.

The urb structure

PIPES FOR URB’sControl pipesusb_sndctrlpipe(), usb_rcvctrlpipe()

Bulk pipesusb_sndbulkpipe(), usb_rcvbulkpipe()

Interrupt pipesusb_sndintpipe(), usb_rcvintpipe()

Isochronous pipesusb_sndisocpipe(), usb_rcvisocpipe()

Creating an URB’sstruct urb *usb_alloc_urb(int isoframes, int mem_flags)Allocating URB’s isoframes->for isochronous transfer,’0’ for othersmem_flags->holds the memory allocation flag which allows to control the block

Note: we must do the error handling if allocation fails it returns NULLEg:urb = usb_alloc_urb(0, GFP_KERNEL); if(urb!=0) printk(KERN_ALERT “Allocation failed”);

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 .

Initializing urb’s

interrupt urbs

bulk urbs

control urbs

isochronous urbs(has to be done manually by driver,no function available).

Function for Initilizing URB’svoid usb_fill_int_urb (struct urb *urb, // urb to be initializedstruct usb_device *dev, // device to send the urb tounsigned int pipe, // pipe (endpoint and device specific) void*transfer_buffer, //transferbufferint buffer_length, // transfer buffer size usb_complete_t complete, // completion handlervoid *context, // context (for handler)int interval // Scheduling interval (for interrupt URB’s)unsigned char *setup_packet;//for control urbs

interval->low speed in ms/high speed in (1/8)ms

SUBMITTING URB’sint 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.

Return Values-usb_sumit_urbOut 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 lookintounless we get a completion call.

Cancelling URB’s

There are two ways->asynchronous cancel: int usb_unlink_urb(struct urb *urb);->synchronously cancel: void usb_kill_urb(struct urb *urb);

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

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.

Writing USB driverschecking 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)

Declaring supported devicesUSB_DEVICE(vendor, product)

Creates a usb_device_id structure which can be used tomatch only the specified vendor and product ids.

Created usb_device_id structures are declaredwith the MODULE_DEVICE_TABLE() macro

Drivers need to announce the devices they support in usb_device_id structures.

Driver Registrationusb_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);}

Driver unregistration

usb_deregister() to register your driver

static void __exit mtouchusb_cleanup(void){ usb_deregister(&mtouchusb_driver);}

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 clean up.

Transfering without URB’s

The kernel provides two usb_bulk_msg()and usb_control_msg() helper functions that make it possible to transfer simple bulk and control messages

Constrains of transfering without URB’s

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

Thank you