From: John Keeping <john@metanate.com>
To: Minas Harutyunyan <minas.harutyunyan@synopsys.com>
Cc: Felipe Balbi <balbi@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, John Youn <john.youn@synopsys.com>
Subject: usb: dwc2: gadget: Consider VBUS discharge time in disconnect flow
Date: Wed, 6 Feb 2019 18:52:43 +0000 [thread overview]
Message-ID: <20190206185243.3b35220d@donbot> (raw)
On Tue, 5 Feb 2019 12:08:48 +0400
Minas Harutyunyan <minas.harutyunyan@synopsys.com> wrote:
> If VBUS discharge time > 3ms then on device cable disconnect, core
> asserted Early Suspend then Suspend interrupts which no need to
> handle.
>
> VBUS discharge time depend on PHY schematic implementation.
> Can be up to 1 sec.
>
> To unambiguous recognize disconnect event on Early_Suspend interrupt
> added delay to allow VBUS fully discharge and as result
> GOTGCTL_BSESVLD goes to 0. If GOTGCTL_BSESVLD after delay still set
> to 1 that mean Suspend initiated by host, not by disconnect.
> In case of disconnect after Early_Suspend core asserting Suspend,
> Reset Detect and Reset interrupts which no any meaning, so these
> interrupts no need to handle and resetting in GINTSTS.
I have just tried this and it makes enumeration much slower. The host
system shows:
[1495332.243080] usb 1-2.4.7: new high-speed USB device number 89 using xhci_hcd
[1495337.399713] usb 1-2.4.7: device descriptor read/64, error -110
[1495347.779878] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[1495348.004513] usb 1-2.4.7: New USB device found, idVendor=0001, idProduct=0001, bcdDevice= 1.01
My guess is that the added delay is triggering in cases when it
shouldn't and delaying the response to the setup device command.
next reply other threads:[~2019-02-06 18:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-06 18:52 John Keeping [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-02-07 11:15 usb: dwc2: gadget: Consider VBUS discharge time in disconnect flow Felipe Balbi
2019-02-05 8:08 Minas Harutyunyan
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=20190206185243.3b35220d@donbot \
--to=john@metanate.com \
--cc=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=john.youn@synopsys.com \
--cc=linux-usb@vger.kernel.org \
--cc=minas.harutyunyan@synopsys.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.