Re: Behavior of USB controller when receiving isochronous transfers with CRC errors

[Peter Chen <peter.chen@nxp.com>]

On 20-06-18 20:24:17, Marc Carino wrote:
> Hi Peter,
> 
> I noticed your extensive commits in the mainline for the chipidea USB controller. I must say you’ve done quite a bit of good work - thank you for contributing it all to the community!
> 
> That said, I had a question about the USB controller itself. I’m using an NXP i.MX8M Mini and USB gadget mode (UAC2.0, f_uac2). We have a custom board which needs some signal integrity work. That said, we are expecting to see spurious CRC errors on USB.
> 
> From what I currently know about the controller it seems to properly handle the CRC in hardware by setting the appropriate bit in the TD [1]. In our application we can accept the CRC failure and keep goin, since it’s expected that isochronous transfers can have errors and should keep on coming.
> 

Do you really see the error bit is set at dTD status entry? Which bit,
it is IN or OUT transfer?

> That said, is there a good way to change _hardware_dequeue to let it keep processing the TDs if they’re for isochronous transfers? Or, do you think we need to use a “big hammer” approach, reset everything, and restart the transfers? I would much prefer the former because it minimizes the amount of time and allows us to mask the glitch. On that same vein perhaps we should have a counter for the number of times this occurs, just for debugging reasons.
> 

If the error bit is set, the controller driver returns the error value, it depends on gadget
driver if it stops the ongoing transfer or not.

Peter

> Any advice is greatly appreciated.
> 
> Thanks,
> Marc
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/chipidea/udc.c?h=v5.8-rc1#n680<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdrivers%2Fusb%2Fchipidea%2Fudc.c%3Fh%3Dv5.8-rc1%23n680&data=02%7C01%7Cpeter.chen%40nxp.com%7Caf143f6938d443b874a808d813c59503%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637281086611601329&sdata=r%2BA9tByhxiS%2By%2FCv42huoLpsyvx7fCF6hpskNqN8Ut4%3D&reserved=0>
> 
> The contents of this message may contain confidential and proprietary information of the sender. Its contents are only intended to be shared with the intended recipient and used only for the limited purposes of the underlying communication consistent with the services rendered or other contractual relationship between the parties. Recipient agrees not to re-circulate or share this communication or its contents with any third party without Sender’s prior approval or use it in any manner inconsistent with the intended purpose of the underlying communication. Recipient also agrees to take all reasonable measures to protect the secrecy of and avoid disclosure and unauthorized use of any confidential or proprietary Information of the sender contained in this or any other communication. To the extent recipient is unable or unwilling to abide by these terms and conditions, he or she should return this correspondence immediately, and delete all copies.

-- 

Thanks,
Peter Chen