Hi!
> > Well, you can do "half suspend to ram; change your frequency; half
> > resume" today, and it should work, but I do not think you'll like the
> > speed.
>
> Indeed. With people running things like cpuspeed daemons to dynamically
> scale speed, this is going to be really painful.
> Of course, any operation where we have to quiesce DMA is going to mean
> we're increasing latency around the scaling operation, but we don't
> have to go through all the hoops that are necessary when suspending.
> Thankfully some of the more recent implementations of speed/voltage
> scaling don't have this requirement.
Good, because some devices really need DMA. (Won't audio skip, and USB
break when you disable DMA? I do not see how cpufreq doing DMA disable
can be usefull.)
> > In a ideal world, calling device_suspend(PMSG_FREEZE) gets you exactly
> > that, and we'll do our best to make it fast enough.
> >
> > OTOH it *needs* to switch consoles to text one (because X may be
> > running DMA, right?); I do not think you'll like that one.
>
> That would be insane, and make cpufreq totally useless for anyone
> running X, so no. This is one of the reasons the kernel needs to
> arbitrate DMA on behalf of X. It just needs someone to do the work.
Yes... But it also looks like a lot of work :-(.
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
