~/linux-3.9.11$ grep -r TRSMRCY
drivers/usb/core/hub.c:/* TRSMRCY = 20 msec */
drivers/usb/core/hub.c:/* TRSMRCY = 10 msec */
drivers/usb/core/hcd.c: * unsuspended. If they are then a TRSMRCY
delay is needed
drivers/usb/core/hcd.c:usleep_range(1,
On Wed, 28 Aug 2013, Dmitri Zolotov wrote:
~/linux-3.9.11$ grep -r TRSMRCY
drivers/usb/core/hub.c:/* TRSMRCY = 20 msec */
Where did that come from? In the 3.9.11 kernel this says 10, not 20.
drivers/usb/core/hub.c:/* TRSMRCY = 10 msec */
drivers/usb/core/hcd.c: *
On Thu, Aug 22, 2013 at 02:55:07PM -0700, Greg KH wrote:
On Thu, Aug 22, 2013 at 02:49:07PM -0700, Sarah Sharp wrote:
On Thu, Aug 22, 2013 at 10:42:49AM -0400, Alan Stern wrote:
On Wed, 21 Aug 2013, Sarah Sharp wrote:
Possible fixes
--
The USB core obviously
On Mon, 26 Aug 2013, Sarah Sharp wrote:
One last thought on this note: We know Windows doesn't have high-res
timers, and Arjan says asking for a 10 ms delay will produce a delay
around 17 ms. Since Linux is busy waiting, we may be communicating with
the device sooner than Windows does.
On Fri, Aug 23, 2013 at 10:43:19AM -0400, Alan Stern wrote:
On Wed, 21 Aug 2013, Sarah Sharp wrote:
Background
--
The USB 2.0 specification, section 7.1.7.7, says that upon device remote
wakeup signaling, the first active hub (which is often the roothub) must
rebroadcast
On Mon, 26 Aug 2013, Sarah Sharp wrote:
By the way, I just noticed your Google+ posting about this. I think
you (and perhaps the engineers you spoke with) may have misunderstood
what Table 7-14 means when it lists 10 ms as the _minimum_ value for
TRSMRCY.
This delay value is a
On Mon, Aug 26, 2013 at 10:45:30AM -0700, Sarah Sharp wrote:
On Thu, Aug 22, 2013 at 02:55:07PM -0700, Greg KH wrote:
On Thu, Aug 22, 2013 at 02:49:07PM -0700, Sarah Sharp wrote:
On Thu, Aug 22, 2013 at 10:42:49AM -0400, Alan Stern wrote:
On Wed, 21 Aug 2013, Sarah Sharp wrote:
On Mon, Aug 26, 2013 at 03:07:25PM -0700, Greg KH wrote:
On Mon, Aug 26, 2013 at 10:45:30AM -0700, Sarah Sharp wrote:
One last thought on this note: We know Windows doesn't have high-res
timers, and Arjan says asking for a 10 ms delay will produce a delay
around 17 ms. Since Linux is
On Mon, 26 Aug 2013, Sarah Sharp wrote:
I double checked with the Intel Windows devs, and they say that Arjan is
mistaken, and they'll get around 11 ms, just like we do.
They say:
The EHCI driver stack applies the 10 ms starting at the point that it
sees C_PORT_SUSPEND asserted for the
On Wed, 21 Aug 2013, Sarah Sharp wrote:
Background
--
The USB 2.0 specification, section 7.1.7.7, says that upon device remote
wakeup signaling, the first active hub (which is often the roothub) must
rebroadcast the resume signaling for at least 20 ms (TDRSMDN). After
that's
On Wed, 21 Aug 2013, Sarah Sharp wrote:
Possible fixes
--
The USB core obviously needs to be changed to check the port status
after the TRSMRCY timeout, and continue to wait if the port is still in
the resuming state. I will have to study the EHCI port status diagrams
in
On Thu, Aug 22, 2013 at 10:42:49AM -0400, Alan Stern wrote:
On Wed, 21 Aug 2013, Sarah Sharp wrote:
Possible fixes
--
The USB core obviously needs to be changed to check the port status
after the TRSMRCY timeout, and continue to wait if the port is still in
the resuming
On Thu, Aug 22, 2013 at 02:49:07PM -0700, Sarah Sharp wrote:
On Thu, Aug 22, 2013 at 10:42:49AM -0400, Alan Stern wrote:
On Wed, 21 Aug 2013, Sarah Sharp wrote:
Possible fixes
--
The USB core obviously needs to be changed to check the port status
after the TRSMRCY
On Thu, 22 Aug 2013, Sarah Sharp wrote:
As far as EHCI is concerned, this is a non-problem. The closest
analogy to the RExit-U0 transition is in the description of the Force
Port Resume bit (bit 6) in Table 2-16 of the EHCI spec, where it says
that the host controller must complete the
The TLDR; version:
We've assumed that when a device disconnects after a resume from device
suspend, it was just a cheap, buggy device. It turns out that the USB
core simply wasn't waiting long enough for the devices to transition
from resume to U0, and it's actually been the USB core's fault all
15 matches
Mail list logo
