USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

[Enric Balletbo Serra]

 Hi all,

I'm trying to use the USB OTG driver of OMAP3 processor in HOST mode
when it's configured in dual role mode (CONFIG_USB_MUSB_DUAL_ROLE=y)

The test case that I'm trying to solve is as follows.

1) Boot the board.
2) Put the USB ID pin to ground
3) Connect a pendrive.

In such case doesn't work as expected and pendrive is never detected.

Enabling debug information, I see that the phyter (twl4030) is
constantly polling the STS_HW_CONDITIONS register, who reports:

  twl4030_usb 48070000.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1

The STS_HW_CONDITIONS register reports:

Bit 2: STS_USB : 1: USB is plugged in.
Bit 4: STS_WAKEUP1: Level status of WAKEUP1 pad (active high) = nSLEEP1
Bit 6: STS_WAKEUP3: Level status of WAKEUP3 pad (active high) = CLKREQ

I guess that in this case the state machine is waiting for VBUS, and
looks for bit 7 STS_VBUS (Level status of VBUS port), but this never
occurs. Using an oscilloscope I checked VBUS level and I can confirm
that it's a 0 level.

My understand is that in this case the driver should enable VBUS but I
didn't find where is the best place to do this and why is not doing
this already. Any clue on this?

Thanks in advance,
   Enric

Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

[Tony Lindgren]

* Enric Balletbo Serra <eballetbo@gmail.com> [141117 07:15]:
>  Hi all,
> 
> I'm trying to use the USB OTG driver of OMAP3 processor in HOST mode
> when it's configured in dual role mode (CONFIG_USB_MUSB_DUAL_ROLE=y)
> 
> The test case that I'm trying to solve is as follows.
> 
> 1) Boot the board.
> 2) Put the USB ID pin to ground
> 3) Connect a pendrive.
> 
> In such case doesn't work as expected and pendrive is never detected.
> 
> Enabling debug information, I see that the phyter (twl4030) is
> constantly polling the STS_HW_CONDITIONS register, who reports:
> 
>   twl4030_usb 48070000.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1
> 
> The STS_HW_CONDITIONS register reports:
> 
> Bit 2: STS_USB : 1: USB is plugged in.
> Bit 4: STS_WAKEUP1: Level status of WAKEUP1 pad (active high) = nSLEEP1
> Bit 6: STS_WAKEUP3: Level status of WAKEUP3 pad (active high) = CLKREQ
> 
> I guess that in this case the state machine is waiting for VBUS, and
> looks for bit 7 STS_VBUS (Level status of VBUS port), but this never
> occurs. Using an oscilloscope I checked VBUS level and I can confirm
> that it's a 0 level.
> 
> My understand is that in this case the driver should enable VBUS but I
> didn't find where is the best place to do this and why is not doing
> this already. Any clue on this?

Just tested v3.18-rc5 with beagleboard xm, and the host mode
enumerates the devices, then may fail with "insufficient bus power"
at least for the WLAN device I tried with.

I noticed that this only works with CONFIG_USB_MUSB_HDRC and
CONFIG_TWL4030_USB built into the kernel. No luck so far with them
as loadable modules for some reason. Looks like also USB gadgets
fail with MUSB as modules.

And on the 37xx EVM, I've never had any luck getting any twl4030_usb
interrupts for some reason.

Regards,

Tony

Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

[Enric Balletbo Serra]

Hi Tony,

2014-11-17 19:04 GMT+01:00 Tony Lindgren <tony@atomide.com>:
> * Enric Balletbo Serra <eballetbo@gmail.com> [141117 07:15]:
>>  Hi all,
>>
>> I'm trying to use the USB OTG driver of OMAP3 processor in HOST mode
>> when it's configured in dual role mode (CONFIG_USB_MUSB_DUAL_ROLE=y)
>>
>> The test case that I'm trying to solve is as follows.
>>
>> 1) Boot the board.
>> 2) Put the USB ID pin to ground
>> 3) Connect a pendrive.
>>
>> In such case doesn't work as expected and pendrive is never detected.
>>
>> Enabling debug information, I see that the phyter (twl4030) is
>> constantly polling the STS_HW_CONDITIONS register, who reports:
>>
>>   twl4030_usb 48070000.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1
>>
>> The STS_HW_CONDITIONS register reports:
>>
>> Bit 2: STS_USB : 1: USB is plugged in.
>> Bit 4: STS_WAKEUP1: Level status of WAKEUP1 pad (active high) = nSLEEP1
>> Bit 6: STS_WAKEUP3: Level status of WAKEUP3 pad (active high) = CLKREQ
>>
>> I guess that in this case the state machine is waiting for VBUS, and
>> looks for bit 7 STS_VBUS (Level status of VBUS port), but this never
>> occurs. Using an oscilloscope I checked VBUS level and I can confirm
>> that it's a 0 level.
>>
>> My understand is that in this case the driver should enable VBUS but I
>> didn't find where is the best place to do this and why is not doing
>> this already. Any clue on this?
>
> Just tested v3.18-rc5 with beagleboard xm, and the host mode
> enumerates the devices, then may fail with "insufficient bus power"
> at least for the WLAN device I tried with.
>

Is this with following options ?

CONFIG_USB_MUSB_DUAL_ROLE=y
# CONFIG_USB_MUSB_HOST is not set
# CONFIG_USB_MUSB_GADGET is not set

Because with these options doesn't work for me. It only works if I
don't use dual role mode

CONFIG_USB_MUSB_HOST=y
CONFIG_USB_MUSB_DUAL_ROLE is not set

> I noticed that this only works with CONFIG_USB_MUSB_HDRC and
> CONFIG_TWL4030_USB built into the kernel. No luck so far with them
> as loadable modules for some reason. Looks like also USB gadgets
> fail with MUSB as modules.
>

It's weird, for me fails in both cases, built-in and with loadable
modules. Connecting the OTG Cable Adapter with a pendrive reports

[   51.462432] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
HW_CONDITIONS 0x54/84; link 1
[   51.470916] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
twl4030_usb_runtime_resume
[   51.487274] musb-hdrc musb-hdrc.0.auto: ID GND
[   52.480712] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
HW_CONDITIONS 0x54/84; link 1
[   53.489044] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
HW_CONDITIONS 0x54/84; link 1

And then polls until I disconnect the OTG Cable Adapter with the pendrive.

[   71.488983] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
HW_CONDITIONS 0x54/84; link 1
[   71.778930] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
HW_CONDITIONS 0x50/80; link 4
[   71.787536] musb-hdrc musb-hdrc.0.auto: VBUS Disconnect
[   72.489044] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
HW_CONDITIONS 0x50/80; link 4
[   74.088714] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
twl4030_usb_runtime_suspend


> And on the 37xx EVM, I've never had any luck getting any twl4030_usb
> interrupts for some reason.
>

Regards,

Enric

> Regards,
>
> Tony

Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

[Enric Balletbo Serra]

2014-11-18 10:02 GMT+01:00 Enric Balletbo Serra <eballetbo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> Hi Tony,
>
> 2014-11-17 19:04 GMT+01:00 Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
>> * Enric Balletbo Serra <eballetbo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [141117 07:15]:
>>>  Hi all,
>>>
>>> I'm trying to use the USB OTG driver of OMAP3 processor in HOST mode
>>> when it's configured in dual role mode (CONFIG_USB_MUSB_DUAL_ROLE=y)
>>>
>>> The test case that I'm trying to solve is as follows.
>>>
>>> 1) Boot the board.
>>> 2) Put the USB ID pin to ground
>>> 3) Connect a pendrive.
>>>
>>> In such case doesn't work as expected and pendrive is never detected.
>>>
>>> Enabling debug information, I see that the phyter (twl4030) is
>>> constantly polling the STS_HW_CONDITIONS register, who reports:
>>>
>>>   twl4030_usb 48070000.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1
>>>
>>> The STS_HW_CONDITIONS register reports:
>>>
>>> Bit 2: STS_USB : 1: USB is plugged in.
>>> Bit 4: STS_WAKEUP1: Level status of WAKEUP1 pad (active high) = nSLEEP1
>>> Bit 6: STS_WAKEUP3: Level status of WAKEUP3 pad (active high) = CLKREQ
>>>
>>> I guess that in this case the state machine is waiting for VBUS, and
>>> looks for bit 7 STS_VBUS (Level status of VBUS port), but this never
>>> occurs. Using an oscilloscope I checked VBUS level and I can confirm
>>> that it's a 0 level.
>>>
>>> My understand is that in this case the driver should enable VBUS but I
>>> didn't find where is the best place to do this and why is not doing
>>> this already. Any clue on this?
>>
>> Just tested v3.18-rc5 with beagleboard xm, and the host mode
>> enumerates the devices, then may fail with "insufficient bus power"
>> at least for the WLAN device I tried with.
>>
>
> Is this with following options ?
>
> CONFIG_USB_MUSB_DUAL_ROLE=y
> # CONFIG_USB_MUSB_HOST is not set
> # CONFIG_USB_MUSB_GADGET is not set
>
> Because with these options doesn't work for me. It only works if I
> don't use dual role mode
>
> CONFIG_USB_MUSB_HOST=y
> CONFIG_USB_MUSB_DUAL_ROLE is not set
>

Sorry this is not true, it only works if I set  mode = <1> in my
device tree, either it's CONFIG_USB_MUSB_DUAL_ROLE=y or
CONFIG_USB_MUSB_HOST=y configured.

>> I noticed that this only works with CONFIG_USB_MUSB_HDRC and
>> CONFIG_TWL4030_USB built into the kernel. No luck so far with them
>> as loadable modules for some reason. Looks like also USB gadgets
>> fail with MUSB as modules.
>>
>
> It's weird, for me fails in both cases, built-in and with loadable
> modules. Connecting the OTG Cable Adapter with a pendrive reports
>
> [   51.462432] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> HW_CONDITIONS 0x54/84; link 1
> [   51.470916] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> twl4030_usb_runtime_resume
> [   51.487274] musb-hdrc musb-hdrc.0.auto: ID GND
> [   52.480712] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> HW_CONDITIONS 0x54/84; link 1
> [   53.489044] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> HW_CONDITIONS 0x54/84; link 1
>
> And then polls until I disconnect the OTG Cable Adapter with the pendrive.
>
> [   71.488983] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> HW_CONDITIONS 0x54/84; link 1
> [   71.778930] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> HW_CONDITIONS 0x50/80; link 4
> [   71.787536] musb-hdrc musb-hdrc.0.auto: VBUS Disconnect
> [   72.489044] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> HW_CONDITIONS 0x50/80; link 4
> [   74.088714] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> twl4030_usb_runtime_suspend
>
>
>> And on the 37xx EVM, I've never had any luck getting any twl4030_usb
>> interrupts for some reason.
>>
>
> Regards,
>
> Enric
>
>> Regards,
>>
>> Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

[Tony Lindgren]

* Enric Balletbo Serra <eballetbo@gmail.com> [141118 01:04]:
> Hi Tony,
> 
> 2014-11-17 19:04 GMT+01:00 Tony Lindgren <tony@atomide.com>:
> >
> > Just tested v3.18-rc5 with beagleboard xm, and the host mode
> > enumerates the devices, then may fail with "insufficient bus power"
> > at least for the WLAN device I tried with.
> >
> 
> Is this with following options ?
> 
> CONFIG_USB_MUSB_DUAL_ROLE=y
> # CONFIG_USB_MUSB_HOST is not set
> # CONFIG_USB_MUSB_GADGET is not set
> 
> Because with these options doesn't work for me. It only works if I
> don't use dual role mode
> 
> CONFIG_USB_MUSB_HOST=y
> CONFIG_USB_MUSB_DUAL_ROLE is not set

Weird. Yes I have CONFIG_USB_MUSB_DUAL_ROLE. AFAIK there's actually
no way to disable the role switching in MUSB hardware, the hardware
tries to do things on it's own anyways. So it's probably best to always
set it to CONFIG_USB_MUSB_DUAL_ROLE=y unless size of the code is an
issue.

> > I noticed that this only works with CONFIG_USB_MUSB_HDRC and
> > CONFIG_TWL4030_USB built into the kernel. No luck so far with them
> > as loadable modules for some reason. Looks like also USB gadgets
> > fail with MUSB as modules.

I found the core issue with loadable modules, we currently need to
have just one platform glue layer module compiled in. I have a
fix coming up for that..

> It's weird, for me fails in both cases, built-in and with loadable
> modules. Connecting the OTG Cable Adapter with a pendrive reports
>
> [   51.462432] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> HW_CONDITIONS 0x54/84; link 1
> [   51.470916] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> twl4030_usb_runtime_resume
> [   51.487274] musb-hdrc musb-hdrc.0.auto: ID GND
> [   52.480712] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> HW_CONDITIONS 0x54/84; link 1
> [   53.489044] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> HW_CONDITIONS 0x54/84; link 1
> 
> And then polls until I disconnect the OTG Cable Adapter with the pendrive.
> 
> [   71.488983] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> HW_CONDITIONS 0x54/84; link 1
> [   71.778930] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> HW_CONDITIONS 0x50/80; link 4
> [   71.787536] musb-hdrc musb-hdrc.0.auto: VBUS Disconnect
> [   72.489044] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> HW_CONDITIONS 0x50/80; link 4
> [   74.088714] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
> twl4030_usb_runtime_suspend

Looks like the twl4030-usb is producing interrupts alright. Maybe
check your MUSB configuration one more time. See the attached
patch, but note you need to only select the glue layer for the
CONFIG_USB_MUSB_OMAP2PLUS option and disable other glue layer
module options.

Also, you may want to monitor the VBUS line in host mode. If the
VBUS does not come up fast enough, MUSB hardware will give up as
it's again trying to do things on its own. 
 
> > And on the 37xx EVM, I've never had any luck getting any twl4030_usb
> > interrupts for some reason.

Turns out the 37xx EVM is using an isp1507 phy instead of the
twl4030 phy. The proper fix for that will be to start using the
usb-nop-xceiv or phy-ulpi when we have drivers/phy/ driver for
it. Right now trying to use it seems to fail with the following
error:

HS USB OTG: no PHY configured

Regards,

Tony

8< -------------
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 17 Nov 2014 07:53:59 -0800
Subject: [PATCH] ARM: omap2plus_defconfig: Enable USB as loadable modules

NOTE: Currently only one MUSB glue layer can be selected
below because of the ifdefs, I'll do a fix for that.

--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -270,17 +270,92 @@ CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m
 CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
 CONFIG_USB=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_DYNAMIC_MINORS=y
+CONFIG_USB_OTG=y
 CONFIG_USB_MON=y
 CONFIG_USB_WDM=y
 CONFIG_USB_STORAGE=y
+CONFIG_USB_MUSB_HDRC=m
+CONFIG_USB_MUSB_TUSB6010=m
+CONFIG_USB_MUSB_OMAP2PLUS=m
+CONFIG_USB_MUSB_AM35X=m
+CONFIG_USB_MUSB_DSPS=m
 CONFIG_USB_DWC3=m
-CONFIG_USB_TEST=y
-CONFIG_AM335X_PHY_USB=y
+CONFIG_USB_SERIAL=m
+CONFIG_USB_SERIAL_GENERIC=y
+CONFIG_USB_SERIAL_SIMPLE=m
+CONFIG_USB_SERIAL_FTDI_SIO=m
+CONFIG_USB_SERIAL_PL2303=m
+CONFIG_USB_EMI62=m
+CONFIG_USB_EMI26=m
+CONFIG_USB_ADUTUX=m
+CONFIG_USB_SEVSEG=m
+CONFIG_USB_RIO500=m
+CONFIG_USB_LEGOTOWER=m
+CONFIG_USB_LCD=m
+CONFIG_USB_LED=m
+CONFIG_USB_CYPRESS_CY7C63=m
+CONFIG_USB_CYTHERM=m
+CONFIG_USB_IDMOUSE=m
+CONFIG_USB_FTDI_ELAN=m
+CONFIG_USB_APPLEDISPLAY=m
+CONFIG_USB_SISUSBVGA=m
+CONFIG_USB_SISUSBVGA_CON=y
+CONFIG_USB_LD=m
+CONFIG_USB_TRANCEVIBRATOR=m
+CONFIG_USB_IOWARRIOR=m
+CONFIG_USB_TEST=m
+CONFIG_USB_EHSET_TEST_FIXTURE=m
+CONFIG_USB_ISIGHTFW=m
+CONFIG_USB_YUREX=m
+CONFIG_USB_EZUSB_FX2=m
+CONFIG_USB_HSIC_USB3503=m
+CONFIG_USB_LINK_LAYER_TEST=m
+CONFIG_NOP_USB_XCEIV=y
+CONFIG_AM335X_PHY_USB=m
+CONFIG_TWL6030_USB=m
+CONFIG_USB_GPIO_VBUS=m
+CONFIG_USB_ISP1301=m
+CONFIG_USB_ULPI=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_DEBUG=y
 CONFIG_USB_GADGET_DEBUG_FILES=y
 CONFIG_USB_GADGET_DEBUG_FS=y
+CONFIG_USB_CONFIGFS=m
+CONFIG_USB_CONFIGFS_SERIAL=y
+CONFIG_USB_CONFIGFS_ACM=y
+CONFIG_USB_CONFIGFS_OBEX=y
+CONFIG_USB_CONFIGFS_NCM=y
+CONFIG_USB_CONFIGFS_ECM=y
+CONFIG_USB_CONFIGFS_ECM_SUBSET=y
+CONFIG_USB_CONFIGFS_RNDIS=y
+CONFIG_USB_CONFIGFS_EEM=y
+CONFIG_USB_CONFIGFS_MASS_STORAGE=y
+CONFIG_USB_CONFIGFS_F_LB_SS=y
+CONFIG_USB_CONFIGFS_F_FS=y
 CONFIG_USB_ZERO=m
+CONFIG_USB_ZERO_HNPTEST=y
+CONFIG_USB_AUDIO=m
+CONFIG_GADGET_UAC1=y
+CONFIG_USB_ETH=m
+CONFIG_USB_ETH_EEM=y
+CONFIG_USB_G_NCM=m
+CONFIG_USB_GADGETFS=m
+CONFIG_USB_FUNCTIONFS=m
+CONFIG_USB_FUNCTIONFS_ETH=y
+CONFIG_USB_FUNCTIONFS_RNDIS=y
+CONFIG_USB_FUNCTIONFS_GENERIC=y
+CONFIG_USB_MASS_STORAGE=m
+CONFIG_USB_G_SERIAL=m
+CONFIG_USB_MIDI_GADGET=m
+CONFIG_USB_G_PRINTER=m
+CONFIG_USB_CDC_COMPOSITE=m
+CONFIG_USB_G_ACM_MS=m
+CONFIG_USB_G_MULTI=m
+CONFIG_USB_G_MULTI_CDC=y
+CONFIG_USB_G_HID=m
+CONFIG_USB_G_DBGP=m
+CONFIG_USB_LED_TRIG=y
 CONFIG_MMC=y
 CONFIG_SDIO_UART=y
 CONFIG_MMC_OMAP=y
@@ -310,6 +385,7 @@ CONFIG_PWM_TWL=y
 CONFIG_PWM_TWL_LED=y
 CONFIG_OMAP_USB2=y
 CONFIG_TI_PIPE3=y
+CONFIG_TWL4030_USB=m
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 # CONFIG_EXT3_FS_XATTR is not set

Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

[Enric Balletbo Serra]

Hi Tony,

