Extcon driver and its application in USB driver


Extcon, short for external connector, is used to abstract external connectors, such as audio jack, USB microb / typec interface, etc. Its prototype is the switch class driver of Android. After modification, it was introduced into the kernel in kernel version 3.4.0.

Extcon (external connector): import Android’s switch class and modify.

External connector class (extcon) is based on and an extension of Android kernel’s switch class located at linux/drivers/switch/.


The main function of extcon driver is to identify the state change of external connector and notify other drivers related to external connector of the state change.

What are the benefits of using extcon driver? Before the kernel has no extcon driver, how to deal with these external connectors? Take USB driver as an example to see the changes before and after using extcon driver.

There are three common USB external interfaces: type A / B / C, of which type A / B includes standard A / B, mini A / B and micro A / B, as shown in the figure above:

For these three different interfaces, typea / B is only the connection on the physical signal. There is no special controller for typea / B in the main control chip. Whether the USB host or USB peripheral is connected can be identified by the status of VBUS and ID pins. Before connecting to the host, there is no voltage on the VBUS pin. After connecting to the host, the host terminal will provide 5V voltage on the VBUS pin; Before accessing the peripheral, the ID pin is at high level. After accessing the peripheral, the ID pin is pulled down. Therefore, the software can know the change of state by actively reading the level of the two pins or asynchronously responding to the interruption of the two pins.

Typec is a little special. As can be seen from the typec specification, typec has a state machine. When it goes from the unattached state to the attached sink state (as a slave device) or the attached source state (as a host), there is a corresponding controller inside the master chip. The controller will report the state change through the register and generate an interrupt notification to the master. The typec controller requires software programming to configure and enable it.

Screenshot from official specification: USB type-C 2.1 release


The above is the situation faced by USB for different external interfaces. Before the emergence of extcon driver, a common method for the same USB controller driver code is to specify the interface in the device tree (DTS). The definition in the device tree will be parsed in the USB controller driver code through if else… Let’s go through different code logic. If it is a microb interface, register the interrupt of VBUS and ID pin and query the level status of IO pin; If it is a typec interface, register the interrupt of typec and query the status of typec. Assuming that a new interface appears later and the working principle is different from the existing interface, it is necessary to add relevant codes to the USB controller driver.

After the emergence of extcon driver, the USB controller driver can be decoupled from the external interface driver. In the view of USB controller driver, no matter what the external interface is, I just need to know the change of the external interface state, such as whether it is connected to the host and whether there are devices connected. Use the function interface provided by the extcon driver to register the notifier. When the state of the external interface changes, the extcon driver is responsible for calling back the notifier. The USB controller driver code does not need to be changed for different external interfaces. Different external interfaces use extcon to abstract their own behavior.

The above are all the introduction of principles. Finally, it is clear enough to implement the code. Take kernel native code as an example:

drivers\extcon\extcon-usb-gpio.c  //Extcon driver exampledrivers\usb\dwc3\dwc3-omap. C / / useExtcon example

extcon-usb-gpio. C realizes the extcon driver that detects USB plug-in through IO pin (VBUS and ID). The whole driver is based on platform driver.

In the probe function of the driver, the GPIO corresponding to VBUS and ID pin will be obtained from the device tree. The relevant attributes of the extcon device are defined in the device tree.

Then an extcon device will be allocated and registered. usb_ extcon_ The cable array defines the state type supported by this extcon device, extcon_ USB means USB device, extcon_ USB_ Host means USB is the host. The status value is of course inserted or pulled out.

Finally, register the interrupt of ID pin and VBUS pin. Note that the interrupt processing functions of both pins are USB_ irq_ handler。 The interrupt processing functions of the two pins are not necessarily the same. They are set to the same one here for the convenience of logical processing, because VBUS and ID pins need to be judged jointly.

usb_ irq_ Queue work will be in the handler function, and the processing function corresponding to this work is shown in the figure below. Via extcon_ set_ state_ The sync function notifies other drivers. As long as a driver registers the corresponding notifier, it will be notified.

The above isextcon-usb-gpio. C. similarly, the typec driver can also register extcon device through extcon_ set_ state_ The sync function reports the status to other drivers. Here are no more repeated examples.

Last lookdwc3-omap. C how to use extcon. The probe function of the driver will call the following function, which first calls extcon_ get_ edev_ by_ Phandle obtains extcon device from the device tree, and then registers the notifier. When the state of extcon device changes, the notifier is called back; You can also use extcon_ get_ State actively queries the status of extcon device.

—— END ——

Author: BigFish 99

Blog: https://www.cnblogs.com/bigfish0506/

Official account: big fish embedded