From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] USB Host not enumerating properly on AM335x-based board
Date: Mon, 8 Dec 2014 14:59:14 +0100 [thread overview]
Message-ID: <20141208135914.GA8739@lukather> (raw)
In-Reply-To: <20141122004058.093765b1@crub>
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141208/87ed240e/attachment.pgp>
next prev parent reply other threads:[~2014-12-08 13:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-20 16:49 [U-Boot] USB Host not enumerating properly on AM335x-based board Maxime Ripard
2014-11-21 10:20 ` Eric Bénard
2014-11-21 14:57 ` Maxime Ripard
2014-11-21 19:35 ` Marek Vasut
2014-11-21 23:40 ` Anatolij Gustschin
2014-11-23 11:56 ` Albert ARIBAUD
2014-11-24 22:23 ` Maxime Ripard
2014-12-08 13:59 ` Maxime Ripard [this message]
2014-12-10 15:23 ` Maxime Ripard
2014-12-11 13:09 ` Marek Vasut
2014-12-11 15:44 ` Maxime Ripard
2014-12-14 19:18 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141208135914.GA8739@lukather \
--to=maxime.ripard@free-electrons.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.