• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [LINARO] AWEstruck v1.04 12/14/14 | [3.4.107] v1.05b6 5/30/15

Just want to report in, I've been busy looking at the limit overrun issue the last few days and not much luck so far. Other kernels are using more or less the same frequency adjustment code as we are. It's looking less likely that I can keep the "efficient" scaling in, what I may do is turn on scaling for all frequencies above 1GHz to work around this, in theory it'll still result in some power savings for light loads. My last hope of keeping the efficient scaling is to remove ZTE's early suspend code, which I'll hopefully try tomorrow.
 
There's a function in freq_table.c that checks the frequency table for its min and max frequency and sets them, essentially overriding what the user entered. I kept the frequency detection but removed the policy setting. Frequency should stick now.
 
spock1104 said:
There's a function in freq_table.c that checks the frequency table for its min and max frequency and sets them, essentially overriding what the user entered. I kept the frequency detection but removed the policy setting. Frequency should stick now.
Click to expand...
kool I will let u know
 
Knee jerk reaction here, but I was running for over a day in the kernel with frequency set by Android tuner and didn't see any unwanted frequencies. After running with the frequency set by performance control I have one second of usage at 1.7 and no unused frequencies. I'll clear my statistics and set with trickster next. My initial guess is performance control still needs work. At least it's open source.
 
This thing is going to drive me nuts, now they're all broken. I'll look into other areas that touch max policy or see if it's not getting set where it should.
 
Getting closer, but not too happy about where the source may be. I enabled some debugs:

<7>[06-20 02:52:25.740] [0][429: thermald]setting new policy for CPU 0: 162000 - 1404000 kHz
<7>[06-20 02:52:25.740] [0][429: thermald]new min and max freqs are 162000 - 1404000 kHz

*mutter*
 
LcfYiVL.png


TRUQe1N.png



oSgWZx9.png
 
Interesting result on my phone, if I disable the Temperature Throttle option I can readily create the issue. If I re-enable it doesn't seem to happen. Can anyone confirm?
 
brittnearl, I see where you're coming from. take a look at tsens_tz_sensor9. That looks like info for the 8930ab. Changing 1404000 and 1296000 to 1188000 might take care of this.

*edit* no, it doesn't. If we can't come up with a config that fixes this I'm going to propose removal of thermald

*edit2* big surprise, removal of thermald seems to fix it. Here's the kernel with the in-built thermal controls so that if you test the same config you don't burn up your phone. freq7.img - 7.35 MB

it also has frequency debugs enabled in cpufreq, so if the phone has another frequency issue there will be evidence of why in dmesg. The trick is dmesg is too short most of the time, so I run this command in a terminal: while true; do dmesg -c >> /sdcard/dmesg.txt; sleep1; done
 
You must log in or register to reply here.
Back
Top Bottom