Messages in this thread |  | | Subject | Re: Test Patch: 2.5.69 Interrupt Latency | From | Paul Fulghum <> | Date | 15 May 2003 14:17:38 -0500 |
| |
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
- 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/
|  |