drivers: usb: Add VBUS detector#103840
drivers: usb: Add VBUS detector#103840nandojve wants to merge 5 commits intozephyrproject-rtos:mainfrom
Conversation
Add devicetree binding for GPIO-based USB VBUS detection. This binding allows boards to specify a GPIO pin for sensing VBUS presence and associate it with a USB device controller. Properties: - vbus-gpios: GPIO pin for VBUS sensing - udc: phandle to USB device controller - debounce-ms: optional debounce interval (default 20ms) Signed-off-by: BUDKE Gerson Fernando <gerson.budke@leica-geosystems.com>
Add a VBUS detection subsystem for the USB-next stack that provides: - Minimal API (usb_vbus_ready/usb_vbus_removed) for detector drivers - Wrapper around udc_submit_event() to isolate UDC dependency - GPIO-based detection driver with debounce support The GPIO driver monitors VBUS state via interrupt and notifies the USB device controller of connection/disconnection events. Signed-off-by: BUDKE Gerson Fernando <gerson.budke@leica-geosystems.com>
Add ztest suite for the VBUS detection GPIO driver covering: - GPIO interrupt configuration verification - VBUS ready event on GPIO high - VBUS removed event on GPIO low - Debounce behavior Tests run on native_sim using the GPIO emulator. Signed-off-by: BUDKE Gerson Fernando <gerson.budke@leica-geosystems.com>
Add sample application demonstrating VBUS detection usage. The sample logs VBUS state changes to the console. Also update the USB Common sample Kconfig to conditionally enable VBUS detection when the devicetree binding is present. Signed-off-by: BUDKE Gerson Fernando <gerson.budke@leica-geosystems.com>
Add VBUS detection node using PA9 GPIO for sensing USB cable connection. This enables the board to properly handle USB plug/unplug events with the USB-next stack. Signed-off-by: BUDKE Gerson Fernando <gerson.budke@leica-geosystems.com>
zephyrbot
added
area: USB
zephyrbot
requested review from
FRASTM,
GeorgeCGV,
JarmouniA,
decsny,
djiatsaf-st,
erwango,
etienne-lms,
gautierg-st,
jfischer-no,
josuah,
juickar,
mathieuchopstm,
nashif,
rruuaanng and
tmon-nordic
|
|
Some vendor-specifics of DWC2 also does some VBUS detection, in a different way: zephyr/drivers/usb/udc/udc_dwc2_vendor_quirks.h Lines 115 to 123 in 72c4354 Not sure if this qualifies for this API as well. |
What you mean in a different way? Do you have something in mind? |
I meant that UDC not using a GPIO for VBUS detection could also use this API.
This is orthogonal though: only trying to anticipate possible use-cases. |
| #endif | ||
|
|
||
| /** | ||
| * @brief Notify USB stack that VBUS is ready. |
There was a problem hiding this comment.
I think this will need some versioning.
| common: | ||
| tags: | ||
| - usb | ||
| - vbus |
There was a problem hiding this comment.
Is it possible that other, different protocols also have something called "VBUS"? Or is it unambiguous enough?
| static inline void udc_set_can_detect_vbus(const struct device *dev) | ||
| { | ||
| struct udc_data *data = (struct udc_data *)dev->data; | ||
|
|
||
| data->caps.can_detect_vbus = true; | ||
| } |
There was a problem hiding this comment.
How is this synchronized against UDC init and USB stack using the value?
|
This pull request has been marked as stale because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 7 days. Note, that you can always re-open a closed pull request at any time. |
This is a perfectly valid use-case. In fact nRF devices would have two separate VBUS detectors. nRF54H20 would use nrfs, while nRF54LM20 would use the VREGUSB regulator. |
|
This pull request has been marked as stale because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 7 days. Note, that you can always re-open a closed pull request at any time. |
5 participants
This introduce a generic VBUS detect mechanism that allow group USB interfaces.
Problem:
A board that is connected on a host were both host and device have their own battery to operate could require VBUS monitoring. This, in many cases, can be solved with the in tree solution. However, when multiple devices are connected to the host by the same USB interface it became more complicate to operate. Some device may need that the MCU monitor the VBUS not only for their own interface but should act on behalf of another. This could be more complicated when the MCU have multiple interfaces and then distinct control should be made and when external devices like modems with USB interfaces are in place and require software coordination.
Proposal:
The proposal is define a generic mechanism that monitor the VBUS in behalf of one or many interfaces. This central point then will configure, for instance, a GPIO pin to interrupt the main CPU when a VBUS detection/removal happens. This help the application to control a power domain or use regulators.
The VBUS detector act injecting the
UDC_EVT_VBUS_READY/UDC_EVT_VBUS_REMOVEDevents direct in the USB interface. From a system perspective, it is like each interface have their own VBUS function. In this case, no changes in the USB stack are needed. The injection is made direct using the USB interface instance and should be compatible with any future USB improvements inside the core. The events are dispatch in the exact order that the interfaces are defined in the devicetree. A software de-bounce optional is available. The only requirement is that the detector should be initialized after the USB interfaces, which can be easy defined using KConfig. A sample was developed to help anyone understand the concept and tests are defined to make sure regressions can be detected.