Re: Test Patch: 2.5.69 Interrupt Latency

[Alan Stern]

On 16 May 2003, Paul Fulghum wrote:

> Agreed, when the controller sets the FGR bit, it
> starts sending the resume signal to all ports,
> waking attached devices, which will send back
> valid resume signals to the host controller, which
> will complete the wakeup. Which takes us back
> to the thrashing problem.
> 
> For the case where ports are not hardwired to OC,
> we should account for the possibility that the
> OC condition may clear (bad cable replaced, etc).
> 
> So if we allow suspend, and then ignore resumes
> on an OC (temporary condition) port, then that port will not
> be able to cause a valid resume when the OC
> condition is cleared. (per port RD is already set)
> 
> So always allowing suspend, and selectively doing the
> wakeup will cause:
> 1. thrashing for case of one port OC,
> other port OK with attached device.
> 2. prevent port with OC from doing resume
> after clearing OC condition.

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).

But I agree with 2.  So yes, it's probably safer to do a conditional 
suspend rather than a conditional resume.

> 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.

Alan Stern