David Brownell wrote: > On Tuesday 20 February 2007 12:27 pm, [EMAIL PROTECTED] wrote: >> >> This patch turns off periodic list processing in the EHCI controller >> for the duration of processor frequency changes. > > Did you test this with any kind of isochronous device active, like a > set of USB speakers playing? ISO transfers work differently than the > interrupt transfers you tested (with a HID device). > > Also ... what kind of hardware did you test this with? I wonder how > much of the (potential) 1.125 msec it was spinning while waiting for > the periodic schedule to actually turn off. That seems like it > should be modifying the latency metrics used by cpufreq... is there > even a feedback mechanism whereby the system can say that _right now_ > it would take this much more time? Last time I remember looking at > cpufreq, it had static metrics basically relating only to the CPUs; > so costs related to components like EHCI were hidden. (Much less > costs associated with re-clocking other peripherals, which is a big > issue with embedded SOC chips!) >
No--I'll try that (with & without the patch). I also only tried this on a Serverworks EHCI controller with AMD processors... I'll test an Intel system, too, and see if I see the MMF errors on it without this patch. > > The patch looks mostly OK, but the issue with isochronous transfers > is a difference in how transfer completion is handled in the > hardware. > > Rather than scanning a queue head node in the schedule tree, which > will be re-scanned after the periodic list is re-activated. Instead, > isochronous transfers use an entirely different hardware mechanism. > Their ITDs go before that schedule tree, and won't get re-scanned > after the relevant frame passes. > > I'd not be sure that the current iso scanning logic would behave > correctly with this kind of on/off mechanism. In fact I'd kind of > expect it to break. > > That's in addition to the issue that it might not be a Good Thing to > let cpufreq create audio (or video etc) dropouts ... > > Maybe the best solution to this issue would be to reject the cpufreq > change if ISO transfers are active on EHCI. > > - Dave You might get audio/video dropouts during cpu frequency changes without or with this patch. But... if cpufreq changes are rejected when ISO transfers are active, wouldn't that have the potential to lock the processors into a low-frquency state, if an isochronous device starts up while the CPUs are otherwise idle? How would the user know that his performance is crap because of his isochronous device(s)? ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
