Re: Question regarding MUSB and dynamic fifo sizing
On Wed, 2009-08-12 at 00:17 +0300, Felipe Balbi wrote: On Tue, Aug 11, 2009 at 05:17:56PM -0400, Peter Barada wrote: On Tue, 2009-08-11 at 23:51 +0300, Felipe Balbi wrote: Hi, On Tue, Aug 11, 2009 at 11:21:17AM -0400, Peter Barada wrote: Unfortunately, with the patch, and: 1) modprobe musb_hdrc 2) modprobe g_ether 3) connect micro-a cable 4) echo 1 /sys/devices/platform/musb_hdrc/connect Nothing happens - no isr or output. did you have anything at the other end of the micro-a cable ? Not then. :) I just connected my OTG adapter/thumbdrive, in step three and nothing no isr or output. I know my OTG adapter (micro-a - female A) is valid as I ohm'd out ID and ground on the baseboard (with the SOM removed), and indeed ID is shorted to ground with the adapter plugged in and open with it removed... Well, looks like I'll have to go back to my documentation tomorrow at the office and see if I can get it working on one board of mine, let's see what happens and if I have to patch anything and what. Felipe, I was wondering if you've had a look at this? -- Peter Barada pet...@logicpd.com Logic Product Development, Inc. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding MUSB and dynamic fifo sizing
Hi, On Mon, Aug 10, 2009 at 10:42:41PM +0200, ext Peter Barada wrote: Since the twl4030 thinks its got Vbus, I've added code to dump the TWL4030 register accesses and other structure in the twl4030-usb.c code to understand what its doing. So, from power up(with nothing connected), I see: twl4030_usb twl4030_usb: ++ twl4030_usb_ldo_init: twl4030_usb twl4030_usb: -- twl4030_usb_ldo_init: twl4030_usb twl4030_usb: ++ twl4030_usb_irq: twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data 72 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) twl4030_usb twl4030_usb: ++ twl4030_phy_suspend: controller_off 0 twl4030_usb twl4030_usb: -- twl4030_usb_irq: twl4030_usb twl4030_usb: Initialized TWL4030 USB module twl4030_usb twl4030_usb: twl4030_usb_write: address 0c data 20 1) The only write is from twl4030_vbus_work to clear DRVBUS in OTG_CTRL since HW_CONDITION shows Vbus and ID not set. that's ok, so far. modprobe of the driver gives OMAP-35x# modprobe musb_hdrc musb_hdrc: version 6.0, pio, host, debug=3 twl4030_usb twl4030_usb: ++ twl4030_phy_resume: twl4030_usb twl4030_usb: ++ twl4030_phy_power: on 1 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fd data 01 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fd data 00 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_usb_write: address fe data 06 twl4030_usb twl4030_usb: -- twl4030_phy_power: twl4030_usb twl4030_usb: twl4030_i2c_access: on 1 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 07 twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: -- twl4030_i2c_access: twl4030_usb twl4030_usb: twl4030_usb_set_mode: mode 1 twl4030_usb twl4030_usb: twl4030_usb_write: address 09 data 04 twl4030_usb twl4030_usb: twl4030_usb_write: address ad data 20 twl4030_usb twl4030_usb: twl4030_usb_write: address 06 data 1b twl4030_usb twl4030_usb: -- twl4030_usb_set_mode: twl4030_usb twl4030_usb: twl4030_i2c_access: on 0 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 07 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 06 twl4030_usb twl4030_usb: -- twl4030_i2c_access: twl4030_usb twl4030_usb: -- twl4030_phy_resume: HS USB OTG: revision 0x33, sysconfig 0x2010, sysstatus 0x1, intrfsel 0x1, simenable 0x0 musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk split (X), HB-ISO Rx, HB-ISO Tx, SoftConn) musb_hdrc: MHDRC RTL version 1.400 musb_hdrc: setup fifo_mode 4 musb_hdrc: 28/31 max ep, 16384/16384 memory musb_hdrc: hw_ep 0shared, max 64 musb_hdrc: hw_ep 1tx, max 512 musb_hdrc: hw_ep 1rx, max 512 musb_hdrc: hw_ep 2tx, max 512 musb_hdrc: hw_ep 2rx, max 512 musb_hdrc: hw_ep 3tx, max 512 musb_hdrc: hw_ep 3rx, max 512 musb_hdrc: hw_ep 4tx, max 512 musb_hdrc: hw_ep 4rx, max 512 musb_hdrc: hw_ep 5tx, max 512 musb_hdrc: hw_ep 5rx, max 512 musb_hdrc: hw_ep 6tx, max 512 musb_hdrc: hw_ep 6rx, max 512 musb_hdrc: hw_ep 7tx, max 512 musb_hdrc: hw_ep 7rx, max 512 musb_hdrc: hw_ep 8tx, max 512 musb_hdrc: hw_ep 8rx, max 512 musb_hdrc: hw_ep 9tx, max 512 musb_hdrc: hw_ep 9rx, max 512 musb_hdrc: hw_ep 10tx, max 256 musb_hdrc: hw_ep 10rx, max 64 musb_hdrc: hw_ep 11tx, max 256 musb_hdrc: hw_ep 11rx, max 64 musb_hdrc: hw_ep 12tx, max 256 musb_hdrc: hw_ep 12rx, max 64 musb_hdrc: hw_ep 13shared, max 4096 musb_hdrc: hw_ep 14shared, max 1024 musb_hdrc: hw_ep 15shared, max 1024 musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected musb_start 883: == devctl 80 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty musb-hcd usb usb1: SerialNumber: musb_hdrc musb_init_controller 2057: HOST mode, status 0, devctl 81 B twl4030_usb twl4030_usb: ++ twl4030_usb_irq: twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data f2 twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) twl4030_usb twl4030_usb: ++ twl4030_phy_resume: twl4030_usb twl4030_usb: -- twl4030_usb_irq: twl4030_usb twl4030_usb: twl4030_usb_write: address 0c data 20 OMAP-35x# musb_stage2_irq 812: SUSPEND (b_idle) devctl 91 power e0 twl4030_usb twl4030_usb: ++ twl4030_usb_irq: twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data 72 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) twl4030_usb twl4030_usb: ++
Re: Question regarding MUSB and dynamic fifo sizing
On Tue, 2009-08-11 at 09:33 +0300, Felipe Balbi wrote: Hi, On Mon, Aug 10, 2009 at 10:42:41PM +0200, ext Peter Barada wrote: Since the twl4030 thinks its got Vbus, I've added code to dump the TWL4030 register accesses and other structure in the twl4030-usb.c code to understand what its doing. So, from power up(with nothing connected), I see: twl4030_usb twl4030_usb: ++ twl4030_usb_ldo_init: twl4030_usb twl4030_usb: -- twl4030_usb_ldo_init: twl4030_usb twl4030_usb: ++ twl4030_usb_irq: twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data 72 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) twl4030_usb twl4030_usb: ++ twl4030_phy_suspend: controller_off 0 twl4030_usb twl4030_usb: -- twl4030_usb_irq: twl4030_usb twl4030_usb: Initialized TWL4030 USB module twl4030_usb twl4030_usb: twl4030_usb_write: address 0c data 20 1) The only write is from twl4030_vbus_work to clear DRVBUS in OTG_CTRL since HW_CONDITION shows Vbus and ID not set. that's ok, so far. modprobe of the driver gives OMAP-35x# modprobe musb_hdrc musb_hdrc: version 6.0, pio, host, debug=3 twl4030_usb twl4030_usb: ++ twl4030_phy_resume: twl4030_usb twl4030_usb: ++ twl4030_phy_power: on 1 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fd data 01 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fd data 00 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_usb_write: address fe data 06 twl4030_usb twl4030_usb: -- twl4030_phy_power: twl4030_usb twl4030_usb: twl4030_i2c_access: on 1 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 07 twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: -- twl4030_i2c_access: twl4030_usb twl4030_usb: twl4030_usb_set_mode: mode 1 twl4030_usb twl4030_usb: twl4030_usb_write: address 09 data 04 twl4030_usb twl4030_usb: twl4030_usb_write: address ad data 20 twl4030_usb twl4030_usb: twl4030_usb_write: address 06 data 1b twl4030_usb twl4030_usb: -- twl4030_usb_set_mode: twl4030_usb twl4030_usb: twl4030_i2c_access: on 0 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 07 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 06 twl4030_usb twl4030_usb: -- twl4030_i2c_access: twl4030_usb twl4030_usb: -- twl4030_phy_resume: HS USB OTG: revision 0x33, sysconfig 0x2010, sysstatus 0x1, intrfsel 0x1, simenable 0x0 musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk split (X), HB-ISO Rx, HB-ISO Tx, SoftConn) musb_hdrc: MHDRC RTL version 1.400 musb_hdrc: setup fifo_mode 4 musb_hdrc: 28/31 max ep, 16384/16384 memory musb_hdrc: hw_ep 0shared, max 64 musb_hdrc: hw_ep 1tx, max 512 musb_hdrc: hw_ep 1rx, max 512 musb_hdrc: hw_ep 2tx, max 512 musb_hdrc: hw_ep 2rx, max 512 musb_hdrc: hw_ep 3tx, max 512 musb_hdrc: hw_ep 3rx, max 512 musb_hdrc: hw_ep 4tx, max 512 musb_hdrc: hw_ep 4rx, max 512 musb_hdrc: hw_ep 5tx, max 512 musb_hdrc: hw_ep 5rx, max 512 musb_hdrc: hw_ep 6tx, max 512 musb_hdrc: hw_ep 6rx, max 512 musb_hdrc: hw_ep 7tx, max 512 musb_hdrc: hw_ep 7rx, max 512 musb_hdrc: hw_ep 8tx, max 512 musb_hdrc: hw_ep 8rx, max 512 musb_hdrc: hw_ep 9tx, max 512 musb_hdrc: hw_ep 9rx, max 512 musb_hdrc: hw_ep 10tx, max 256 musb_hdrc: hw_ep 10rx, max 64 musb_hdrc: hw_ep 11tx, max 256 musb_hdrc: hw_ep 11rx, max 64 musb_hdrc: hw_ep 12tx, max 256 musb_hdrc: hw_ep 12rx, max 64 musb_hdrc: hw_ep 13shared, max 4096 musb_hdrc: hw_ep 14shared, max 1024 musb_hdrc: hw_ep 15shared, max 1024 musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected musb_start 883: == devctl 80 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty musb-hcd usb usb1: SerialNumber: musb_hdrc musb_init_controller 2057: HOST mode, status 0, devctl 81 B twl4030_usb twl4030_usb: ++ twl4030_usb_irq: twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data f2 twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) twl4030_usb twl4030_usb: ++ twl4030_phy_resume: twl4030_usb twl4030_usb: -- twl4030_usb_irq: twl4030_usb twl4030_usb: twl4030_usb_write: address 0c data 20 OMAP-35x# musb_stage2_irq 812: SUSPEND (b_idle) devctl 91 power e0 twl4030_usb twl4030_usb: ++ twl4030_usb_irq:
Re: Question regarding MUSB and dynamic fifo sizing
Hi, On Tue, Aug 11, 2009 at 11:21:17AM -0400, Peter Barada wrote: Unfortunately, with the patch, and: 1) modprobe musb_hdrc 2) modprobe g_ether 3) connect micro-a cable 4) echo 1 /sys/devices/platform/musb_hdrc/connect Nothing happens - no isr or output. did you have anything at the other end of the micro-a cable ? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding MUSB and dynamic fifo sizing
On Tue, 2009-08-11 at 23:51 +0300, Felipe Balbi wrote: Hi, On Tue, Aug 11, 2009 at 11:21:17AM -0400, Peter Barada wrote: Unfortunately, with the patch, and: 1) modprobe musb_hdrc 2) modprobe g_ether 3) connect micro-a cable 4) echo 1 /sys/devices/platform/musb_hdrc/connect Nothing happens - no isr or output. did you have anything at the other end of the micro-a cable ? Not then. :) I just connected my OTG adapter/thumbdrive, in step three and nothing no isr or output. I know my OTG adapter (micro-a - female A) is valid as I ohm'd out ID and ground on the baseboard (with the SOM removed), and indeed ID is shorted to ground with the adapter plugged in and open with it removed... -- Peter Barada pet...@logicpd.com Logic Product Development, Inc. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding MUSB and dynamic fifo sizing
On Tue, Aug 11, 2009 at 05:17:56PM -0400, Peter Barada wrote: On Tue, 2009-08-11 at 23:51 +0300, Felipe Balbi wrote: Hi, On Tue, Aug 11, 2009 at 11:21:17AM -0400, Peter Barada wrote: Unfortunately, with the patch, and: 1) modprobe musb_hdrc 2) modprobe g_ether 3) connect micro-a cable 4) echo 1 /sys/devices/platform/musb_hdrc/connect Nothing happens - no isr or output. did you have anything at the other end of the micro-a cable ? Not then. :) I just connected my OTG adapter/thumbdrive, in step three and nothing no isr or output. I know my OTG adapter (micro-a - female A) is valid as I ohm'd out ID and ground on the baseboard (with the SOM removed), and indeed ID is shorted to ground with the adapter plugged in and open with it removed... Well, looks like I'll have to go back to my documentation tomorrow at the office and see if I can get it working on one board of mine, let's see what happens and if I have to patch anything and what. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding MUSB and dynamic fifo sizing
On Sat, 2009-08-08 at 10:17 +0300, Felipe Balbi wrote:
Hi,
On Sat, Aug 08, 2009 at 09:43:13AM +0300, Felipe Balbi wrote:
On Fri, Aug 07, 2009 at 10:17:12PM +0200, Balbi Felipe (Nokia-D/Helsinki)
wrote:
On Fri, Aug 07, 2009 at 09:22:33PM +0200, ext Peter Barada wrote:
Someting strange is going on. If I boot with the MUSB-OTG adapter -
thumbdrive plugged in, and then modprobe the driver, it finds the
thumbdrive. I can then remove/reinsert the OTG adapter - thumbdrive
multiple times, and each time it is enumerated.
If I boot w/o the OTG adapter - thumbdrive plugged in, modprobe the
musb driver, and then plug in the OTG adaptor -thumbdrive, it is not
enumerated.
Any idea why I need the OTG adapter - thumbdrive plugged in at kernel
boot for it to enumerate the thumbdrive?
which board are you using ?
ok, got you. it's 35xx-based with twl4030.
when you plug the micro-a cable, see on drivers/usb/otg/twl4030-usb.c
what happens. You should have a print about the link status, see if that
is ID.
Then try something like this patch:
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 9e3e7a5..4bc5b7f 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
Felipe,
Thanks for the patch. With the following modified patch (to fit my tree
as my pull was from the Kevin's PM tree, commit
7c5cb7862d32cb344be7831d466535d5255e35ac) it worked like a charm:
diff --exclude CVS -uNr linux-2.6.28-rc8/drivers/usb/otg/twl4030-usb.c
linux-2.6.28-rc8.modified/drivers/usb/otg/twl4030-usb.c
--- linux-2.6.28-rc8/drivers/usb/otg/twl4030-usb.c 2009-08-09
12:52:51.0 -0400
+++ linux-2.6.28-rc8.modified/drivers/usb/otg/twl4030-usb.c 2009-08-09
03:38:20.0 -0400
@@ -250,6 +250,8 @@
};
struct twl4030_usb {
+ /* used for driving or not vbus */
+ struct work_struct vbus_work;
struct otg_transceiver otg;
struct device *dev;
@@ -263,6 +265,7 @@
u8 linkstat;
u8 asleep;
boolirq_enabled;
+booldrive_vbus;
};
/* internal define on top of container_of */
@@ -344,6 +347,18 @@
return twl4030_usb_write(twl, reg + 2, bits);
}
+static void twl4030_vbus_work(struct work_struct *work)
+{
+ struct twl4030_usb *twl = container_of(work, struct
twl4030_usb, vbus_work);
+
+ if (twl-drive_vbus)
+ (void) twl4030_usb_set_bits(twl, TWL4030_OTG_CTRL,
+ TWL4030_OTG_CTRL_DRVVBUS);
+ else
+ (void) twl4030_usb_set_bits(twl, TWL4030_OTG_CTRL,
+ TWL4030_OTG_CTRL_DRVVBUS);
+}
+
/*-*/
static enum linkstat twl4030_usb_linkstat(struct twl4030_usb *twl)
@@ -374,12 +389,16 @@
if (linkstat == USB_LINK_ID) {
twl-otg.default_a = true;
twl-otg.state = OTG_STATE_A_IDLE;
+ twl-drive_vbus = true;
} else {
twl-otg.default_a = false;
twl-otg.state = OTG_STATE_B_IDLE;
+ twl-drive_vbus = false;
}
spin_unlock_irq(twl-lock);
+ schedule_work(twl-vbus_work);
+
return linkstat;
}
@@ -657,6 +676,8 @@
if (!twl)
return -ENOMEM;
+ INIT_WORK(twl-vbus_work, twl4030_vbus_work);
+
twl-dev= pdev-dev;
twl-irq= platform_get_irq(pdev, 0);
twl-otg.dev= twl-dev;
With it I can enumerate my OTG adapter/thumbdrive on insertion.
--
Peter Barada pet...@logicpd.com
Logic Product Development, Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding MUSB and dynamic fifo sizing
Hi, On Mon, Aug 10, 2009 at 10:33:19AM -0400, Peter Barada wrote: On Sat, 2009-08-08 at 10:17 +0300, Felipe Balbi wrote: Hi, On Sat, Aug 08, 2009 at 09:43:13AM +0300, Felipe Balbi wrote: On Fri, Aug 07, 2009 at 10:17:12PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote: On Fri, Aug 07, 2009 at 09:22:33PM +0200, ext Peter Barada wrote: Someting strange is going on. If I boot with the MUSB-OTG adapter - thumbdrive plugged in, and then modprobe the driver, it finds the thumbdrive. I can then remove/reinsert the OTG adapter - thumbdrive multiple times, and each time it is enumerated. If I boot w/o the OTG adapter - thumbdrive plugged in, modprobe the musb driver, and then plug in the OTG adaptor -thumbdrive, it is not enumerated. Any idea why I need the OTG adapter - thumbdrive plugged in at kernel boot for it to enumerate the thumbdrive? which board are you using ? ok, got you. it's 35xx-based with twl4030. when you plug the micro-a cable, see on drivers/usb/otg/twl4030-usb.c what happens. You should have a print about the link status, see if that is ID. Then try something like this patch: diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c index 9e3e7a5..4bc5b7f 100644 --- a/drivers/usb/otg/twl4030-usb.c +++ b/drivers/usb/otg/twl4030-usb.c Felipe, Thanks for the patch. With the following modified patch (to fit my tree as my pull was from the Kevin's PM tree, commit 7c5cb7862d32cb344be7831d466535d5255e35ac) it worked like a charm: Great, I'll clean it up and send it to Greg for mainline integration. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding MUSB and dynamic fifo sizing
On Mon, 2009-08-10 at 19:16 +0300, Felipe Balbi wrote: Hi, On Mon, Aug 10, 2009 at 10:33:19AM -0400, Peter Barada wrote: On Sat, 2009-08-08 at 10:17 +0300, Felipe Balbi wrote: Hi, On Sat, Aug 08, 2009 at 09:43:13AM +0300, Felipe Balbi wrote: On Fri, Aug 07, 2009 at 10:17:12PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote: On Fri, Aug 07, 2009 at 09:22:33PM +0200, ext Peter Barada wrote: Someting strange is going on. If I boot with the MUSB-OTG adapter - thumbdrive plugged in, and then modprobe the driver, it finds the thumbdrive. I can then remove/reinsert the OTG adapter - thumbdrive multiple times, and each time it is enumerated. If I boot w/o the OTG adapter - thumbdrive plugged in, modprobe the musb driver, and then plug in the OTG adaptor -thumbdrive, it is not enumerated. Any idea why I need the OTG adapter - thumbdrive plugged in at kernel boot for it to enumerate the thumbdrive? which board are you using ? ok, got you. it's 35xx-based with twl4030. when you plug the micro-a cable, see on drivers/usb/otg/twl4030-usb.c what happens. You should have a print about the link status, see if that is ID. Then try something like this patch: diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c index 9e3e7a5..4bc5b7f 100644 --- a/drivers/usb/otg/twl4030-usb.c +++ b/drivers/usb/otg/twl4030-usb.c Felipe, Thanks for the patch. With the following modified patch (to fit my tree as my pull was from the Kevin's PM tree, commit 7c5cb7862d32cb344be7831d466535d5255e35ac) it worked like a charm: Great, I'll clean it up and send it to Greg for mainline integration. Actually, not quite. I noticed that twl4030_vbus_work only sets Vbus, never clears it. With that change and the driver configured for OTG mode (I had it host when I tested), it doesn't enumerate. I added code to decipher the link state, and on startup I now see: Jan 1 00:00:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) Then when I load the driver: Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) And when I plug in the OTG adapter/thumbdrive: Jan 1 00:02:24 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x76/118; link 3 (ID) and Vbus goes to +5V 30mS after ID grounds, and stays at 5V for only 30mS then goes back to ground. Pulling out and reinserting repeast the cycle. During this total time, only two interrupts occur ont he MUSB controller. It looks like the connect interrupt is not occuring. I'm adding more code to track the interrupts for both the twl4030-usb and musb_hdrc so I can understand better what's happening (and more importantly what's not). -- Peter Barada pet...@logicpd.com Logic Product Development, Inc. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding MUSB and dynamic fifo sizing
Hi, On Mon, Aug 10, 2009 at 01:00:07PM -0400, Peter Barada wrote: Actually, not quite. I noticed that twl4030_vbus_work only sets Vbus, never clears it. With that change and the driver configured for OTG mode (I had it host when I tested), it doesn't enumerate. I added code to decipher the link state, and on startup I now see: Jan 1 00:00:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) Then when I load the driver: Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) And when I plug in the OTG adapter/thumbdrive: Jan 1 00:02:24 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x76/118; link 3 (ID) and Vbus goes to +5V 30mS after ID grounds, and stays at 5V for only 30mS then goes back to ground. Pulling out and reinserting repeast the cycle. During this total time, only two interrupts occur ont he MUSB controller. It looks like the connect interrupt is not occuring. I'm adding more code to track the interrupts for both the twl4030-usb and musb_hdrc so I can understand better what's happening (and more importantly what's not). good you reported :-) I was about to send a version to linux-usb. Let's see what's going on: on you setup: # echo 3 /sys/modules/musb_hdrc/parameters/debug # echo 9 /proc/sysrq-trigger this will give you more verbose output of what musb sees. BTW, it's odd you get a VBUS link irq when there shouldn't be any unless you have the board attached to pc at that time. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding MUSB and dynamic fifo sizing
On Mon, 2009-08-10 at 20:02 +0300, Felipe Balbi wrote: Hi, On Mon, Aug 10, 2009 at 01:00:07PM -0400, Peter Barada wrote: Actually, not quite. I noticed that twl4030_vbus_work only sets Vbus, never clears it. With that change and the driver configured for OTG mode (I had it host when I tested), it doesn't enumerate. I added code to decipher the link state, and on startup I now see: Jan 1 00:00:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) Then when I load the driver: Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) And when I plug in the OTG adapter/thumbdrive: Jan 1 00:02:24 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x76/118; link 3 (ID) and Vbus goes to +5V 30mS after ID grounds, and stays at 5V for only 30mS then goes back to ground. Pulling out and reinserting repeast the cycle. During this total time, only two interrupts occur ont he MUSB controller. It looks like the connect interrupt is not occuring. I'm adding more code to track the interrupts for both the twl4030-usb and musb_hdrc so I can understand better what's happening (and more importantly what's not). good you reported :-) I was about to send a version to linux-usb. Let's see what's going on: on you setup: # echo 3 /sys/modules/musb_hdrc/parameters/debug # echo 9 /proc/sysrq-trigger this will give you more verbose output of what musb sees. BTW, it's odd you get a VBUS link irq when there shouldn't be any unless you have the board attached to pc at that time. Nothing's attached to the OTG port at that time. W/nothing plugged in from powerup, The log first shows: Jan 1 12:26:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) I rebuild with musb_debug=3 to get messages from the module on startup, and nothing plugges in from powerup, loading the module comes back with: OMAP-35x# modprobe musb_hdrc musb_hdrc: version 6.0, pio, host, debug=3 HS USB OTG: revision 0x33, sysconfig 0x2010, sysstatus 0x1, intrfsel 0x1, simenable 0x0 musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk split (X), HB-ISO Rx, HB-ISO Tx, SoftConn) musb_hdrc: MHDRC RTL version 1.400 musb_hdrc: setup fifo_mode 4 musb_hdrc: 28/31 max ep, 16384/16384 memory musb_hdrc: hw_ep 0shared, max 64 musb_hdrc: hw_ep 1tx, max 512 musb_hdrc: hw_ep 1rx, max 512 musb_hdrc: hw_ep 2tx, max 512 musb_hdrc: hw_ep 2rx, max 512 musb_hdrc: hw_ep 3tx, max 512 musb_hdrc: hw_ep 3rx, max 512 musb_hdrc: hw_ep 4tx, max 512 musb_hdrc: hw_ep 4rx, max 512 musb_hdrc: hw_ep 5tx, max 512 musb_hdrc: hw_ep 5rx, max 512 musb_hdrc: hw_ep 6tx, max 512 musb_hdrc: hw_ep 6rx, max 512 musb_hdrc: hw_ep 7tx, max 512 musb_hdrc: hw_ep 7rx, max 512 musb_hdrc: hw_ep 8tx, max 512 musb_hdrc: hw_ep 8rx, max 512 musb_hdrc: hw_ep 9tx, max 512 musb_hdrc: hw_ep 9rx, max 512 musb_hdrc: hw_ep 10tx, max 256 musb_hdrc: hw_ep 10rx, max 64 musb_hdrc: hw_ep 11tx, max 256 musb_hdrc: hw_ep 11rx, max 64 musb_hdrc: hw_ep 12tx, max 256 musb_hdrc: hw_ep 12rx, max 64 musb_hdrc: hw_ep 13shared, max 4096 musb_hdrc: hw_ep 14shared, max 1024 musb_hdrc: hw_ep 15shared, max 1024 musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected musb_start 883: == devctl 80 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty musb-hcd usb usb1: SerialNumber: musb_hdrc musb_init_controller 2057: HOST mode, status 0, devctl 81 B twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) OMAP-35x# musb_stage2_irq 812: SUSPEND (b_idle) devctl 91 power e0 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) Looking at the schematics, outside of a 4.7uF between Vbus and ground, nothing else is connected to the OTG D+, D-, ID, or Vbus except the connector... 1) With the twl4030 triggering Vbus, the MUSB must think its a peripheral, and then goes into suspend - why would the twl4030 think its getting Vbus supplied to it? -- Peter Barada pet...@logicpd.com Logic Product Development, Inc. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding MUSB and dynamic fifo sizing
On Mon, 2009-08-10 at 21:48 +0300, Felipe Balbi wrote: On Mon, Aug 10, 2009 at 01:28:43PM -0400, Peter Barada wrote: On Mon, 2009-08-10 at 20:02 +0300, Felipe Balbi wrote: Hi, On Mon, Aug 10, 2009 at 01:00:07PM -0400, Peter Barada wrote: Actually, not quite. I noticed that twl4030_vbus_work only sets Vbus, never clears it. With that change and the driver configured for OTG mode (I had it host when I tested), it doesn't enumerate. I added code to decipher the link state, and on startup I now see: Jan 1 00:00:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) Then when I load the driver: Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) Jan 1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) And when I plug in the OTG adapter/thumbdrive: Jan 1 00:02:24 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x76/118; link 3 (ID) and Vbus goes to +5V 30mS after ID grounds, and stays at 5V for only 30mS then goes back to ground. Pulling out and reinserting repeast the cycle. During this total time, only two interrupts occur ont he MUSB controller. It looks like the connect interrupt is not occuring. I'm adding more code to track the interrupts for both the twl4030-usb and musb_hdrc so I can understand better what's happening (and more importantly what's not). good you reported :-) I was about to send a version to linux-usb. Let's see what's going on: on you setup: # echo 3 /sys/modules/musb_hdrc/parameters/debug # echo 9 /proc/sysrq-trigger this will give you more verbose output of what musb sees. BTW, it's odd you get a VBUS link irq when there shouldn't be any unless you have the board attached to pc at that time. Nothing's attached to the OTG port at that time. W/nothing plugged in from powerup, The log first shows: Jan 1 12:26:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) I rebuild with musb_debug=3 to get messages from the module on startup, and nothing plugges in from powerup, loading the module comes back with: OMAP-35x# modprobe musb_hdrc musb_hdrc: version 6.0, pio, host, debug=3 HS USB OTG: revision 0x33, sysconfig 0x2010, sysstatus 0x1, intrfsel 0x1, simenable 0x0 musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk split (X), HB-ISO Rx, HB-ISO Tx, SoftConn) musb_hdrc: MHDRC RTL version 1.400 musb_hdrc: setup fifo_mode 4 musb_hdrc: 28/31 max ep, 16384/16384 memory musb_hdrc: hw_ep 0shared, max 64 musb_hdrc: hw_ep 1tx, max 512 musb_hdrc: hw_ep 1rx, max 512 musb_hdrc: hw_ep 2tx, max 512 musb_hdrc: hw_ep 2rx, max 512 musb_hdrc: hw_ep 3tx, max 512 musb_hdrc: hw_ep 3rx, max 512 musb_hdrc: hw_ep 4tx, max 512 musb_hdrc: hw_ep 4rx, max 512 musb_hdrc: hw_ep 5tx, max 512 musb_hdrc: hw_ep 5rx, max 512 musb_hdrc: hw_ep 6tx, max 512 musb_hdrc: hw_ep 6rx, max 512 musb_hdrc: hw_ep 7tx, max 512 musb_hdrc: hw_ep 7rx, max 512 musb_hdrc: hw_ep 8tx, max 512 musb_hdrc: hw_ep 8rx, max 512 musb_hdrc: hw_ep 9tx, max 512 musb_hdrc: hw_ep 9rx, max 512 musb_hdrc: hw_ep 10tx, max 256 musb_hdrc: hw_ep 10rx, max 64 musb_hdrc: hw_ep 11tx, max 256 musb_hdrc: hw_ep 11rx, max 64 musb_hdrc: hw_ep 12tx, max 256 musb_hdrc: hw_ep 12rx, max 64 musb_hdrc: hw_ep 13shared, max 4096 musb_hdrc: hw_ep 14shared, max 1024 musb_hdrc: hw_ep 15shared, max 1024 musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected musb_start 883: == devctl 80 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty musb-hcd usb usb1: SerialNumber: musb_hdrc musb_init_controller 2057: HOST mode, status 0, devctl 81 B twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) OMAP-35x# musb_stage2_irq 812: SUSPEND (b_idle) devctl 91 power e0 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) Looking at the schematics, outside of a 4.7uF between Vbus and ground, nothing else is connected to the OTG D+, D-, ID, or Vbus except the connector... 1) With the twl4030 triggering Vbus, the MUSB must think its a peripheral, and then goes into suspend - why would the twl4030 think its getting Vbus supplied to it? donno yet, no clue unfortunately. but could you try the following Since
Re: Question regarding MUSB and dynamic fifo sizing
Hi,
On Sat, Aug 08, 2009 at 09:43:13AM +0300, Felipe Balbi wrote:
On Fri, Aug 07, 2009 at 10:17:12PM +0200, Balbi Felipe (Nokia-D/Helsinki)
wrote:
On Fri, Aug 07, 2009 at 09:22:33PM +0200, ext Peter Barada wrote:
Someting strange is going on. If I boot with the MUSB-OTG adapter -
thumbdrive plugged in, and then modprobe the driver, it finds the
thumbdrive. I can then remove/reinsert the OTG adapter - thumbdrive
multiple times, and each time it is enumerated.
If I boot w/o the OTG adapter - thumbdrive plugged in, modprobe the
musb driver, and then plug in the OTG adaptor -thumbdrive, it is not
enumerated.
Any idea why I need the OTG adapter - thumbdrive plugged in at kernel
boot for it to enumerate the thumbdrive?
which board are you using ?
ok, got you. it's 35xx-based with twl4030.
when you plug the micro-a cable, see on drivers/usb/otg/twl4030-usb.c
what happens. You should have a print about the link status, see if that
is ID.
Then try something like this patch:
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 9e3e7a5..4bc5b7f 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -246,6 +246,8 @@ enum linkstat {
};
struct twl4030_usb {
+ /* used for driving or not vbus */
+ struct work_struct work;
struct otg_transceiver otg;
struct device *dev;
forgot to add the drive_vbus field here. Better patch right below
== cut here =
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 9e3e7a5..2a2cc8e 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -246,6 +246,8 @@ enum linkstat {
};
struct twl4030_usb {
+ /* used for driving or not vbus */
+ struct work_struct work;
struct otg_transceiver otg;
struct device *dev;
@@ -264,6 +266,7 @@ struct twl4030_usb {
u8 linkstat;
u8 asleep;
boolirq_enabled;
+ booldrive_vbus;
};
/* internal define on top of container_of */
@@ -347,6 +350,18 @@ twl4030_usb_clear_bits(struct twl4030_usb *twl, u8 reg, u8
bits)
/*-*/
+static void twl4030_vbus_work(struct work_struct *work)
+{
+ struct twl4030_usb *twl = container_of(work, twl4030_usb, work);
+
+ if (twl-driver_vbus)
+ (void) twl4030_usb_set_bits(twl, TWL4030_OTG_CTRL,
+ TWL4030_OTG_DRVVBUS);
+ else
+ (void) twl4030_usb_set_bits(twl, TWL4030_OTG_CTRL,
+ TWL4030_OTG_DRVVBUS);
+}
+
static enum linkstat twl4030_usb_linkstat(struct twl4030_usb *twl)
{
int status;
@@ -386,12 +401,16 @@ static enum linkstat twl4030_usb_linkstat(struct
twl4030_usb *twl)
if (linkstat == USB_LINK_ID) {
twl-otg.default_a = true;
twl-otg.state = OTG_STATE_A_IDLE;
+ twl-drive_vbus = true;
} else {
twl-otg.default_a = false;
twl-otg.state = OTG_STATE_B_IDLE;
+ twl-drive_vbus = false;
}
spin_unlock_irq(twl-lock);
+ schedule_work(twl-vbus_work);
+
return linkstat;
}
@@ -668,6 +687,8 @@ static int __devinit twl4030_usb_probe(struct
platform_device *pdev)
if (!twl)
return -ENOMEM;
+ INIT_WORK(twl-work, twl4030_vbus_work);
+
twl-dev= pdev-dev;
twl-irq= platform_get_irq(pdev, 0);
twl-otg.dev= twl-dev;
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question regarding MUSB and dynamic fifo sizing
On Fri, 2009-08-07 at 01:41 +0530, Gadiyar, Anand wrote: Peter Barada wrote: I'm running into a problem where the MUSB controller stops talking with the hardwired device on the other end, and I wasn to unload the musb as a module and reload it to the connection working again. I can compile MSUB as a module, but when I load it the 2nd time it complains with: OMAP-35x# modprobe musb_hdrc musb_hdrc: version 6.0, pio, otg (peripheral+host), debug=0 musb_core_init 1421: reconfigure software for static FIFOs musb_hdrc musb_hdrc: musb_init_controller failed with status -19 This is due to the platform device wanting dynamic fifo sizing but the CONFIGDATA register has DYNFIFO bit cleared. Looking through the TRM, I can't find informaiton on how the MUSB controller changes the state of DYNFIFO - I'm guessing once any of the dynamic registers are written to that the controller switches to Dynamic Fifo sizing. This patch from Ajay (already in mainline) should fix it for you. http://marc.info/?l=linux-usbm=124881724122257w=2 The problem is not that the CONFIGDATA changes, but that we attempt to read from CONFIGDATA without having set the INDEX register to 0. CONFIGDATA is a read-only register. Thanks, that patch allows me to modprobe/rmmod the musb_hdrc module, but shows another problem - after a modprobe/rmmod/modprobe of the musb_hdrc driver I don't see any USB devices downstream of the MUSB: I have the following setup plugged in at boot(and left plugged in): MUSB - OTG cable - Hub - thumbdrive When I modprobe the driver the first time I get: OMAP-35x# modprobe musb_hdrc musb_hdrc: version 6.0, pio, host, debug=0 musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty musb-hcd usb usb1: SerialNumber: musb_hdrc usb 1-1: new high speed USB device using musb_hdrc and address 2 usb 1-1: configuration #1 chosen from 1 choice hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb 1-1: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1: Product: USB2.0 Hub hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) OMAP-35x# lsusb Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Bus 001 Device 001: ID 1d6b:0002 OMAP-35x# Rmmod'ng the driver shows: OMAP-35x# rmmod musb_hdrc musb_hdrc musb_hdrc: remove, state 1 usb usb1: USB disconnect, address 1 usb 1-1: USB disconnect, address 2 musb_hdrc musb_hdrc: USB bus 1 deregistered But modprobing the musb_hdrc driver a 2nd time shows: OMAP-35x# modprobe musb_hdrc musb_hdrc: version 6.0, pio, host, debug=0 musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty musb-hcd usb usb1: SerialNumber: musb_hdrc OMAP-35x# OMAP-35x# lsusb Bus 001 Device 001: ID 1d6b:0002 And it fails to find the hub or thumbdrive. 1) Any idea why I'd see -ETIMEDOUT from musb_hdrc on the first modprobe? 2) Any ideas why musb_hdrc finds the hub/thumbdrive on the first modprobe, but not the 2nd? 3) I don't see any twl4030_usb interrupts from kernel boot - should I see them? Thanks in advance! -- Peter Barada pet...@logicpd.com Logic Product Development, Inc. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question regarding MUSB and dynamic fifo sizing
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Peter Barada Sent: Friday, August 07, 2009 12:24 PM To: Gadiyar, Anand Cc: linux-omap Subject: RE: Question regarding MUSB and dynamic fifo sizing On Fri, 2009-08-07 at 01:41 +0530, Gadiyar, Anand wrote: Peter Barada wrote: I'm running into a problem where the MUSB controller stops talking with the hardwired device on the other end, and I wasn to unload the musb as a module and reload it to the connection working again. I can compile MSUB as a module, but when I load it the 2nd time it complains with: OMAP-35x# modprobe musb_hdrc musb_hdrc: version 6.0, pio, otg (peripheral+host), debug=0 musb_core_init 1421: reconfigure software for static FIFOs musb_hdrc musb_hdrc: musb_init_controller failed with status -19 This is due to the platform device wanting dynamic fifo sizing but the CONFIGDATA register has DYNFIFO bit cleared. Looking through the TRM, I can't find informaiton on how the MUSB controller changes the state of DYNFIFO - I'm guessing once any of the dynamic registers are written to that the controller switches to Dynamic Fifo sizing. This patch from Ajay (already in mainline) should fix it for you. http://marc.info/?l=linux-usbm=124881724122257w=2 The problem is not that the CONFIGDATA changes, but that we attempt to read from CONFIGDATA without having set the INDEX register to 0. CONFIGDATA is a read-only register. Thanks, that patch allows me to modprobe/rmmod the musb_hdrc module, but shows another problem - after a modprobe/rmmod/modprobe of the musb_hdrc driver I don't see any USB devices downstream of the MUSB: I have the following setup plugged in at boot(and left plugged in): MUSB - OTG cable - Hub - thumbdrive When I modprobe the driver the first time I get: hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) OMAP-35x# lsusb Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Bus 001 Device 001: ID 1d6b:0002 Do things work fine without the hub for multiple insmod/rmmod? Case = MUSB - OTG cable - thumbdrive Is hub introducing some issue here looking at above logs? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question regarding MUSB and dynamic fifo sizing
On Fri, 2009-08-07 at 22:55 +0530, Pandita, Vikram wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Peter Barada Sent: Friday, August 07, 2009 12:24 PM To: Gadiyar, Anand Cc: linux-omap Subject: RE: Question regarding MUSB and dynamic fifo sizing On Fri, 2009-08-07 at 01:41 +0530, Gadiyar, Anand wrote: Peter Barada wrote: I'm running into a problem where the MUSB controller stops talking with the hardwired device on the other end, and I wasn to unload the musb as a module and reload it to the connection working again. I can compile MSUB as a module, but when I load it the 2nd time it complains with: OMAP-35x# modprobe musb_hdrc musb_hdrc: version 6.0, pio, otg (peripheral+host), debug=0 musb_core_init 1421: reconfigure software for static FIFOs musb_hdrc musb_hdrc: musb_init_controller failed with status -19 This is due to the platform device wanting dynamic fifo sizing but the CONFIGDATA register has DYNFIFO bit cleared. Looking through the TRM, I can't find informaiton on how the MUSB controller changes the state of DYNFIFO - I'm guessing once any of the dynamic registers are written to that the controller switches to Dynamic Fifo sizing. This patch from Ajay (already in mainline) should fix it for you. http://marc.info/?l=linux-usbm=124881724122257w=2 The problem is not that the CONFIGDATA changes, but that we attempt to read from CONFIGDATA without having set the INDEX register to 0. CONFIGDATA is a read-only register. Thanks, that patch allows me to modprobe/rmmod the musb_hdrc module, but shows another problem - after a modprobe/rmmod/modprobe of the musb_hdrc driver I don't see any USB devices downstream of the MUSB: I have the following setup plugged in at boot(and left plugged in): MUSB - OTG cable - Hub - thumbdrive When I modprobe the driver the first time I get: hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) OMAP-35x# lsusb Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Bus 001 Device 001: ID 1d6b:0002 Do things work fine without the hub for multiple insmod/rmmod? Case = MUSB - OTG cable - thumbdrive Is hub introducing some issue here looking at above logs? Someting strange is going on. If I boot with the MUSB-OTG adapter - thumbdrive plugged in, and then modprobe the driver, it finds the thumbdrive. I can then remove/reinsert the OTG adapter - thumbdrive multiple times, and each time it is enumerated. If I boot w/o the OTG adapter - thumbdrive plugged in, modprobe the musb driver, and then plug in the OTG adaptor -thumbdrive, it is not enumerated. Any idea why I need the OTG adapter - thumbdrive plugged in at kernel boot for it to enumerate the thumbdrive? -- Peter Barada pet...@logicpd.com Logic Product Development, Inc. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding MUSB and dynamic fifo sizing
On Fri, Aug 07, 2009 at 09:22:33PM +0200, ext Peter Barada wrote: Someting strange is going on. If I boot with the MUSB-OTG adapter - thumbdrive plugged in, and then modprobe the driver, it finds the thumbdrive. I can then remove/reinsert the OTG adapter - thumbdrive multiple times, and each time it is enumerated. If I boot w/o the OTG adapter - thumbdrive plugged in, modprobe the musb driver, and then plug in the OTG adaptor -thumbdrive, it is not enumerated. Any idea why I need the OTG adapter - thumbdrive plugged in at kernel boot for it to enumerate the thumbdrive? which board are you using ? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question regarding MUSB and dynamic fifo sizing
Someting strange is going on. If I boot with the MUSB-OTG adapter - thumbdrive plugged in, and then modprobe the driver, it finds the thumbdrive. I can then remove/reinsert the OTG adapter - thumbdrive multiple times, and each time it is enumerated. If I boot w/o the OTG adapter - thumbdrive plugged in, modprobe the musb driver, and then plug in the OTG adaptor -thumbdrive, it is not enumerated. Any idea why I need the OTG adapter - thumbdrive plugged in at kernel boot for it to enumerate the thumbdrive? It seems Vbus is off and thus nothing is detected. There is already a fix for this (at least for host only driver) in mainline but as you are using v2.6.28-rc8 that fix is not in your driver. Please try using below patch, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=743821717c611913a5a3f95010b141f0b4cb5463 This will solve the problem for host only driver but for otg build driver Vbus will be switched off as of now we don't have any entry to revive it.We use to start session and Vbus using $echo F /proc/driver/musb_hdrc but now that proc entry is gone and equivalent debugfs entry is suppose to come. I would suggest to pull in all musb specific patches from mainline tree into your driver or move to a newer kernel version. -Ajay -- Peter Barada pet...@logicpd.com Logic Product Development, Inc. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question regarding MUSB and dynamic fifo sizing
-Original Message- From: Gupta, Ajay Kumar Sent: Friday, August 07, 2009 10:04 PM To: Peter Barada; Pandita, Vikram Cc: Gadiyar, Anand; linux-omap Subject: RE: Question regarding MUSB and dynamic fifo sizing Please try using below patch, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux- 2.6.git;a=commitdiff;h=743821717c611913a5a3f95010b141f0b4cb5463 This will solve the problem for host only driver but for otg build driver Vbus will be switched off as of now we don't have any entry to revive it.We use to start session and Vbus using $echo F /proc/driver/musb_hdrc but now that proc entry is gone and equivalent debugfs entry is suppose to come. The sysfs entry is already there and working like charm - echo otg /sys/devices/platform/musb_hdrc/mode I would suggest to pull in all musb specific patches from mainline tree into your driver or move to a newer kernel version. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question regarding MUSB and dynamic fifo sizing
Peter Barada wrote:
I'm running into a problem where the MUSB controller stops talking with
the hardwired device on the other end, and I wasn to unload the musb as
a module and reload it to the connection working again.
I can compile MSUB as a module, but when I load it the 2nd time it
complains with:
OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, otg (peripheral+host), debug=0
musb_core_init 1421: reconfigure software for static FIFOs
musb_hdrc musb_hdrc: musb_init_controller failed with status -19
This is due to the platform device wanting dynamic fifo sizing but the
CONFIGDATA register has DYNFIFO bit cleared. Looking through the TRM, I
can't find informaiton on how the MUSB controller changes the state of
DYNFIFO - I'm guessing once any of the dynamic registers are written to
that the controller switches to Dynamic Fifo sizing.
This patch from Ajay (already in mainline) should fix it for you.
http://marc.info/?l=linux-usbm=124881724122257w=2
The problem is not that the CONFIGDATA changes, but that we attempt
to read from CONFIGDATA without having set the INDEX register to 0.
CONFIGDATA is a read-only register.
- Anand
The code that aborts is:
if (reg MUSB_CONFIGDATA_DYNFIFO) {
if (musb-config-dyn_fifo)
status = ep_config_from_table(musb);
else {
ERR(reconfigure software for Dynamic FIFOs\n);
status = -ENODEV;
}
} else {
if (!musb-config-dyn_fifo)
status = ep_config_from_hw(musb);
else {
ERR(reconfigure software for static FIFOs\n);
return -ENODEV;
}
}
1) How can one change from dynamic to static fifo sizing in the MUSB?
2) Would it be safe to program for dynamic fifo sizing if CONFIG_DATA
indicates the fifos are Statically sized?
--
Peter Barada pet...@logicpd.com
Logic Product Development, Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
