quoted

quoted

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.

quoted

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

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