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.
Regards,
Siddharth.
