public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Looijmans <mike.looijmans@topic.nl>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state
Date: Tue, 11 Jun 2024 06:59:07 +0200	[thread overview]
Message-ID: <2cd9d6ad-7154-486c-b64c-e5ea1ecd17c9@topic.nl> (raw)
In-Reply-To: <20240607225731.2d24p4as4x7mrfaf@synopsys.com>

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@topic.nl
W: www.topic.nl




  reply	other threads:[~2024-06-11  4:59 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.c5f44c79-75b2-43c1-a791-806fe8b693cd@emailsignatures365.codetwo.com>
2024-06-03 13:13 ` [PATCH] usb: dwc3: gadget: Inform system of suspended state Mike Looijmans
2024-06-04  1:03   ` Thinh Nguyen
2024-06-04  5:26     ` Mike Looijmans
2024-06-04  6:45       ` Krishna Kurapati PSSNV
2024-06-04  8:25         ` Mike Looijmans
2024-06-04  8:52           ` Krishna Kurapati PSSNV
2024-06-04 23:06       ` Thinh Nguyen
2024-06-05 14:32         ` Mike Looijmans
2024-06-06  0:28           ` Thinh Nguyen
2024-06-06  5:52             ` Mike Looijmans
2024-06-06 15:11             ` Mike Looijmans
2024-06-06 20:21               ` Thinh Nguyen
2024-06-07  6:10                 ` Mike Looijmans
2024-06-07 22:57                   ` Thinh Nguyen
2024-06-11  4:59                     ` Mike Looijmans [this message]
2024-06-11  8:02                     ` Mike Looijmans
2024-06-13  0:32                       ` Thinh Nguyen
2024-06-13  8:51                         ` Mike Looijmans
2024-06-17 23:46                           ` Thinh Nguyen
2024-06-18  0:26                             ` Thinh Nguyen
2024-06-05 14:41         ` Mike Looijmans
2024-06-06  0:29           ` Thinh Nguyen
2026-03-05  9:45             ` Ravineet Singh
2026-03-06  2:06               ` Thinh Nguyen
2026-03-06 12:07                 ` Ravineet Singh
2026-03-06 23:05                   ` Thinh Nguyen
2026-03-09  9:52                     ` Ravineet Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2cd9d6ad-7154-486c-b64c-e5ea1ecd17c9@topic.nl \
    --to=mike.looijmans@topic.nl \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox