Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
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 signature.asc Description: Digital signature
Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
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 : > > Hi everybody, > > We are working on IGEPv2 board about OTG issue. > > 2014-11-19 18:53 GMT+01:00 Tony Lindgren : >> >> * Enric Balletbo Serra [141119 03:14]: >> > 2014-11-18 16:42 GMT+01:00 Tony Lindgren : >> > >> > 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: ega...@iseebcn.com 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 majord...@vger.kernel.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
On Mon, Dec 01, 2014 at 08:57:14AM +0100, Yegor Yefremov wrote: > On Sat, Nov 29, 2014 at 4:35 PM, Felipe Balbi 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 wrote: > >> > * Enric Balletbo Serra [141119 03:14]: > >> >> 2014-11-18 16:42 GMT+01:00 Tony Lindgren : > >> >> > >> >> 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 signature.asc Description: Digital signature
Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
On Sat, Nov 29, 2014 at 4:35 PM, Felipe Balbi 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 wrote: >> > * Enric Balletbo Serra [141119 03:14]: >> >> 2014-11-18 16:42 GMT+01:00 Tony Lindgren : >> >> >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
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 wrote: > > * Enric Balletbo Serra [141119 03:14]: > >> 2014-11-18 16:42 GMT+01:00 Tony Lindgren : > >> > >> 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 signature.asc Description: Digital signature
Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
On Wed, Nov 19, 2014 at 6:53 PM, Tony Lindgren wrote: > * Enric Balletbo Serra [141119 03:14]: >> 2014-11-18 16:42 GMT+01:00 Tony Lindgren : >> >> 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 majord...@vger.kernel.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
* Enric Balletbo Serra [141119 03:14]: > 2014-11-18 16:42 GMT+01:00 Tony Lindgren : > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
Hi Tony, 2014-11-18 16:42 GMT+01:00 Tony Lindgren : > * Enric Balletbo Serra [141118 01:04]: >> Hi Tony, >> >> 2014-11-17 19:04 GMT+01:00 Tony Lindgren : >> > >> > 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 4807.i2c:twl@48:twl4030-usb: >> HW_CONDITIONS 0x54/84; link 1 >> [ 51.470916] twl4030_usb 4807.i2c:twl@48:twl4030-usb: >> twl4030_usb_runtime_resume >> [ 51.487274] musb-hdrc musb-hdrc.0.auto: ID GND >> [ 52.480712] twl4030_usb 4807.i2c:twl@48:twl4030-usb: >> HW_CONDITIONS 0x54/84; link 1 >> [ 53.489044] twl4030_usb 4807.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 4807.i2c:twl@48:twl4030-usb: >> HW_CONDITIONS 0x54/84; link 1 >> [ 71.778930] twl4030_usb 4807.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 4807.i2c:twl@48:twl4030-usb: >> HW_CONDITIONS 0x50/80; link 4 >> [ 74.088714] twl4030_usb 4807.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 > 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_IDMOUS
Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
* Enric Balletbo Serra [141118 01:04]: > Hi Tony, > > 2014-11-17 19:04 GMT+01:00 Tony Lindgren : > > > > 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 4807.i2c:twl@48:twl4030-usb: > HW_CONDITIONS 0x54/84; link 1 > [ 51.470916] twl4030_usb 4807.i2c:twl@48:twl4030-usb: > twl4030_usb_runtime_resume > [ 51.487274] musb-hdrc musb-hdrc.0.auto: ID GND > [ 52.480712] twl4030_usb 4807.i2c:twl@48:twl4030-usb: > HW_CONDITIONS 0x54/84; link 1 > [ 53.489044] twl4030_usb 4807.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 4807.i2c:twl@48:twl4030-usb: > HW_CONDITIONS 0x54/84; link 1 > [ 71.778930] twl4030_usb 4807.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 4807.i2c:twl@48:twl4030-usb: > HW_CONDITIONS 0x50/80; link 4 > [ 74.088714] twl4030_usb 4807.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 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_CON
Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
2014-11-18 10:02 GMT+01:00 Enric Balletbo Serra : > Hi Tony, > > 2014-11-17 19:04 GMT+01:00 Tony Lindgren : >> * Enric Balletbo Serra [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 4807.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 4807.i2c:twl@48:twl4030-usb: > HW_CONDITIONS 0x54/84; link 1 > [ 51.470916] twl4030_usb 4807.i2c:twl@48:twl4030-usb: > twl4030_usb_runtime_resume > [ 51.487274] musb-hdrc musb-hdrc.0.auto: ID GND > [ 52.480712] twl4030_usb 4807.i2c:twl@48:twl4030-usb: > HW_CONDITIONS 0x54/84; link 1 > [ 53.489044] twl4030_usb 4807.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 4807.i2c:twl@48:twl4030-usb: > HW_CONDITIONS 0x54/84; link 1 > [ 71.778930] twl4030_usb 4807.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 4807.i2c:twl@48:twl4030-usb: > HW_CONDITIONS 0x50/80; link 4 > [ 74.088714] twl4030_usb 4807.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 majord...@vger.kernel.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
Hi Tony, 2014-11-17 19:04 GMT+01:00 Tony Lindgren : > * Enric Balletbo Serra [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 4807.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 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 [ 51.470916] twl4030_usb 4807.i2c:twl@48:twl4030-usb: twl4030_usb_runtime_resume [ 51.487274] musb-hdrc musb-hdrc.0.auto: ID GND [ 52.480712] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 [ 53.489044] twl4030_usb 4807.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 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 [ 71.778930] twl4030_usb 4807.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 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x50/80; link 4 [ 74.088714] twl4030_usb 4807.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 majord...@vger.kernel.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
* Enric Balletbo Serra [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 4807.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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
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 4807.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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html