Re: dwc3 38100000.usb: No resource for ep1in

[Felipe Balbi <balbi@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 4556 bytes --]


Hi,

Dan Scally <dan.scally@ideasonboard.com> writes:
> I'm having an issue with DWC3 which I'm hoping you might be able to shed 
> light on. I'm using the UVC gadget function to stream video from an 
> imx8mp platform, which works just fine. Once I have stopped streaming 
> however and after some time has passed (the exact duration seems to vary 
> quite a lot from 1-2 minutes to 15+ mins) I get a kernel warning like so:

As Greg mentioned, please add Thinh, the new maintainer, to the loop.

> [  737.996842] configfs-gadget gadget.0: uvc: uvc_function_disable()
> [  738.519582] configfs-gadget gadget.0: uvc: uvc_function_set_alt(0, 0)
> [  738.526060] configfs-gadget gadget.0: uvc: reset UVC interrupt endpoint
> [  738.532713] ------------[ cut here ]------------
> [  738.537683] dwc3 38100000.usb: No resource for ep1in
> [  738.542712] WARNING: CPU: 0 PID: 645 at drivers/usb/dwc3/gadget.c:384 
> dwc3_send_gadget_ep_cmd+0x478/0x580
> [  738.552314] Modules linked in:
> [  738.555402] CPU: 0 PID: 645 Comm: irq/208-dwc3 Not tainted 
> 5.19.0-00034-gf017ce943b32 #82
> [  738.563601] Hardware name: Polyhex Debix Model A i.MX8MPlus board (DT)
> [  738.570145] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS 
> BTYPE=--)
> [  738.577128] pc : dwc3_send_gadget_ep_cmd+0x478/0x580
> [  738.582116] lr : dwc3_send_gadget_ep_cmd+0x478/0x580
> [  738.587102] sp : ffffffc00c3c39e0
> [  738.590433] x29: ffffffc00c3c39e0 x28: 0000000000031006 x27: 
> 00000000ffffffea
> [  738.597618] x26: 0000000000000006 x25: ffffff8004f32880 x24: 
> ffffffc00c3c3abc
> [  738.604801] x23: 0000000000000406 x22: ffffffffffff3f00 x21: 
> ffffffffffff3f0c
> [  738.611984] x20: ffffff8003872600 x19: 0000000000000001 x18: 
> ffffffffffffffff
> [  738.619166] x17: 000000000000001c x16: 00000000c99c42a5 x15: 
> ffffffc08c3c36b7
> [  738.626347] x14: 0000000000000000 x13: 6e6931706520726f x12: 
> 6620656372756f73
> [  738.633528] x11: 00000000000c02a7 x10: ffffffc009af1ac0 x9 : 
> ffffffc0080c42bc
> [  738.640710] x8 : 00000000ffffefff x7 : ffffffc009af1ac0 x6 : 
> 0000000000000000
> [  738.647891] x5 : ffffff807fb2eb08 x4 : 0000000000000000 x3 : 
> 0000000000000027
> [  738.655072] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 
> ffffff80158a8000
> [  738.662255] Call trace:
> [  738.664721]  dwc3_send_gadget_ep_cmd+0x478/0x580
> [  738.669362]  __dwc3_gadget_ep_enable+0x4f4/0x714
> [  738.674004]  dwc3_gadget_ep_enable+0x6c/0x15c
> [  738.678382]  usb_ep_enable+0x4c/0x1bc
> [  738.682067]  uvc_function_set_alt+0xcc/0x264
> [  738.686362]  composite_setup+0x7ec/0x195c
> [  738.690395]  configfs_composite_setup+0x90/0xc0
> [  738.694950]  dwc3_ep0_interrupt+0x834/0x9e0
> [  738.699156]  dwc3_thread_interrupt+0x994/0xd70
> [  738.703624]  irq_thread_fn+0x38/0xa4
> [  738.707221]  irq_thread+0x184/0x230
> [  738.710733]  kthread+0x118/0x120
> [  738.713981]  ret_from_fork+0x10/0x20
> [  738.717582] irq event stamp: 41021
> [  738.720998] hardirqs last  enabled at (41019): [<ffffffc008082858>] 
> finish_task_switch.isra.0+0xe8/0x264
> [  738.730501] hardirqs last disabled at (41021): [<ffffffc008f15058>] 
> _raw_spin_lock_irqsave+0xc4/0x170
> [  738.739747] softirqs last  enabled at (41014): [<ffffffc008a25b90>] 
> dwc3_thread_interrupt+0x1c0/0xd70
> [  738.748988] softirqs last disabled at (41020): [<ffffffc008a259dc>] 
> dwc3_thread_interrupt+0xc/0xd70
>
>
> ep1in in this instance refers to a Status Interrupt Endpoint under the 
> UVC specification, which is being "reset" by uvc_function_set_alt() 
> against the VideoControl interface (meaning a call to usb_ep_disable() 
> followed by usb_ep_enable(), see [1]). The isochronous endpoint that 
> data is streamed across is treated similarly in the same function (when 
> called for the VideoStreaming interface) and never seems to show the 
> same warning and as far as I can tell the operation ought to be safe, so 
> I'm struggling to see anything in the f_uvc code that's misbehaving to 
> cause the problem. I wondered if you might be able to take a look at the 
> trace and regdump of the dwc3 (which was taken immediately after the 
> warning is thrown) and see if that sheds any light on what might be 
> going on?

Best way forward is to collect dwc3 trace points, so we can see what the
HW is doing. For details, see [1].

[1] https://kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]