2014-11-18 16:42 GMT+01:00 Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
> * Enric Balletbo Serra <eballetbo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [141118 01:04]:
>> Hi Tony,
>>
>> 2014-11-17 19:04 GMT+01:00 Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
>> >
>> > Just tested v3.18-rc5 with beagleboard xm, and the host mode
>> > enumerates the devices, then may fail with "insufficient bus power"
>> > at least for the WLAN device I tried with.
>> >
>>
>> Is this with following options ?
>>
>> CONFIG_USB_MUSB_DUAL_ROLE=y
>> # CONFIG_USB_MUSB_HOST is not set
>> # CONFIG_USB_MUSB_GADGET is not set
>>
>> Because with these options doesn't work for me. It only works if I
>> don't use dual role mode
>>
>> CONFIG_USB_MUSB_HOST=y
>> CONFIG_USB_MUSB_DUAL_ROLE is not set
>
> Weird. Yes I have CONFIG_USB_MUSB_DUAL_ROLE. AFAIK there's actually
> no way to disable the role switching in MUSB hardware, the hardware
> tries to do things on it's own anyways. So it's probably best to always
> set it to CONFIG_USB_MUSB_DUAL_ROLE=y unless size of the code is an
> issue.
>
>> > I noticed that this only works with CONFIG_USB_MUSB_HDRC and
>> > CONFIG_TWL4030_USB built into the kernel. No luck so far with them
>> > as loadable modules for some reason. Looks like also USB gadgets
>> > fail with MUSB as modules.
>
> I found the core issue with loadable modules, we currently need to
> have just one platform glue layer module compiled in. I have a
> fix coming up for that..
>
>> It's weird, for me fails in both cases, built-in and with loadable
>> modules. Connecting the OTG Cable Adapter with a pendrive reports
>>
>> [   51.462432] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
>> HW_CONDITIONS 0x54/84; link 1
>> [   51.470916] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
>> twl4030_usb_runtime_resume
>> [   51.487274] musb-hdrc musb-hdrc.0.auto: ID GND
>> [   52.480712] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
>> HW_CONDITIONS 0x54/84; link 1
>> [   53.489044] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
>> HW_CONDITIONS 0x54/84; link 1
>>
>> And then polls until I disconnect the OTG Cable Adapter with the pendrive.
>>
>> [   71.488983] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
>> HW_CONDITIONS 0x54/84; link 1
>> [   71.778930] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
>> HW_CONDITIONS 0x50/80; link 4
>> [   71.787536] musb-hdrc musb-hdrc.0.auto: VBUS Disconnect
>> [   72.489044] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
>> HW_CONDITIONS 0x50/80; link 4
>> [   74.088714] twl4030_usb 48070000.i2c:twl@48:twl4030-usb:
>> twl4030_usb_runtime_suspend
>
> Looks like the twl4030-usb is producing interrupts alright. Maybe
> check your MUSB configuration one more time. See the attached
> patch, but note you need to only select the glue layer for the
> CONFIG_USB_MUSB_OMAP2PLUS option and disable other glue layer
> module options.
>

Checked again, and no luck. It's very weird because from the OTG point
of view, OTG is exactly the same between Beagleboard-XM and IGEPv2.

Can you confirm that you're using kernel 3.18-rc5 without other
patches applied ? At this moment, I don't have a Beagleboard-XM to
test, I'll try to get one because at this moment I'm a bit stuck with
this problem.

> Also, you may want to monitor the VBUS line in host mode. If the
> VBUS does not come up fast enough, MUSB hardware will give up as
> it's again trying to do things on its own.
>
>> > And on the 37xx EVM, I've never had any luck getting any twl4030_usb
>> > interrupts for some reason.
>
> Turns out the 37xx EVM is using an isp1507 phy instead of the
> twl4030 phy. The proper fix for that will be to start using the
> usb-nop-xceiv or phy-ulpi when we have drivers/phy/ driver for
> it. Right now trying to use it seems to fail with the following
> error:
>
> HS USB OTG: no PHY configured
>
> Regards,
>
> Tony
>

Thanks,
  Enric

