[PATCH v3] usb: dwc2: add bus suspend/resume for dwc2

[Alan Stern]

On Thu, 13 Nov 2014, Julius Werner wrote:

> Another thing might be that the port connect interrupt does not
> correctly resume the root hub. I don't really know many details about
> how that works, and it seems pretty complicated. But I can see that
> all other HCDs seem to call usb_hcd_resume_root_hub() from their
> interrupt handlers, which we don't. There's also a

That's how a root hub sends a wakeup request to the kernel.  The
controller issues an interrupt, and when the HCD's interrupt handler
sees that the root hub is suspended, it calls usb_hcd_resume_root_hub()
instead of trying to query the hardware (because in general you _can't_
query the hardware while it's in a low-power state).

> usb_hcd_start_port_resume() in EHCI which I'm not familiar with, that
> seems to have been added recently.

usb_hcd_start_port_resume() and usb_hcd_end_port_resume() were added in 
order to fix a race.  We want to avoid suspending a root hub if a 
downstream suspended device is currently being resumed.

The HCD is supposed to call these two routines when it begins and ends
resume signalling on any of its ports.  This will prevent the core from
suspending the root hub while the port resume is in progress.

> And finally, it seems that all
> normal host controllers (UHCI/OHCI/EHCI/XHCI) now do the
> usb_hcd->uses_new_polling thing (where you're supposed to call
> hcd_poll_rh_status() from the HCD code)... the old polling code still
> seems to be in place, but without any relevant driver using I wouldn't
> be so sure if it's still functional.

It is functional.  The difference between the old and new polling
schemes isn't all that big.  In the old scheme, the core polls for root
hub status changes every 250 ms.  With the new scheme, the core doesn't
poll -- it relies on the HCD to call usb_hcd_poll_rh_status() whenever
there's a status-change interrupt.

There's also a flag the HCD can set to ask for polling even if it uses
the new scheme.  This helps in situations where the 
root-hub status-change interrupts aren't reliable (for example, if they 
are edge-triggered rather than level-triggered).

> +Alan who should know HCD/core interactions much better and might have
> some ideas what the DWC2 driver is still missing right now.

I know essentially zero about the DWC2 driver.  But I'm happy to help 
by explaining how the core mechanisms are intended to be used.

Alan Stern