Messages in this thread |  | | Subject | Re: Test Patch: 2.5.69 Interrupt Latency | From | Paul Fulghum <> | Date | 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/
|  |