Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08-06-2024 00:57, Thinh Nguyen wrote:
On Fri, Jun 07, 2024, Mike Looijmans wrote:
On 06-06-2024 22:21, Thinh Nguyen wrote:
On Thu, Jun 06, 2024, Mike Looijmans wrote:
On 06-06-2024 02:28, Thinh Nguyen wrote:
On Wed, Jun 05, 2024, Mike Looijmans wrote:
On 05-06-2024 01:06, Thinh Nguyen wrote:
Hi,

On Tue, Jun 04, 2024, Mike Looijmans wrote:
On 04-06-2024 03:03, Thinh Nguyen wrote:
Hi,

On Mon, Jun 03, 2024, Mike Looijmans wrote:
When disconnecting the USB cable on an LS1028 device, nothing happens
in userspace, which keeps thinking everything is still up and running.
Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND
in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would
expect. As a result, sysfs attribute "state" remains "configured"
until something resets it.

Forward the "suspended" state to sysfs, so that the "state" at least
changes into "suspended" when one removes the cable, and hence also
matches the gadget's state when really suspended.
On disconnection, did you see disconnect interrupt? If so, it should
transition to USB_STATE_NOATTACHED. This change doesn't seem to directly
address your issue. Can you provide the driver tracepoints?
The device doesn't issue a disconnect event, I didn't have tracing enabled
in the kernel but added some dev_info() calls to determine what was going
on. Added this to dwc3_process_event_entry():

dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type);

When disconnecting the cable from the host, I see this:

[   50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42
[   50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43
[   50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42
[   50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43
[   50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43
[   52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0

The "0x4086" and "0x6084" messages are endpoint events that occur all the
time while connected. The last event is the "suspend" one. After that, total
silence.

If you need traces, please point me to a description on how to obtain them.


Let me know if you run into issues following this instructions to
capture the tracepoints:
https://urldefense.com/v3/__https://docs.kernel.org/driver-api/usb/dwc3.html*required-information__;Iw!!A4F2R9G_pg!bahfjil5HEUq-fOHAwDfusutLJCLognfyLHTFLiSlVuZotpr99XBGg7nB0zRRnNF_M1pqEKcVa4KxNJwh3_F2dZWwVKTkUY$
I've attached the traces as a tarball. Hope it survives.
Got them. Thanks.

At the start, the USB is up and running (and doing ethernet+mass storage). I
saved the trace after pulling the USB cable.

   From the capture, we can see that there's no system suspend, so there's
no soft-disconnect.

Base on the suspend event, you're running in usb2 speed (ignore the
incorrect U3 state, should be L2):

	irq/94-dwc3-631     [000] D..1.   149.139290: dwc3_event: event (00030601): Suspend [U3]

The DSTS from the regdump indicated that you're still in L2 despite
disconnected. Looks like the phy was unable to detect and wakeup from
the disconnection to notify the controller.

Can you experiment with setting "snps,dis_u2_susphy_quirk" to disable
usb2 phy suspend.
Adding snps,dis_u2_susphy_quirk doesn't make a difference, behavior is
identical.


Does your device support SuperSpeed? If so, do you observe the same
behavior while operating in SuperSpeed?
Just checked, still connects with superspeed. What led you to think it was
only high speed?

Bit(4) of event info (0003) from device event value (00030601) indicates
usb2 speed.

Register DSTS field 2:0 indicates fullspeed. Even though this was
captured after disconnection, the linkstate did not change, which led me
to think that the connected speed did not change to Es.Disable either.

Do you want me to send new traces?

Can you also try to disable usb3 phy suspend with
"snps,dis_u3_susphy_quirk" if you think it's connected in SuperSpeed?
Added this to the devicetree, but also no change in behavior.


Please capture the traces again if it's operating in SuperSpeed.
I've attached new traces. Connected at superspeed (host reports "superspeed"
in its dmesg log, and the real data transfer speed is way above highspeed)

I added register dumps before and after the disconnect.

Thanks for the trace. It's indeed operating in SuperSpeed in the
connected regdump. However, the GUSB3PIPECTL.SUSPENDENABLE is still set.
Can you double check if you properly set the "snps,dis_u3_susphy_quirk"?

The trace was made before I added the property. It doesn't change the behavior. Should I create a new trace?


--
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@xxxxxxxx
W: www.topic.nl








[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux