[PATCH 3/3] fix-stop-sitting-printing-in-time-critical-context.patch
laforge at openmoko.org
Wed Aug 27 14:59:18 CEST 2008
On Wed, Aug 27, 2008 at 09:03:08AM -0300, Cesar Eduardo Barros wrote:
> Andy Green escreveu:
>> No, one doesn't expect the hardware USB unit to go insane until the
>> device is reset because we were a little delayed servicing its
>> interrupt! I guess the same can happen in Linux if there was ever long
>> service time ISR with higher priority that pushed out this one's latency.
> Wait... THAT would explain why the USB gets stuck on cpufreq if it is in
> use during a frequency transition, but only if it is in use. The cpufreq
> frequency switch pauses the clock for the whole device for many clocks,
> while waiting for the PLL to recover. That's more than enough to cause a
> very high interrupt latency.
maybe, but the routines in question are only used during control point
transfers, specifically device enumeration. Endpoint 0 works completely
different from the actual bulk/irq endpoints used during transfers.
- Harald Welte <laforge at openmoko.org> http://openmoko.org/
Software for the world's first truly open Free Software mobile phone
More information about the openmoko-kernel