Trinity Support / Preferences Reset

[GoogleCodeExporter]

I got an A4-4355M APU, i found out that pstate 6 and boost states are 
disabled(by default?) so i activate them but if i poweroff the machine 
everything resets. If I reboot, instead, everything works.

Could you add trinity / piledriver support?

Original issue reported on code.google.com by mr.fabi...@gmail.com on 17 May 2014 at 9:39

[GoogleCodeExporter]

It's very quite possible that your machine's BIOS does not enable Boost states.

Have you examined BIOS settings to see if there is, perhaps, an option that 
would
allow boosting? It might be called "Turbo" or "CPB" or "APM".

What is the output of: TurionPowerControl -l  after fresh power-on?

Note that changes to APM/Boost/P-state configuration made by TPC are not 
persistent
(they go away the moment the power goes away).
This is hardware limitation -- there is no universal way to make the CPU 
"remember"
new configuration after the machine is turned off.

This means that APM/Boost/P-state manipulation needs to be re-done after every
reboot or power-cycle (depending on the BIOS). TPC's configuration file was
made to make this process a bit easier but it doesn't receive a lot of testing
lately and is in need of complete revamp.

That said, I'd probably resort to a batch file (Windows) or a script of sorts 
(Linux)
to cope with this issue (at least for the time being).

Original comment by kszy...@gmail.com on 20 Jun 2014 at 1:00

[GoogleCodeExporter]

OK so it's a limitation. Thank you for your answer..i wrote a guide on enabling 
pstate and undervolt it on AMD APU a4 4355m( 
http://ubuntuforums.org/showthread.php?t=2221545 ), and i've done some changes 
on my rc.local to make everything work on boot. But the main problem is:
after all is setted i need to restart my machine to make indicator-cpufreq see 
my new pstate frequency. Is there a way to refresh frequencies on 
indicator-cpufreq without reboot??

Thank you ;)

Original comment by mr.fabi...@gmail.com on 20 Jun 2014 at 1:25

[GoogleCodeExporter]

Maybe something that must be done before cpufreq module is loaded..so something 
like a kernel patch..

Original comment by mr.fabi...@gmail.com on 20 Jun 2014 at 1:27

[GoogleCodeExporter]

You could check how powernow-k8 code has been built.

If it's built as a module [powernow-k8.ko exists for your running kernel], then 
I think
reloading powernow-k8 should make the kernel see additional P-states [you can 
then
run 'dmesg' to see if they have been detected].

If it's compiled-in, however (some distributions compile it in) then the only 
option
is rebooting the machine -- something you already noticed.

Original comment by kszy...@gmail.com on 20 Jun 2014 at 1:40

[GoogleCodeExporter]

Ok..thank you for your help! Anyway this could be a nice thing to do for the 
next release.

Bye ;)

Original comment by mr.fabi...@gmail.com on 20 Jun 2014 at 1:48

[GoogleCodeExporter]

I've also noticed that you've used 0.1V in your post. Wasn't that a typo by 
chance?
0.1 V is pretty low for a CMOS circuit and I think it may not work.

Also, something you may be interested in -- TurionPowerControl -CM should let 
you
monitor P-states of all cores in the system.

Re Linux+CPU frequency scaling, I believe this problem has been noticed by 
Paolo in
the past. One possible solution is disabling frequency scaling in the BIOS or 
kernel
and relying on TurionPowerControl to scale CPU frequency (that way you wouldn't
need to reboot the machine at all).

The downside is TPC's scaler code needing a bit of rework to fit in current
architecture so it's not a plug-and-play solution at this time.

Original comment by kszy...@gmail.com on 20 Jun 2014 at 2:04

[GoogleCodeExporter]

No it was not by chance, i tested possible voltages and that was the lowest..if 
i remember well..

Anyway i think it would be better to solve this problem without changing the 
default scaler..cause in this way the code will be more difficult to 
maintain(for all the cpus). But it's your code..so..good luck!!

Original comment by mr.fabi...@gmail.com on 20 Jun 2014 at 2:11

[GoogleCodeExporter]

I'm just pointing theoretical options out as I won't have time to work on TPC's 
scaler
any time soon anyway.

I agree that sticking with already-invented wheel (kernel scaler) is better.

The downside is that you need an extra reboot when powernow-k8 code is _not_ a 
module
(which is sort of an inconvenience).

So, assuming we want to stick with kernel scaler, one can:
(a) reload powernow-k8 (if compiled as a module) after making TPC 
modifications, or
(b) if powernow-k8 is _not_ a module -- rebuild the kernel so it _is_ a module
    (and then going by item (a)), or
(c) reloading the kernel after making TPC modifications (a reboot or, just got 
this
    idea, using kexec to do it quicker:)
(a) rebuild the kernel so powernow-k8
is a module

Original comment by kszy...@gmail.com on 20 Jun 2014 at 2:25

[GoogleCodeExporter]

Err, ignore last (a) item, it's some old junk that I accidentally left.

Original comment by kszy...@gmail.com on 20 Jun 2014 at 2:26

[GoogleCodeExporter]

Yeah..i agree.

Original comment by mr.fabi...@gmail.com on 20 Jun 2014 at 2:30

[GoogleCodeExporter]

I'm going to set status of this issue to 'Invalid'.

Changes performed by TPC do not persist across reboots because they are reset by
the processor itself (not a lot TPC can do to remedy that). One needs to re-set 
any
TPC modifications after the machine boots (either manually or from an 
initscript).

If you run into other problems or have further questions feel free to file a new
issue.

Original comment by kszy...@gmail.com on 21 Nov 2014 at 9:41

• Changed state: Invalid

[GoogleCodeExporter]

Ok no problem. Thank you anyway for you help

2014-11-21 22:42 GMT+01:00 <turionpowercontrol@googlecode.com>:

Original comment by mr.fabi...@gmail.com on 22 Nov 2014 at 9:57