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:
~/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, 1100
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 fo
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 Li
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, 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 va
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
> > r
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 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
> > > > --
> > > >
> > > >
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'
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 comple
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
> >
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
> >
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
> i
14 matches
Mail list logo
