[PATCH 3/3] fix-stop-sitting-printing-in-time-critical-context.patch

[Harald Welte]

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