> 8< -------------
> From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> Date: Mon, 17 Nov 2014 07:53:59 -0800
> Subject: [PATCH] ARM: omap2plus_defconfig: Enable USB as loadable modules
>
> NOTE: Currently only one MUSB glue layer can be selected
> below because of the ifdefs, I'll do a fix for that.
>
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -270,17 +270,92 @@ CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m
>  CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
>  CONFIG_USB=y
>  CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
> +CONFIG_USB_DYNAMIC_MINORS=y
> +CONFIG_USB_OTG=y
>  CONFIG_USB_MON=y
>  CONFIG_USB_WDM=y
>  CONFIG_USB_STORAGE=y
> +CONFIG_USB_MUSB_HDRC=m
> +CONFIG_USB_MUSB_TUSB6010=m
> +CONFIG_USB_MUSB_OMAP2PLUS=m
> +CONFIG_USB_MUSB_AM35X=m
> +CONFIG_USB_MUSB_DSPS=m
>  CONFIG_USB_DWC3=m
> -CONFIG_USB_TEST=y
> -CONFIG_AM335X_PHY_USB=y
> +CONFIG_USB_SERIAL=m
> +CONFIG_USB_SERIAL_GENERIC=y
> +CONFIG_USB_SERIAL_SIMPLE=m
> +CONFIG_USB_SERIAL_FTDI_SIO=m
> +CONFIG_USB_SERIAL_PL2303=m
> +CONFIG_USB_EMI62=m
> +CONFIG_USB_EMI26=m
> +CONFIG_USB_ADUTUX=m
> +CONFIG_USB_SEVSEG=m
> +CONFIG_USB_RIO500=m
> +CONFIG_USB_LEGOTOWER=m
> +CONFIG_USB_LCD=m
> +CONFIG_USB_LED=m
> +CONFIG_USB_CYPRESS_CY7C63=m
> +CONFIG_USB_CYTHERM=m
> +CONFIG_USB_IDMOUSE=m
> +CONFIG_USB_FTDI_ELAN=m
> +CONFIG_USB_APPLEDISPLAY=m
> +CONFIG_USB_SISUSBVGA=m
> +CONFIG_USB_SISUSBVGA_CON=y
> +CONFIG_USB_LD=m
> +CONFIG_USB_TRANCEVIBRATOR=m
> +CONFIG_USB_IOWARRIOR=m
> +CONFIG_USB_TEST=m
> +CONFIG_USB_EHSET_TEST_FIXTURE=m
> +CONFIG_USB_ISIGHTFW=m
> +CONFIG_USB_YUREX=m
> +CONFIG_USB_EZUSB_FX2=m
> +CONFIG_USB_HSIC_USB3503=m
> +CONFIG_USB_LINK_LAYER_TEST=m
> +CONFIG_NOP_USB_XCEIV=y
> +CONFIG_AM335X_PHY_USB=m
> +CONFIG_TWL6030_USB=m
> +CONFIG_USB_GPIO_VBUS=m
> +CONFIG_USB_ISP1301=m
> +CONFIG_USB_ULPI=y
>  CONFIG_USB_GADGET=y
>  CONFIG_USB_GADGET_DEBUG=y
>  CONFIG_USB_GADGET_DEBUG_FILES=y
>  CONFIG_USB_GADGET_DEBUG_FS=y
> +CONFIG_USB_CONFIGFS=m
> +CONFIG_USB_CONFIGFS_SERIAL=y
> +CONFIG_USB_CONFIGFS_ACM=y
> +CONFIG_USB_CONFIGFS_OBEX=y
> +CONFIG_USB_CONFIGFS_NCM=y
> +CONFIG_USB_CONFIGFS_ECM=y
> +CONFIG_USB_CONFIGFS_ECM_SUBSET=y
> +CONFIG_USB_CONFIGFS_RNDIS=y
> +CONFIG_USB_CONFIGFS_EEM=y
> +CONFIG_USB_CONFIGFS_MASS_STORAGE=y
> +CONFIG_USB_CONFIGFS_F_LB_SS=y
> +CONFIG_USB_CONFIGFS_F_FS=y
>  CONFIG_USB_ZERO=m
> +CONFIG_USB_ZERO_HNPTEST=y
> +CONFIG_USB_AUDIO=m
> +CONFIG_GADGET_UAC1=y
> +CONFIG_USB_ETH=m
> +CONFIG_USB_ETH_EEM=y
> +CONFIG_USB_G_NCM=m
> +CONFIG_USB_GADGETFS=m
> +CONFIG_USB_FUNCTIONFS=m
> +CONFIG_USB_FUNCTIONFS_ETH=y
> +CONFIG_USB_FUNCTIONFS_RNDIS=y
> +CONFIG_USB_FUNCTIONFS_GENERIC=y
> +CONFIG_USB_MASS_STORAGE=m
> +CONFIG_USB_G_SERIAL=m
> +CONFIG_USB_MIDI_GADGET=m
> +CONFIG_USB_G_PRINTER=m
> +CONFIG_USB_CDC_COMPOSITE=m
> +CONFIG_USB_G_ACM_MS=m
> +CONFIG_USB_G_MULTI=m
> +CONFIG_USB_G_MULTI_CDC=y
> +CONFIG_USB_G_HID=m
> +CONFIG_USB_G_DBGP=m
> +CONFIG_USB_LED_TRIG=y
>  CONFIG_MMC=y
>  CONFIG_SDIO_UART=y
>  CONFIG_MMC_OMAP=y
> @@ -310,6 +385,7 @@ CONFIG_PWM_TWL=y
>  CONFIG_PWM_TWL_LED=y
>  CONFIG_OMAP_USB2=y
>  CONFIG_TI_PIPE3=y
> +CONFIG_TWL4030_USB=m
>  CONFIG_EXT2_FS=y
>  CONFIG_EXT3_FS=y
>  # CONFIG_EXT3_FS_XATTR is not set
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

[Tony Lindgren]

* Enric Balletbo Serra <eballetbo@gmail.com> [141119 03:14]:
> 2014-11-18 16:42 GMT+01:00 Tony Lindgren <tony@atomide.com>:
> 
> Checked again, and no luck. It's very weird because from the OTG point
> of view, OTG is exactly the same between Beagleboard-XM and IGEPv2.
> 
> Can you confirm that you're using kernel 3.18-rc5 without other
> patches applied ? At this moment, I don't have a Beagleboard-XM to
> test, I'll try to get one because at this moment I'm a bit stuck with
> this problem.

Yes it was with v3.18-rc5 and the defconfig patch I posted except
I had to disable all the other MUSB platforms. Also tested it with
built in modules.

Maybe you need to check the .dts pinctrl entries for hsusb0_* lines?

Regards,

Tony

Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

[Yegor Yefremov]

On Wed, Nov 19, 2014 at 6:53 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> * Enric Balletbo Serra <eballetbo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [141119 03:14]:
>> 2014-11-18 16:42 GMT+01:00 Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
>>
>> Checked again, and no luck. It's very weird because from the OTG point
>> of view, OTG is exactly the same between Beagleboard-XM and IGEPv2.
>>
>> Can you confirm that you're using kernel 3.18-rc5 without other
>> patches applied ? At this moment, I don't have a Beagleboard-XM to
>> test, I'll try to get one because at this moment I'm a bit stuck with
>> this problem.
>
> Yes it was with v3.18-rc5 and the defconfig patch I posted except
> I had to disable all the other MUSB platforms. Also tested it with
> built in modules.
>
> Maybe you need to check the .dts pinctrl entries for hsusb0_* lines?

