Microchip USB2642 Hub not resuming from USB autosuspend

Microchip USB2642 Hub not resuming from USB autosuspend

[Martin Kepplinger]

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?

Re: Microchip USB2642 Hub not resuming from USB autosuspend

[Martin Kepplinger]

On 26.05.20 09:04, Martin Kepplinger wrote:
> 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?
> 

Here's what USB traffic is going on when the connected (modem) device
tries to resume the Hub, which fails:

https://source.puri.sm/snippets/382

you can see 1.3.x (SD cardreader) is being removed (manually) for this
test (otherwise the Hub would never suspend). And I marked where I
called the modem in order to resume...

What could I try to change in order to improve my situation and make the
Hub resume?


btw, I'm still trying to get access to the DWC USB3 "programming guide"
that is even reference in the mainline kernel docs:
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/usb/dwc3.txt#L101

thanks,
                              martin

Re: Microchip USB2642 Hub not resuming from USB autosuspend

[Martin Kepplinger]

On 26.05.20 09:04, Martin Kepplinger wrote:
> 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?

For future reference: We've been able to make the Hub resume when not
applying any quirks to dwc3.

> 
> 
> 
> 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?
> 

We've resolved this issue too. When scsi (sd) runtime pm is not enabled
by default, it needs to be enabled of course and events_dfl_poll_msecs
for the block layer set to 0.

scsi sd has until now incomplete support for runtime pm and this
addition makes it work, i.e. suspend when not mounted:
https://lore.kernel.org/linux-scsi/20200623111018.31954-1-martin.kepplinger@puri.sm/T/
the whole USB path is suspended as a consequence - and woken up if opened.

                                 martin

Re: Microchip USB2642 Hub not resuming from USB autosuspend

[Alan Stern]

On Tue, Jun 23, 2020 at 03:48:01PM +0200, Martin Kepplinger wrote:

> We've resolved this issue too. When scsi (sd) runtime pm is not enabled
> by default, it needs to be enabled of course and events_dfl_poll_msecs
> for the block layer set to 0.

Actually that last step isn't needed.  But if you don't do it, the device 
will wake up from runtime suspend every time the block layer polls it.  So 
you probably do want to either turn off polling or increase the polling 
interval significantly.

> scsi sd has until now incomplete support for runtime pm and this
> addition makes it work, i.e. suspend when not mounted:
> https://lore.kernel.org/linux-scsi/20200623111018.31954-1-martin.kepplinger@puri.sm/T/
> the whole USB path is suspended as a consequence - and woken up if opened.

I don't understand this.  As far as I know, runtime-PM support in the SCSI 
and block layers has been complete for many years.  If you have to do 
anything extra (like applying the patch in the email you mentioned) then 
something is broken.  The device should be able to go into runtime suspend 
just fine with the current code -- even when a file system is mounted.

Alan Stern

Re: Microchip USB2642 Hub not resuming from USB autosuspend

[Martin Kepplinger]

On 23.06.20 16:54, Alan Stern wrote:
> On Tue, Jun 23, 2020 at 03:48:01PM +0200, Martin Kepplinger wrote:
> 
>> We've resolved this issue too. When scsi (sd) runtime pm is not enabled
>> by default, it needs to be enabled of course and events_dfl_poll_msecs
>> for the block layer set to 0.
> 
> Actually that last step isn't needed.  But if you don't do it, the device 
> will wake up from runtime suspend every time the block layer polls it.  So 
> you probably do want to either turn off polling or increase the polling 
> interval significantly.

true, thanks for pointing that out. a long interval is totally an option
too.

> 
>> scsi sd has until now incomplete support for runtime pm and this
>> addition makes it work, i.e. suspend when not mounted:
>> https://lore.kernel.org/linux-scsi/20200623111018.31954-1-martin.kepplinger@puri.sm/T/
>> the whole USB path is suspended as a consequence - and woken up if opened.
> 
> I don't understand this.  As far as I know, runtime-PM support in the SCSI 
> and block layers has been complete for many years.  If you have to do 
> anything extra (like applying the patch in the email you mentioned) then 
> something is broken.  The device should be able to go into runtime suspend 
> just fine with the current code -- even when a file system is mounted.
> 

The scsi and usb layers have good implementations for runtime pm for a
long time indeed. The scsi drivers though vary: for example sr indeed
suspends when unused, when mounted and open too.

look at the sd driver in comparison though: From what I see, it "uses"
autopm (runtime pm) as it would let the device suspend, but never
resumes from it (except when removing and probing again). My suspicion
is that it's not really used for that reason.

I might be wrong of course - I usually don't look at scsi code and I'm
so thankful for feedback. That's what I read though and also what my
tests verify. Hence the patch to the sd driver that makes enabling
runtime pm result in a usable device (granted, not yet saving as much
power as it really could, but that can be added later).

so thanks for your feedback again,

                                 martin


> Alan Stern
> 

Re: Microchip USB2642 Hub not resuming from USB autosuspend

[Alan Stern]

[CC: list drastically trimmed]

On Wed, Jun 24, 2020 at 09:22:42AM +0200, Martin Kepplinger wrote:
> On 23.06.20 16:54, Alan Stern wrote:
> > I don't understand this.  As far as I know, runtime-PM support in the SCSI 
> > and block layers has been complete for many years.  If you have to do 
> > anything extra (like applying the patch in the email you mentioned) then 
> > something is broken.  The device should be able to go into runtime suspend 
> > just fine with the current code -- even when a file system is mounted.
> > 
> 
> The scsi and usb layers have good implementations for runtime pm for a
> long time indeed. The scsi drivers though vary: for example sr indeed
> suspends when unused, when mounted and open too.
> 
> look at the sd driver in comparison though: From what I see, it "uses"
> autopm (runtime pm) as it would let the device suspend, but never
> resumes from it (except when removing and probing again). My suspicion
> is that it's not really used for that reason.
> 
> I might be wrong of course - I usually don't look at scsi code and I'm
> so thankful for feedback. That's what I read though and also what my
> tests verify. Hence the patch to the sd driver that makes enabling
> runtime pm result in a usable device (granted, not yet saving as much
> power as it really could, but that can be added later).

I haven't looked at this code or tested it for a long time, so maybe it 
isn't working properly.

Still, here's the general idea of how it's _intended_ to work: The 
runtime PM control for sd lies not in the sd driver itself but in the 
block layer core.  If a SCSI drive is suspended when a block request is 
issued, the block layer initiates a runtime resume.  See the kerneldoc for 
blk_pm_runtime_init() and the following functions in block/blk-pm.c.

If you need a more detailed explanation, please ask.

Alan Stern