W dniu 05.06.2015 05:38, Peter Chen pisze: > On Fri, Jun 05, 2015 at 12:12:19AM +0200, Maciej S. Szmigiero wrote: >> Hi Peter, >> >>> All imx usb controller's non core registers uses the same clock gate with >>> core registers, the usbmisc_imx is the library for imx glue driver, the >>> glue keeps clock on when it calls usbmisc_imx API to change non-core register. >>> >>> Besides, we will support runtime pm in the future, it also needs to >>> close this clock when the usb is not in use. >>> >>> Philipp Zabel also verifies it at imx6q platform, see >>> http://www.spinics.net/lists/linux-usb/msg118491.html >>> >>> Cc: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> >>> Signed-off-by: Peter Chen <peter.chen@xxxxxxxxxxxxx> >>> --- >>> drivers/usb/chipidea/usbmisc_imx.c | 19 ------------------- >>> 1 file changed, 19 deletions(-) >> >> This commit causes hard lockup when loading ci_hdrc_imx module >> on my iMX6DL (UDOO Dual) board. >> >> Specifically, on current git the lockup happens on read from USBNC >> register in usbmisc_imx6q_set_wakeup() in usbmisc_imx. > > The core and NC use the same clock (ahb clock), and the ci_hdrc_imx.c should already > enable the clock before calling usbmisc_imx6q_set_wakeup, would you > help dump stack to see what happens? Here is stack dump just before taking a spinlock before mentioned read: [ 894.687524] CPU: 0 PID: 1329 Comm: modprobe Not tainted 4.1.0-rc6-01105-g34c5d61-dirty #22 [ 894.695896] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 894.702561] [<8010f154>] (unwind_backtrace) from [<8010b7c8>] (show_stack+0x10/0x14) [ 894.710398] [<8010b7c8>] (show_stack) from [<805ae654>] (dump_stack+0x84/0x94) [ 894.717736] [<805ae654>] (dump_stack) from [<7f1bb3cc>] (usbmisc_imx6q_set_wakeup+0x38/0xf4 [usbmisc_imx]) [ 894.727456] [<7f1bb3cc>] (usbmisc_imx6q_set_wakeup [usbmisc_imx]) from [<7f1bb4bc>] (usbmisc_imx6q_init+0x34/0xa8 [usbmisc_imx]) [ 894.739087] [<7f1bb4bc>] (usbmisc_imx6q_init [usbmisc_imx]) from [<7f1bb090>] (imx_usbmisc_init+0x28/0x34 [usbmisc_imx]) [ 894.749996] [<7f1bb090>] (imx_usbmisc_init [usbmisc_imx]) from [<7f1c344c>] (ci_hdrc_imx_probe+0x1bc/0x2d8 [ci_hdrc_imx]) [ 894.761011] [<7f1c344c>] (ci_hdrc_imx_probe [ci_hdrc_imx]) from [<803ff3dc>] (platform_drv_probe+0x44/0xa4) [ 894.770785] [<803ff3dc>] (platform_drv_probe) from [<803fdc74>] (driver_probe_device+0x20c/0x410) [ 894.779699] [<803fdc74>] (driver_probe_device) from [<803fdf48>] (__driver_attach+0x8c/0x90) [ 894.788171] [<803fdf48>] (__driver_attach) from [<803fbf38>] (bus_for_each_dev+0x60/0x94) [ 894.796394] [<803fbf38>] (bus_for_each_dev) from [<803fd22c>] (bus_add_driver+0x160/0x21c) [ 894.804688] [<803fd22c>] (bus_add_driver) from [<803fe318>] (driver_register+0x78/0xf8) [ 894.812796] [<803fe318>] (driver_register) from [<801016bc>] (do_one_initcall+0xd8/0x214) [ 894.821020] [<801016bc>] (do_one_initcall) from [<805abcdc>] (do_init_module+0x60/0x1b4) [ 894.829146] [<805abcdc>] (do_init_module) from [<80193654>] (load_module+0x1d58/0x21c8) [ 894.837172] [<80193654>] (load_module) from [<80193ba4>] (SyS_init_module+0xe0/0x154) [ 894.845035] [<80193ba4>] (SyS_init_module) from [<80107dc0>] (ret_fast_syscall+0x0/0x3c) > Besides, have you added clock property at your usbotg node? That was a good lead, I've looked at imx6qdl-udoo.dtsi definition of usbh1 USB host device and it overrides clock property from imx6qdl.dtsi (USBOH3) with a clock that is used to drive on-board USB hub. After commenting out this line in imx6qdl-udoo.dtsi the SoC no longer locked up, but USB still don't work due to lack of hub clocking. Previously, looks like this has worked because USBOH3 clock is also used in usbmisc clock property and so was enabled there until this commit. Now, there is a question where to put this USB hub clock, since ci_hdrc seems to support just one clock definition. Is there any generic clock consumer driver that can be used for this? Best regards, Maciej Szmigiero -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
