On 8/24/25 10:02 AM, Siddharth Vadapalli wrote:
On Sat, Aug 23, 2025 at 02:21:18PM +0200, Marek Vasut wrote:
On 8/23/25 4:07 AM, Siddharth Vadapalli wrote:
Hi,
I was planning to test this patch but the change being made is only
applicable to Controller Versions:
#define DEV_VER_NXP_V1 0x00024502
#define DEV_VER_TI_V1 0x00024509
and not to:
#define DEV_VER_V2 0x0002450C
#define DEV_VER_V3 0x0002450d
Since I don't have an SoC and a Board with DEV_VER_TI_V1, I cannot test
it. However, the change looks correct to me.
Reviewed-by: Siddharth Vadapalli <s-vadapa...@ti.com>
The change does indeed look correct.
Do you know who might still have that board and could test ? (and which
board/soc is that) ?
None of the boards that I have worked with have a DEV_VER_TI_V1 version
of the controller. I also tried to use the Linux device-tree to check if
I could identify the SoC/board but I was unable to do so.
Do you know which SoC is V2 and V3 ?
I spent more time on this and found out that J721E SR 1.0 has the
controller with DEV_VER_TI_V1 version but other revisions of J721E as
well as all of the following SoCs have DEV_VER_V3 version of the
controller:
AM64, AM68, AM69, J7200, J721S2, J722S, J742S2 and J784S4.
I will try to find an SR 1.0 J721E SoC and test the patch on it and
share the results here.
This is awesome, thank you !
I was able to get an SR 1.0 J721E SoC and also the J721E
Common-Processor-Board for testing the patch.
Enabling debug info in the cdns3/gadget.c driver, I see:
cdns-usb3-peripheral usb@6000000: Device Controller version: 00024509
cdns-usb3-peripheral usb@6000000: USB Capabilities:: 09203324
cdns-usb3-peripheral usb@6000000: On-Chip memory cnfiguration: 00000c34
which confirms the Controller Version.
However, the code changed by the current patch is only affecting the
execution of code associated with Workaround 2 which is described in
detail in the driver. I am summarizing it here for your reference:
Issue:
Controller for OUT endpoints has shared on-chip buffers for all
incoming packets. The buffer acts as a FIFO, due to which,
missing a DMA descriptor for one packet will block subsequent
transfers/packets meant for other Endpoints that were queued.
Workaround:
If the Endpoint Status register indicates a Descriptor Miss,
rearm the DMA transfer to complete the missed transfer.
In order to test the patch, I used USBACM for STDIO/STDOUT to check if I
could trigger the descriptor miss workaround. The command I ran was:
setenv stdio usbacm; setenv stdout usbacm;
/dev/ttyACM0 showed up on my PC and I was also able to access the U-Boot
prompt via ACM0. While it is functional, I didn't see the code
associated with the workaround being triggered. Reviewing the driver
again, I identified that the workaround is being disabled very early on
within "cdns3_wa2_gadget_ep_queue()" with the comment stating:
* If transfer was queued before DESCMISS appear than we
* can disable handling of DESCMISS interrupt. Driver assumes that it
* can disable special treatment for this endpoint.
Given the above, it doesn't seem easy to recreate the issue since I
would have to trigger a descriptor miss event prior to the very first
USB transfer for the Endpoint. Please let me know if you have any
suggestions for speeding up testing.
Can you maybe simply force-enable the workaround code and see if that
itself works, without crashing ? If yes, then I would say let's apply this.
