Repository navigation
Conversation
|
|
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. |
343b640 to
c1676d3
Compare
|
| /* TODO: Do we need to toggle PID? */ | ||
| /* TODO: where to keep the toggle flag? How it is done in the other drivers? */ | ||
| /* PID support to be a part of EP or XFER, not channel */ |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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
PIDin the end of transfer (CPLT) and count thenext_pidbased on this value, keep thenext_pidsomeplace for the next transfer - calculate
next_pidbefore schedule the transfer and keep it till the next transfer. But in this case we do not need to toggle it, if the result wasNACK.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Yep, I got exactly this specific case failure with the test:
Found MSC interface 0
MSC IN EP=81 mps=512
MSC OUT EP=02 mps=512
W: Thread channel0 events: 00000009h
W: Thread channel0 events: 00000009h
W: Bulk transfer xfer validation not implemented
W: BULK OUT
W: 55 53 42 43 01 00 00 00 |USBC....
W: 24 00 00 00 80 00 06 12 |$.......
W: 00 00 00 24 00 00 00 00 |...$....
W: 00 00 00 00 00 00 00 |.......
W: size 31
W: Thread channel0 events: 00000009h
W: Bulk transfer xfer validation not implemented
W: BULK IN
W: size 0
W: handle_in, 00000003h
W: Thread channel0 events: 00000009h
W: Bulk transfer xfer validation not implemented
W: BULK IN
W: size 0
W: handle_in, 00000410h
W: ACK, NAK or DTG Error
I will fix it by:
- workaround in the driver first (keep the correspondent value in the additional object, tied to the EP number), and then, when I will find a good place in the stack
- add the member to the object somewhere at
usbhlevel.
There was a problem hiding this comment.
Ok, this is done now.
@josuah, Yes, we do need to keep pid somewhere.
Right now I have it as ep quirk in uhc_dwc2 driver, but maybe it can be moved one layer higher.
Anyway, MSC Inquiry request works now:
===================================================================
START - test_inquiry
Found MSC interface 0
MSC IN EP=81 mps=512
MSC OUT EP=02 mps=512
W: Bulk transfer xfer validation not implemented
W: BULK OUT
W: 55 53 42 43 01 00 00 00 |USBC....
W: 24 00 00 00 80 00 06 12 |$.......
W: 00 00 00 24 00 00 00 00 |...$....
W: 00 00 00 00 00 00 00 |.......
W: Release channel after BULK is done
W: Release channel0, prog=31, len=31, tailroom=0, mps=512, next_pid=2
W: Bulk transfer xfer validation not implemented
W: BULK IN, tailroom=36
W: Release channel after BULK is done
W: Release channel0, prog=36, len=36, tailroom=0, mps=512, next_pid=2
W: Bulk transfer xfer validation not implemented
W: BULK IN, tailroom=13
W: Release channel after BULK is done
W: Release channel0, prog=13, len=13, tailroom=0, mps=512, next_pid=0
I: MSC vendor: USB product: SanDisk 3.2Gen1 revision: 1.00
PASS - test_inquiry in 0.510 seconds
===================================================================
There was a problem hiding this comment.
W: ACK, NAK or DTG Error
It looks like you put the finger on the problem!
Some hardware would handle it completely without software API? Or maybe it wouldn't work to just store that inside DWC2, or maybe it is simply useful to have helpers to simplify the drivers.
There was a problem hiding this comment.
It looks like you put the finger on the problem!
I just wrote a test which needs PID toggling on bulk EP 🤷
But fixed already. I will check the rest msc host class commands and read10/write10.
So, MSC Host class already might be implemented above uhc_dwc2.
There was a problem hiding this comment.
Added specific data pointer to the channel object, that is being selected during the channel claim.
We have xfer object, which we associate with specific channel. This xfer already has endpoint number and type.
Based on these parameters (ep_dir=[0x00,0x01] and ep_num=[0x01..0x0F]) we select specific struct and save the pointer in the channel object till it is released.
Currently, it holds only data for Bulk transfer (next_pid), but maybe we will need it for the other transfers in the future.
In any way, note solved.
Get core revision: Different core revisions require different hanlding. To have an option to get the revision and apply different logic add the possibility to read masked revision from GSNPSID register. Set PHY Low Power Clock Select: For the HS UTMI+ PHY interface uses 48MHz for Low speed devices, instead of 480 MHz. We need to configure this after port completed a reset. Signed-off-by: Roman Leonov <jam_roma@yahoo.com>
|
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. |
c1676d3 to
a097232
Compare
|
Please, remove the |
Note: Control transfers only Add initial usb host driver for Synopsys DWC2 with vendor quirks. Signed-off-by: Roman Leonov <jam_roma@yahoo.com>
a097232 to
9ae95ea
Compare
Add bulk transfer to the driver. Signed-off-by: Roman Leonov <jam_roma@yahoo.com>
9ae95ea to
105536c
Compare
|
Hi everyone, current state of the driver allows to utilize the channel, configured as Bulk type. Locally verified the basic scenarios and possibility to implement the MSC Class specific requests: Parameters of xfer object covered with verification before start transfer on the claimed channel. As this is already provide the possibility to start or to move the development if it is already already in the process to the nRF54LM20 and other targets with DWC2 or another compatible controller, I would like to keep it in his state and move to Interrupt type. |
|
|
Closed, as it has been integrated in the main PR with initial support: #102967 |
Description
TBD
Testing on ESP32-S3
From the
/samples/subsys/usb/shellfolder, runTesting on nRF54LM20
then run:
and the the common usbh shell commands are available.
IMPORTANT: usbh shell sample allows to send data filled with 0x00 configured length. Real behavior may vary from device to device.
Use
usbh device bulkcommand to initiate bulk transfer:Related