RE: [PATCH 0/3] USB IMX Chipidea fix gpio vbus control

[Peter Chen <peter.chen@nxp.com>]

 
> > I had the problem that the vbus regulator wasn't turned off during a
> > suspend/resume logic. The first issue within the usb-core should be
> > fixed by [1] (v2 RFC is on the way). You never run in that case if you
> > don't fix this. After I fixed it the port-power is called during
> > suspend but obviously the regulator didn't get turned off because we don't add it
> to the priv->reg_vbus.
> >
> > This patchset should fix this and get rid of the
> > CI_HDRC_TURN_VBUS_EARLY_ON flag.
> >
> 
> Hi Marco,
> 
> I may understand your case now. At old USB port design, the VBUS is never
> allowed to turned off to response the USB wakeup event. But the expected behavior
> has changed after pm_qos_no_power_off is introduced for USB port, it is allowed
> the port is powered off.
> 
> PORTSC.PP could be controlled by USB core, but USB VBUS's power is not
> controlled by this bit if the VBUS power enable pin is configured as GPIO function,
> that is your case.
> 
> CI_HDRC_TURN_VBUS_EARLY_ON is introduced by fixing a bug that some i.mx
> USB controllers PHY's power is sourced from VBUS, the PHY's power need to be
> on before touch some ehci registers, otherwise, the USB signal will be wrong at
> some low speed devices use case. So, this flag can't be deleted, it may cause
> regression.
> 
> The solution I see is your may need to implement chipidea VBUS control flow by
> considering pm_qos_no_power_off at suspend situation. You may add .suspend
> API for ci_role_driver, and called by ci_controller_suspend/ci_controller_resume, of
> cos, better solution is welcome.
> 

Or you keep refcount for VBUS regulator on/off, if VBUS is already on, don't re-turn on
again. Do not consider CI_HDRC_TURN_VBUS_EARLY_ON after probe, and let
the USB core handle pm_qos_no_power_off, and call .ehci_ci_portpower accordingly.

Peter