With an AMD APU, the following factors are of interest.
If your system will only use console output, you will want to use the
radeon driver for it. An active console handled by the
radeon driver will save 8 W as compared to both the fallback driver and
fglrx on an A10-6700 (Richland). If the console is idle,
radeon will save an additional 2 W.
The AMD APU's Turbo Core feature must be enabled one way or the other. Contrary to what some people believe, Turbo Core (which, once enabled, is an autonomous APU feature) works excellently on APU level and has reasonable use cases. But either the
radeon or the
fglrx driver must be present and in both cases, care must be taken.
If you feel that it's worth reducing the idle power consumption of a complete A10-6700 Richland system (including fans, DDR3-1866 RAM and a single SSD) from 40 W to 30 W, or if you want to have full Turbo Core speed for longer (the available Turbo Core frequency is based on total chip power consumption including graphics, as well as temperature) then you should care.
All above statements relate to my former analysis How to set up Linux for full AMD APU power management support: Turbo Core, Cool'n'Quiet, Dynamic Power Management?
Be aware that you cannot necessarily rely on information from
/sys regarding the actual frequencies of your AMD APU's cores. To be on the safe side, use
cpufreq-aperf (or either
cpupower frequency-info or
cpupower monitor) after
Sadly, up to and including Debian Jessie 8.2, you will not get everything out of an AMD APU with a Debian installation out of the box.
Debian Option 1: The
fglrx driver enables Turbo Core, which should not come as a surpirse.
However, while the APUs show a very reasonable and useful Turbo Core behaviour with the free Linux
radeon driver, this is not necessarily the case when you use
fglrx driver appears to manipulate the core affinity of processes. Maybe it even replaces microcode in the APU. But regardless of how
fglrx works on detail level, you'll get this:
On an APU with four cores, if you have two processes requiring full performance, Linux will start them on the two separate APU modules. (E.g. the A10-6700 has two modules with two cores each, and while each core has a small individual L3 cache, both cores on the same module share the a single L2 cache.) This initial setup will give you maximum performance and also high power consumtion. (The A10-6700 power consumption will increase by 70 W in this example.)
fglrx will relocate one of the porcesses to the second core of the other module if the APU gets too hot. (This will reduce A10-6700 power consumption by 25 W as compared to using both APU modules.) It presumably does this to demonstrate a high core frequency for a longer time. However, the migrated process is very likely to effectively stop for a moment due to the L2 cache not having any of the required data at hand, and usually, performance after the migration will be lower due to the shared L2 cache.
fglrx does not take any proactive measures to slightly reduce core frequencies before the APU's limits are reached, it consequently reduces core speeds drastically if the processes run for a longer time. This means that after the burst, you'll have to live with lower frequencies until your APU has cooled down.
Other than for core frequency demonstration, the behaviour of
fglrx is somewhat questionable in my view; I believe you'll get a better overall performance with
radeon. But if you want a 2D/3D system and find this abrupt frequency scaling behaviour acceptable, you can choose
fglrx up to and including Debian 7. You can additionally choose
fglrx for Debian 8 if you don't intend to use the GNOME desktop.
Debian Option 2: The
As mentioned, the
radeon driver offers a much lower console mode power consumption and a much smoother Turbo Core experience. The price you'll have to pay is its worse 3D support.
Debian 6 (Squeeze): Even with the Linux 3.2 available as a backport, the
radeon driver will not handle your APU's Turbo Core feature.
Debian 7 (Wheezy): Linux 3.16 is available as a backport. Upgrade to Linux 3.16 (if no other requirements prevent it) and see below.
Debian 8 (Jessie): Based on Linux 3.16. See below.
The flag responsible for Turbo Core handling is called
bapm; it is located in the
trinity_dpm.c file of the
radeon driver. Before Linux 3.16, it was always disabled due to stability issues with some configurations. As of Linux 3.16, two changes were planned:
The value for
bapm can be provided as a module parameter (see here).
The value of
bapm is set to 1 by default for Kaveri, Kabini and desktop Trinity, Richland systems (see here), resulting in Turbo Core being enabled.
This means that with current Linux kernels, you'll most likely get best value (Turbo Core, energy efficient console) out of the box (this is e.g. true for current ArchLinux installers).
Much to my surprise, even with the Debian Jessie 8.2 installer, you need to take care of two things:
Following its policies, Debian will not provide the required microcode by default. You'll want to provide it: Append
contrib to the relevant entries in
/etc/apt/sources.list and run
sudo apt-get update as well as
sudo apt-get install firmware-linux-nonfree
Interestingly, despite the 3.16 defaults, Turbo Core does not work on the same system where a recent ArchLinux succeeded. It could be that the Debian 3.16 kernel is too old to incorporate the defaults, or that the Debian patch to isolate the microcode has some side effect. Either way, Turbo Core can be enabled for Debian Jessie in the presence of the microcode by providing a
bapm value at boot time: Append
radeon.bapm=1 to the value of
/etc/default/grub and run
After these two changes, Turbo Core and the low console power consumption worked for me like a charm.