Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)
On Fri, Apr 07, 2017 at 06:52:53AM -0700, Tony Lindgren wrote: > * Bin Liu[170406 12:09]: > > On Wed, Apr 05, 2017 at 08:29:55AM -0700, Tony Lindgren wrote: > > > If the the port is configured as OTG, we should not need to > > > try to force any states during init. The change below will stop > > > > True, but the code has been there for a very long time, any idea what > > causes the regression? > > I think it's just that with commit d8e5f0eca1e8 we now have phy enabled > earlier and calling musb_host_setup() with phy enabled sends it into > a loop of trying to force the host mode with nothing connected. This > loops seems to end after few seconds if there are devices connected, > but keeps going if there's nothing connected. Fair enough. Thanks. -Bin. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)
* Peter Ujfalusi[170406 10:07]: > Tony, > > On 04/05/2017 06:29 PM, Tony Lindgren wrote: > > * Tony Lindgren [170405 06:53]: > > > * Peter Ujfalusi [170405 00:15]: > > > > To be precise this is what I have tried: > > > > - boot w/o cable connected > > > > - boot w/ board connected to PC (device mode) > > > > - boot w/ OTG-A cable with USB keyboard > > > > - boot w/ OTG-A cable connected to powered USB hub and the same keyboard > > > > > > > > w/ and w/o this patch I have the same flood of prints in all cases. > > > > > > OK interesting that it also happens with nothing connected. > > > > > > > Fwiw I have checked where the is_active is set - which causes the > > > > prints: > > > > musb_core.c:musb_start() > > > > > > > > if (musb->port_mode != MUSB_PORT_MODE_HOST && > > > > musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON && > > > > (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) { > > > > musb->is_active = 1; > > > > } else { > > > > devctl |= MUSB_DEVCTL_SESSION; > > > > } > > > > > > > > this was the only place where the is_active was set to 1. > > > > > > That seems normal in musb_start(). Will try with your .config > > > here. > > > > If the the port is configured as OTG, we should not need to > > try to force any states during init. The change below will stop > > the warnings with your .config, needs to be tested more though > > to make sure things still work in all cases. > > With this change I can boot up without issues, thanks! OK > I can not get the kernel to react to anything I plug to the A/B connector. Yeah it seems that we have only peripheral mode working with panda, so there seems to be also a long time vbus related regression. > Keyboard (directly or via powered hub), flash drive, connecting the board to > PC. Nothing. > Actually if I connect to a PC I got a print from twl6030 about an interrupt, > but nothing happens in USB front. > > The same thing happens with 4.8, so it is not regression. Most likely it is > an error in my setup... For me peripheral mode works fine. You needs at least one gadget configured, looks like your .config has CONFIG_USB_GADGET disabled. The VBUS should be coming from twl6030 and it seems to have some vbus code. Would be nice to get the host mode working on panda too for the OTG port.. > Tested-by: Peter Ujfalusi OK thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)
* Bin Liu[170406 12:09]: > On Wed, Apr 05, 2017 at 08:29:55AM -0700, Tony Lindgren wrote: > > If the the port is configured as OTG, we should not need to > > try to force any states during init. The change below will stop > > True, but the code has been there for a very long time, any idea what > causes the regression? I think it's just that with commit d8e5f0eca1e8 we now have phy enabled earlier and calling musb_host_setup() with phy enabled sends it into a loop of trying to force the host mode with nothing connected. This loops seems to end after few seconds if there are devices connected, but keeps going if there's nothing connected. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)
On Wed, Apr 05, 2017 at 08:29:55AM -0700, Tony Lindgren wrote: > * Tony Lindgren[170405 06:53]: > > * Peter Ujfalusi [170405 00:15]: > > > To be precise this is what I have tried: > > > - boot w/o cable connected > > > - boot w/ board connected to PC (device mode) > > > - boot w/ OTG-A cable with USB keyboard > > > - boot w/ OTG-A cable connected to powered USB hub and the same keyboard > > > > > > w/ and w/o this patch I have the same flood of prints in all cases. > > > > OK interesting that it also happens with nothing connected. > > > > > Fwiw I have checked where the is_active is set - which causes the prints: > > > musb_core.c:musb_start() > > > > > > if (musb->port_mode != MUSB_PORT_MODE_HOST && > > > musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON && > > > (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) { > > > musb->is_active = 1; > > > } else { > > > devctl |= MUSB_DEVCTL_SESSION; > > > } > > > > > > this was the only place where the is_active was set to 1. > > > > That seems normal in musb_start(). Will try with your .config > > here. > > If the the port is configured as OTG, we should not need to > try to force any states during init. The change below will stop True, but the code has been there for a very long time, any idea what causes the regression? Regards, -Bin. > the warnings with your .config, needs to be tested more though > to make sure things still work in all cases. > > Regards, > > Tony > > 8< -- > diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c > --- a/drivers/usb/musb/musb_host.c > +++ b/drivers/usb/musb/musb_host.c > @@ -2780,10 +2780,11 @@ int musb_host_setup(struct musb *musb, int > power_budget) > int ret; > struct usb_hcd *hcd = musb->hcd; > > - MUSB_HST_MODE(musb); > - musb->xceiv->otg->default_a = 1; > - musb->xceiv->otg->state = OTG_STATE_A_IDLE; > - > + if (musb->port_mode == MUSB_PORT_MODE_HOST) { > + MUSB_HST_MODE(musb); > + musb->xceiv->otg->default_a = 1; > + musb->xceiv->otg->state = OTG_STATE_A_IDLE; > + } > otg_set_host(musb->xceiv->otg, >self); > hcd->self.otg_port = 1; > musb->xceiv->otg->host = >self; > -- > 2.12.2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)
Tony, On 04/05/2017 06:29 PM, Tony Lindgren wrote: * Tony Lindgren[170405 06:53]: * Peter Ujfalusi [170405 00:15]: To be precise this is what I have tried: - boot w/o cable connected - boot w/ board connected to PC (device mode) - boot w/ OTG-A cable with USB keyboard - boot w/ OTG-A cable connected to powered USB hub and the same keyboard w/ and w/o this patch I have the same flood of prints in all cases. OK interesting that it also happens with nothing connected. Fwiw I have checked where the is_active is set - which causes the prints: musb_core.c:musb_start() if (musb->port_mode != MUSB_PORT_MODE_HOST && musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON && (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) { musb->is_active = 1; } else { devctl |= MUSB_DEVCTL_SESSION; } this was the only place where the is_active was set to 1. That seems normal in musb_start(). Will try with your .config here. If the the port is configured as OTG, we should not need to try to force any states during init. The change below will stop the warnings with your .config, needs to be tested more though to make sure things still work in all cases. With this change I can boot up without issues, thanks! I can not get the kernel to react to anything I plug to the A/B connector. Keyboard (directly or via powered hub), flash drive, connecting the board to PC. Nothing. Actually if I connect to a PC I got a print from twl6030 about an interrupt, but nothing happens in USB front. The same thing happens with 4.8, so it is not regression. Most likely it is an error in my setup... Tested-by: Peter Ujfalusi Regards, Tony 8< -- diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -2780,10 +2780,11 @@ int musb_host_setup(struct musb *musb, int power_budget) int ret; struct usb_hcd *hcd = musb->hcd; - MUSB_HST_MODE(musb); - musb->xceiv->otg->default_a = 1; - musb->xceiv->otg->state = OTG_STATE_A_IDLE; - + if (musb->port_mode == MUSB_PORT_MODE_HOST) { + MUSB_HST_MODE(musb); + musb->xceiv->otg->default_a = 1; + musb->xceiv->otg->state = OTG_STATE_A_IDLE; + } otg_set_host(musb->xceiv->otg, >self); hcd->self.otg_port = 1; musb->xceiv->otg->host = >self; -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)
* Tony Lindgren[170405 06:53]: > * Peter Ujfalusi [170405 00:15]: > > To be precise this is what I have tried: > > - boot w/o cable connected > > - boot w/ board connected to PC (device mode) > > - boot w/ OTG-A cable with USB keyboard > > - boot w/ OTG-A cable connected to powered USB hub and the same keyboard > > > > w/ and w/o this patch I have the same flood of prints in all cases. > > OK interesting that it also happens with nothing connected. > > > Fwiw I have checked where the is_active is set - which causes the prints: > > musb_core.c:musb_start() > > > > if (musb->port_mode != MUSB_PORT_MODE_HOST && > > musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON && > > (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) { > > musb->is_active = 1; > > } else { > > devctl |= MUSB_DEVCTL_SESSION; > > } > > > > this was the only place where the is_active was set to 1. > > That seems normal in musb_start(). Will try with your .config > here. If the the port is configured as OTG, we should not need to try to force any states during init. The change below will stop the warnings with your .config, needs to be tested more though to make sure things still work in all cases. Regards, Tony 8< -- diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -2780,10 +2780,11 @@ int musb_host_setup(struct musb *musb, int power_budget) int ret; struct usb_hcd *hcd = musb->hcd; - MUSB_HST_MODE(musb); - musb->xceiv->otg->default_a = 1; - musb->xceiv->otg->state = OTG_STATE_A_IDLE; - + if (musb->port_mode == MUSB_PORT_MODE_HOST) { + MUSB_HST_MODE(musb); + musb->xceiv->otg->default_a = 1; + musb->xceiv->otg->state = OTG_STATE_A_IDLE; + } otg_set_host(musb->xceiv->otg, >self); hcd->self.otg_port = 1; musb->xceiv->otg->host = >self; -- 2.12.2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)
* Peter Ujfalusi[170405 00:15]: > Tony, > > On 2017-04-05 03:36, Tony Lindgren wrote: > > * Tony Lindgren [170404 07:06]: > > > * Bin Liu [170404 05:30]: > > > > On Tue, Apr 04, 2017 at 10:09:50AM +0300, Peter Ujfalusi wrote: > > > > > Tony, > > > > > > > > > > since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb > > > > > is compiled in. The kernel will stuck printing: > > > > > > > > > > ** 206 printk messages dropped ** [8.926727] musb_bus_suspend > > > > > 2584: trying to suspend as a_idle while active > > > > > > OK so compiled in. Do you have something connected also when > > > booting? > > > > > > > Does it sound a similar issue to > > > > http://marc.info/?l=linux-usb=149036531809506=2 > > > > > > Yup. > > > > > > > > The bisect (log is [1]) points to: > > > > > d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order > > > > > error > > > > > > > > > > and reverting the d8e5f0eca1e8 makes the board to boot up fine > > > > > (Linux 4.11-rc5 and next-20170331). > > > > > > OK thanks for bisecting it. > > > > > > > > any idea on how to fix this w/o reverting the commit? > > > > > > I'll take a look. > > > > OK I was able to reproduce this with loadable modules by reloading > > the modules while having OTG-A cable inserted with a hub and USB > > drive connected. > > > > Peter, care to check if the following fixes the problem for you? > > There should no longer be much any musb core tinkering happening > > in the glue layers.. > > I had similar hunch first, but did not worked. I have tested this patch and > did not helped. > > To be precise this is what I have tried: > - boot w/o cable connected > - boot w/ board connected to PC (device mode) > - boot w/ OTG-A cable with USB keyboard > - boot w/ OTG-A cable connected to powered USB hub and the same keyboard > > w/ and w/o this patch I have the same flood of prints in all cases. OK interesting that it also happens with nothing connected. > Fwiw I have checked where the is_active is set - which causes the prints: > musb_core.c:musb_start() > > if (musb->port_mode != MUSB_PORT_MODE_HOST && > musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON && > (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) { > musb->is_active = 1; > } else { > devctl |= MUSB_DEVCTL_SESSION; > } > > this was the only place where the is_active was set to 1. That seems normal in musb_start(). Will try with your .config here. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)
On 2017-04-05 10:13, Peter Ujfalusi wrote: I had similar hunch first, but did not worked. I have tested this patch and did not helped. To be precise this is what I have tried: - boot w/o cable connected - boot w/ board connected to PC (device mode) - boot w/ OTG-A cable with USB keyboard - boot w/ OTG-A cable connected to powered USB hub and the same keyboard w/ and w/o this patch I have the same flood of prints in all cases. the config I have for linux-next: https://pastebin.com/KixvyiRR Fwiw I have checked where the is_active is set - which causes the prints: musb_core.c:musb_start() if (musb->port_mode != MUSB_PORT_MODE_HOST && musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON && (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) { musb->is_active = 1; } else { devctl |= MUSB_DEVCTL_SESSION; } this was the only place where the is_active was set to 1. Regards, Tony 8< --- diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -91,12 +91,6 @@ static void omap2430_musb_set_vbus(struct musb *musb, int is_on) } otg_set_vbus(otg, 1); -} else { -musb->is_active = 1; -otg->default_a = 1; -musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; -devctl |= MUSB_DEVCTL_SESSION; -MUSB_HST_MODE(musb); } } else { musb->is_active = 0; - Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - Péter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)
Tony, On 2017-04-05 03:36, Tony Lindgren wrote: * Tony Lindgren[170404 07:06]: * Bin Liu [170404 05:30]: On Tue, Apr 04, 2017 at 10:09:50AM +0300, Peter Ujfalusi wrote: Tony, since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb is compiled in. The kernel will stuck printing: ** 206 printk messages dropped ** [8.926727] musb_bus_suspend 2584: trying to suspend as a_idle while active OK so compiled in. Do you have something connected also when booting? Does it sound a similar issue to http://marc.info/?l=linux-usb=149036531809506=2 Yup. The bisect (log is [1]) points to: d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order error and reverting the d8e5f0eca1e8 makes the board to boot up fine (Linux 4.11-rc5 and next-20170331). OK thanks for bisecting it. any idea on how to fix this w/o reverting the commit? I'll take a look. OK I was able to reproduce this with loadable modules by reloading the modules while having OTG-A cable inserted with a hub and USB drive connected. Peter, care to check if the following fixes the problem for you? There should no longer be much any musb core tinkering happening in the glue layers.. I had similar hunch first, but did not worked. I have tested this patch and did not helped. To be precise this is what I have tried: - boot w/o cable connected - boot w/ board connected to PC (device mode) - boot w/ OTG-A cable with USB keyboard - boot w/ OTG-A cable connected to powered USB hub and the same keyboard w/ and w/o this patch I have the same flood of prints in all cases. Fwiw I have checked where the is_active is set - which causes the prints: musb_core.c:musb_start() if (musb->port_mode != MUSB_PORT_MODE_HOST && musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON && (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) { musb->is_active = 1; } else { devctl |= MUSB_DEVCTL_SESSION; } this was the only place where the is_active was set to 1. Regards, Tony 8< --- diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -91,12 +91,6 @@ static void omap2430_musb_set_vbus(struct musb *musb, int is_on) } otg_set_vbus(otg, 1); - } else { - musb->is_active = 1; - otg->default_a = 1; - musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; - devctl |= MUSB_DEVCTL_SESSION; - MUSB_HST_MODE(musb); } } else { musb->is_active = 0; - Péter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)
* Tony Lindgren[170404 07:06]: > * Bin Liu [170404 05:30]: > > On Tue, Apr 04, 2017 at 10:09:50AM +0300, Peter Ujfalusi wrote: > > > Tony, > > > > > > since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb > > > is compiled in. The kernel will stuck printing: > > > > > > ** 206 printk messages dropped ** [8.926727] musb_bus_suspend > > > 2584: trying to suspend as a_idle while active > > OK so compiled in. Do you have something connected also when > booting? > > > Does it sound a similar issue to > > http://marc.info/?l=linux-usb=149036531809506=2 > > Yup. > > > > The bisect (log is [1]) points to: > > > d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order error > > > > > > and reverting the d8e5f0eca1e8 makes the board to boot up fine > > > (Linux 4.11-rc5 and next-20170331). > > OK thanks for bisecting it. > > > > any idea on how to fix this w/o reverting the commit? > > I'll take a look. OK I was able to reproduce this with loadable modules by reloading the modules while having OTG-A cable inserted with a hub and USB drive connected. Peter, care to check if the following fixes the problem for you? There should no longer be much any musb core tinkering happening in the glue layers.. Regards, Tony 8< --- diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -91,12 +91,6 @@ static void omap2430_musb_set_vbus(struct musb *musb, int is_on) } otg_set_vbus(otg, 1); - } else { - musb->is_active = 1; - otg->default_a = 1; - musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; - devctl |= MUSB_DEVCTL_SESSION; - MUSB_HST_MODE(musb); } } else { musb->is_active = 0; -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)
* Bin Liu[170404 05:30]: > On Tue, Apr 04, 2017 at 10:09:50AM +0300, Peter Ujfalusi wrote: > > Tony, > > > > since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb > > is compiled in. The kernel will stuck printing: > > > > ** 206 printk messages dropped ** [8.926727] musb_bus_suspend > > 2584: trying to suspend as a_idle while active OK so compiled in. Do you have something connected also when booting? > Does it sound a similar issue to > http://marc.info/?l=linux-usb=149036531809506=2 Yup. > > The bisect (log is [1]) points to: > > d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order error > > > > and reverting the d8e5f0eca1e8 makes the board to boot up fine > > (Linux 4.11-rc5 and next-20170331). OK thanks for bisecting it. > > any idea on how to fix this w/o reverting the commit? I'll take a look. Regards, Tony > > [1] https://pastebin.com/Z2HJY229 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)
On Tue, Apr 04, 2017 at 10:09:50AM +0300, Peter Ujfalusi wrote: > Tony, > > since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb > is compiled in. The kernel will stuck printing: > > ** 206 printk messages dropped ** [8.926727] musb_bus_suspend > 2584: trying to suspend as a_idle while active Does it sound a similar issue to http://marc.info/?l=linux-usb=149036531809506=2 Regards, -Bin. > > The bisect (log is [1]) points to: > d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order error > > and reverting the d8e5f0eca1e8 makes the board to boot up fine > (Linux 4.11-rc5 and next-20170331). > > any idea on how to fix this w/o reverting the commit? > > [1] https://pastebin.com/Z2HJY229 > > - Péter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html