| Message ID | 20161110150152.GA27724@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Tony, On Thursday 10 Nov 2016 08:01:52 Tony Lindgren wrote: > * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161110 05:46]: > > On Monday 07 Nov 2016 14:50:16 Tony Lindgren wrote: > > > Hi all, > > > > > > Here are musb fixes for the issues that I've been able to track down. > > > Not sure if these will help with the problem Ladis was seeing as I'm > > > not able to reproduce that one it seems. > > > > > > As many people depend on this driver I'd like to have these merged > > > for v4.9-rc cycle after review and testing. > > > > > > Please review and test. You need to use v4.9-rc3 or later for testing > > > because of the earlier fixes. > > > > The series fixes my problems, both with the original and latest version of > > patch 2/4. > > > > Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > OK good to hear and thanks for testing. > > > I have however seen the following warning once with the original version > > of 2/4. > > > > [ 3.094116] usb 1-1: New USB device found, idVendor=0424, > > idProduct=9514 > > [ 3.101257] usb 1-1: New USB device strings: Mfr=0, Product=0, > > SerialNumber=0 [ 3.110626] ------------[ cut here ]------------ > > [ 3.110717] WARNING: CPU: 0 PID: 4 at > > /home/laurent/src/kernel/omap4/linux-2.6/drivers/bus/omap_l3_noc.c:147 > > l3_interrupt_handler+0x220/0x348 [ 3.110717] 44000000.ocp:L3 Custom > > Error: MASTER MPU TARGET L4CFG (Read): Data Access in User mode during > > Functional access > I've seen similar with interconnect target was not ready in time > on ti81xx when booting that got fixed with commit ebf244148092 > ("ARM: OMAP2+: Use srst_udelay for USB on dm814x"). It is possible > that omap4 needs similar fix but hard to say unless we have it > reproducable. Anyways, below is an untested patch for omap4 to play > with. Maybe repeated reboot or modprobe test would make it > reproducable? I'll try to give it a go, but right now I'm stuck with a different MUSB problem :-) I'm trying to boot my panda board over the SMSC95xx ethernet, and have switched gadget support from being compiled in to being compiled as a module. I then get [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while active printed in a loop at boot time. I've traced musb->is_active being set to 1 in musb_start() with musb->port_mode = MUSB_PORT_MODE_DUAL_ROLE musb->xceiv->otg->state = OTG_STATE_A_IDLE devctl = MUSB_DEVCTL_BDEVICE | MUSB_DEVCTL_VBUS I can disable gadget support completely which will I believe fix the problem, but that's just a workaround. Help would be appreciated. > 8< ------------------------------ > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c --- > a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > @@ -2982,6 +2982,7 @@ static struct omap_hwmod_class_sysconfig > omap44xx_usb_otg_hs_sysc = { .rev_offs = 0x0400, > .sysc_offs = 0x0404, > .syss_offs = 0x0408, > + .srst_udelay = 2, > .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP | > SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE | > SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
On Thursday 10 Nov 2016 19:18:23 Laurent Pinchart wrote: > On Thursday 10 Nov 2016 08:01:52 Tony Lindgren wrote: > > * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161110 05:46]: > >> On Monday 07 Nov 2016 14:50:16 Tony Lindgren wrote: > >>> Hi all, > >>> > >>> Here are musb fixes for the issues that I've been able to track down. > >>> Not sure if these will help with the problem Ladis was seeing as I'm > >>> not able to reproduce that one it seems. > >>> > >>> As many people depend on this driver I'd like to have these merged > >>> for v4.9-rc cycle after review and testing. > >>> > >>> Please review and test. You need to use v4.9-rc3 or later for testing > >>> because of the earlier fixes. > >> > >> The series fixes my problems, both with the original and latest version > >> of > >> patch 2/4. > >> > >> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > > > OK good to hear and thanks for testing. > > > > I have however seen the following warning once with the original version > >> of 2/4. > >> > >> [ 3.094116] usb 1-1: New USB device found, idVendor=0424, > >> idProduct=9514 > >> [ 3.101257] usb 1-1: New USB device strings: Mfr=0, Product=0, > >> SerialNumber=0 [ 3.110626] ------------[ cut here ]------------ > >> [ 3.110717] WARNING: CPU: 0 PID: 4 at > >> /home/laurent/src/kernel/omap4/linux-2.6/drivers/bus/omap_l3_noc.c:147 > >> l3_interrupt_handler+0x220/0x348 [ 3.110717] 44000000.ocp:L3 Custom > >> Error: MASTER MPU TARGET L4CFG (Read): Data Access in User mode during > >> Functional access > > > > I've seen similar with interconnect target was not ready in time > > on ti81xx when booting that got fixed with commit ebf244148092 > > ("ARM: OMAP2+: Use srst_udelay for USB on dm814x"). It is possible > > that omap4 needs similar fix but hard to say unless we have it > > reproducable. Anyways, below is an untested patch for omap4 to play > > with. Maybe repeated reboot or modprobe test would make it > > reproducable? > > I'll try to give it a go, but right now I'm stuck with a different MUSB > problem :-) I'm trying to boot my panda board over the SMSC95xx ethernet, > and have switched gadget support from being compiled in to being compiled > as a module. I then get > > [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while > active > > printed in a loop at boot time. I've traced musb->is_active being set to 1 > in musb_start() with > > musb->port_mode = MUSB_PORT_MODE_DUAL_ROLE > musb->xceiv->otg->state = OTG_STATE_A_IDLE > devctl = MUSB_DEVCTL_BDEVICE | MUSB_DEVCTL_VBUS > > I can disable gadget support completely which will I believe fix the > problem, but that's just a workaround. Help would be appreciated. And on a side note, selecting CONFIG_USB_GADGET=m makes it impossible to build CONFIG_USB_NOT_XCEIV=y, making OMAP3 EHCI support only available as a module. *sigh* :-) Felipe, git blame points at you, can this be fixed ? > > 8< ------------------------------ > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > > b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c --- > > a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > > @@ -2982,6 +2982,7 @@ static struct omap_hwmod_class_sysconfig > > omap44xx_usb_otg_hs_sysc = { .rev_offs = 0x0400, > > > > .sysc_offs = 0x0404, > > .syss_offs = 0x0408, > > > > + .srst_udelay = 2, > > > > .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP | > > > > SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE | > > SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
On Thursday 10 Nov 2016 19:18:23 Laurent Pinchart wrote: > Hi Tony, > > On Thursday 10 Nov 2016 08:01:52 Tony Lindgren wrote: > > * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161110 05:46]: > > > On Monday 07 Nov 2016 14:50:16 Tony Lindgren wrote: > > > > Hi all, > > > > > > > > Here are musb fixes for the issues that I've been able to track down. > > > > Not sure if these will help with the problem Ladis was seeing as I'm > > > > not able to reproduce that one it seems. > > > > > > > > As many people depend on this driver I'd like to have these merged > > > > for v4.9-rc cycle after review and testing. > > > > > > > > Please review and test. You need to use v4.9-rc3 or later for testing > > > > because of the earlier fixes. > > > > > > The series fixes my problems, both with the original and latest version > > > of > > > patch 2/4. > > > > > > Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > > > OK good to hear and thanks for testing. > > > > > I have however seen the following warning once with the original version > > > of 2/4. > > > > > > [ 3.094116] usb 1-1: New USB device found, idVendor=0424, > > > idProduct=9514 > > > [ 3.101257] usb 1-1: New USB device strings: Mfr=0, Product=0, > > > SerialNumber=0 [ 3.110626] ------------[ cut here ]------------ > > > [ 3.110717] WARNING: CPU: 0 PID: 4 at > > > /home/laurent/src/kernel/omap4/linux-2.6/drivers/bus/omap_l3_noc.c:147 > > > l3_interrupt_handler+0x220/0x348 [ 3.110717] 44000000.ocp:L3 Custom > > > Error: MASTER MPU TARGET L4CFG (Read): Data Access in User mode during > > > Functional access > > > > I've seen similar with interconnect target was not ready in time > > on ti81xx when booting that got fixed with commit ebf244148092 > > ("ARM: OMAP2+: Use srst_udelay for USB on dm814x"). It is possible > > that omap4 needs similar fix but hard to say unless we have it > > reproducable. Anyways, below is an untested patch for omap4 to play > > with. Maybe repeated reboot or modprobe test would make it > > reproducable? > > I'll try to give it a go, but right now I'm stuck with a different MUSB > problem :-) I'm trying to boot my panda board over the SMSC95xx ethernet, > and have switched gadget support from being compiled in to being compiled > as a module. I then get > > [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while > active > > printed in a loop at boot time. I've traced musb->is_active being set to 1 > in musb_start() with > > musb->port_mode = MUSB_PORT_MODE_DUAL_ROLE > musb->xceiv->otg->state = OTG_STATE_A_IDLE > devctl = MUSB_DEVCTL_BDEVICE | MUSB_DEVCTL_VBUS > > I can disable gadget support completely which will I believe fix the > problem, but that's just a workaround. Help would be appreciated. Turns out it doesn't :-( CONFIG_USB_MUSB_HDRC=y CONFIG_USB_MUSB_HOST=y # CONFIG_USB_GADGET is not set and the problem still occurs. > > 8< ------------------------------ > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > > b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c --- > > a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > > @@ -2982,6 +2982,7 @@ static struct omap_hwmod_class_sysconfig > > omap44xx_usb_otg_hs_sysc = { .rev_offs = 0x0400, > > > > .sysc_offs = 0x0404, > > .syss_offs = 0x0408, > > > > + .srst_udelay = 2, > > > > .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP | > > > > SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE | > > SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161110 10:18]: > I'll try to give it a go, but right now I'm stuck with a different MUSB > problem :-) I'm trying to boot my panda board over the SMSC95xx ethernet, and > have switched gadget support from being compiled in to being compiled as a > module. I then get > > [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while active > > printed in a loop at boot time. I've traced musb->is_active being set to 1 in > musb_start() with > > musb->port_mode = MUSB_PORT_MODE_DUAL_ROLE > musb->xceiv->otg->state = OTG_STATE_A_IDLE > devctl = MUSB_DEVCTL_BDEVICE | MUSB_DEVCTL_VBUS > > I can disable gadget support completely which will I believe fix the problem, > but that's just a workaround. Help would be appreciated. Do you have the ID pin grounded or how do you get to the A_IDLE state? I'm pretty much only testing with loadable modules as in omap2plus_defconfig, I don't think I've seen this issue.. Maybe check the changes in your .config against just plain omap2plus_defconfig? Are you trying to force host only mode? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tony, On Thursday 10 Nov 2016 10:50:33 Tony Lindgren wrote: > * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161110 10:18]: > > I'll try to give it a go, but right now I'm stuck with a different MUSB > > problem :-) I'm trying to boot my panda board over the SMSC95xx ethernet, > > and have switched gadget support from being compiled in to being compiled > > as a module. I then get > > > > [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while > > active > > > > printed in a loop at boot time. I've traced musb->is_active being set to 1 > > in musb_start() with > > > > musb->port_mode = MUSB_PORT_MODE_DUAL_ROLE > > musb->xceiv->otg->state = OTG_STATE_A_IDLE > > devctl = MUSB_DEVCTL_BDEVICE | MUSB_DEVCTL_VBUS > > > > I can disable gadget support completely which will I believe fix the > > problem, but that's just a workaround. Help would be appreciated. > > Do you have the ID pin grounded I've measured it on the board and I don't. Booting with the USB cable unplugged and the board powered through the power jack gives the same result. > or how do you get to the A_IDLE state? Don't ask me :-) > I'm pretty much only testing with loadable modules as in > omap2plus_defconfig, I don't think I've seen this issue.. > > Maybe check the changes in your .config against just plain > omap2plus_defconfig? Are you trying to force host only mode? I started anew from omap2plus_defconfig and applied the following changes to enable NFS root. -CONFIG_USB_NET_DRIVERS=m -CONFIG_USB_USBNET=m -CONFIG_USB_NET_SMSC95XX=m -CONFIG_USB=m -CONFIG_USB_EHCI_HCD=m -CONFIG_USB_EHCI_HCD_OMAP=m -CONFIG_NOP_USB_XCEIV=m -CONFIG_USB_GADGET=m -CONFIG_OMAP_USB2=m +CONFIG_USB_NET_DRIVERS=y +CONFIG_USB_USBNET=y +CONFIG_USB_NET_SMSC95XX=y +CONFIG_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_HCD_OMAP=y +CONFIG_NOP_USB_XCEIV=y +# CONFIG_USB_GADGET is not set +CONFIG_OMAP_USB2=y I had to disable CONFIG_USB_GADGET is compiling it as a module prevents selecting CONFIG_NOP_USB_XCEIV=y, which is a dependency for CONFIG_USB_EHCI_HCD_OMAP=m. The new configuration resulted in a few changes, among which the most notable is -# CONFIG_USB_MUSB_HOST is not set -# CONFIG_USB_MUSB_GADGET is not set -CONFIG_USB_MUSB_DUAL_ROLE=y +CONFIG_USB_MUSB_HOST=y I then get the same error as originally reported.
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161110 13:29]: > I had to disable CONFIG_USB_GADGET is compiling it as a module prevents > selecting CONFIG_NOP_USB_XCEIV=y, which is a dependency for > CONFIG_USB_EHCI_HCD_OMAP=m. > > The new configuration resulted in a few changes, among which the most notable > is > > -# CONFIG_USB_MUSB_HOST is not set > -# CONFIG_USB_MUSB_GADGET is not set > -CONFIG_USB_MUSB_DUAL_ROLE=y > +CONFIG_USB_MUSB_HOST=y > > I then get the same error as originally reported. Yeah OK, that's the problem.. We still have musb hardware trying to do things on it's own and phy trying to detect the state. Any ideas why we have a dependency like that in Kconfig? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tony, On Thursday 10 Nov 2016 22:29:34 Laurent Pinchart wrote: > On Thursday 10 Nov 2016 10:50:33 Tony Lindgren wrote: > > * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161110 10:18]: > > > I'll try to give it a go, but right now I'm stuck with a different MUSB > > > problem :-) I'm trying to boot my panda board over the SMSC95xx > > > ethernet, and have switched gadget support from being compiled in to > > > being compiled as a module. I then get > > > > > > [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while > > > active > > > > > > printed in a loop at boot time. I've traced musb->is_active being set to > > > 1 in musb_start() with > > > > > > musb->port_mode = MUSB_PORT_MODE_DUAL_ROLE > > > musb->xceiv->otg->state = OTG_STATE_A_IDLE > > > devctl = MUSB_DEVCTL_BDEVICE | MUSB_DEVCTL_VBUS > > > > > > I can disable gadget support completely which will I believe fix the > > > problem, but that's just a workaround. Help would be appreciated. > > > > Do you have the ID pin grounded > > I've measured it on the board and I don't. Booting with the USB cable > unplugged and the board powered through the power jack gives the same > result. > > or how do you get to the A_IDLE state? > > Don't ask me :-) > > > I'm pretty much only testing with loadable modules as in > > omap2plus_defconfig, I don't think I've seen this issue.. > > > > Maybe check the changes in your .config against just plain > > omap2plus_defconfig? Are you trying to force host only mode? > > I started anew from omap2plus_defconfig and applied the following changes to > enable NFS root. > > -CONFIG_USB_NET_DRIVERS=m > -CONFIG_USB_USBNET=m > -CONFIG_USB_NET_SMSC95XX=m > -CONFIG_USB=m > -CONFIG_USB_EHCI_HCD=m > -CONFIG_USB_EHCI_HCD_OMAP=m > -CONFIG_NOP_USB_XCEIV=m > -CONFIG_USB_GADGET=m > -CONFIG_OMAP_USB2=m > +CONFIG_USB_NET_DRIVERS=y > +CONFIG_USB_USBNET=y > +CONFIG_USB_NET_SMSC95XX=y > +CONFIG_USB=y > +CONFIG_USB_EHCI_HCD=y > +CONFIG_USB_EHCI_HCD_OMAP=y > +CONFIG_NOP_USB_XCEIV=y > +# CONFIG_USB_GADGET is not set > +CONFIG_OMAP_USB2=y > > I had to disable CONFIG_USB_GADGET is compiling it as a module prevents > selecting CONFIG_NOP_USB_XCEIV=y, which is a dependency for > CONFIG_USB_EHCI_HCD_OMAP=m. > > The new configuration resulted in a few changes, among which the most > notable is > > -# CONFIG_USB_MUSB_HOST is not set > -# CONFIG_USB_MUSB_GADGET is not set > -CONFIG_USB_MUSB_DUAL_ROLE=y > +CONFIG_USB_MUSB_HOST=y > > I then get the same error as originally reported. Actually disabling CONFIG_USB_MUSB_HDRC gets rid of the problem, quite understandably. It's not a fix though, just a workaround. Are you interested in investigating this ?
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161110 14:26]: > On Thursday 10 Nov 2016 22:29:34 Laurent Pinchart wrote: > Actually disabling CONFIG_USB_MUSB_HDRC gets rid of the problem, quite > understandably. It's not a fix though, just a workaround. Are you interested > in investigating this ? OK I think I have my hands full already.. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tony, On Thursday 10 Nov 2016 13:42:34 Tony Lindgren wrote: > * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161110 13:29]: > > I had to disable CONFIG_USB_GADGET is compiling it as a module prevents > > selecting CONFIG_NOP_USB_XCEIV=y, which is a dependency for > > CONFIG_USB_EHCI_HCD_OMAP=m. > > > > The new configuration resulted in a few changes, among which the most > > notable is > > > > -# CONFIG_USB_MUSB_HOST is not set > > -# CONFIG_USB_MUSB_GADGET is not set > > -CONFIG_USB_MUSB_DUAL_ROLE=y > > +CONFIG_USB_MUSB_HOST=y > > > > I then get the same error as originally reported. > > Yeah OK, that's the problem.. We still have musb hardware > trying to do things on it's own and phy trying to detect > the state. > > Any ideas why we have a dependency like that in Kconfig? Well, with CONFIG_USB_GADGET disabled, I don't expect CONFIG_USB_MUSB_GADGET to be enabled. MUSB can only operate in host mode in that case, so musb- >xceiv->otg->state = OTG_STATE_A_IDLE makes sense.
Hello, On Friday 11 Nov 2016 00:27:52 Laurent Pinchart wrote: > On Thursday 10 Nov 2016 13:42:34 Tony Lindgren wrote: > > * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161110 13:29]: > >> I had to disable CONFIG_USB_GADGET is compiling it as a module prevents > >> selecting CONFIG_NOP_USB_XCEIV=y, which is a dependency for > >> CONFIG_USB_EHCI_HCD_OMAP=m. > >> > >> The new configuration resulted in a few changes, among which the most > >> notable is > >> > >> -# CONFIG_USB_MUSB_HOST is not set > >> -# CONFIG_USB_MUSB_GADGET is not set > >> -CONFIG_USB_MUSB_DUAL_ROLE=y > >> +CONFIG_USB_MUSB_HOST=y > >> > >> I then get the same error as originally reported. > > > > Yeah OK, that's the problem.. We still have musb hardware > > trying to do things on it's own and phy trying to detect > > the state. > > > > Any ideas why we have a dependency like that in Kconfig? > > Well, with CONFIG_USB_GADGET disabled, I don't expect CONFIG_USB_MUSB_GADGET > to be enabled. MUSB can only operate in host mode in that case, so musb-> > xceiv->otg->state = OTG_STATE_A_IDLE makes sense. I've tried to investigate this but I'm not familiar enough with the MUSB driver to reach any conclusion. Felipe, if you have time could you give me a hand ? To summarize the issue, on a pandaboard-es where the MUSB is wired to an OTG connector with mode rightfully set to MUSB_PORT_MODE_DUAL_ROLE in DT, a kernel configured with CONFIG_USB_MUSB_HOST=y (for instance because CONFIG_USB_GADGET is disabled) will print an endless stream of the following meessage. [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while active musb_init_controller() performs the following actions case MUSB_PORT_MODE_DUAL_ROLE: status = musb_host_setup(musb, plat->power); if (status < 0) goto fail3; status = musb_gadget_setup(musb); if (status) { musb_host_cleanup(musb); goto fail3; } status = musb_platform_set_mode(musb, MUSB_OTG); break; and as gadget support is disabled musb_gadget_setup() compiles to a no-op inline function. The system is thus configured in host mode by musb_host_setup() with musb->xceiv->otg->state = OTG_STATE_A_IDLE. A later call to musb_start() verifies the condition if (musb->port_mode != MUSB_PORT_MODE_HOST && musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON && (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) { and sets musb->is_active to 1. Later, musb_bus_suspend() complains because is_active is not 0. What is wrong in that sequence ?
On Fri, Nov 11, 2016 at 01:39:28AM +0200, Laurent Pinchart wrote: > Hello, > > On Friday 11 Nov 2016 00:27:52 Laurent Pinchart wrote: > > On Thursday 10 Nov 2016 13:42:34 Tony Lindgren wrote: > > > * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161110 13:29]: > > >> I had to disable CONFIG_USB_GADGET is compiling it as a module prevents > > >> selecting CONFIG_NOP_USB_XCEIV=y, which is a dependency for > > >> CONFIG_USB_EHCI_HCD_OMAP=m. > > >> > > >> The new configuration resulted in a few changes, among which the most > > >> notable is > > >> > > >> -# CONFIG_USB_MUSB_HOST is not set > > >> -# CONFIG_USB_MUSB_GADGET is not set > > >> -CONFIG_USB_MUSB_DUAL_ROLE=y > > >> +CONFIG_USB_MUSB_HOST=y > > >> > > >> I then get the same error as originally reported. > > > > > > Yeah OK, that's the problem.. We still have musb hardware > > > trying to do things on it's own and phy trying to detect > > > the state. > > > > > > Any ideas why we have a dependency like that in Kconfig? > > > > Well, with CONFIG_USB_GADGET disabled, I don't expect CONFIG_USB_MUSB_GADGET > > to be enabled. MUSB can only operate in host mode in that case, so musb-> > > xceiv->otg->state = OTG_STATE_A_IDLE makes sense. > > I've tried to investigate this but I'm not familiar enough with the MUSB > driver to reach any conclusion. Felipe, if you have time could you give me a > hand ? > > To summarize the issue, on a pandaboard-es where the MUSB is wired to an OTG > connector with mode rightfully set to MUSB_PORT_MODE_DUAL_ROLE in DT, a kernel > configured with CONFIG_USB_MUSB_HOST=y (for instance because CONFIG_USB_GADGET > is disabled) will print an endless stream of the following meessage. > > [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while active I don't have a omap3/4 platform to test on this, but I don't see this problem on am335x board. > > musb_init_controller() performs the following actions > > case MUSB_PORT_MODE_DUAL_ROLE: > status = musb_host_setup(musb, plat->power); > if (status < 0) > goto fail3; > status = musb_gadget_setup(musb); > if (status) { > musb_host_cleanup(musb); > goto fail3; > } > status = musb_platform_set_mode(musb, MUSB_OTG); > break; > > and as gadget support is disabled musb_gadget_setup() compiles to a no-op > inline function. The system is thus configured in host mode by > musb_host_setup() with musb->xceiv->otg->state = OTG_STATE_A_IDLE. A later > call to musb_start() verifies the condition > > if (musb->port_mode != MUSB_PORT_MODE_HOST && > musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON && > (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) { To get there, devctl[MUSB_DEVCTL_VBUS] bits have to be set, where does the vbus voltage come from? Session is not on yet. > > and sets musb->is_active to 1. Later, musb_bus_suspend() complains because > is_active is not 0. > > What is wrong in that sequence ? > > -- > Regards, > > Laurent Pinchart > Regards, -Bin. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Bin Liu <b-liu@ti.com> [161111 08:25]: > On Fri, Nov 11, 2016 at 01:39:28AM +0200, Laurent Pinchart wrote: > > Hello, > > > > On Friday 11 Nov 2016 00:27:52 Laurent Pinchart wrote: > > > On Thursday 10 Nov 2016 13:42:34 Tony Lindgren wrote: > > > > * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161110 13:29]: > > > >> I had to disable CONFIG_USB_GADGET is compiling it as a module prevents > > > >> selecting CONFIG_NOP_USB_XCEIV=y, which is a dependency for > > > >> CONFIG_USB_EHCI_HCD_OMAP=m. > > > >> > > > >> The new configuration resulted in a few changes, among which the most > > > >> notable is > > > >> > > > >> -# CONFIG_USB_MUSB_HOST is not set > > > >> -# CONFIG_USB_MUSB_GADGET is not set > > > >> -CONFIG_USB_MUSB_DUAL_ROLE=y > > > >> +CONFIG_USB_MUSB_HOST=y > > > >> > > > >> I then get the same error as originally reported. > > > > > > > > Yeah OK, that's the problem.. We still have musb hardware > > > > trying to do things on it's own and phy trying to detect > > > > the state. > > > > > > > > Any ideas why we have a dependency like that in Kconfig? > > > > > > Well, with CONFIG_USB_GADGET disabled, I don't expect CONFIG_USB_MUSB_GADGET > > > to be enabled. MUSB can only operate in host mode in that case, so musb-> > > > xceiv->otg->state = OTG_STATE_A_IDLE makes sense. > > > > I've tried to investigate this but I'm not familiar enough with the MUSB > > driver to reach any conclusion. Felipe, if you have time could you give me a > > hand ? > > > > To summarize the issue, on a pandaboard-es where the MUSB is wired to an OTG > > connector with mode rightfully set to MUSB_PORT_MODE_DUAL_ROLE in DT, a kernel > > configured with CONFIG_USB_MUSB_HOST=y (for instance because CONFIG_USB_GADGET > > is disabled) will print an endless stream of the following meessage. > > > > [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while active > > I don't have a omap3/4 platform to test on this, but I don't see this > problem on am335x board. > > > > > musb_init_controller() performs the following actions > > > > case MUSB_PORT_MODE_DUAL_ROLE: > > status = musb_host_setup(musb, plat->power); > > if (status < 0) > > goto fail3; > > status = musb_gadget_setup(musb); > > if (status) { > > musb_host_cleanup(musb); > > goto fail3; > > } > > status = musb_platform_set_mode(musb, MUSB_OTG); > > break; > > > > and as gadget support is disabled musb_gadget_setup() compiles to a no-op > > inline function. The system is thus configured in host mode by > > musb_host_setup() with musb->xceiv->otg->state = OTG_STATE_A_IDLE. A later > > call to musb_start() verifies the condition > > > > if (musb->port_mode != MUSB_PORT_MODE_HOST && > > musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON && > > (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) { > > To get there, devctl[MUSB_DEVCTL_VBUS] bits have to be set, where does the > vbus voltage come from? Session is not on yet. > > > > > and sets musb->is_active to 1. Later, musb_bus_suspend() complains because > > is_active is not 0. > > > > What is wrong in that sequence ? I think the issue is pandaboard connected to a PC with mini-B cable while musb is being forced to host mode? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, On Friday 11 Nov 2016 08:53:22 Tony Lindgren wrote: > * Bin Liu <b-liu@ti.com> [161111 08:25]: > > On Fri, Nov 11, 2016 at 01:39:28AM +0200, Laurent Pinchart wrote: > >> Hello, > >> > >> On Friday 11 Nov 2016 00:27:52 Laurent Pinchart wrote: > >>> On Thursday 10 Nov 2016 13:42:34 Tony Lindgren wrote: > >>>> * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161110 13:29]: > >>>>> I had to disable CONFIG_USB_GADGET is compiling it as a module > >>>>> prevents selecting CONFIG_NOP_USB_XCEIV=y, which is a dependency for > >>>>> CONFIG_USB_EHCI_HCD_OMAP=m. > >>>>> > >>>>> The new configuration resulted in a few changes, among which the > >>>>> most notable is > >>>>> > >>>>> -# CONFIG_USB_MUSB_HOST is not set > >>>>> -# CONFIG_USB_MUSB_GADGET is not set > >>>>> -CONFIG_USB_MUSB_DUAL_ROLE=y > >>>>> +CONFIG_USB_MUSB_HOST=y > >>>>> > >>>>> I then get the same error as originally reported. > >>>> > >>>> Yeah OK, that's the problem.. We still have musb hardware > >>>> trying to do things on it's own and phy trying to detect > >>>> the state. > >>>> > >>>> Any ideas why we have a dependency like that in Kconfig? > >>> > >>> Well, with CONFIG_USB_GADGET disabled, I don't expect > >>> CONFIG_USB_MUSB_GADGET to be enabled. MUSB can only operate in host > >>> mode in that case, so musb-> xceiv->otg->state = OTG_STATE_A_IDLE > >>> makes sense. > >> > >> I've tried to investigate this but I'm not familiar enough with the MUSB > >> driver to reach any conclusion. Felipe, if you have time could you give > >> me a hand ? > >> > >> To summarize the issue, on a pandaboard-es where the MUSB is wired to an > >> OTG connector with mode rightfully set to MUSB_PORT_MODE_DUAL_ROLE in > >> DT, a kernel configured with CONFIG_USB_MUSB_HOST=y (for instance > >> because CONFIG_USB_GADGET is disabled) will print an endless stream of > >> the following meessage. > >> > >> [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while > >> active > > > > I don't have a omap3/4 platform to test on this, but I don't see this > > problem on am335x board. Which board is that ? For the problem to occur the board has to have an OTG connector. > >> musb_init_controller() performs the following actions > >> > >> case MUSB_PORT_MODE_DUAL_ROLE: > >> status = musb_host_setup(musb, plat->power); > >> if (status < 0) > >> goto fail3; > >> status = musb_gadget_setup(musb); > >> if (status) { > >> musb_host_cleanup(musb); > >> goto fail3; > >> } > >> status = musb_platform_set_mode(musb, MUSB_OTG); > >> break; > >> > >> and as gadget support is disabled musb_gadget_setup() compiles to a > >> no-op inline function. The system is thus configured in host mode by > >> musb_host_setup() with musb->xceiv->otg->state = OTG_STATE_A_IDLE. A > >> later call to musb_start() verifies the condition > >> > >> if (musb->port_mode != MUSB_PORT_MODE_HOST && > >> musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON && > >> (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) { > > > > To get there, devctl[MUSB_DEVCTL_VBUS] bits have to be set, where does the > > vbus voltage come from? Session is not on yet. MUSB_DEVCTL is first set to 0 by musb_generic_disable() called from musb_init_controller(). The register is then left untouched (as far as I can tell, I've intercepted all musb_writeb() and musb_readb() calls) until musb_start() to reads the register. The read value has BDEVICE and VBUS=3 set. > >> and sets musb->is_active to 1. Later, musb_bus_suspend() complains > >> because is_active is not 0. > >> > >> What is wrong in that sequence ? > > I think the issue is pandaboard connected to a PC with mini-B > cable while musb is being forced to host mode? The issue also occurs when the cable isn't connected.
On Sat, Nov 12, 2016 at 12:11:04AM +0200, Laurent Pinchart wrote: > Hello, > > On Friday 11 Nov 2016 08:53:22 Tony Lindgren wrote: > > * Bin Liu <b-liu@ti.com> [161111 08:25]: > > > On Fri, Nov 11, 2016 at 01:39:28AM +0200, Laurent Pinchart wrote: > > >> Hello, > > >> > > >> On Friday 11 Nov 2016 00:27:52 Laurent Pinchart wrote: > > >>> On Thursday 10 Nov 2016 13:42:34 Tony Lindgren wrote: > > >>>> * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161110 13:29]: > > >>>>> I had to disable CONFIG_USB_GADGET is compiling it as a module > > >>>>> prevents selecting CONFIG_NOP_USB_XCEIV=y, which is a dependency for > > >>>>> CONFIG_USB_EHCI_HCD_OMAP=m. > > >>>>> > > >>>>> The new configuration resulted in a few changes, among which the > > >>>>> most notable is > > >>>>> > > >>>>> -# CONFIG_USB_MUSB_HOST is not set > > >>>>> -# CONFIG_USB_MUSB_GADGET is not set > > >>>>> -CONFIG_USB_MUSB_DUAL_ROLE=y > > >>>>> +CONFIG_USB_MUSB_HOST=y > > >>>>> > > >>>>> I then get the same error as originally reported. > > >>>> > > >>>> Yeah OK, that's the problem.. We still have musb hardware > > >>>> trying to do things on it's own and phy trying to detect > > >>>> the state. > > >>>> > > >>>> Any ideas why we have a dependency like that in Kconfig? > > >>> > > >>> Well, with CONFIG_USB_GADGET disabled, I don't expect > > >>> CONFIG_USB_MUSB_GADGET to be enabled. MUSB can only operate in host > > >>> mode in that case, so musb-> xceiv->otg->state = OTG_STATE_A_IDLE > > >>> makes sense. > > >> > > >> I've tried to investigate this but I'm not familiar enough with the MUSB > > >> driver to reach any conclusion. Felipe, if you have time could you give > > >> me a hand ? > > >> > > >> To summarize the issue, on a pandaboard-es where the MUSB is wired to an > > >> OTG connector with mode rightfully set to MUSB_PORT_MODE_DUAL_ROLE in > > >> DT, a kernel configured with CONFIG_USB_MUSB_HOST=y (for instance > > >> because CONFIG_USB_GADGET is disabled) will print an endless stream of > > >> the following meessage. > > >> > > >> [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while > > >> active > > > > > > I don't have a omap3/4 platform to test on this, but I don't see this > > > problem on am335x board. > > Which board is that ? For the problem to occur the board has to have an OTG > connector. It is the TI am335x GP EVM, which usb0 port has an otg receptacle, and a power switch controlled by usb0 drvvbus pin. > > > >> musb_init_controller() performs the following actions > > >> > > >> case MUSB_PORT_MODE_DUAL_ROLE: > > >> status = musb_host_setup(musb, plat->power); > > >> if (status < 0) > > >> goto fail3; > > >> status = musb_gadget_setup(musb); > > >> if (status) { > > >> musb_host_cleanup(musb); > > >> goto fail3; > > >> } > > >> status = musb_platform_set_mode(musb, MUSB_OTG); > > >> break; > > >> > > >> and as gadget support is disabled musb_gadget_setup() compiles to a > > >> no-op inline function. The system is thus configured in host mode by > > >> musb_host_setup() with musb->xceiv->otg->state = OTG_STATE_A_IDLE. A > > >> later call to musb_start() verifies the condition > > >> > > >> if (musb->port_mode != MUSB_PORT_MODE_HOST && > > >> musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON && > > >> (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) { > > > > > > To get there, devctl[MUSB_DEVCTL_VBUS] bits have to be set, where does the > > > vbus voltage come from? Session is not on yet. > > MUSB_DEVCTL is first set to 0 by musb_generic_disable() called from > musb_init_controller(). The register is then left untouched (as far as I can > tell, I've intercepted all musb_writeb() and musb_readb() calls) until > musb_start() to reads the register. The read value has BDEVICE and VBUS=3 set. The DEVCTL_VBUS bits are set by the controller, when it sense VBUS voltage > VBUS_VALID. > > > >> and sets musb->is_active to 1. Later, musb_bus_suspend() complains > > >> because is_active is not 0. > > >> > > >> What is wrong in that sequence ? > > > > I think the issue is pandaboard connected to a PC with mini-B > > cable while musb is being forced to host mode? > > The issue also occurs when the cable isn't connected. If the otg port is not connected to a host but you still get VBUS=3, the vbus voltage must be provided from the board itself. We have to check the schematics to see how it is possible. This is pandaboard es, right? Assume I will be able to find its schematics on internet... > > -- > Regards, > > Laurent Pinchart > Regards, -Bin. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Bin, On Friday 11 Nov 2016 17:06:02 Bin Liu wrote: > On Sat, Nov 12, 2016 at 12:11:04AM +0200, Laurent Pinchart wrote: > > On Friday 11 Nov 2016 08:53:22 Tony Lindgren wrote: > >> * Bin Liu <b-liu@ti.com> [161111 08:25]: > >>> On Fri, Nov 11, 2016 at 01:39:28AM +0200, Laurent Pinchart wrote: > >>>> On Friday 11 Nov 2016 00:27:52 Laurent Pinchart wrote: > >>>>> On Thursday 10 Nov 2016 13:42:34 Tony Lindgren wrote: > >>>>>> * Laurent Pinchart [161110 13:29]: > >>>>>>> I had to disable CONFIG_USB_GADGET is compiling it as a module > >>>>>>> prevents selecting CONFIG_NOP_USB_XCEIV=y, which is a dependency > >>>>>>> for CONFIG_USB_EHCI_HCD_OMAP=m. > >>>>>>> > >>>>>>> The new configuration resulted in a few changes, among which the > >>>>>>> most notable is > >>>>>>> > >>>>>>> -# CONFIG_USB_MUSB_HOST is not set > >>>>>>> -# CONFIG_USB_MUSB_GADGET is not set > >>>>>>> -CONFIG_USB_MUSB_DUAL_ROLE=y > >>>>>>> +CONFIG_USB_MUSB_HOST=y > >>>>>>> > >>>>>>> I then get the same error as originally reported. > >>>>>> > >>>>>> Yeah OK, that's the problem.. We still have musb hardware > >>>>>> trying to do things on it's own and phy trying to detect > >>>>>> the state. > >>>>>> > >>>>>> Any ideas why we have a dependency like that in Kconfig? > >>>>> > >>>>> Well, with CONFIG_USB_GADGET disabled, I don't expect > >>>>> CONFIG_USB_MUSB_GADGET to be enabled. MUSB can only operate in host > >>>>> mode in that case, so musb-> xceiv->otg->state = OTG_STATE_A_IDLE > >>>>> makes sense. > >>>> > >>>> I've tried to investigate this but I'm not familiar enough with the > >>>> MUSB driver to reach any conclusion. Felipe, if you have time could > >>>> you give me a hand ? > >>>> > >>>> To summarize the issue, on a pandaboard-es where the MUSB is wired to > >>>> an OTG connector with mode rightfully set to MUSB_PORT_MODE_DUAL_ROLE > >>>> in DT, a kernel configured with CONFIG_USB_MUSB_HOST=y (for instance > >>>> because CONFIG_USB_GADGET is disabled) will print an endless stream > >>>> of the following meessage. > >>>> > >>>> [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle > >>>> while active > >>> > >>> I don't have a omap3/4 platform to test on this, but I don't see this > >>> problem on am335x board. > > > > Which board is that ? For the problem to occur the board has to have an > > OTG connector. > > It is the TI am335x GP EVM, which usb0 port has an otg receptacle, and a > power switch controlled by usb0 drvvbus pin. > > >>>> musb_init_controller() performs the following actions > >>>> > >>>> case MUSB_PORT_MODE_DUAL_ROLE: > >>>> status = musb_host_setup(musb, plat->power); > >>>> if (status < 0) > >>>> goto fail3; > >>>> status = musb_gadget_setup(musb); > >>>> if (status) { > >>>> musb_host_cleanup(musb); > >>>> goto fail3; > >>>> } > >>>> status = musb_platform_set_mode(musb, MUSB_OTG); > >>>> break; > >>>> > >>>> and as gadget support is disabled musb_gadget_setup() compiles to a > >>>> no-op inline function. The system is thus configured in host mode by > >>>> musb_host_setup() with musb->xceiv->otg->state = OTG_STATE_A_IDLE. A > >>>> later call to musb_start() verifies the condition > >>>> > >>>> if (musb->port_mode != MUSB_PORT_MODE_HOST && > >>>> musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON && > >>>> (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) { > >>> > >>> To get there, devctl[MUSB_DEVCTL_VBUS] bits have to be set, where does > >>> the vbus voltage come from? Session is not on yet. > > > > MUSB_DEVCTL is first set to 0 by musb_generic_disable() called from > > musb_init_controller(). The register is then left untouched (as far as I > > can tell, I've intercepted all musb_writeb() and musb_readb() calls) > > until musb_start() to reads the register. The read value has BDEVICE and > > VBUS=3 set. > > The DEVCTL_VBUS bits are set by the controller, when it sense VBUS > voltage > VBUS_VALID. > > >>>> and sets musb->is_active to 1. Later, musb_bus_suspend() complains > >>>> because is_active is not 0. > >>>> > >>>> What is wrong in that sequence ? > >> > >> I think the issue is pandaboard connected to a PC with mini-B > >> cable while musb is being forced to host mode? > > > > The issue also occurs when the cable isn't connected. > > If the otg port is not connected to a host but you still get VBUS=3, the > vbus voltage must be provided from the board itself. We have to check > the schematics to see how it is possible. This is pandaboard es, right? > Assume I will be able to find its schematics on internet... http://pandaboard.org/sites/default/files/board_reference/ES/750-2170-002-sch_revb.pdf It would seem that the voltage is provided by the TWL6030. I'm not sure what's turning it on as the MUSB driver doesn't seem to perform any set_vbus call in the faulty configuration (I've traced musb_platform_set_vbus(), omap2430_musb_set_vbus(), otg_set_vbus(), omap_usb_set_vbus() and twl6030_set_vbus() and none of them get called). An interesting point to note is that the TWL6030 gets probed after MUSB when MUSB is configured in host mode only, and that happens after the call to musb_start().
On 10/11/16 23:25, Laurent Pinchart wrote: >>>> [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while >>>> active >>>> >>>> printed in a loop at boot time. I've traced musb->is_active being set to >>>> 1 in musb_start() with > Actually disabling CONFIG_USB_MUSB_HDRC gets rid of the problem, quite > understandably. It's not a fix though, just a workaround. Are you interested > in investigating this ? I'm seeing this too. Did you manage to boot your Panda? If I disable CONFIG_USB_MUSB_HDRC, I don't see that error print, but the ethernet doesn't work, and so my nfsroot doesn't mount. Tomi
Hi Tomi, On Wednesday 23 Nov 2016 12:14:17 Tomi Valkeinen wrote: > On 10/11/16 23:25, Laurent Pinchart wrote: > >>>> [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while > >>>> active > >>>> > >>>> printed in a loop at boot time. I've traced musb->is_active being set > >>>> to 1 in musb_start() with > > > > Actually disabling CONFIG_USB_MUSB_HDRC gets rid of the problem, quite > > understandably. It's not a fix though, just a workaround. Are you > > interested in investigating this ? > > I'm seeing this too. Did you manage to boot your Panda? If I disable > CONFIG_USB_MUSB_HDRC, I don't see that error print, but the ethernet > doesn't work, and so my nfsroot doesn't mount. Do you use ethernet over USB gadget or over LAN9514 (smsx95xx) ? The LAN9514 is connected to the EHCI USB interface so it shouldn't depend on MUSB. I've attached my .config to this e-mail.
On 23/11/16 17:49, Laurent Pinchart wrote: > Hi Tomi, > > On Wednesday 23 Nov 2016 12:14:17 Tomi Valkeinen wrote: >> On 10/11/16 23:25, Laurent Pinchart wrote: >>>>>> [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while >>>>>> active >>>>>> >>>>>> printed in a loop at boot time. I've traced musb->is_active being set >>>>>> to 1 in musb_start() with >>> >>> Actually disabling CONFIG_USB_MUSB_HDRC gets rid of the problem, quite >>> understandably. It's not a fix though, just a workaround. Are you >>> interested in investigating this ? >> >> I'm seeing this too. Did you manage to boot your Panda? If I disable >> CONFIG_USB_MUSB_HDRC, I don't see that error print, but the ethernet >> doesn't work, and so my nfsroot doesn't mount. > > Do you use ethernet over USB gadget or over LAN9514 (smsx95xx) ? The LAN9514 > is connected to the EHCI USB interface so it shouldn't depend on MUSB. smsx95xx. I didn't look at it further, so possibly there's something else broken/changed that prevented the ethernet from working. Tomi
* Tomi Valkeinen <tomi.valkeinen@ti.com> [161123 07:54]: > On 23/11/16 17:49, Laurent Pinchart wrote: > > Hi Tomi, > > > > On Wednesday 23 Nov 2016 12:14:17 Tomi Valkeinen wrote: > >> On 10/11/16 23:25, Laurent Pinchart wrote: > >>>>>> [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while > >>>>>> active > >>>>>> > >>>>>> printed in a loop at boot time. I've traced musb->is_active being set > >>>>>> to 1 in musb_start() with > >>> > >>> Actually disabling CONFIG_USB_MUSB_HDRC gets rid of the problem, quite > >>> understandably. It's not a fix though, just a workaround. Are you > >>> interested in investigating this ? > >> > >> I'm seeing this too. Did you manage to boot your Panda? If I disable > >> CONFIG_USB_MUSB_HDRC, I don't see that error print, but the ethernet > >> doesn't work, and so my nfsroot doesn't mount. > > > > Do you use ethernet over USB gadget or over LAN9514 (smsx95xx) ? The LAN9514 > > is connected to the EHCI USB interface so it shouldn't depend on MUSB. > > smsx95xx. I didn't look at it further, so possibly there's something > else broken/changed that prevented the ethernet from working. I have omap2plus_defconfig with initramfs work just fine for nfsroot and musb peripheral mode on pandaboard es. Well I have not tried it since last week with Linux next. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tomi Valkeinen <tomi.valkeinen@ti.com> [161123 08:13]: > On 23/11/16 17:57, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [161123 07:54]: > >> On 23/11/16 17:49, Laurent Pinchart wrote: > >>> Hi Tomi, > >>> > >>> On Wednesday 23 Nov 2016 12:14:17 Tomi Valkeinen wrote: > >>>> On 10/11/16 23:25, Laurent Pinchart wrote: > >>>>>>>> [ 2.766174] musb_bus_suspend 2586: trying to suspend as a_idle while > >>>>>>>> active > >>>>>>>> > >>>>>>>> printed in a loop at boot time. I've traced musb->is_active being set > >>>>>>>> to 1 in musb_start() with > >>>>> > >>>>> Actually disabling CONFIG_USB_MUSB_HDRC gets rid of the problem, quite > >>>>> understandably. It's not a fix though, just a workaround. Are you > >>>>> interested in investigating this ? > >>>> > >>>> I'm seeing this too. Did you manage to boot your Panda? If I disable > >>>> CONFIG_USB_MUSB_HDRC, I don't see that error print, but the ethernet > >>>> doesn't work, and so my nfsroot doesn't mount. > >>> > >>> Do you use ethernet over USB gadget or over LAN9514 (smsx95xx) ? The LAN9514 > >>> is connected to the EHCI USB interface so it shouldn't depend on MUSB. > >> > >> smsx95xx. I didn't look at it further, so possibly there's something > >> else broken/changed that prevented the ethernet from working. > > > > I have omap2plus_defconfig with initramfs work just fine for nfsroot > > and musb peripheral mode on pandaboard es. Well I have not tried it > > since last week with Linux next. > > Ok, I found the issue. I had to enable CONFIG_NOP_USB_XCEIV. (the > musb_bus_suspend issue is still there, though). OK. And what changes to your current .config make the musb_bus_suspend() issues show up? If it happens with USB-B cable from host to musb with musb set to host only mode I'm not suprised there are errors :) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tomi Valkeinen <tomi.valkeinen@ti.com> [161123 08:40]: > On 23/11/16 18:34, Tony Lindgren wrote: > > > OK. And what changes to your current .config make the musb_bus_suspend() > > issues show up? > > > > If it happens with USB-B cable from host to musb with musb set to host > > only mode I'm not suprised there are errors :) > > I have no USB cables connected. I have attached my config. If > CONFIG_USB_MUSB_HDRC is disabled, the musb error goes away. Maybe compare against omap2plus_defconfig? If you have musb set to host only mode it still tries to follow the ID pin from phy and do things on it's own. And ID pin is floating in B mode and with no cable connected. AFAIK, the only sane configuration for musb is the OTG mode because the hardware tries to do things on it's own. And the host only mode only really works if phy has ID pin grounded or else the phy has to do trickery to rewrite the state to musb. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161123 08:44]: > Hello, > > On Wednesday 23 Nov 2016 18:40:09 Tomi Valkeinen wrote: > > On 23/11/16 18:34, Tony Lindgren wrote: > > > OK. And what changes to your current .config make the musb_bus_suspend() > > > issues show up? > > > > > > If it happens with USB-B cable from host to musb with musb set to host > > > only mode I'm not suprised there are errors :) > > > > I have no USB cables connected. I have attached my config. If > > CONFIG_USB_MUSB_HDRC is disabled, the musb error goes away. > > For what it's worth, that's exactly the same problem I experienced. See > https://www.spinics.net/lists/linux-usb/msg149172.html for an analysis. The problem is that with the built-in musb configuration we're trying to set USB-B cable to host mode with ID pin not grounded. That's not going to work on most hardware unless the PHY can configure the ID pin. Here's how to fix the .config for built-in musb: 1. Change to have CONFIG_USB_GADGET=y 2. Then change CONFIG_USB_MUSB_DUAL_ROLE=y instead of CONFIG_USB_MUSB_HOST We should probably get rid of CONFIG_USB_MUSB_HOST to avoid this. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tony, On Wednesday 07 Dec 2016 21:51:23 Tony Lindgren wrote: > * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161123 08:44]: > > On Wednesday 23 Nov 2016 18:40:09 Tomi Valkeinen wrote: > >> On 23/11/16 18:34, Tony Lindgren wrote: > >>> OK. And what changes to your current .config make the > >>> musb_bus_suspend() issues show up? > >>> > >>> If it happens with USB-B cable from host to musb with musb set to host > >>> only mode I'm not suprised there are errors :) > >> > >> I have no USB cables connected. I have attached my config. If > >> CONFIG_USB_MUSB_HDRC is disabled, the musb error goes away. > > > > For what it's worth, that's exactly the same problem I experienced. See > > https://www.spinics.net/lists/linux-usb/msg149172.html for an analysis. > > The problem is that with the built-in musb configuration we're trying to > set USB-B cable to host mode with ID pin not grounded. That's not going > to work on most hardware unless the PHY can configure the ID pin. > > Here's how to fix the .config for built-in musb: > > 1. Change to have CONFIG_USB_GADGET=y > > 2. Then change CONFIG_USB_MUSB_DUAL_ROLE=y instead of CONFIG_USB_MUSB_HOST > > We should probably get rid of CONFIG_USB_MUSB_HOST to avoid this. The reason I went for host mode is that I had to disable CONFIG_USB_GADGET as compiling it as a module prevents selecting CONFIG_NOP_USB_XCEIV=y, which is a dependency for CONFIG_USB_EHCI_HCD_OMAP=m. config NOP_USB_XCEIV tristate "NOP USB Transceiver Driver" depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, NOP can't be built-in select USB_PHY
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161208 04:03]: > Hi Tony, > > On Wednesday 07 Dec 2016 21:51:23 Tony Lindgren wrote: > > * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161123 08:44]: > > > On Wednesday 23 Nov 2016 18:40:09 Tomi Valkeinen wrote: > > >> On 23/11/16 18:34, Tony Lindgren wrote: > > >>> OK. And what changes to your current .config make the > > >>> musb_bus_suspend() issues show up? > > >>> > > >>> If it happens with USB-B cable from host to musb with musb set to host > > >>> only mode I'm not suprised there are errors :) > > >> > > >> I have no USB cables connected. I have attached my config. If > > >> CONFIG_USB_MUSB_HDRC is disabled, the musb error goes away. > > > > > > For what it's worth, that's exactly the same problem I experienced. See > > > https://www.spinics.net/lists/linux-usb/msg149172.html for an analysis. > > > > The problem is that with the built-in musb configuration we're trying to > > set USB-B cable to host mode with ID pin not grounded. That's not going > > to work on most hardware unless the PHY can configure the ID pin. > > > > Here's how to fix the .config for built-in musb: > > > > 1. Change to have CONFIG_USB_GADGET=y > > > > 2. Then change CONFIG_USB_MUSB_DUAL_ROLE=y instead of CONFIG_USB_MUSB_HOST > > > > We should probably get rid of CONFIG_USB_MUSB_HOST to avoid this. > > The reason I went for host mode is that I had to disable CONFIG_USB_GADGET as > compiling it as a module prevents selecting CONFIG_NOP_USB_XCEIV=y, which is a > dependency for CONFIG_USB_EHCI_HCD_OMAP=m. OK well like I said the CONFIG_USB_MUSB_HOST selection for a USB-B cable won't work from the hardware point of view. The only case where it works is if the PHY ID pin is grounded. Anything else will be flakey and won't prevent musb from attempting to change it's state on it's own. > config NOP_USB_XCEIV > tristate "NOP USB Transceiver Driver" > depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, NOP can't be > built-in > select USB_PHY No idea why it's done that way.. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -2982,6 +2982,7 @@ static struct omap_hwmod_class_sysconfig omap44xx_usb_otg_hs_sysc = { .rev_offs = 0x0400, .sysc_offs = 0x0404, .syss_offs = 0x0408, + .srst_udelay = 2, .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP | SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),