From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 1/1] tegra: usb: Fix device enumeration problem of USB1
Date: Tue, 19 Jun 2012 23:16:52 +0200 [thread overview]
Message-ID: <201206192316.52907.marek.vasut@gmail.com> (raw)
In-Reply-To: <4FE0B327.3060502@wwwdotorg.org>
Dear Stephen Warren,
> On 06/19/2012 02:47 AM, Jim Lin wrote:
> > A known hardware issue of USB1 port where bit 1 (connect status
> > change) of PORTSC register will be set after issuing Port Reset
> > (like "usb reset" in u-boot command line).
> > This will be treated as an error and stops later device enumeration.
> >
> > Therefore we add a definition in header file and a callback function
> > to clear that bit after Port Reset in order to proceed later device
> > enumeration.
> >
> > CONFIG_USB_EHCI_SUBMIT_ROOT_POST_CALLBACK
We did such fix in the past by adding weak function. Check ehci-hcd.c
>
> This style of fix (adding an optional callback from the USB core) seems
> like the idea to me. Thanks.
>
> However, I'm a little worried that it implements the bug workaround at a
> different time to the Linux kernel. The kernel does:
>
> * Assert reset to the port
> * Poll the port for enable (any time delays are here)
> * Clear the CSC bit
>
> So, the CSC bit is cleared a long time after the port is reset.
>
> However, this U-Boot patch does:
>
> * Assert reset to the port
> * Clear the CSC bit
> * Wait a long time; 200mS
> * Check the port is enabled
>
> So, the CSC bit is cleared immediately after the port is reset.
>
> Is this U-Boot fix still guaranteed to solve the problem? In your
> testing, how many times did you test without this fix, and what was the
> failure percentage. How many times did you test with the fix, and what
> was the failure percentage?
>
> I think it'd be safer to execute the callback from inside
> hub_port_reset() right before the call to usb_get_port_status(). That
> would make the time when CSC gets cleared much more equivalent between
> the Linux kernel and U-Boot. The implementation of the callback function
> could probably be a lot simpler to (e.g. doesn't need to check which
> feature is being set etc.)
Best regards,
Marek Vasut
prev parent reply other threads:[~2012-06-19 21:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-19 8:47 [U-Boot] [PATCH v2 1/1] tegra: usb: Fix device enumeration problem of USB1 Jim Lin
2012-06-19 17:13 ` Stephen Warren
2012-06-19 21:16 ` Marek Vasut [this message]
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=201206192316.52907.marek.vasut@gmail.com \
--to=marek.vasut@gmail.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.