Linux Device Driver subsystem-USB

Source: Internet
Author: User

0. Preparation Theory

1. USB core

2. USB Hub

3. USB OTG

4. USB Host

5. USB Gadget

6. USB Mass Storage

USB is extensive and profound, not explained in one or two blog posts. To study USB in depth, the USB protocol (plus host and OTG protocols) is necessary. In addition, the fudan_abc <USB matters> in China is also well written and detailed. The only drawback is that it is too detailed, but it seems that the idea architecture is not very clear, I am not very knowledgeable. I want to simply sort out the structure framework of USB in Linux, and focus on the analysis of USB core and hub.

0. Preparation Theory

To be honest, reading the protocol is still quite painful. It is just a protocol, a game rule made in the USB world, just like the legal provisions, it is not written for learners, poor readability. Here we will summarize the following key points.

0.1 topology (ch4.1.1)

 

 

  • This tree-like topology is required to avoid annular connections.
  • One USB bus has only one USB host, corresponding to one roothub
  • There are two types of USB devices: hub and functions. hub connects to more USB devices through Port port. functions is an external USB slave device.
  • A maximum of 7 levels, and no hub or functions are available for layer 7th.
  • Compound device-a hub is connected to multiple devices to form a small device.
  • Composite device-a USB external device has multiple reuse functions.

0.2 mechanical properties (CH5)

  • The connection connector is the connection interface on the device.
  • Plug is the plug at both ends of the USB cable.
  • Mini-AB and micro-AB are connectors supporting plug a and plug B.

0.3 electrical performance (ch6)

  • Vbus-+ 5 V power supply.
  • D + d--cables used for data transmission.
  • Low-speed low-speed 10-100kb/s for mouse and keyboard
  • Full-speed 500kb-10mbit/s for audio and microphone applications
  • High-speed 25-400 Mb/s for storage and video (10 times that of USB)

0.4 four Descriptors (ch9.5)

The Protocol specifies four USB descriptors: descriptor-device, configure, interface, and endpoint.

Enter the command # ls/sys/bus/USB/devices

Usb1
1-0: 1. 0
Usb2
2-. 0 // USB Bus (roothub) No. 2, USB port number no.0, configuration number No.1, and interface number no.0.

  • The difference between a port and an endpoint is that an endpoint is required by each USB device for data transmission.
  • Device> Configure> interface> setting> endpoint.
  • A device can have multiple configurations, one or more interfaces, and one or more interfaces.
  • An interface corresponds to a driver, which is a set of endpoints.

0.5 START process (ch9.1, 9.2)

 

  • Attached-> powered-> default-> address-> configured
  • The main difference between the startup process and other devices, such as the SD card, is the hub. The host determines whether the USB external device is available based on the changes in the hub status.
  • The whole implementation process of USB external device insertion and removal is called Bus enumeration bus enumeration.

0.6 data stream transmission (CH5)

  • The endpoint is divided into zero endpoint and non-zero endpoint. The zero endpoint is used as the default control method to initialize and manipulate the USB logical device.
  • Data Stream Transmission is divided into control/bulk/interrupt/isochronous data transfer.

0.7 data packets (ch8)

  • Data packets are divided into four types: Token, Data, handshake, and special, which have their own data organization methods.
  • The token package can only be sent to the device by the host, including in, out, Sof, and setup.
  • The setup package allows the host to send a request to the device in a specific format. (Ch9.3, 9.4)

1. USB core

I would like to answer a question that has plagued me for a long time. To what extent should I read the Linux source code? This is an eternal topic. Everyone in the same path has his own opinions. In my opinion, how to read the source code mainly depends on my career positioning, whether it is R & D or development, whether it is contributing to the Linux community or using the existing solution development? I think most of the driver engineers belong to the latter. Is there any need to look at the well-developed source code of the core layer, or is it necessary to study it in depth? I think that since we have already stood on the shoulders of giants, we should at least know how the wide shoulders are made, the value of their existence, and how to use them.

In this case, what is the USB core layer and what it does silently? How should we use it? There are two main points here: USB bus and urb.

1.1 USB subsystem structure

In the protocol, HCD provides hardware abstraction driven by the master controller. It is only responsible for the USB core. The USB core maps user requests to the relevant HCD, and users cannot directly access HCD. In other words, USB core is the only bridge between HCD and USB devices.

1.2 USB subsystem Initialization

The source code of the USB core is located in./Drivers/USB/core. The makefile digest is as follows,

The USB core module represents not a certain device, but the survival module of all USB devices. It is the USB subsystem.

./Drivers/USB/CORE/USB. c implements initialization. The pseudocode is as follows,

USB core is registered with USB bus, USB file system, USB hub and USB device driver USB Generic Driver.

