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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox