From: Alan Stern <stern@rowland.harvard.edu>
To: Paul Fulghum <paulkf@microgate.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
<johannes@erdfelt.com>,
USB development list <linux-usb-devel@lists.sourceforge.net>
Subject: Re: Test Patch: 2.5.69 Interrupt Latency
Date: Fri, 16 May 2003 11:33:09 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.44L0.0305161045270.738-100000@ida.rowland.org> (raw)
In-Reply-To: <1053026258.1548.7.camel@doobie>
Paul:
On 15 May 2003, Paul Fulghum wrote:
> I think I misread your message. Is there a per port resume
> indication? (I'm at home and don't have the specs in front
> of me) I was thinking of the global USBSTS_RD bit.
You can probably find this information in your copy of the specs. Bit 6
of the PORTSC register is Resume Detect. When that bit gets set, the host
controller signals a global resume and presumably sets bit 2 of the USBSTS
register.
> If you can qualify the global USBSTS_RD bit with a per
> port resume indication on a non OC port, then it might
> make sense to do this on the wakeup side.
>
> Pro: you could suspend the controller when appropriate
> without interference from the OC ports
>
> Con: you would be generating a lot of spurious interrupts
> as the global USBSTS_RD is set (incorrectly) by the OC ports.
> Even though you would not actually do the wake, you still
> burn cycles servicing the false interrupts.
I'm not sure about that. For ports in a permanent OC state, the RD bit
would get set just once, so a single interrupt would be generated. When
the host clears the Resume Detect bit in the USBSTS register, it shouldn't
get set again (not until a different port signals a resume). Otherwise a
properly working system would generate continuous interrupts during the
global resume sequence.
That's just guesswork on my part; the spec isn't sufficiently precise to
be certain one way or the other. You can find out pretty easily by
testing the driver on your machine. Just don't do anything in the ISR
when USBSTS_RD is set. Come to think of it, I can try the same thing
here.
> So my inclination is still to nab this on the suspend side.
By a nice coincidence, my system has a 8086:7112 controller -- wired up
correctly and perfectly useable. So I can easily test to make sure that
the final proposed change works okay on a good system.
BTW, I'm not entirely pleased with the size of my test patch. It's a bit
lengthy for something intended mainly to move a delay loop outside an ISR.
But I couldn't think of any simpler way to do it, and once the state
transition code is there it's really no harder to add the 1-second "grace"
periods. So of the three ingredients we've got here (20ms delay outside
of ISR, "grace" periods, checking for OC ports), I don't think we could
make the patch much simpler by eliminating any. What do you think?
Alan Stern
next prev parent reply other threads:[~2003-05-16 15:20 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-07 16:12 2.5.69 Interrupt Latency Paul Fulghum
2003-05-07 19:41 ` Paul Fulghum
2003-05-07 22:28 ` Andrew Morton
2003-05-08 0:25 ` Paul Fulghum
2003-05-08 13:56 ` Paul Fulghum
2003-05-08 19:22 ` Andrew Morton
2003-05-08 19:35 ` Paul Fulghum
2003-05-08 23:20 ` Brian Gerst
2003-05-09 18:12 ` Paul Fulghum
2003-05-09 20:30 ` Paul Fulghum
2003-05-09 21:28 ` Andrew Morton
2003-05-12 13:57 ` Paul Fulghum
2003-05-12 14:06 ` Paul Fulghum
2003-05-12 16:24 ` Greg KH
2003-05-12 17:08 ` Paul Fulghum
2003-05-12 17:30 ` Greg KH
2003-05-12 17:49 ` Paul Fulghum
2003-05-12 18:01 ` Greg KH
2003-05-12 18:15 ` Paul Fulghum
2003-05-13 15:26 ` Alan Stern
2003-05-13 15:35 ` Paul Fulghum
2003-05-13 17:30 ` Greg KH
2003-05-13 13:01 ` Paul Fulghum
2003-05-13 18:09 ` Greg KH
2003-05-13 18:11 ` Greg KH
2003-05-13 21:35 ` Alan Stern
2003-05-13 21:48 ` Helge Hafting
2003-05-13 22:09 ` Alan Stern
2003-05-14 21:06 ` Paul Fulghum
2003-05-14 21:15 ` Johannes Erdfelt
2003-05-14 21:30 ` Greg KH
2003-05-14 21:45 ` Paul Fulghum
2003-05-13 20:17 ` Bill Davidsen
2003-05-13 22:39 ` Paul Fulghum
2003-05-14 20:52 ` Test Patch: " Alan Stern
2003-05-15 13:45 ` Paul Fulghum
2003-05-15 14:12 ` Paul Fulghum
2003-05-15 21:07 ` Alan Stern
2003-05-15 15:26 ` Paul Fulghum
2003-05-15 18:11 ` Alan Stern
2003-05-15 18:40 ` Paul Fulghum
2003-05-15 19:42 ` Paul Fulghum
2003-05-15 19:59 ` Paul Fulghum
2003-05-15 21:13 ` Alan Stern
2003-05-15 21:30 ` Paul Fulghum
2003-05-15 19:17 ` Paul Fulghum
2003-05-16 15:33 ` Alan Stern [this message]
2003-05-16 15:58 ` Paul Fulghum
2003-05-16 16:18 ` Paul Fulghum
2003-05-16 17:16 ` Alan Stern
2003-05-16 17:48 ` Paul Fulghum
2003-05-16 18:31 ` Paul Fulghum
2003-05-16 18:40 ` Alan Stern
2003-05-16 19:05 ` Paul Fulghum
2003-05-18 0:57 ` Andrew McGregor
2003-05-16 17:20 ` Alan Stern
2003-05-16 17:51 ` Paul Fulghum
2003-05-19 16:41 ` Alan Stern
2003-05-19 18:20 ` Paul Fulghum
2003-05-19 18:49 ` Alan Stern
2003-05-16 18:10 ` Paul Fulghum
2003-05-14 17:50 ` Paul Fulghum
2003-05-09 21:07 ` Andrew Morton
2003-05-09 21:28 ` Paul Fulghum
2003-05-08 14:47 ` Paul Fulghum
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=Pine.LNX.4.44L0.0305161045270.738-100000@ida.rowland.org \
--to=stern@rowland.harvard.edu \
--cc=johannes@erdfelt.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=paulkf@microgate.com \
/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;
as well as URLs for NNTP newsgroup(s).