lkml.org 
[lkml]   [2003]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Test Patch: 2.5.69 Interrupt Latency
From
Date
On Wed, 2003-05-14 at 15:52, Alan Stern wrote:
> Below is a patch that addresses both of the issues raised in this thread.
> The delay time is moved out of the interrupt handler, and the
> wakeup/suspend transitions are de-bounced. To do this, I needed to add a
> mildly elaborate state mechanism. State transitions are polled during the
> stall-timer callback.
>
> There is no protection against simultaneous access from multiple threads,
> such as a PCI suspend occurring at the same time as a normal suspend or
> resume. The original driver didn't have any either; it's probably not
> worth worrying too much about. The patch works okay on my system. Try it
> and see how it works on yours.
>
> Johannes, please look over this code and verify that I haven't screwed
> anything up.
>
> Alan Stern

I tested the patch, and it solves the IRQ latency problems by moving
the delay outside of the ISR. The debouncing period reduces the
rate of thrashing back and forth between wake and suspend, but
the cycle does continue forever:

May 15 08:27:27 diemos kernel: suspend_hc():UHCI_RUNNING_GRACE
May 15 08:27:27 diemos kernel: suspend_hc():UHCI_RUNNING
May 15 08:27:28 diemos kernel: suspend_hc():UHCI_SUSPENDING_GRACE
May 15 08:27:28 diemos kernel: wakeup_hc():UHCI_SUSPENDED
May 15 08:27:28 diemos kernel: wakeup_hc():UHCI_RESUMING_1
May 15 08:27:28 diemos kernel: suspend_hc():UHCI_RESUMING_2
May 15 08:27:29 diemos kernel: suspend_hc():UHCI_RUNNING_GRACE
May 15 08:27:29 diemos kernel: suspend_hc():UHCI_RUNNING
May 15 08:27:30 diemos kernel: suspend_hc():UHCI_SUSPENDING_GRACE
May 15 08:27:30 diemos kernel: wakeup_hc():UHCI_SUSPENDED
May 15 08:27:30 diemos kernel: wakeup_hc():UHCI_RESUMING_1
May 15 08:27:30 diemos kernel: suspend_hc():UHCI_RESUMING_2
May 15 08:27:31 diemos kernel: suspend_hc():UHCI_RUNNING_GRACE

This patch removes my complaint, but I do wonder why this
unused controller continually generates the USBSTS_RD
indications. I would hope HP used pull-ups/downs on unused
input signals of the PIIX3 chipset, but maybe not.

I also can't vouch for the correct operation of this patch
for fully functional USB implementations.

If you have other tests you want me to do to try and figure
out a sane way of dealing with such unused controllers,
just ask.

Thanks,
Paul

--
Paul Fulghum, paulkf@microgate.com
Microgate Corporation, http://www.microgate.com


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:35    [W:2.144 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site