1.3 USB Bus

Register the USB bus through bus_register (& usb_bus_type );

Struct bus_type usb_bus_type = {
. Name = "USB ",
. Match =Usb_device_match, // This is an important function used to match USB devices and drivers.
. Uevent = usb_uevent,
. PM = & usb_bus_pm_ops,
};
Next, we will summarize the entire process of matching USB devices and drivers,

-> Step 1-USB device driver

When the USB subsystem is initialized, it registers usb_generic_driver. Its struct type is usb_device_driver. It is the only USB device driver in the USB world, which is different from the USB driver of struct usb_driver.

  • There is only one USB device driver, that is, the usb_generice_driver object. All USB devices must be bound to usb_generic_driver. Its mission can be summarized as follows: select an appropriate configuration for the USB device to bring the device to the CONFIGURED state.
  • USB driver is the interface driver of a USB device, such as the ADB driver, USB flash drive, and mouse driver.

-> Step 2-USB driver

 

When Linux is started, the USB driver is registered. In xxx_init (), the USB driver is submitted to the device model through usb_register () and added to the driver chain table of the USB bus.

-> Step 3-USB device

The USB device is connected to the hub. The Hub detects that a device is connected, assigns a struct usb_device struct object to the device, and adds the device to the device list of the USB bus.

-> Step 4-USB Interface

 

Detailed information about each configuration of the USB device has been obtained and stored in several related members during the long journey of the USB core.

Usb_generic_driver obtains detailed information about the USB device, then sends the prepared interface to the device model. The Linux Device Model adds the interface to the device linked list, and then polls another USB driver linked list, call the match function of the USB Bus for each driver to complete the matching.

1.4 USB request block (urb)

Communication between a USB host and a device is transmitted in the form of packets. The Linux idea is to encapsulate the data that follows the Protocol into blocks for unified scheduling, the USB data block is urb, the struct urb, defined in <Linux/USB. h>. The member unsigned char * setup_packet Pointer Points to the setup packet. The following is a summary of the processes that need to be performed to complete a complete USB communication using urb,

-> Step 1-usb_alloc_urb ()

Create a urb and specify the destination endpoint of the USB device.

-> Step 2-usb_control_msg ()

Submit the urb to the USB core and the USB core to the HCD host controller driver.

-> Step 3-usb_parse_configuration ()

HCd parses urb and obtains data to communicate with the USB device.

-> Step 4

HCd returns the ownership of urb to the driver.

The most important function in the protocol layer is usb_control/bulk/interrupt_msg (). Here is a simple Geographic clue,

Usb_control_msg () => usb_internal_control_msg () => usb_start_wait_urb () => usb_submit_urb () => usb_hcd_submit_urb => HCD-> driver-> urb_enqueue () the HCD master controller driver implements USB data communication based on the specific platform.

2. USB Hub

The Hub is used to connect more USB devices. In hardware, the bus enumeration process of USB devices is realized. In software, the matching between USB devices and interfaces on the USB Bus is realized.

The following summarizes the implementation mechanism of USB hub in the Linux USB core layer,

During USB subsystem initialization, usb_hub_init () enables a kernel thread named "khubd,

The kernel thread khubd serves USB hub from start to end after Linux is started. If there is no hub event, khubd goes to sleep. When a USB hub event is triggered, it will go through hud_irq () => hub_activate () => kick_khubd () wakes up khubd, adds the event to the hub_event_list list, and executes hub_events (). Hub_events () will continuously poll the hub_events_list list to complete the event triggered by the hub until the exit ends when the list is empty and return to wait_event_xxx to continue waiting.

The entire process of handling hub events can be roughly divided into two steps,

  • Step 1: Determine port status changes

Use hub_port_status () to obtain the hub port status.

Functions such as hub_port_status () and hub_hub_status () in the source code call usb_control_msg () at the core layer to implement communication between the master controller and the USB device.

  • Step 2 handle port changes

Hub_port_connect_change () is the core function. Taking the insertion of a new USB device on the port as an example, USB hub performs the following steps for the USB device, note that the USB device is an external USB device (including hub and functions) That is inserted into the USB hub. Then, the hub is serving the USB device.

1) usb_alloc_dev () applies for a sturct usb_device structure for the USB device.

2) Set USB _ set_device_state () to power-on. (The device on the hardware is in the powered status ).

3) choose_address () selects an address for the USB device, and uses a polling algorithm to select an address number from 0 to 12 7.

4) hub_port_init () Port Initialization is to obtain the device descriptor.

5) usb_get_status () is special. It is specially prepared for the hub and external hub.

6) usb_new_device () the USB device is in the CONFIGURED state. Call device_add () to find the driver on the USB bus. If the matching is successful, load the corresponding driver.

 

