drivers: usb: uhc_dwc2: add bulk transfer support

[roma-jam]

Collective Pull-request

Contains the incoming features and all the prerequisites.

Work in Progress

Description

N/A

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.

then run:

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

and the the common usbh shell commands are available:

...

*** Booting Zephyr OS build 18c5216bfc70 ***
uart:~$ usbh init 
host: USB host initialized
uart:~$ usbh enable 
host: USB host enabled
[00:00:04.638,000] <inf> usbh_dev: New device with address 1 state 2
[00:00:04.640,000] <inf> usbh_dev: Configuration 1 bNumInterfaces 3
uart:~$ usbh device list 
1
uart:~$ usbh device bulk 1 0x01 64
host: Bulk transfer finished
[00:00:22.065,000] <wrn> uhc_dwc2: Submit channel type: 2
[00:00:22.065,000] <wrn> uhc_dwc2: BULK OUT
                                   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |........ ........
                                   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |........ ........
                                   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |........ ........
                                   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |........ ........
[00:00:22.065,000] <inf> usbh_shell: Bulk request finished
uart:~$ 

Changes

Updated

• drivers/usb/uhc/uhc_dwc2.c - Added BULK transfer type.

Related

• Follow-up in [TBC]
• Prerequisites in drivers: usb: uhc_dwc2: add initial support #102967

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[github-actions]

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.

[sonarqubecloud]

Quality Gate passed

Issues
2 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

[josuah]

I think with BULK and Buffer DMA mode, the toggling of DATA0/DATA1 PIDs is automatic.

In completer mode, the CPU is involved every packet.

In buffer DMA, the CPU is involved at the beginning and the end.

So the CPU does not have access to the packet-level information, such as the PID (beyon the first one).

[roma-jam]

Correct.

In buffer DMA, the CPU is involved at the beginning and the end.

But when we prepare the transfer in the begging - we need to understand, do we need to use the same PID on the next transfer with the same EP, or we need to toggle it:
This is why I added the calculation logic:

/* If amount of packets are even - do not toggle */
	if ((pkt_cnt & 0x01U) == 0U) {

There are two common possible ways:

• fetch the PID in the end of transfer (CPLT) and count the next_pid based on this value, keep the next_pid someplace for the next transfer
• calculate next_pid before schedule the transfer and keep it till the next transfer. But in this case we do not need to toggle it, if the result was NACK.

[josuah]

I see the problem now. It is not about toggling the PID every time, but detecting the current toggling state after feeding more buffers to an ongoing transfer.

Thank you for clarifying.