Re: cpufreq problem wrt suspend/resume on Athlon64

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Thursday, 3 of February 2005 13:40, Dominik Brodowski wrote:
[-- snip --]
> > So, would it be acceptable to check in _suspend() if the state is S4
> > and drop the frequency in that case or do nothing otherwise?
> 
> No. The point is that this is _very_ system-specific. Some systems resume
> always at full speed, some always at low speed; for S4 the behaviour may be
> completely unpredictable. And in fact I wouldn't want my desktop P4 drop th
> 12.5 % frequency if I ask it to suspend to disk, too. "Ignoring" the warning
> seems to be the best thing to me. The good thing is, after all, that cpufreq
> detected this situation and tries to correct for it.

Well, the warning is not a big problem, as far as I'm concerned.  The problem is
that the box often reboots when it's woken up on batteries and this certainly
is related to cpufreq (ie it does not happen if cpufreq is not compiled in).

Pavel has suggested that it may happen when the frequency of
the CPU is too high on resume, so I'm trying to verify if this is the case.  If so,
which I'm not entirely convinced about yet, I'll be going to provide a fix
for it, but I wouldn't like to do anything that's not acceptable from the
start.

I'm currently thinking that the proper approach may be to add a ->suspend()
routine to struct cpufreq_driver and call the driver-specific ->suspend()
(if one is defined) from cpufreq_suspend().  Then, it'll be possible to do
whatever-is-necessary on a per-driver basis.  Just a thought. :-)

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"