3. USB OTG

The concept of OTG is introduced to enable the device to act as the master and slave devices. The master device is HCD, And the slave device is UDC or gadget. Here we will simply sort out the protocol and source code.

3.1 Protocol

1) Protocol

OTG transmission protocols include three types: ADP, SRP, and HNP.

  • ADP (attach Detection protocol) when there is no power supply on the USB bus, ADP allows the OTG device or USB device to determine the connection status.
  • SRP (Session Request Protocol) allows the slave device to control the master device.
  • HNP (host negotiation protocol) allows two devices to switch between the master and slave roles.

2) device role

The Protocol defines two roles: otg a-device and otg B-device. A-device is the power supplier and B-device is the power consumer. By default, a-device is the master device, b-device is used as the slave device, which can then be exchanged through HNP.

3) OTG micro plug

In terms of protocol, "An OTG product must have a single micro-AB between tacle and no other USB between tacles." is a problem... It should also include mini-AB receptacle, and all the following micro can be mini.

One end of the OTG cable is micro-a plug, and the other end is micro-B plug.

OTG adds 5th pin pins named ID-pin, ID-pin of micro-A plug is grounded, and Id-pin of micro-B plug is suspended.

The OTG device is called micro-A device after being connected to micro-a plug, and then called micro-B device after being connected to micro-B plug.

3.2 source code analysis

The OTG controller is integrated into the CPU. the Linux source code driver is provided by various development platforms and is located under./Drivers/USB/OTG.

Taking the Freescale platform as an example, the main idea is that when an OTG line is inserted into the OTG device, there is an interruption. The upper part of the interrupt processing function reads the corresponding value of the OTG controller register to determine that the OTG device belongs to the host (HCD) or gadget (UDC). In the lower half, the host or gadget controller and resume () are restarted by the callback function like host-> resume () or gadget-> resume () through the working queue () the specific implementation process is implemented in HCD or UDC-related drivers.

 

4. USB Host

The USB master controller (HCD) is also integrated into the CPU and is driven by the Development Platform vendor. The source code is located under./Drivers/USB/host.

There are four main types of Master controllers: EHCI, fhci, OHCI, and uhci. Their respective Register interface protocols are different, and most embedded devices are EHCI.

The struct type of the driver is struct hc_driver, and the member (* urb_enqueue) is the most important. It is the core implementation function of the main controller HCD to transmit the data packet urb to the USB device. As mentioned earlier, the main function usb_control_msg () in the protocol layer calls back the main controller (* urb_enqueue ).

Usb_control_msg () => usb_internal_control_msg () => usb_start_wait_urb () => usb_submit_urb () => usb_hcd_submit_urb => HCD-> driver-> urb_enqueue ()

 

5. USB Gadget

I wrote a gadget... http://blog.csdn.net/qianjin0703/archive/2011/01/15/6141763.aspx.

The source code of gadget is located under./Drivers/USB/gadget/, which involves many drivers and data structures.

Drivers mainly include,

  • Platform-related gadget controller driver
  • Platform-independent Reuse Device Driver composite. c
  • Android. c
  • The ADB driver f_adb.c, USB flash drive f_mass_storage.c, and other reusable USB Drivers

Data Structures mainly include,

  • Struct usb_gadget contains (* OPS) and struct usb_ep * ep0.
  • In struct usb_gadget_driver, (* bind) is bound to the multiplex device driver, and (* setup) is used to complete USB enumeration.
  • In struct usb_compostie_driver, (* bind) is bound, for example, the android multiplex device driver.
  • Struct usb_request USB Data Request package, similar to urb.
  • Struct usb_configuration is the configuration of this gadget device. The struct usb_function * interface [] Array records its USB interface/function/driver.
  • In struct usb_function, (* bind) is bound to the relevant USB interface, and (* setup) is used to complete the USB enumeration operation.

The overall framework can be summarized as, (mv_gadget is the data of the gadget Controller)

6. USB Mass Storage

There is only one Linux USB flash drive in the world. /Drivers/USB/storage/USB. c. The pseudocode is as follows. Note that USB core and hub have done two major work on the USB flash drive before initializing probe.

1) after completing the USB device enumeration, the USB flash disk enters the CONFIGURED state and the USB flash disk data is stored in struct usb_interface.

2) After matching the device and driver on the USB Bus is completed, the driver corresponding to the interface, that is, the USB flash drive, has been found on the bus.

  • The khaki part is encapsulated by the SCSI subsystem to implement the final U disk driver registration.
  • Usb_stor_scan_thread: scan the thread of the USB flash disk. Wait for 5 seconds. If it is not pulled out within 5 seconds, SCSI will scan the whole disk,
  • Usb_stor_contro_thread is a core thread. For more information, see USB.

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.