lkml.org 
[lkml]   [2003]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Test Patch: 2.5.69 Interrupt Latency
From
Date
On Fri, 2003-05-16 at 13:40, Alan Stern wrote:

> I disagree with 1. When one port has an attached device there won't be
> any problem because suspends will never occur (since one port is active).
> ...
> > For the case of all ports hardwired OC, this
> > will work because you suspend the whole controller
> > and never get a valid resume.
>
> Not suspending isn't really a big deal. After all, we would suspend only
> when no devices are plugged in anyway. Is the PIIX4 chipset used in
> laptops, where the power saving might be important? That's the only
> reason I can think of for wanting to suspend whenever possible.

OK, my bad. I thought global suspend could occur
with devices plugged in, if not that makes #1 a non issue.

The PIIX4E (same ID, same bug) is used in some laptops.
I would assume the 99% of laptop users without the OC
condition would like to save power.

I don't want to get in the way of the vast majority
of users for these rare special cases.

Since the thrashing is not a problem (no global suspend
when a device is plugged in), the only downside of
your original qualify wakeup plan is the possibility of
missing a valid resume once a transient OC condition is cleared.

Maybe just polling individual ports for OC cleared and
RD set to do a global wakeup?

You convinced me that the qualified wakeup is the
way to go.

--
Paul Fulghum
paulkf@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:0.105 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site