[0/4] musb fixes for v4.9-rc cycle
diff mbox

Message ID 20161110150152.GA27724@atomide.com
State New
Headers show

Commit Message

Tony Lindgren Nov. 10, 2016, 3:01 p.m. UTC
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [161110 05:46]:
> Hi Tony,
> 
> Thank you for the patches.
> 
> 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?

Regards,

Tony

8< ------------------------------
--
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

Comments

Laurent Pinchart Nov. 10, 2016, 5:18 p.m. UTC | #1
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),
Laurent Pinchart Nov. 10, 2016, 5:25 p.m. UTC | #2
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),
Laurent Pinchart Nov. 10, 2016, 5:43 p.m. UTC | #3
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),
Tony Lindgren Nov. 10, 2016, 5:50 p.m. UTC | #4
* 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
Laurent Pinchart Nov. 10, 2016, 8:29 p.m. UTC | #5
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.
Tony Lindgren Nov. 10, 2016, 8:42 p.m. UTC | #6
* 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
Laurent Pinchart Nov. 10, 2016, 9:25 p.m. UTC | #7
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 ?
Tony Lindgren Nov. 10, 2016, 9:56 p.m. UTC | #8
* 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
Laurent Pinchart Nov. 10, 2016, 10:27 p.m. UTC | #9
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.
Laurent Pinchart Nov. 10, 2016, 11:39 p.m. UTC | #10
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 ?
Bin Liu Nov. 11, 2016, 4:24 p.m. UTC | #11
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
Tony Lindgren Nov. 11, 2016, 4:53 p.m. UTC | #12
* 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
Laurent Pinchart Nov. 11, 2016, 10:11 p.m. UTC | #13
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.
Bin Liu Nov. 11, 2016, 11:06 p.m. UTC | #14
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
Laurent Pinchart Nov. 12, 2016, 1:21 a.m. UTC | #15
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().
Tomi Valkeinen Nov. 23, 2016, 10:14 a.m. UTC | #16
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
Laurent Pinchart Nov. 23, 2016, 3:49 p.m. UTC | #17
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.
Tomi Valkeinen Nov. 23, 2016, 3:54 p.m. UTC | #18
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
Tony Lindgren Nov. 23, 2016, 3:57 p.m. UTC | #19
* 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
Tony Lindgren Nov. 23, 2016, 4:34 p.m. UTC | #20
* 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
Tony Lindgren Nov. 23, 2016, 4:44 p.m. UTC | #21
* 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
Tony Lindgren Dec. 8, 2016, 5:51 a.m. UTC | #22
* 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
Laurent Pinchart Dec. 8, 2016, 12:03 p.m. UTC | #23
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
Tony Lindgren Dec. 8, 2016, 6:47 p.m. UTC | #24
* 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

Patch
diff mbox

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),