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