[U-Boot] USB Host not enumerating properly on AM335x-based board
Hi,
I'm currently working on 2014.07, on a custom TI AM335x based board.
Everything works great so far, except when we're trying to have USB host working.
The board has the MUSB1 controller wired as USB Host only, with the following configuration:
#define CONFIG_USB_MUSB_DSPS #define CONFIG_ARCH_MISC_INIT #define CONFIG_MUSB_PIO_ONLY #define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_MUSB_HOST #define CONFIG_MUSB_DSPS #define CONFIG_AM335X_USB1 #define CONFIG_AM335X_USB1_MODE MUSB_HOST
#ifdef CONFIG_MUSB_HOST #define CONFIG_CMD_USB #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_ASIX #endif
Whenever we try to scan the USB controller and that a device is attached, we get the following output:
U-Boot# usb start (Re)start USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found
The device itself being a USB key, it's somewhat odd that it enumerates the device, but doesn't find the storage device...
The same USB port with the same device works fine under Linux.
The VBUS pin is still up after running the command, so it's not really a matter of power being shut down on the bus.
I'm kind of running out of idea on what to test next. The differences between u-boot's musb-new and Linux' own musb driver seems thin and to make sense, so I don't think the driver itself is to blame.
Anyone experienced such a thing?
Thanks, Maxime
Hi Maxime,
Le Thu, 20 Nov 2014 17:49:17 +0100, Maxime Ripard maxime.ripard@free-electrons.com a écrit :
Hi,
I'm currently working on 2014.07, on a custom TI AM335x based board.
Everything works great so far, except when we're trying to have USB host working.
The board has the MUSB1 controller wired as USB Host only, with the following configuration:
#define CONFIG_USB_MUSB_DSPS #define CONFIG_ARCH_MISC_INIT #define CONFIG_MUSB_PIO_ONLY #define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_MUSB_HOST #define CONFIG_MUSB_DSPS #define CONFIG_AM335X_USB1 #define CONFIG_AM335X_USB1_MODE MUSB_HOST
#ifdef CONFIG_MUSB_HOST #define CONFIG_CMD_USB #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_ASIX #endif
Whenever we try to scan the USB controller and that a device is attached, we get the following output:
U-Boot# usb start (Re)start USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found
The device itself being a USB key, it's somewhat odd that it enumerates the device, but doesn't find the storage device...
The same USB port with the same device works fine under Linux.
The VBUS pin is still up after running the command, so it's not really a matter of power being shut down on the bus.
I'm kind of running out of idea on what to test next. The differences between u-boot's musb-new and Linux' own musb driver seems thin and to make sense, so I don't think the driver itself is to blame.
Anyone experienced such a thing?
what is the log you get when you run "usb start" and the USB device is not plugged ?
Eric
Hi Eric,
On Fri, Nov 21, 2014 at 11:20:37AM +0100, Eric Bénard wrote:
Hi Maxime,
Le Thu, 20 Nov 2014 17:49:17 +0100, Maxime Ripard maxime.ripard@free-electrons.com a écrit :
Hi,
I'm currently working on 2014.07, on a custom TI AM335x based board.
Everything works great so far, except when we're trying to have USB host working.
The board has the MUSB1 controller wired as USB Host only, with the following configuration:
#define CONFIG_USB_MUSB_DSPS #define CONFIG_ARCH_MISC_INIT #define CONFIG_MUSB_PIO_ONLY #define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_MUSB_HOST #define CONFIG_MUSB_DSPS #define CONFIG_AM335X_USB1 #define CONFIG_AM335X_USB1_MODE MUSB_HOST
#ifdef CONFIG_MUSB_HOST #define CONFIG_CMD_USB #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_ASIX #endif
Whenever we try to scan the USB controller and that a device is attached, we get the following output:
U-Boot# usb start (Re)start USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found
The device itself being a USB key, it's somewhat odd that it enumerates the device, but doesn't find the storage device...
The same USB port with the same device works fine under Linux.
The VBUS pin is still up after running the command, so it's not really a matter of power being shut down on the bus.
I'm kind of running out of idea on what to test next. The differences between u-boot's musb-new and Linux' own musb driver seems thin and to make sense, so I don't think the driver itself is to blame.
Anyone experienced such a thing?
what is the log you get when you run "usb start" and the USB device is not plugged ?
I get: U-Boot# usb start (Re)start USB... USB0: lowlevel init failed USB error: all controllers failed lowlevel init
Which seems like something worth looking at. Also, when I do it a second time, then it hangs, and finally reboots the board.
I don't really know what's going on, but we'll look into this.
Thanks! Maxime
On Friday, November 21, 2014 at 03:57:42 PM, Maxime Ripard wrote:
Hi Eric,
On Fri, Nov 21, 2014 at 11:20:37AM +0100, Eric Bénard wrote:
Hi Maxime,
Le Thu, 20 Nov 2014 17:49:17 +0100,
Maxime Ripard maxime.ripard@free-electrons.com a écrit :
Hi,
I'm currently working on 2014.07, on a custom TI AM335x based board.
Everything works great so far, except when we're trying to have USB host working.
The board has the MUSB1 controller wired as USB Host only, with the following configuration:
#define CONFIG_USB_MUSB_DSPS #define CONFIG_ARCH_MISC_INIT #define CONFIG_MUSB_PIO_ONLY #define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_MUSB_HOST #define CONFIG_MUSB_DSPS #define CONFIG_AM335X_USB1 #define CONFIG_AM335X_USB1_MODE MUSB_HOST
#ifdef CONFIG_MUSB_HOST #define CONFIG_CMD_USB #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_ASIX #endif
Whenever we try to scan the USB controller and that a device is attached, we get the following output:
U-Boot# usb start (Re)start USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) foundThe device itself being a USB key, it's somewhat odd that it enumerates the device, but doesn't find the storage device...
The same USB port with the same device works fine under Linux.
The VBUS pin is still up after running the command, so it's not really a matter of power being shut down on the bus.
I'm kind of running out of idea on what to test next. The differences between u-boot's musb-new and Linux' own musb driver seems thin and to make sense, so I don't think the driver itself is to blame.
Anyone experienced such a thing?
what is the log you get when you run "usb start" and the USB device is not plugged ?
I get: U-Boot# usb start (Re)start USB... USB0: lowlevel init failed USB error: all controllers failed lowlevel init
Which seems like something worth looking at. Also, when I do it a second time, then it hangs, and finally reboots the board.
I don't really know what's going on, but we'll look into this.
Thanks for the helpful comments. I personally don't have much experience with the mUSB, so I'm glad that others do help here.
Thanks!
Hi Maxime,
On Thu, 20 Nov 2014 17:49:17 +0100 Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi,
I'm currently working on 2014.07, on a custom TI AM335x based board.
Everything works great so far, except when we're trying to have USB host working.
The board has the MUSB1 controller wired as USB Host only, with the following configuration:
#define CONFIG_USB_MUSB_DSPS #define CONFIG_ARCH_MISC_INIT #define CONFIG_MUSB_PIO_ONLY #define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_MUSB_HOST #define CONFIG_MUSB_DSPS #define CONFIG_AM335X_USB1 #define CONFIG_AM335X_USB1_MODE MUSB_HOST
#ifdef CONFIG_MUSB_HOST #define CONFIG_CMD_USB #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_ASIX #endif
I'm not familiar with AM335x, so I can't say if this configuration is okay.
Whenever we try to scan the USB controller and that a device is attached, we get the following output:
U-Boot# usb start (Re)start USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found
The device itself being a USB key, it's somewhat odd that it enumerates the device, but doesn't find the storage device...
The device found is the controller's root hub device, not the USB storage device. "usb info" should show more about it.
The same USB port with the same device works fine under Linux.
The VBUS pin is still up after running the command, so it's not really a matter of power being shut down on the bus.
I'm kind of running out of idea on what to test next. The differences between u-boot's musb-new and Linux' own musb driver seems thin and to make sense, so I don't think the driver itself is to blame.
Anyone experienced such a thing?
We experienced similar thing this week, but on an imx6dl based board. Quite a lot of debugging and comparison with USB host operation under Linux didn't really help much. Finally we found the issue with the timer implementation, udelay(1) took too much time, about 35 usec. Whereas one would expect it to take about 1 usec, ideally. EHCI-HCD, USB-Hub and Storage drivers in U-Boot use udelay()/mdelay() quite extensively. Reworking the timer implementation for our platform resulted in udelay(1) times taking about 2.5 usec. This was enough for USB driver code to work again.
HTH,
Anatolij
Hello Anatolij,
On Sat, 22 Nov 2014 00:40:58 +0100, Anatolij Gustschin agust@denx.de wrote:
Hi Maxime,
On Thu, 20 Nov 2014 17:49:17 +0100 Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi,
I'm currently working on 2014.07, on a custom TI AM335x based board.
Everything works great so far, except when we're trying to have USB host working.
The board has the MUSB1 controller wired as USB Host only, with the following configuration:
#define CONFIG_USB_MUSB_DSPS #define CONFIG_ARCH_MISC_INIT #define CONFIG_MUSB_PIO_ONLY #define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_MUSB_HOST #define CONFIG_MUSB_DSPS #define CONFIG_AM335X_USB1 #define CONFIG_AM335X_USB1_MODE MUSB_HOST
#ifdef CONFIG_MUSB_HOST #define CONFIG_CMD_USB #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_ASIX #endif
I'm not familiar with AM335x, so I can't say if this configuration is okay.
Whenever we try to scan the USB controller and that a device is attached, we get the following output:
U-Boot# usb start (Re)start USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found
The device itself being a USB key, it's somewhat odd that it enumerates the device, but doesn't find the storage device...
The device found is the controller's root hub device, not the USB storage device. "usb info" should show more about it.
The same USB port with the same device works fine under Linux.
The VBUS pin is still up after running the command, so it's not really a matter of power being shut down on the bus.
I'm kind of running out of idea on what to test next. The differences between u-boot's musb-new and Linux' own musb driver seems thin and to make sense, so I don't think the driver itself is to blame.
Anyone experienced such a thing?
We experienced similar thing this week, but on an imx6dl based board. Quite a lot of debugging and comparison with USB host operation under Linux didn't really help much. Finally we found the issue with the timer implementation, udelay(1) took too much time, about 35 usec. Whereas one would expect it to take about 1 usec, ideally. EHCI-HCD, USB-Hub and Storage drivers in U-Boot use udelay()/mdelay() quite extensively. Reworking the timer implementation for our platform resulted in udelay(1) times taking about 2.5 usec. This was enough for USB driver code to work again.
I think the USB code might be mis-using udelay(), then. Here's why I do:
- the semantics of udelay(n) are AFAIUI "delay at least n microseconds", but nothing says it won't delay more, especially for small wait times where the setup/cleanup part of udelay() will obviously get a bigger share of the execution time than the actual delaying.
- OTOH, the problems you witness seem to imply that the USB code is expecting udelay(n) to "wait for at least n microseconds but no more than some unspecified limit", since if udelay /does/ take too long, the code fails because its expectation is not met.
Did you find out why a longer delay() causes the USB code to fail? For instance, is udelay() used for synchronizing to an external event, and delaying too much makes the code miss the event?
HTH,
Anatolij
Amicalement,
Hi,
On Sat, Nov 22, 2014 at 12:40:58AM +0100, Anatolij Gustschin wrote:
Hi Maxime,
On Thu, 20 Nov 2014 17:49:17 +0100 Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi,
I'm currently working on 2014.07, on a custom TI AM335x based board.
Everything works great so far, except when we're trying to have USB host working.
The board has the MUSB1 controller wired as USB Host only, with the following configuration:
#define CONFIG_USB_MUSB_DSPS #define CONFIG_ARCH_MISC_INIT #define CONFIG_MUSB_PIO_ONLY #define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_MUSB_HOST #define CONFIG_MUSB_DSPS #define CONFIG_AM335X_USB1 #define CONFIG_AM335X_USB1_MODE MUSB_HOST
#ifdef CONFIG_MUSB_HOST #define CONFIG_CMD_USB #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_ASIX #endif
I'm not familiar with AM335x, so I can't say if this configuration is okay.
Whenever we try to scan the USB controller and that a device is attached, we get the following output:
U-Boot# usb start (Re)start USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found
The device itself being a USB key, it's somewhat odd that it enumerates the device, but doesn't find the storage device...
Yeah, Eric made me think about that too. What's odd is that it actually fails when there's no device plugged in.
The device found is the controller's root hub device, not the USB storage device. "usb info" should show more about it.
Ok, I'll confirm this then.
The same USB port with the same device works fine under Linux.
The VBUS pin is still up after running the command, so it's not really a matter of power being shut down on the bus.
I'm kind of running out of idea on what to test next. The differences between u-boot's musb-new and Linux' own musb driver seems thin and to make sense, so I don't think the driver itself is to blame.
Anyone experienced such a thing?
We experienced similar thing this week, but on an imx6dl based board. Quite a lot of debugging and comparison with USB host operation under Linux didn't really help much. Finally we found the issue with the timer implementation, udelay(1) took too much time, about 35 usec. Whereas one would expect it to take about 1 usec, ideally. EHCI-HCD, USB-Hub and Storage drivers in U-Boot use udelay()/mdelay() quite extensively. Reworking the timer implementation for our platform resulted in udelay(1) times taking about 2.5 usec. This was enough for USB driver code to work again.
Hmmm, that's very interesting :)
I'll test the time our udelay takes, and let you know about what I find there.
Thanks a lot! Maxime
Hi Anatolij,
On Sat, Nov 22, 2014 at 12:40:58AM +0100, Anatolij Gustschin wrote:
The same USB port with the same device works fine under Linux.
The VBUS pin is still up after running the command, so it's not really a matter of power being shut down on the bus.
I'm kind of running out of idea on what to test next. The differences between u-boot's musb-new and Linux' own musb driver seems thin and to make sense, so I don't think the driver itself is to blame.
Anyone experienced such a thing?
We experienced similar thing this week, but on an imx6dl based board. Quite a lot of debugging and comparison with USB host operation under Linux didn't really help much. Finally we found the issue with the timer implementation, udelay(1) took too much time, about 35 usec. Whereas one would expect it to take about 1 usec, ideally. EHCI-HCD, USB-Hub and Storage drivers in U-Boot use udelay()/mdelay() quite extensively. Reworking the timer implementation for our platform resulted in udelay(1) times taking about 2.5 usec. This was enough for USB driver code to work again.
I just gave it a try.
mdelay(1000) and udelay (1000 * 1000) are both taking around 1s (1.0002... for udelay, 1.13... for mdelay).
udelay(1) on the other hand takes around 151us, which seems to be the same overhead we saw for udelay(1000 * 1000).
While that looks really high with regard to what you were saying, but I just tested it with a beaglebone black that have similar delay values, and yet the usb storage works as expected. So I don't think it's really the issue there :/
Maxime
Hi,
On Thu, Nov 20, 2014 at 05:49:17PM +0100, Maxime Ripard wrote:
Hi,
I'm currently working on 2014.07, on a custom TI AM335x based board.
Everything works great so far, except when we're trying to have USB host working.
The board has the MUSB1 controller wired as USB Host only, with the following configuration:
#define CONFIG_USB_MUSB_DSPS #define CONFIG_ARCH_MISC_INIT #define CONFIG_MUSB_PIO_ONLY #define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_MUSB_HOST #define CONFIG_MUSB_DSPS #define CONFIG_AM335X_USB1 #define CONFIG_AM335X_USB1_MODE MUSB_HOST
#ifdef CONFIG_MUSB_HOST #define CONFIG_CMD_USB #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_ASIX #endif
Whenever we try to scan the USB controller and that a device is attached, we get the following output:
U-Boot# usb start (Re)start USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found
Just an update on this one.
Our configuration was missing CONFIG_USB_GADGET_DUALSPEED that, even though its name suggest otherwise, seems to be needed to enable USB2.0 devices support in the musb-new driver.
With this additional configuration option, everything works as expected.
Thanks! Maxime
On Wednesday, December 10, 2014 at 04:23:49 PM, Maxime Ripard wrote:
Hi,
On Thu, Nov 20, 2014 at 05:49:17PM +0100, Maxime Ripard wrote:
Hi,
I'm currently working on 2014.07, on a custom TI AM335x based board.
Everything works great so far, except when we're trying to have USB host working.
The board has the MUSB1 controller wired as USB Host only, with the following configuration:
#define CONFIG_USB_MUSB_DSPS #define CONFIG_ARCH_MISC_INIT #define CONFIG_MUSB_PIO_ONLY #define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_MUSB_HOST #define CONFIG_MUSB_DSPS #define CONFIG_AM335X_USB1 #define CONFIG_AM335X_USB1_MODE MUSB_HOST
#ifdef CONFIG_MUSB_HOST #define CONFIG_CMD_USB #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_ASIX #endif
Whenever we try to scan the USB controller and that a device is attached, we get the following output:
U-Boot# usb start (Re)start USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) foundJust an update on this one.
Our configuration was missing CONFIG_USB_GADGET_DUALSPEED that, even though its name suggest otherwise, seems to be needed to enable USB2.0 devices support in the musb-new driver.
With this additional configuration option, everything works as expected.
Wow, this is excellent news, good job finding this!
On the other hand, this behavior is very braindead and should be fixed before someone else gets burnt. Do you have any ideas for a patch please ?
Best regards, Marek Vasut
Hi,
On Thu, Dec 11, 2014 at 02:09:30PM +0100, Marek Vasut wrote:
On Wednesday, December 10, 2014 at 04:23:49 PM, Maxime Ripard wrote:
Hi,
On Thu, Nov 20, 2014 at 05:49:17PM +0100, Maxime Ripard wrote:
Hi,
I'm currently working on 2014.07, on a custom TI AM335x based board.
Everything works great so far, except when we're trying to have USB host working.
The board has the MUSB1 controller wired as USB Host only, with the following configuration:
#define CONFIG_USB_MUSB_DSPS #define CONFIG_ARCH_MISC_INIT #define CONFIG_MUSB_PIO_ONLY #define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_MUSB_HOST #define CONFIG_MUSB_DSPS #define CONFIG_AM335X_USB1 #define CONFIG_AM335X_USB1_MODE MUSB_HOST
#ifdef CONFIG_MUSB_HOST #define CONFIG_CMD_USB #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_ASIX #endif
Whenever we try to scan the USB controller and that a device is attached, we get the following output:
U-Boot# usb start (Re)start USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) foundJust an update on this one.
Our configuration was missing CONFIG_USB_GADGET_DUALSPEED that, even though its name suggest otherwise, seems to be needed to enable USB2.0 devices support in the musb-new driver.
With this additional configuration option, everything works as expected.
Wow, this is excellent news, good job finding this!
On the other hand, this behavior is very braindead and should be fixed before someone else gets burnt.
I agree :)
Do you have any ideas for a patch please ?
It's really used by two drivers: musb-new and gadget/ether.c
The ethernet driver seems to be doing the right thing: this option controls wether the gadget should use high or full speed.
musb-new on the other hand seems to be using it to set up the actual controller speed, disregarding wether it's running in host or device mode.
So I guess we could split these two apart, and introduce an option called CONFIG_MUSB_DUALSPEED?
The tricky thing will be to convert the configurations using this option, since you can't really know with a grep / sed what they are using it for: ethernet, musb, both?
Maxime
On Thursday, December 11, 2014 at 04:44:33 PM, Maxime Ripard wrote:
Hi,
On Thu, Dec 11, 2014 at 02:09:30PM +0100, Marek Vasut wrote:
On Wednesday, December 10, 2014 at 04:23:49 PM, Maxime Ripard wrote:
Hi,
On Thu, Nov 20, 2014 at 05:49:17PM +0100, Maxime Ripard wrote:
Hi,
I'm currently working on 2014.07, on a custom TI AM335x based board.
Everything works great so far, except when we're trying to have USB host working.
The board has the MUSB1 controller wired as USB Host only, with the following configuration:
#define CONFIG_USB_MUSB_DSPS #define CONFIG_ARCH_MISC_INIT #define CONFIG_MUSB_PIO_ONLY #define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_MUSB_HOST #define CONFIG_MUSB_DSPS #define CONFIG_AM335X_USB1 #define CONFIG_AM335X_USB1_MODE MUSB_HOST
#ifdef CONFIG_MUSB_HOST #define CONFIG_CMD_USB #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_ASIX #endif
Whenever we try to scan the USB controller and that a device is attached, we get the following output:
U-Boot# usb start (Re)start USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) foundJust an update on this one.
Our configuration was missing CONFIG_USB_GADGET_DUALSPEED that, even though its name suggest otherwise, seems to be needed to enable USB2.0 devices support in the musb-new driver.
With this additional configuration option, everything works as expected.
Wow, this is excellent news, good job finding this!
On the other hand, this behavior is very braindead and should be fixed before someone else gets burnt.
I agree :)
Do you have any ideas for a patch please ?
It's really used by two drivers: musb-new and gadget/ether.c
The ethernet driver seems to be doing the right thing: this option controls wether the gadget should use high or full speed.
musb-new on the other hand seems to be using it to set up the actual controller speed, disregarding wether it's running in host or device mode.
So I guess we could split these two apart, and introduce an option called CONFIG_MUSB_DUALSPEED?
I'd rather see CONFIG_MUSB_FORCE_SPEED or somesuch.
The tricky thing will be to convert the configurations using this option, since you can't really know with a grep / sed what they are using it for: ethernet, musb, both?
I hope Heiko can chime in, I believe it's only the siemens board which needs to force the musb into full-speed operation ; the other boards should be fine with dualspeed.
participants (5)
-
Albert ARIBAUD -
Anatolij Gustschin -
Eric Bénard -
Marek Vasut -
Maxime Ripard