Just my 2 cents, My am335x based board shows similar symptoms
(CONFIG_USB_MUSB_DUAL_ROLE enabled). Only if I specify  dr_mode =
"host"; in my DTS I get device enumerated. 3.15, that I had before
made no problems as OTG.

Yegor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

Hi,

On Fri, Nov 28, 2014 at 11:35:53AM +0100, Yegor Yefremov wrote:
> On Wed, Nov 19, 2014 at 6:53 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Enric Balletbo Serra <eballetbo@gmail.com> [141119 03:14]:
> >> 2014-11-18 16:42 GMT+01:00 Tony Lindgren <tony@atomide.com>:
> >>
> >> Checked again, and no luck. It's very weird because from the OTG point
> >> of view, OTG is exactly the same between Beagleboard-XM and IGEPv2.
> >>
> >> Can you confirm that you're using kernel 3.18-rc5 without other
> >> patches applied ? At this moment, I don't have a Beagleboard-XM to
> >> test, I'll try to get one because at this moment I'm a bit stuck with
> >> this problem.
> >
> > Yes it was with v3.18-rc5 and the defconfig patch I posted except
> > I had to disable all the other MUSB platforms. Also tested it with
> > built in modules.
> >
> > Maybe you need to check the .dts pinctrl entries for hsusb0_* lines?
> 
> Just my 2 cents, My am335x based board shows similar symptoms
> (CONFIG_USB_MUSB_DUAL_ROLE enabled). Only if I specify  dr_mode =
> "host"; in my DTS I get device enumerated. 3.15, that I had before
> made no problems as OTG.

Are you sure your ID pin is properly routed ? If you set dr_mode to otg,
then you *must* have a properly routed ID pin and use a proper
micro-/mini-ab receptacle. That's not true for e.g. beagle bone black.

One USB port is using a Standard-A while the other uses mini-B. You
can't do any role swapping with those.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

[Yegor Yefremov]

On Sat, Nov 29, 2014 at 4:35 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Fri, Nov 28, 2014 at 11:35:53AM +0100, Yegor Yefremov wrote:
>> On Wed, Nov 19, 2014 at 6:53 PM, Tony Lindgren <tony@atomide.com> wrote:
>> > * Enric Balletbo Serra <eballetbo@gmail.com> [141119 03:14]:
>> >> 2014-11-18 16:42 GMT+01:00 Tony Lindgren <tony@atomide.com>:
>> >>
>> >> Checked again, and no luck. It's very weird because from the OTG point
>> >> of view, OTG is exactly the same between Beagleboard-XM and IGEPv2.
>> >>
>> >> Can you confirm that you're using kernel 3.18-rc5 without other
>> >> patches applied ? At this moment, I don't have a Beagleboard-XM to
>> >> test, I'll try to get one because at this moment I'm a bit stuck with
>> >> this problem.
>> >
>> > Yes it was with v3.18-rc5 and the defconfig patch I posted except
>> > I had to disable all the other MUSB platforms. Also tested it with
>> > built in modules.
>> >
>> > Maybe you need to check the .dts pinctrl entries for hsusb0_* lines?
>>
>> Just my 2 cents, My am335x based board shows similar symptoms
>> (CONFIG_USB_MUSB_DUAL_ROLE enabled). Only if I specify  dr_mode =
>> "host"; in my DTS I get device enumerated. 3.15, that I had before
>> made no problems as OTG.
>
> Are you sure your ID pin is properly routed ? If you set dr_mode to otg,
> then you *must* have a properly routed ID pin and use a proper
> micro-/mini-ab receptacle. That's not true for e.g. beagle bone black.
>
> One USB port is using a Standard-A while the other uses mini-B. You
> can't do any role swapping with those.

Yes, I'm sure, that ID pin is routed properly. It is also not BBB, but
real device Baltos iR 5221
(http://visionsystems.de/produkte/baltos-ir-5221.html). With 3.15 I'm
able to use OTG port both as device and host. I boot the device,
insert FTDI based hardware into OTG port and my ttyUSBx devices, then
disconnect and connect to PC and I get usb0 network interface and can
communicate with PC.

Yegor

Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2378 bytes --]

