quoted

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.

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel