On Thu, Aug 28, 2025 at 05:46:56PM +0200, Marek Vasut wrote: > 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.
I did try it out when I wasn't able to trigger the workaround and I didn't see a crash. It seemed to work without issues but I didn't mention it since I felt that this wasn't the right way to test it. Nevertheless, I can confirm that I did not see a crash when forcing the workaround code to execute. Regards, Siddharth.
