Re: Test Patch: 2.5.69 Interrupt Latency

[Paul Fulghum <paulkf@microgate.com>]

On Thu, 2003-05-15 at 16:30, Paul Fulghum wrote:
> On Thu, 2003-05-15 at 16:13, Alan Stern wrote:
> > My intention was to avoid resuming if the resume-detect bit is set only 
> > on ports in an over-current condition, since that is the case mentioned in 
> > the erratum.  Of course, this isn't as failsafe as your suggestion.  Which 
> > do you think would work better?
> 
> This should be caught on the suspend side so
> that you can still service the ports that do not
> have the over current condition.
> 
> A single port in OC makes resume unreliable,
> so the only thing to do is not suspend.

Alan:

I think I misread your message. Is there a per port resume
indication? (I'm at home and don't have the specs in front
of me) I was thinking of the global USBSTS_RD bit.

If you can qualify the global USBSTS_RD bit with a per
port resume indication on a non OC port, then it might
make sense to do this on the wakeup side.

Pro: you could suspend the controller when appropriate
without interference from the OC ports

Con: you would be generating a lot of spurious interrupts
as the global USBSTS_RD is set (incorrectly) by the OC ports.
Even though you would not actually do the wake, you still
burn cycles servicing the false interrupts.

So my inclination is still to nab this on the suspend side.

Paul Fulghum
paulkf@microgate.com