1. USB3.0
USB is the most successful PC peripheral interconnection technology defined in history, and has been rapidly introduced into CE and Mobile fields. In 2006 alone, more than 2 billion USB devices were produced, and now there are more than 6 billion USB products installed.
And as technological innovation continues to advance, new devices, media formats, and cheap high-capacity storage are constantly emerging. They all require higher bandwidth to maintain the user experience expected by users. High-definition cameras will have hundreds of gigabytes of storage content that needs to be migrated to the PC for users to edit, view, and pack for storage. Existing devices such as digital cameras continue to innovate and increase their capacity to hold more uncompressed images. Downloading hundreds or even thousands of raw images of 10MB or larger from a digital camera will be a very time-consuming process unless the transfer rate is improved. In addition, user applications require higher connection bandwidth between the PC and these increasingly complex peripherals. USB 3.0 addresses these needs by adding higher transfer rates to match these new applications and devices.
There are a large number of PCs in use on the market today that only support USB 2.0. There is also a large number of USB 2.0 peripherals used. USB3.0 needs to maintain backward compatibility. From the hardware point of view, usb3.0 and usb2.0 are already two kinds of devices. On the usb port of A-type seat, we can clearly see that usb2.0 still uses GND, D+, D-, VBUS. In 3.0, a pair of USB3_TX differential lines, USB3_RX differential lines, GND, and BUS are used. So physically we have to be clear, in fact, USB2.0 and USB3.0 are not a device. Although USB3.0 still continues most of the concepts of 2.0.
1. The communication process of Usb3.0
Usb3.0 is backward compatible with USB 2.0 at the framework level. In terms of transmission types, there are still four types of control transmission, interrupt transmission, batch transmission, and synchronous transmission. However, there are some fundamental differences between USB 2.0 and the SuperSpeed protocol:
1) USB 2.0 uses a three-part transaction (token, data, and handshake), while SuperSpeed uses these same three parts differently. For outputs (OUTs), the token is included in the packet; for inputs (INs), the token is replaced by the handshake.
2) USB 2.0 does not support bursting (bursting) and super high speed supports continuous bursting (continuous bursting).
3) USB 2.0 is a half-duplex broadcast (broadcast) bus, while SuperSpeed is a dual-simplex unicast (unicast) bus, which allows simultaneous IN and OUT transactions.
4) USB 2.0 uses a polling model, while SuperSpeed uses asynchronous notification.
5) USB 2.0 does not have the ability to stream (Streaming), while super high speed supports streaming (Streaming) to bulk endpoints.
Let's look at an IN transfer:
Hosts and devices SHOULD obey restrictions on transport type and endpoint characteristics. The host initiates a transfer by sending an acknowledgment packet (IN) to the device. This acknowledgment packet contains addressing information to route the packet to the intended endpoint. The host tells the device how many packets it can send, and the sequence number of the first packet it expects to receive from the device. In response, the endpoint sends a packet back to the host with the appropriate sequence number. Acknowledgment packets also implicitly confirm that previous packets were successfully received.
Note that even though the host needs to send an acknowledgment for every received packet, the device can still send the requested number of packets without waiting for any acknowledgments.
The ultra-high-speed input (IN) transaction protocol is shown in the figure below. An input (IN) transfer on a SuperSpeed bus consists of one or more IN transactions and completes when any of the following occurs:
1) All transmitted data is successfully received.
2) The endpoint responds with a packet smaller than the endpoint's maximum packet size.
3) The endpoint responds with an error.
Out transfers are also similar:
From the above model, we can see that compared to the polling mode of usb2.0, on the one hand, the asynchronous mode of usb3.0 is significantly more efficient, and can continuously send out packets without waiting for the device to respond. On the other hand, because usb3.0 sends data point-to-point, other idle usb devices can keep low power consumption until data arrives. In the polling mode of usb2.0, since each device needs to judge the address on the bus, the idle device cannot enter the low power consumption mode.
2. Emergency
The SuperSpeed USB protocol allows the host to continuously send data to the device, or receive data continuously from the device, as long as the device can receive or send data. The number of packets the device can send or receive without an intermediate acknowledgment packet, reported in the endpoint companion descriptor for this endpoint. An endpoint reporting a maximum burst size of more than one packet is said to support "bursty" transactions.
When performing burst transfers, the following rules apply:
1) Before receiving an acknowledgment packet, the maximum number of packets that can be sent in a burst is limited to: the maximum burst size of the endpoint [maximum burst size] (and the last packet received by the endpoint or host The minimum value of the NumP field of the ACK TP or ERDY, minus the number of packets the endpoint or host has sent since the packet acknowledged by the previous ACK TP. Note that whenever the endpoint is initialized, the host can re-enable The maximum number of DPs sent/received is initialized to the maximum burst size of the endpoint [maximum burst size].
2) In burst transmission, each independent packet should have a data packet payload length of maximum packet size. Only the last packet of a burst can be smaller than the reported maximum packet size. If the last one is smaller, then the rules for short packets apply to short packets at the end of the burst.
3) Burst transactions can continue as long as the NumP field of the ACK TP is not set to 0 and each packet has a data payload of the maximum packet size.
3. Streaming
Streaming is a special mode in bulk. When the configuration descriptor of a device is configured with MaxStreams, it means that the device can support streaming.
The figure above represents an input batch pipeline, where a large number of streams (Streams) are established. Associated with each stream (Stream) in host memory are one or more endpoint buffers (Endpoint Buffers) to receive stream data (Stream data). On the device side, there is also a corresponding command or function-specific data that is transmitted to the host.
When the device has data available for a specific stream (G in the figure), it sends ERDY with CStream ID as a tag, and the host will start sending IN ACK TP with CStream ID tag to the device. The device will return the functional data related to the CStream ID, and also add the CStream ID as a label. When the host receives the data, it uses the CStream ID to select a set of endpoint buffers (Endpoint Buffers) to receive the data.
When the data is exhausted, the device terminates the stream. The host is also allowed to terminate the stream if it runs out of endpoint buffers. Streams can be used, for example, to support out-of-order data transfers required by mass storage devices.
A standard bulk endpoint has a single set of endpoint buffers (Endpoint Buffers) associated with it. Streams extend the number of host buffers an endpoint can access, from 1 to 65533. There is a 1:1 mapping between host buffers and Stream IDs.
Since the stream runs against a standard batch pipeline, a single error can halt the pipeline, stopping all activity.
4. Companion Descriptor
The USB3.0 descriptor is basically the same as the USB2.0. The main difference is that a companion descriptor is added after each EP descriptor to indicate the "burst transaction" and "stream transmission" of the device mentioned above. Ability:
5. Summary
In summary, the most important new features of USB3.0 are:
- Bus speed increased to 5Gbps (up to 10Gbps in gen2)
- asynchronous transfer mode
- Burst transactions, relying on the mode of asynchronous transmission, without waiting for the device to respond
- Stream transmission, relying on sudden transaction transmission, can be many-to-one mass transmission
These new features make the transfer rate of USB3.0 much higher than that of USB2.0
2. TYPEC
Typec is a new hardware interface introduced after the launch of usb3.0 for compatibility with forward and reverse insertion, high-power charging, and stronger compatibility. The main features are
- USB Power Delivery technology, can support charging up to 20V5A
- DisplayPort can be integrated, and external screens and speakers can be connected (for example, hdmi devices can be connected)
- Anti-interference, stronger reliability
The female head is shown in the figure below:
The male head is shown in the figure below:
It can be seen that compared with the ordinary usb3.0 A socket, typec has an extra set of tx, rx, vconn and cc. The specific use cases:
1) The extra tx and rx can be used as usb multi-channel output in gen1 or gen2, which can double the data throughput, and can also be multiplexed as DisplayPort interface, so that typec can be used for video output
2) vconn supplies power to the e-mark of the typec active cable, which can further identify the power supply capability of the cable
3) cc pin is the core function of typec, the host and device of usb can communicate through cc pin to realize various functions such as pd, dp and master-slave mode switching
At present, there are many types of implementation solutions for typec on the market. For example, Qualcomm implements it through its own typec phy, and there are also independent typec chip solutions, such as fusb302, etc., but the process is basically similar.
Encoding format:
pd3.0 starts to use the Biphase Mark Coding (BMC) encoding format. The characteristic of this encoding is that the level will switch once at the beginning of each bit period. If the level does not switch during this period, it means bit0. If the level switches once, it represents bit1
1.Power Delivery
Currently there are two types of PDs on the market, one is PD2.0, which only provides several fixed voltage and current gears, such as the common 5V3A, 9V3A, 12V3A, 15V3A, 20V3A. The other is pd3.0, that is, pps. In addition to providing several voltage gears of pd2.0, it will also provide one or more adjustable voltage and current gears, such as: adjustable voltage range 3V ~21V, adjustable current 0A~6.3A
The process is roughly as follows:
The following serves as an example:
2.DisplayPort
As mentioned above, typec has 4 pairs of differential signals, 2 pairs for uplink/downlink. USB-IF has launched an Alternate Mode to support the conversion of USB Type-C cables into other uses, and the DP Alternate Mode is the first application, which can convert some or all of the differential signal channels into DisplayPort signal channels, If there are remaining differential signals, they can continue to be used for USB 3.1 high-speed data transmission.
With the DP alternate mode, the strength of USB Type-C will be greatly increased, because it allows tablet computers and notebook products to achieve high-speed data transmission, video output, power supply and other functions through a mini interface, bringing "single interface, multi-function", which is more powerful than the previous solution of outputting video signals through the USB interface.
The following serves as an example:
Information through train: Linux kernel source code technology learning route + video tutorial kernel source code
Learning through train: Linux kernel source code memory tuning file system process management device driver/network protocol stack
3. USB3.0 OTG
In the era of usb2.0, in order to meet the requirement that a single usb port of a mobile device can be both a master and a slave, the otg function appeared. The otg of Usb2.0 is identified through the level of the fifth id pin on the micro or miniusb socket. When the level of the id pin is high, it is a slave. When the level is low, then for the host.
The internal circuit of the otg cable we buy on the market is to connect the id pin to the GND line, so that after the otg cable is inserted, the mobile phone can be used as a host terminal
In usb3.0, the function of id pin is also replaced by powerful typec, and the identification of master and slave will be identified by cc. At the same time, the master and the slave can also switch roles through cc communication.
In usb2.0, the master-slave relationship between the power supply party and the power receiver and the device is bound, and only the host can supply power to the devices. It is completely different in usb3.0, the two are completely independent, and can still receive power supply while being a host. Solved the problem of "when the phone is out of power, you can't plug in the usb device"
At the same time, on the hardware, we need to clarify the components of usb 3.0 otg
- usb controller
The controller is responsible for processing communication, data verification, distribution, exception handling and other main tasks. In usb2.0 we have multiple different controller ip such as "ehci, uhci, ohci, dwc2". Among them, ehci is compatible with usb1.0, usb1.1, usb2.0 and other functions at the same time, while uhci and ohci can only support up to 1.1. dwc2 is a controller with otg function
In usb3.0, the controller only has xhci, and dwc3, the same dwc3 also has otg function.
- usb phy
Usb phy is mainly responsible for the actual physical signal. Convert the serial usb data into the data format required by the controller. At the same time, the quality of our usb signal is also related to the phy. To a certain extent, the phy can improve the usb eye diagram, but it mainly depends on the usb wiring
- typec phy
Similar to the usb phy function, except that it processes the signal on the cc pin. The cc signal can also be processed by an independent chip, such as fusb302 and other chips.
1.EXTCON
External Connectors is the driver used by usb for status notification. When the phy receives an interrupt and processes the usb status, it broadcasts to all drivers that have listened to the extcon through the extcon driver.
Use devm_extcon_register_notifier to register and monitor usb status changes
Use devm_extcon_dev_register to register and manage usb status changes
The following host identification is taken as an example:
2.USB3.0 HOST
Compared with usb2.0, Usb3.0 does not change much in the usb core layer, and the driver is still the same as the original process. The core data structure of usb code is still URB, and the usage of URB is the same as before:
The difference lies in the code after usb hcd. In xhci, the core data structure is TRB, and each data is exchanged with a trb. In xhci.c, xhci_urb_enqueue further judges the data type, and judges the stream id and burst, and submit to the controller
3. USB3.0 OTG
(1) ConfigFS
In "Take You to the USB World", we introduced the gadget configuration method of android.c. In the early days, the gadget drivers of Linux were all fixed functions, that is, the usb function was fixed after booting and could not be changed. However, such a function obviously cannot meet the needs of mobile devices for otg functions, so android has launched a gadget driver with composite functions of android.c and composite.c.
After that, the android.c method has been used for a long time, until Linux updated the new gadget driver----configfs subsystem, which meets all the needs of the mobile terminal. Compared with android.c, configfs is more flexible, so it replaces android.c.
In the new linux code, configfs basically replaces android.c, so we will introduce configfs
Startup process:
After startup, the upper layer UsbDeviceManager.java controls the gadget function through the property of setprop sys.usb.config, for example:
Each of these bound functions should be a driver in the gadget, such as mtp corresponds to drivers/usb/gadget/function/f_mtp.c
(2) OTG enumeration process
The flow chart is as follows
The data exchange between the Configfs subsystem and the controller is through the struct usb_request *request structure. A complete process is as follows:
Original Author: Kernel Craftsman
