From: Martin Kepplinger <martin.kepplinger@puri.sm>
To: "mathias.nyman@intel.com" <mathias.nyman@intel.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
Felipe Balbi <balbi@kernel.org>,
"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
nicolas.ferre@microchip.com, ludovic.desroches@microchip.com,
cristian.birsan@microchip.com, iain.galloway@nxp.com
Cc: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"kernel@puri.sm" <kernel@puri.sm>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Microchip USB2642 Hub not resuming from USB autosuspend
Date: Tue, 26 May 2020 09:04:12 +0200 [thread overview]
Message-ID: <8738e4d3-62b1-0144-107d-ff42000ed6c6@puri.sm> (raw)
hi all,
our Librem 5 includes the microchip USB2642 hub with
integrated/connected SD cardcreader (and we connect the baseband modem
to it): https://www.microchip.com/wwwproducts/en/USB2642
When we remove the (integrated) SD cardreader entirely (in sysfs), the
Hub suspends as long as the modem doesn't need a connection. But then
the modem fails to *resume* the Hub. Linux xhci host times out and dies
during resuming, which leaves a system without the Hub entirely. You can
see some logs and tests here
https://source.puri.sm/Librem5/linux-next/issues/170#note_89808 (when
scrolling down).
Microchip says the their product has the following bug which results in
our problem:
https://microchipsupport.force.com/s/article/Device-attached-to-Hub-Downstream-Facing-Port-does-not-Resume-from-Suspend
(that may or may not be the real and only reason for our problem)
That issue suggests working around it in the HC by somehow
sending "HS SOF as soon as possible after the HS RESUME EOP".
We use imx8mq and the dwc3 driver for the designware USB hardware that
NXP documents in chapter 11.1.3 of the reference manual:
https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors/i-mx-8m-family-armcortex-a53-cortex-m4-audio-voice-video:i.MX8M?tab=Documentation_Tab
What can we try to change in dwc3 or xhci drivers in order to achieve
sending SOF earlier after resume?
What else that I don't currently think of could lead to the USB
suspend/resume problem here?
I'm happy for any hint, question or thought about this and hope that
this is useful for others too.
thanks,
martin
p.s.: A follow-up for Microchip: The Hub doesn't suspend when the SD
cardreader is connected *without* and SD card inserted (as described
above, we remove the cardreader for testing here). What could cause this?
next reply other threads:[~2020-05-26 7:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-26 7:04 Martin Kepplinger [this message]
2020-06-10 10:25 ` Microchip USB2642 Hub not resuming from USB autosuspend Martin Kepplinger
2020-06-23 13:48 ` Martin Kepplinger
2020-06-23 14:54 ` Alan Stern
2020-06-24 7:22 ` Martin Kepplinger
2020-06-24 14:45 ` Alan Stern
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=8738e4d3-62b1-0144-107d-ff42000ed6c6@puri.sm \
--to=martin.kepplinger@puri.sm \
--cc=balbi@kernel.org \
--cc=cristian.birsan@microchip.com \
--cc=gregkh@linuxfoundation.org \
--cc=iain.galloway@nxp.com \
--cc=kernel@puri.sm \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=ludovic.desroches@microchip.com \
--cc=mathias.nyman@intel.com \
--cc=nicolas.ferre@microchip.com \
--cc=p.zabel@pengutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).