iMac G5: experimental thermal & cpufreq support
Benjamin Herrenschmidt
I now have some experimental thermal control and cpufreq support for
iMac G5. I have not _yet_ implemented support for the SMU based single
CPU desktops (PowerMac9,1), those will have to wait a little bit more
(not too much hopefully, but I need potential testers to contact me as I
lack hardware access). At this point, it should work on PowerMac8,1
(iMacG5 rev A) and PowerMac8,2 (iMacG5 rev B).
WARNING: This is really a 'first shot'. There is no overtemp detection,
so be careful. The driver doesn't yet have a sysfs interface for you to
read the temperature, but I left it with verbose debugging enabled in
the kernel log so you can see what's going on with the 2 control loops
(the System one which ticks every 5 seconds and the CPU one which ticks
every second). Please tell me if it appears to behave properly. On my
iMac G5 rev A, the target temperature for the CPU is set by the firmware
at 78 degree C with a max at about 83 degree. If I put load on the CPU,
the CPU appears to properly ramp up slowly to 82 then go down and
stabilize at 78 while the driver slowly ramps the fans up.
The algorithm itself is extracted from darwin. However, it's a rather
complex modified version of the PID algorithm, and thus it could use
some review to make sure I got everything right.
The thermal control is also part of a new infrastructure I have written
called "windfarm" that splits the whole thing into several modules
(though I have only tested with everything built in at this point).
Ultimately, it should be possible to port the existing Desktop G5 and
Xserver thermal driver to the new infrastructure provided that the
appropriate sensor & control modules are written. The old thermal driver
uses pretty much the same 2 kind of PID control loops as provided by the
windfarm_pid helper.
I would encourage people doing thermal control on other machines
(laptops, etc...) to also use the new infrastructure.
Ok, now the patches. You need to appy them in proper order. First of
all, it all is on top of current -git as of yesterday. I won't guarantee
they will apply on anything more ancient.
First, you need a fix that is currently pending in -mm (and should be in
2.6.14 before it's final) :
http://gate.crashing.org/~benh/ppc64-smu-fix.diff
Then, you can apply the patch that adds cpufreq support for the iMac G5
(and possibly the SMU based desktop, though not tested)
http://gate.crashing.org/~benh/ppc64-fx-freq-scaling.diff
Then apply those 2 patches in that order:
http://gate.crashing.org/~benh/ppc64-smu-partitions.diff
http://gate.crashing.org/~benh/ppc64-smu-thermal-control.diff
That's it. Now enable:
CONFIG_WINDFARM_SMU
and
CONFIG_I2C_PMAC_SMU
If you are using modules, you may have to manually load the whole bunch,
especially the i2c SMU one which isn't requested (yet).
And let me know :)
Regards,
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Benjamin Herrenschmidt
> http://gate.crashing.org/~benh/ppc64-smu-thermal-control.diff
You may want to re-download this one if you got it already, I just fixed
a bug in the calculations of the CPU control loop. It's now getting
results much more consistant with OS X. I still have to add some
overtemp handling and I'll remove the debug stuff and work on supporting
the PowerMac9,1 desktop model.
Geoff Levand
> The algorithm itself is extracted from darwin. However, it's a rather
> complex modified version of the PID algorithm, and thus it could use
> some review to make sure I got everything right.
>
As we are already in the digital domain, I would think it would be
more savvy to use a digital controller than try to simulate an
analog controller... Why don't you abstract the control algorithm
such that you can plug in others as they are developed.
-Geoff
--
To UNSUBSCRIBE, email to debian-powe...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Benjamin Herrenschmidt
> Benjamin Herrenschmidt wrote:
> > The algorithm itself is extracted from darwin. However, it's a rather
> > complex modified version of the PID algorithm, and thus it could use
> > some review to make sure I got everything right.
> >
>
> As we are already in the digital domain, I would think it would be
> more savvy to use a digital controller than try to simulate an
> analog controller... Why don't you abstract the control algorithm
> such that you can plug in others as they are developed.
Because I don't know much about those control algorithms, and all the
calibration data provided by the firmware is in the form of factors for
these algorithms, I wouldn't know how to "unmangle" them to use with
different ones.
Actually, the control algorithms (PID and modified PID) are in a
"helper", so it's fairly easy for the platform module to use whatever it
wants, feel free to submit other algorithms :) But for Apple machines,
I'd rather use what I have calibration data for, unless you can produce
something that works without any...
Ben.
Dean Hamstead
right track. its better to have something in place than nothing.
not putting down the feedback, but im not sure just how much fiddling
people will really want, and its not a huge audience. which
brings me back to the point of just getting something in place and
then people can change it as IMO linux kernel code is more likely to be
fiddled with (and better 'documentation' - whatever that is) than darwin
code.
go ben, keep working hard. and keep chasing the mpeg decoder in the ati
cards of apple ibook and friends!
Dean
Benjamin Herrenschmidt
> On Thu, 2005-09-29 at 17:20 +1000, Benjamin Herrenschmidt wrote:
>
> > http://gate.crashing.org/~benh/ppc64-smu-thermal-control.diff
>
> You may want to re-download this one if you got it already, I just fixed
> a bug in the calculations of the CPU control loop. It's now getting
> results much more consistant with OS X. I still have to add some
> overtemp handling and I'll remove the debug stuff and work on supporting
> the PowerMac9,1 desktop model.
Ok, I've updated it. News are:
- It now requires cpufreq support (it won't start if the cpufreq clamp
sensor isn't loaded). I also changed the Kconfig stuff a bit, you'll
need to enable 2 options now
- It has some totally untested support for PowerMac9,1
- It has overtemp support (will slow CPU down and blow fans full speed
if the machine goes overtemp)
- It has some basic sysfs interface to read values
in /sys/devices/platform/windfarm.0
- DEBUG is disabled by default
Enjoy !