drivers: usb: common: Added uhc dwc2 initial files [part2]

[roma-jam]

• DWC2 USB Host controller (UHC) #102931

Description

Added uhc dwc2 files with:

• Driver API call signatures without implementation
• DT multiinstance definition for uhc dwc2 (usb_otg peripheral)
• Vendor quirks header file (with stubbed quirks for esp32)

Testing

1. From the /samples/subsys/usb/shell folder, run

$ west build -b esp32s3_devkitc/esp32s3/procpu -- \
 -DCONFIG_SHELL=y \
 -DCONFIG_USB_HOST_STACK=y \
 -DCONFIG_USBH_SHELL=y \
 -DCONFIG_UDC_DWC2=n

and get:

... 

Successfully created ESP32-S3 image.

3. Flash the binary with:

$ west flash --esp-device /dev/ttyACM0 && west espressif monitor -p /dev/ttyACM0

and get:

...

*** Booting Zephyr OS build 0e30ba353d11 ***
uart:~$

4. Init usbh with

uart:~$ usbh init
host: Failed to initialize -88
[00:00:03.939,000] <wrn> uhc_dwc2: uhc_dwc2_init has not been implemented
[00:00:03.939,000] <err> uhs: Failed to init device driver
uart:~$ 

If the line uhc_dwc2: uhc_dwc2_init has not been implemented is present in the output, then the source files were build successfully and the driver is reachable.

Changes

Added

• samples/subsys/usb/shell/boards/esp32s3_devkitc_procpu.overlay - ESP32-S3 project overlay for testing purpose
• drivers/usb/uhc/KConfig.dwc2 - Specific host-related configuration
• drivers/usb/uhc/uhc_dwc2.c
• drivers/usb/uhc/uhc_dwc2.h
• drivers/usb/uhc/uhc_dwc2_vendor_quirks.h

Updated

• drivers/usb/uhc/CMakeLists.txt
• drivers/usb/uhc/KConfig

Related

• Follow-up in drivers: usb: uhc: Added dwc2 vendor quirks for esp32 [part3]  #102965
• Prerequisites in drivers: usb: common: Added host register set for DWC2 controller [part1] #101886
• Refactoring of drivers: uhc_dwc2: Initial support #94266
• Relates to uhc: dwc2: vendor quirks for nRF54LM20 #95723

[josuah]

It seems like these instructions do not really work until [part3] because of lack of vendor quirks for ESP32? How about moving the instructions to [part3]?

[roma-jam]

Hi @josuah

It seems like these instructions do not really work until [part3] because of lack of vendor quirks for ESP32? How about moving the instructions to [part3]?

This is strange, I did it while I prepared the description and tried it again one more time right now.
Did you try it out? If yes, you can share the output so I can figure out the difference and consider it in the future.

I introduced this overlay in current [part4], because it make sense as there is some code to test. Here is just that the build is fine.
Although here (if we want to test it), we need to create an overlay manually (as I described in steps). Considering this, maybe I can move adding the overlay to this PR, just to make it easier.

Anyway, it is not that many changes in here, and there are much more to review in [part4].

Am I right, that when development will be finished, I need to delete this overlay file?

[josuah]

I forgot to hit "Submit review" a few days ago, so here it is...

[josuah]

Did you try it out?

No I did not try it out. I did not expect it to work, but I realize that there are placeholders for all the ESP32 vendor quirks, so my bad no problem.

[...] there is some code to test. Here is just that the build is fine.

Although here (if we want to test it), we need to create an overlay manually (as I described in steps). Considering this, maybe I can move adding the overlay to this PR, just to make it easier.

There should not need an overlay to test with build_all as it only relies on Kconfig and use of boards that have status = "okay";. Hence absence of .overlay file here: https://github.com/zephyrproject-rtos/zephyr/tree/main/tests/drivers/build_all/usb

[josuah]

Would you like me to force-push to this branch (and part3) to take the bureaucracy part away and let you focus on what you planned to do?

[roma-jam]

Hi @josuah,

thanks for moving the notes from the fork to the upstream PR to keep them all in one place.

Would you like me to force-push to this branch (and part3) to take the bureaucracy part away and let you focus on what you planned to do?

I would prefer to make it myself, because otherwise that means that you or someone else should do this every time.
I don't see any problem for me to align with such things (yes, it will take some time, but I hope that after that the cumulative pace will be better).

So, give me a moment, I will address all the notes soon.

[josuah]

Understood, no rush and thank you for the effort. I will try to stay reactive all I can.

[josuah]

Here are 2 variants for part2, which might also affect part3 but I think other parts would just need rebase, some few conflicts but no big refactor as function names remain the same.

• UHC DWC2: drivers: usb: uhc: refactored #104359
• UDC DWC2: usb: udc: dwc2: split vendor quirks per-vendor #105030
• UDC DWC3: drivers: usb: udc: dwc3: initial implementation #84544

The goal being not moving code bits of DWC2 from device -> device_next -> host if not needed.

It might be possible to first merge part2, then consider the above two PRs "future improvement" so that it does not impact the timeline on DWC2, or directly merge those above (if preferred) to reduce PR churn.

[josuah]

@roma-jam anything you planned to modify/add before review?
I'll start connecting nRF54LM20's quirks when this gets ready be merged.
Then I guess it is possible can pursue with the chain of PRs.

Thank you

[roma-jam]

Hi @josuah,

anything you planned to modify/add before review?

not, don't think so. Might be marked as "ready for review".

Thanks for the poking.

[sylvioalves]

@roma-jam I see now all PRs are kind of incrementing.. So the comments in the other parts apply here as well.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[roma-jam]

Hi
@jfischer-no,
@tmon-nordic,
@josuah,

PTAL, this is a common initial API for uhc dwc2.

Let me know what you think and how I can push it forward. Thanks.

[jfischer-no]

Let me know what you think and how I can push it forward. Thanks.

Sorry, I started looking at these PRs, but was interrupted by an urgent task. I wanted to comment on all of them, but perhaps this is not necessary.

We do not add unfinished drivers. Basically, a PR should contain a working driver on at least one platform. Please choose a PR with significant progress and include all the necessary commits. I will add it to the milestone of the next release. Then, please close all other PRs with a reference to the one where the work will be done. There will be increasing interest in this driver, so people can start looking at it for their adaptions/contributions. If you need my attention, please ping me directly on Discord. Thank you.

[roma-jam]

Hi @jfischer-no,

thanks for returning back to me.
I'll connect you in discord.

[roma-jam]

Closed because this PR doesn't introduce the working driver state, but just a prerequisites for it.

For the first working state of the driver, please refer #102967.