Created attachment 83926 [details] Dmesg I have Debian Testing 64-bit with the latest git mesa, xf86-ati, libdrm and kernel 3.11 installed on a A8-5500 Trinity APU. Watching the sensors output right after logging in, i noticed that the voltage regulation doesnt actually work initially as the APU is powered by 1.34V (maximum possible with the radeon driver). Nothing is going on so it should have 0.9V (minimum voltage). This lasts until some event - for example forcing dpms off then on or switching vts to a text vt and back (probably some other events like playing video or something, but the dpms and vt switching is consistently working) makes voltage regulation kick in and start actually working lowering the APU voltage to 0.9 if idle then adjusting according to load and temperatures. The real problem this creates if increased temperatures - after making the voltage regulator work, the temperatures drop by as much as 10 C degrees in a few seconds. For reference - my sensors output lists ~17-18 C (not real obviously, seems that these sensors report accurately after the CPU is loaded)) CPU temperatures when idle and powered with 0.9 V. In contrast, right after boot and doing nothing for minutes, powered with 1.34 V i have ~26-27 C idle temperatures.
Created attachment 83927 [details] lspci
I have further information on this. It seems that before the X server is started, the CPU voltage is correctly regulated - it's at 0.9 v, when not doing anything, which is the correct behavior. But after x starts, the voltage jumps to 1.34 or 1.44 and stays there until i dpms off/on the monitor. It seems that vt switching doesnt always help here. If it works correctly and restart just the x server, it will go up again to 1.34, as the first time and i have to do the dpms off/on thing to bring it back to work. Also it seems that this voltage increase kicks in only after i logged in and the desktop (xfce) is loaded - at the lightdm login screen i still have 0.9v.
You might try again with the bapm fixes in my drm-fixes tree: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.12
I use the mainline linux kernel (now 3.12 rc1+) merged with your drm-fixes-3.12 already. This behavior is there and seemingly unchanged since i tried dpm with the kernel 3.11 when was in rc stage. Here is what i get from sensors and the debugfs radeon info: radeon-pci-0008 Adapter: PCI adapter temp1: +0.0°C (crit = +120.0°C, hyst = +90.0°C) it8728-isa-0228 Adapter: ISA adapter in0: +0.90 V (min = +0.00 V, max = +3.06 V) in1: +1.64 V (min = +0.00 V, max = +3.06 V) in2: +2.03 V (min = +0.00 V, max = +3.06 V) in3: +2.04 V (min = +0.00 V, max = +3.06 V) in4: +2.02 V (min = +0.00 V, max = +3.06 V) in5: +2.22 V (min = +0.00 V, max = +3.06 V) in6: +2.22 V (min = +0.00 V, max = +3.06 V) 3VSB: +3.36 V (min = +0.00 V, max = +6.12 V) Vbat: +3.31 V fan1: 1573 RPM (min = 0 RPM) fan2: 1046 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) fan4: 0 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) temp1: +31.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor temp2: -8.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor temp3: +14.0°C (low = +127.0°C, high = +127.0°C) sensor = Intel PECI intrusion0: OK Radeon HD 7560D clocks: uvd vclk: 0 dclk: 0 power level 0 sclk: 30400 vddc: 912 in0 is the CPU voltage - 0.9-1.44 volts, 1.44 is reached only in the erroneous state sometimes, normal operations are between 0.9-1.36v. Troubling is this initial high state because if you dont notice it youll get consitently high temperatures because of the driver. BTW when the dynamic voltage works, i have pretty much the same temperature as with fglrx. I wonder how vddc works - is it a totally separate voltage controlled separately by the radeon driver? I have seen it 1.1 v or something when in0 was 0.9 (vdpau playback for example). Or in0 and vddc are the same thing, and its control is somehow shared between the acpi-cpufreq and radeon drivers?
I did some more poking and i found that setting the cpu governor to "conservative" i get correct voltage handling at bootup after logging into lightdm. But if i restart lightdm and log in, it will get stuck at the 1.34-1.36 levels. With ondemand after boot i always had (maybe 1 or 2 exceptions) the 1.34 and 1.36 voltage levels. Its weird that in that state changing to a vt and back sometimes elevates the voltage to 1.44v and keep it there. I also removed and loaded again the acpi-cpufreq driver - after unloading, the voltage is a fixed (it seems) 1.15v, after loading it again it jumps to 1.34 and stays there (or goes up to 1.36 and back sometimes) until i turn dpms force off and on the monitor, after which it starts to change the voltage levels correctly.
It also seems that only if i use acpi=strict on the kernel command line the conservative governor works well. Otherwise it is exactly the same as ondemand.
With 3.12 rc3 and now rc4 kernels this bug seemso to be gone and replaced with its opposite - the APU never reaches its maximum voltage (1.34) even under full load (4 threads compiling) instead it stays at max 1.22v, thus torbo core is never activated (maybe for a second at start?) and instead of sustained ~3.3 GHz i get with 1.34v i have something like this (max 2 cores are reported as 3.2GHz): # cpufreq-aperf -o CPU Average freq(KHz) Time in C0 Time in Cx C0 percentage 000 3168000 00 sec 987 ms 00 sec 012 ms 98 001 3168000 00 sec 998 ms 00 sec 001 ms 99 002 3168000 00 sec 990 ms 00 sec 009 ms 99 003 3200000 00 sec 997 ms 00 sec 002 ms 99 Granted, the temperatures are lower too (never reaching over 50C), but for that +5C difference i would rather have +200MHz sustained speed (and the initial ~3.5 GHz). The idle voltages are modified, they go as low as 0.7V, they are constantly changing between 0.9 and 0.72 or so. Before it was only 0.9. Maybe this is a acpi-cpufreq issue?
As this bug isnt present in the newer kernels, i mark it as resolved.
It seems that commit 4076a65544e2de310cbf4eaadb13ee15bbfaaf4f, related to the radeon dpm solved this issue.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.