Re: Test Patch: 2.5.69 Interrupt Latency

Paul Fulghum (paulkf@microgate.com)
16 May 2003 14:05:59 -0500


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/