On Thursday, 3 of February 2005 15:22, Pavel Machek wrote:
> Hi!
>
> > > > 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.
>
> Well, try to force your machine to 2GHz while it is on battery. If it
> crashes, you have verified it is indeed the problem. [Insert standard
> disclaimer about exploding batteries here.]
Instead of trying to blow up the battery I used the patch that forces the CPU
to 800 MHz and it apparently survives resuming on batteries - at least 3
times out of 3 attempts (I'll try some times more tomorrow).
It seems to boot at 1800 MHz, though, every time, according to
cpufreq_resume().
> > 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. :-)
>
> Yes, that seems like right solution.
Then I'll try to do something along this line.
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"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
