On Tue, Apr 26, 2005 at 11:39:39AM +0200, Pavel Machek wrote:
> 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.
> 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.
Dave
-------------------------------------------------------
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
