>
> Hi Fabio, Peter, Stefan,
>
> I've incidentally discovered your last year discussion in ML [1] (I hope it rings the
> bell) regarding the issue I'm still observing on the same device with the mainline
> kernel.
>
> The difference between i.MX 6ULL EVK and this particular device, is that usbotg2 is
> used only in host mode with the usb hub integrated on the carrier board [2] [3].
>
> root@colibri-imx6:~# lsusb -s 1:1 --tree
> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ci_hdrc/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
>
> However I can't reproduce the same behavior with i.MX 6ULL EVK with connected
> usb hub to usbotg2. Also this behavior can't be reproduced with NXP downstream
> kernel (Linux version 4.9.144) on my device.
>
> After digging in a bit I found out that this happens only when autosuspend is
> enabled for the usb controller:
> echo auto > /sys/bus/usb/devices/1-1/power/control
>
> It tries to go to suspend mode, but everytime fails and resumes:
> root@colibri-imx6:~# cat /sys/bus/usb/devices/1-1/power/runtime_status
> suspended
> root@colibri-imx6:~# cat /sys/bus/usb/devices/1-1/power/runtime_status
> resuming
> root@colibri-imx6:~# cat /sys/bus/usb/devices/1-1/power/runtime_status
> suspended
> root@colibri-imx6:~# cat /sys/bus/usb/devices/1-1/power/runtime_status
> suspended
> root@colibri-imx6:~# cat /sys/bus/usb/devices/1-1/power/runtime_status
> suspended
> root@colibri-imx6:~# cat /sys/bus/usb/devices/1-1/power/runtime_status
> resuming
>
> I'm observing ~2 seconds wakeup interrupts handled in ci_irq() in core.c and
> subsequent invocation of imx_controller_resume().
>
> Meantime usboh3 remains enabled all the time (though
> imx_disable_unprepare_clks() should disable it):
> root@colibri-imx6:~# cat /sys/kernel/debug/clk/clk_summary | grep usb
> usbphy2_gate 1 1 0 0
> 0 0 50000
> usbphy1_gate 1 1 0 0
> 0 0 50000
> pll7_usb_host 1 1 0 480000000
> 0 0 50000
> usbphy2 1 1 0 480000000
> 0 0 50000
> pll3_usb_otg 2 3 0 480000000
> 0 0 50000
> usbphy1 0 0 0 480000000
> 0 0 50000
> usboh3 1 1 0 66000000
> 0 0 50000
>
> While I'm trying to localize the root cause, maybe you can give some hints where to
> look into?
>
Would you please look below two downstream patches see if it helps?
commit e8e95658fe75f3873e06d5ad72a6bf0bad40f068
Author: Li Jun <jun.li@xxxxxxx>
Date: Mon Oct 16 23:13:19 2017 +0800
MLK-16576 usb: phy: mxs: set hold_ring_off for USB2 PLL power up
USB2 PLL use ring VCO, when the PLL power up, the ring VCO’s supply also
ramp up. There is a possibility that the ring VCO start oscillation at
multi nodes in this phase, especially for VCO which has many stages, then
the multiwave will kept until PLL power down. Hold_ring_off(bit11) can
force the VCO in one determined state when VCO supply start ramp up, to
avoid this multiwave issue. Per IC design's suggestion it's better this
bit can be off from 25us after pll power up to 25us before USB TX/RX.
commit aa4680d844a340a5b6b60484f6e04cb9ba613c65
Author: Peter Chen <peter.chen@xxxxxxx>
Date: Wed Sep 7 12:16:59 2016 +0800
MLK-13125 usb: phy: phy-mxs-usb: enable weak 1p1 regulator for imx6ul during suspend
For imx6ul PHY, when the system enters suspend, its 1p1 is off by default,
that may cause the PHY get inaccurate USB DP/DM value. If the USB wakeup
is enabled at this time, the unexpected wakeup may occur when the system
enters suspend.
In this patch, when the vbus is there, we enable weak 1p1 during the PHY
suspend API, in that case, the USB DP/DM will be accurate for USB PHY,
then unexpected usb wakeup will not be occurred, especially for the USB
charger is connected scenario. The user needs to enable PHY wakeup for
USB wakeup function using below setting.
Peter
> Thanks for helping me!
>
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmarc.info%2
> F%3Fl%3Dlinux-
> usb%26m%3D151844741732751&data=02%7C01%7Cpeter.chen%40nxp.co
> m%7Cb61742d4ff4646c2cb9408d740d735fe%7C686ea1d3bc2b4c6fa92cd99c5c30
> 1635%7C0%7C0%7C637049165376859788&sdata=eZdOVCuyVyA502DgwoN
> 16QmU5WDknrqCK5xmEbIovAE%3D&reserved=0
> [2]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
> 2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Farch%2Farm%2Fboot%2Fdts%2Fimx6
> ull-
> colibri.dtsi%23L191&data=02%7C01%7Cpeter.chen%40nxp.com%7Cb61742d
> 4ff4646c2cb9408d740d735fe%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> 0%7C637049165376859788&sdata=7%2FVP15v1XGeQzweIu%2FaGhJEt1ov
> Tn4zl%2F3pghKBcGlw%3D&reserved=0
> [3]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
> 2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Farch%2Farm%2Fboot%2Fdts%2Fimx6
> ull-colibri-eval-
> v3.dtsi%23L143&data=02%7C01%7Cpeter.chen%40nxp.com%7Cb61742d4ff4
> 646c2cb9408d740d735fe%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
> C637049165376859788&sdata=M43BXrJedKgszOJkZ9W4h5bqQo9WBaxe7C
> L4tAD2Ouk%3D&reserved=0
>
> --
> Best regards - Freundliche Grüsse - Meilleures salutations
>
> Igor Opaniuk
>
> mailto: igor.opaniuk@xxxxxxxxx
> skype: igor.opanyuk
> +380 (93) 836 40 67
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fua.linkedin.co
> m%2Fin%2Fiopaniuk&data=02%7C01%7Cpeter.chen%40nxp.com%7Cb61742
> d4ff4646c2cb9408d740d735fe%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C0%7C637049165376859788&sdata=qzgWZaeraIUjiLG24s9x%2BUQEnRrJ2
> TiRKD%2F6ndna4Ws%3D&reserved=0