On Mon, Dec 01, 2014 at 08:57:14AM +0100, Yegor Yefremov wrote:
> On Sat, Nov 29, 2014 at 4:35 PM, Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> wrote:
> > Hi,
> >
> > On Fri, Nov 28, 2014 at 11:35:53AM +0100, Yegor Yefremov wrote:
> >> On Wed, Nov 19, 2014 at 6:53 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> >> > * Enric Balletbo Serra <eballetbo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [141119 03:14]:
> >> >> 2014-11-18 16:42 GMT+01:00 Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
> >> >>
> >> >> Checked again, and no luck. It's very weird because from the OTG point
> >> >> of view, OTG is exactly the same between Beagleboard-XM and IGEPv2.
> >> >>
> >> >> Can you confirm that you're using kernel 3.18-rc5 without other
> >> >> patches applied ? At this moment, I don't have a Beagleboard-XM to
> >> >> test, I'll try to get one because at this moment I'm a bit stuck with
> >> >> this problem.
> >> >
> >> > Yes it was with v3.18-rc5 and the defconfig patch I posted except
> >> > I had to disable all the other MUSB platforms. Also tested it with
> >> > built in modules.
> >> >
> >> > Maybe you need to check the .dts pinctrl entries for hsusb0_* lines?
> >>
> >> Just my 2 cents, My am335x based board shows similar symptoms
> >> (CONFIG_USB_MUSB_DUAL_ROLE enabled). Only if I specify  dr_mode =
> >> "host"; in my DTS I get device enumerated. 3.15, that I had before
> >> made no problems as OTG.
> >
> > Are you sure your ID pin is properly routed ? If you set dr_mode to otg,
> > then you *must* have a properly routed ID pin and use a proper
> > micro-/mini-ab receptacle. That's not true for e.g. beagle bone black.
> >
> > One USB port is using a Standard-A while the other uses mini-B. You
> > can't do any role swapping with those.
> 
> Yes, I'm sure, that ID pin is routed properly. It is also not BBB, but
> real device Baltos iR 5221
> (http://visionsystems.de/produkte/baltos-ir-5221.html). With 3.15 I'm
> able to use OTG port both as device and host. I boot the device,
> insert FTDI based hardware into OTG port and my ttyUSBx devices, then
> disconnect and connect to PC and I get usb0 network interface and can
> communicate with PC.

if you know it works on v3.15, then you have a bisection point. Can you
bisect it down to one commit ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

Hi,

(no top-posting)

On Fri, Dec 19, 2014 at 12:16:04PM +0100, Eduard Gavin wrote:
> Hi Everybody,
> 
> After several test with IGEPv2 board (OMAP3) and linux kernel 3.17 and
> 3.18, the OTG works but, (from my point of view) with an weird
> behaviour.
> 
> The OTG like a Host only is activated after load a gadget driver, I
> mean that, If I plug a USB memory dongle in the OTG port before load a
> Gadget driver like "g_ether" the dongle is not recognized. After load
> g_ether driver, the usb dongle is recognized without problems.
> I miss something in the configuration?
> It this the normal behaviour?

it's normal. If you configured your kernel for OTG/dual-role, you must
have both roles ready to go.

that should be considered common sense.

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

[Eduard Gavin]

Hi Everybody,

After several test with IGEPv2 board (OMAP3) and linux kernel 3.17 and
3.18, the OTG works but, (from my point of view) with an weird
behaviour.

The OTG like a Host only is activated after load a gadget driver, I
mean that, If I plug a USB memory dongle in the OTG port before load a
Gadget driver like "g_ether" the dongle is not recognized. After load
g_ether driver, the usb dongle is recognized without problems.
I miss something in the configuration?
It this the normal behaviour?
Best Regards
Eduard

2014-12-17 11:18 GMT+01:00 Agustí Fontquerni <af-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org>:
>
> Hi everybody,
>
> We are working on IGEPv2 board about OTG issue.
>
> 2014-11-19 18:53 GMT+01:00 Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
>>
>> * Enric Balletbo Serra <eballetbo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [141119 03:14]:
>> > 2014-11-18 16:42 GMT+01:00 Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
>> >
>> > Checked again, and no luck. It's very weird because from the OTG point
>> > of view, OTG is exactly the same between Beagleboard-XM and IGEPv2.
>> >
>> > Can you confirm that you're using kernel 3.18-rc5 without other
>> > patches applied ? At this moment, I don't have a Beagleboard-XM to
>> > test, I'll try to get one because at this moment I'm a bit stuck with
>> > this problem.
>>
>> Yes it was with v3.18-rc5 and the defconfig patch I posted except
>> I had to disable all the other MUSB platforms. Also tested it with
>> built in modules.
>>
>> Maybe you need to check the .dts pinctrl entries for hsusb0_* lines?
>
>
>  Command "root@arm:/sys/kernel/debug/pinctrl# cat pinctrl-maps | grep -5
> usb" reports:
>
>  device 480025a0.pinmux
>  state default
>  type MUX_GROUP (2)
>  controlling device 480025a0.pinmux
>  group pinmux_hsusbb1_pins
>  function pinmux_hsusbb1_pins
>
>  So, I think that is needed configure usb0 in lastest "omap3-igep0020.dts"
>
>  Moreover, in old 2.6.37 kernel, we saw omap_mux pin configuration in
> "/sys/kernel/debug/omap_mux/hsusb0_xxx".
> Now in newer 3.1x kernels, Where could it read omap_mux pin configuration ?
>
>>
>> Regards,
>>
>> Tony
>>
>
>  Best Regards,
>  Agusti Fontquerni
>



-- 
Eduard Gavin Carulla

e: egavin-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org

t: +34 935 763 931

t: +34 935 763 932

www.isee.biz

C/ Marcos Redondo, 5 Valldoreix CP. 08197 (Barcelona) - Spain

 Important notice: This message and any files transmitted with it are
confidential and intended solely for the individual to whom it is
addressed. Unauthorized publication, use, dissemination, forwarding,
printing or copying of this email and its associated attachments is
strictly prohibited. If you have received this email in error, please
notify the sender and delete the original immediately. Thank you for
your cooperation.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html