> > > > > > Note, I'm using a imx6q which has the CI_HDRC_TURN_VBUS_EARLY_ON set. > > > > > > > Do you have a VBUS regulator at your dts, and add it at controller's > > node? See: arch/arm/boot/dts/imx6qdl-sabresd.dtsi as an example please? > > Yes, that's my use case too. > > > If you have set CI_HDRC_TURN_VBUS_EARLY_ON, the VBUS is controlled by > > chipidea driver, not by USB core through PORTSC.PP (ehci_ci_portpower). > > I know, pls have a look my the patches. > > 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. Peter
