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 -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot