• 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

I have found just removing default gov and freqs from script improves batt life, also freqs won't hold with anything CPU intensive they auto scale up
 
init.qcom.post_boot.sh - 3.22 KB

Script with redundant code, default governor, and freq settings removed for those who want to try it goes in etc directory "make backup of original!!!!" Set perm "rw-r-r" let me know if it helps

Edit: updated script with jimsmith80's edits
 
brittnearl said:
init.qcom.post_boot.sh - 5.24 KB

Script with redundant code, default governor, and freq settings removed for those who want to try it goes in etc directory "make backup of original!!!!" Set perm "rw-r-r" let me know if it helps
Click to expand...

Looks good, though there is no cpu2 or cpu3 in our device, those can go also. Also poor practice to remove the copyright. Mind if I base my changes off this? (Thanks for testing!!!!) Long story short, I've been away from my computer since Friday. I blame marriage.

*edit* Hopefully you're ok with it, so here's b3 that replaces the post_boots AWEstruck_v1.03b3.zip - 8.62 MB No boot image changes this time around

Will add to op tomorrow as official release pending feedback.
 
spock1104 said:
Looks good, though there is no cpu2 or cpu3 in our device, those can go also. Also poor practice to remove the copyright. Mind if I base my changes off this? (Thanks for testing!!!!) Long story short, I've been away from my computer since Friday. I blame marriage.

*edit* Hopefully you're ok with it, so here's b3 that replaces the post_boots AWEstruck_v1.03b3.zip - 8.62 MB No boot image changes this time around

Will add to op tomorrow as official release pending feedback.
Click to expand...

No problem, i figured theres enough copyright in the other files lol
 
brittnearl said:
Battery life is good 1.4 and lower, 1.5 and above is funky it doubles battery drain and sometimes freqs don't stick, this is with script removed, I'm gonna try just removing governor presets from script
Click to expand...


Force stop performance control, wipe data, and reboot. That should take care of it
 
I'm having the opposite issue its reporting 1.4 but the scale is at 486mhz ...weird. Going back to stock and watch progress lol.
upaha7y2.jpg
 
brittnearl said:
ybu7yqu2.jpg


I also have this issue if apply on boot is unchecked
Click to expand...

Believe it or not this is expected behavior according to my revised tables. Take a look at https://github.com/spock1104/android_kernel_zte_nex/blob/master/arch/arm/mach-msm/acpuclock-8930.c anything with a 1 in front is used for scaling and anything with 0 is not. What you're seeing is consistent with the fast cpu table, where 384MHz and 486MHz have the same voltage and you wouldn't save anything by using 384 over 486 (voltage is the last number). It's being smart :D

And what's this post from starkraving!? Please tell me it runs on your device again...
 
spock1104 said:
Believe it or not this is expected behavior according to my revised tables. Take a look at https://github.com/spock1104/android_kernel_zte_nex/blob/master/arch/arm/mach-msm/acpuclock-8930.c anything with a 1 in front is used for scaling and anything with 0 is not. What you're seeing is consistent with the fast cpu table, where 384MHz and 486MHz have the same voltage and you wouldn't save anything by using 384 over 486 (voltage is the last number). It's being smart :D

And what's this post from starkraving!? Please tell me it runs on your device again...
Click to expand...

It runs but the sliding scale is at 486 (on its own) but reporting 1.4ghz ... Settings don't seem to stick for me. I'll shoot you some logs when I get a chance.
 
brittnearl said:
What about freqs not sticking under load??

Also why is it still showing default freqs instead of actual freqs with apply on boot unchecked shouldn't this have been changed??
Click to expand...

Not sure I understand the second question. First one may be the app you're using.
 
Freqs stuck with stock kernel?? I mean the scubbers show stock kernel freqs which aren't even part of the table anymore, shouldnt they have been changed to match new table?
 
I haven't had a chance to look over your modifications, I'm running with what I put into the 1.03b3 zip.

Stock frequencies are STILL in the table, only the clocks that go over and under stock have been modified, and what gets used for scaling. Check my changelog if you don't believe me. Nor should they be removed. I want the kernel defaulting to 384-1.18 since that's what comes out of the factory, I don't want to run into any accusations that the modifications burned out someones device.
 
spock1104 said:
I haven't had a chance to look over your modifications, I'm running with what I put into the 1.03b3 zip.

Stock frequencies are STILL in the table, only the clocks that go over and under stock have been modified, and what gets used for scaling. Check my changelog if you don't believe me. Nor should they be removed. I want the kernel defaulting to 384-1.18 since that's what comes out of the factory, I don't want to run into any accusations that the modifications burned out someones device.
Click to expand...

That explains the scrubber issue as there is no scale for default, also it doesn't default to stock min of 384 it goes to 486 on boot, stock max it does though
 
brittnearl said:
That explains the scrubber issue as there is no scale for default, also it doesn't default to stock min of 384 it goes to 486 on boot, stock max it does though
Click to expand...

See my screenshots above, my phone is doing 384-1.18 with the latest kernel. Again, please double check with other apps.
 
You must log in or register to reply here.
Back
Top Bottom