Re: [PATCH v2] arm64: dts: msm8996: Use dwc3-qcom glue driver for USB
From: Felipe Balbi <hidden>
Date: 2018-06-27 12:32:51
Also in:
linux-usb
Attachments
- signature.asc [application/pgp-signature] 832 bytes
From: Felipe Balbi <hidden>
Date: 2018-06-27 12:32:51
Also in:
linux-usb
Hi, Pierre LE MAGOUROU [off-list ref] writes:
quoted
quoted
quoted
Thanks a lot, I will test this branch.I just tested USB gadget with this branch on the db820c. If I activate a USB composite gadget device with EEM function, I can see the 'usb0' Ethernet interfaces on the device and on the host and I canpingquoted
the db820c from the host. When I create a USB composite gadget device with UAC2 function, I can see the audio cards on host and device but cannot play or record any sound. While looking at dwc3 traces with Ftrace, I noticed that the dwc3 driverisquoted
stuck on wait_event_lock_irq() in dwc3_gadget_ep_dequeue() function whenIquoted
use UAC2 gadget.can you share tracepoint data?Here are the trace results when I start the UAC2 gadget device (all dwc3 functions and events are activated) : https://pastebin.com/NBP3tM8N The last line you see "before wait_event EP_END_TRANSFER_PENDING" is a trace_printk I added just before wait_event_lock_irq(). I also have a trace_printk after the wait_event_lock_irq() that is never called.
looks like we need to do away with the wait_event_lock_irq() call. usb_ep_dequeue() can be called from within the controller's interrupt handler, so we can't rely on wait_event_lock_irq(). I guess the best thing here would be to mark TRBs as dirty (and not increment dequeue pointer), so they aren't reused by accident, then let endpoint continue processing. Once command completion interrupt fires, we increment dequeue pointer. This should work better, I suppose. Do you want a shot at implementing this? -- balbi