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