I apologize if this thread is in the wrong section, but I cannot post in the development section as I do not have 10 posts.
I'm currently using Clockworkmod with the stock 4.2.2 ROM and franco's kernel r92. I was reading the changelog and saw that in r29, he mentions that only one core is activated when touching the screen unless the second touch is more than 100px away. When using the Kernel Updater app's monitor, I see that both my cores are always activated and current clockspeed is 384 MHz. In settings, I have it set to scale cores as necessary.
Is two cores running when not touching the screen (and with no other apps running) expected behavior and a change in a later build, or is something going on here that I need to address?
Thanks!
ihakim said:
I apologize if this thread is in the wrong section, but I cannot post in the development section as I do not have 10 posts.
I'm currently using Clockworkmod with the stock 4.2.2 ROM and franco's kernel r92. I was reading the changelog and saw that in r29, he mentions that only one core is activated when touching the screen unless the second touch is more than 100px away. When using the Kernel Updater app's monitor, I see that both my cores are always activated and current clockspeed is 384 MHz. In settings, I have it set to scale cores as necessary.
Is two cores running when not touching the screen (and with no other apps running) expected behavior and a change in a later build, or is something going on here that I need to address?
Thanks!
Click to expand...
Click to collapse
Current kernel is 2 cores online with hotplugging for the other two. It has been several releases since it has been one core with two online for swipe.
ihakim said:
I apologize if this thread is in the wrong section, but I cannot post in the development section as I do not have 10 posts.
I'm currently using Clockworkmod with the stock 4.2.2 ROM and franco's kernel r92. I was reading the changelog and saw that in r29, he mentions that only one core is activated when touching the screen unless the second touch is more than 100px away. When using the Kernel Updater app's monitor, I see that both my cores are always activated and current clockspeed is 384 MHz. In settings, I have it set to scale cores as necessary.
Is two cores running when not touching the screen (and with no other apps running) expected behavior and a change in a later build, or is something going on here that I need to address?
Thanks!
Click to expand...
Click to collapse
So you looked at a changelog for r29 and are applying it to r92?!?!?
The recent changelogs are the relevant ones. As I understand there were stability and lag issues with single core mode. His kernel now is either in dual core or quad core mode depending on CPU load.
diablos991 said:
So you looked at a changelog for r29 and are applying it to r92?!?!?
The recent changelogs are the relevant ones. As I understand there were stability and lag issues with single core mode. His kernel now is either in dual core or quad core mode depending on CPU load.
Click to expand...
Click to collapse
Not expecting the change log to be the same, but read through the rest of the changes leading up to r92 and didn't see a mention of him changing it back to two cores (maybe I missed it?). Thanks for answering my question!
ihakim said:
Not expecting the change log to be the same, but read through the rest of the changes leading up to r92 and didn't see a mention of him changing it back to two cores (maybe I missed it?). Thanks for answering my question!
Click to expand...
Click to collapse
Franco is constantly releasing new kernels through his app and he has some of the best kernels out there but they are true nightlies meaning they experimental I find matrix and trinity are the best for performance
Is there a way to have individual core Control clock speeds and governor if possible I'd prefer an app for obvious reasons (easier) I'm on cm10.1 5/9 nightlies
Sent from my Nexus 7 using Tapatalk 2
Some of the rate governors (not all of them) let you select the maximum number of cores allowed to be online. Depends on the kernel, but in principle you can use Trickster Mod. While clocking on the Tegra 3 is quite flexible, I believe it is not possible to have separate G cores operating simultaneously with different clock rates.
That's lame the subject came up because I have it working on my Atrix HD AT&T but I think I'll try another kernel
Sent from my Nexus 7 using Tapatalk HD
Franzferdinan51 said:
That's lame the subject came up because I have it working on my Atrix HD AT&T but I think I'll try another kernel
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
What's the point of it?
bftb0 said:
What's the point of it?
Click to expand...
Click to collapse
Extra battery but more speed with a kind of stepping stone per say look at it like this using my dual core 1.5 ghz atrix hd as an example
Sleep one core and you run single core with lots of lag
But with this method you can under clock core 0 1ghz to and change the government to interactive use the second core as something to the n7 companion core take it way down farther let's say 600mhz with on demand or possibly conservative governor. That way the second core would come on in times of lag for a small push to end lag spikes and like I said works on my atrix quite well
Sent from my Nexus 7 using Tapatalk HD
I think I would expect what you are describing to exhibit strange (pathological) behavior unless all of the rate governors are re-coded to collect their heuristics partitioned by processor thread affinity.
Does this also mean the 2nd processor is never off-lined? (They can drain a lot of juice even when underclocked due to static power dissipation issues, so it makes me wonder if the power savings is real)
Is the kernel development work for that device (Atrix HD) described anywhere by the implementer(s)?
A couple I couldn't point you to a definitive answer as I'm not a dev though it's defiantly someplace here on the forums even a kernel to look at
Sent from my Nexus 7 using Tapatalk HD
Franzferdinan51 said:
A couple I couldn't point you to a definitive answer as I'm not a dev though it's defiantly someplace here on the forums even a kernel to look at
Click to expand...
Click to collapse
Are you talking about that script-ware by smokin1337? If so, it seems to (try to) work by forcing the second core to be on-line at all times, and then changing rate governors on a per cpu basis, not in the kernel but by continuously writing to each cpu entry in sysfs.
I peeked over in the Atrix HD forum and it seems it doesn't even have any working custom kernels yet...
http://forum.xda-developers.com/showthread.php?p=40253686
That's the only kernel to my knowledge
Sent from my Nexus 7 using Tapatalk HD
@Franzferdinan51
Maybe you could throw me a bone - what exactly is it that you are using on your Atrix HD that does this? (Is it baked in to somebody's ROM, or a separate flashable patch)?
I *did* go searching over in the Atrix HD forum rather extensively.
Downloaded Codex01's "CM10.1PreformanceEnhancements-3.0.1" and looked in there - this doesn't do what you say.
Downloaded tcf38012's popcorn kernel and unpacked it and poked around - it also doesn't do what you say (lots of other tweaks tho).
Found a mention of something similar in posts by skeevydude. Downloaded smokin1337's "CPU Editor" for snapdragon - it was mentioned in passing in the Atrix CM 10.1 thread.
Am I just looking at the wrong things?
Anyway, everything that I've found so far that looks close to what you are describing writes control information to stuff in /sys/devices/system/cpu{/cpu0|/cpu1}/*
For what it is worth, that same (sysfs) stuff does exist in various N7 kernels - for instance, per-cpu entries for min/max frequencies and rate governors in /sys/devices/system/cpu/cpu{0|1|2|3}/cpufreq/.
So, maybe what I said first was wrong. Maybe the right answer should have been "kinda - maybe - sorta". I would have to understand the PLL schemes that different kernels use a lot better than I do to be definitive.
But I am still a bit skeptical that it actually produces the result that it claims - saving battery life by forcing two cores to be online at all times... without also affecting performance. And the part about two independent control loops affecting each other in pathological ways remains open as well (threads running on the other core with a different rate governor affect the measurement of the recent system load averages used by the second rate governor - and vice versa).
It would be useful to have a decent and repeatable way to benchmark interactivity - the first-person reports of "this is really smooth" or "lags badly" are always completely subjective and non-repeatable, so it is hard to know who to really believe when it comes to reports about this stuff.
cheers
I am sorry if what im about to ask is already posted somewhere (probably is), but this forum is pretty vast and I couldnt find what im looking for. The question is this, Im using Vanir ROM. Now with the inbuilt kernel I had around 20k benchmark on antutu. I flash hells core, excited to see any difference and whoop, i got 14k. Also i checked the part with 3D testing and fps was higher for about 5-7 points. So what Im asking is this,What is the meaning of this and also how can I, how to put it to not sound noobish, tweak the kernel to perform/save battery etc.?Because Im assuming thats not the top what HellsCore kernel can do, am I right? Or if you guys have any kernels to recommend, all is appreciated. Also if this helps, Im using Nexus 4, Vanir ROM(as posted above) and dont know what else would you need to know to answer.
Thanks in advance
/So I rebooted and now I am on 20840 for some reason.
Benchmarks are not very conclusive abnout anything. Each phone is different each user has different needs and how and where there phone is used. Everyone will tell u to try this kernel and that kernel but u just have to find one that works for you
Sent from my GT-P3110 using Tapatalk
mymeatb18 said:
Benchmarks are not very conclusive abnout anything. Each phone is different each user has different needs and how and where there phone is used. Everyone will tell u to try this kernel and that kernel but u just have to find one that works for you
Sent from my GT-P3110 using Tapatalk
Click to expand...
Click to collapse
I get that, i was more concerned about those numbers. Why did it drop to 14k and then went to 20k again.
Probably some patches were included in the rom's kernel, which can affect the scores.
When you flashed another kernel (helldoctor), you stopped using these patches, so scores went down.
Sent from my NookColor using Tapatalk
Almayce said:
I am sorry if what im about to ask is already posted somewhere (probably is), but this forum is pretty vast and I couldnt find what im looking for. The question is this, Im using Vanir ROM. Now with the inbuilt kernel I had around 20k benchmark on antutu. I flash hells core, excited to see any difference and whoop, i got 14k. Also i checked the part with 3D testing and fps was higher for about 5-7 points. So what Im asking is this,What is the meaning of this and also how can I, how to put it to not sound noobish, tweak the kernel to perform/save battery etc.?Because Im assuming thats not the top what HellsCore kernel can do, am I right? Or if you guys have any kernels to recommend, all is appreciated. Also if this helps, Im using Nexus 4, Vanir ROM(as posted above) and dont know what else would you need to know to answer.
Thanks in advance
/So I rebooted and now I am on 20840 for some reason.
Click to expand...
Click to collapse
Anututu and other benchmarks depend on a number of factors/conditions which affect the final result . The major conditions which affect it result are below
1) The CPU temperature !! When ur phone gets hot the CPU throttle will automatically reduce the active cores and the clock speed to cool down your CPU !! This results in decrease in performance !! When you flash new kernels its possible that ur phone is hot and hence performance decreases
2) Using your phone while running tests also affect the results . for eg if there is a notification during the test or background sync going on it will affect the result
3) probably the kernel packed with vanir had 4 cores active all the time to increase scores and hells core has just 2 cores active ( at a given moment) will mean decreased performance
The ideal way to test kernels is as follows
1) Dirty flash your ROM before flashing kernel
2) Reboot your device after the first boot
3) Let it settle down for an hour
4) turn of data/WiFi during the test
5) see the kernels specs( like cores active/the maximum CPU speed) through an app like trickster/faux clock
6) Now run the test
7) after test let your phone cool down for 15 mins
8) repeat the test a few times and take the average of all scores
Kindly hit the thanks button as a token of appreciation
Antutu was never accurate if you ask me. Sometimes it goes down and the other it went up..so..
I see, thank you guys.
Benchmarks are like putting makeup on.
Sent from my Nexus 4 using Tapatalk
Update
All the changes I made were merged into CoCore-refresh kernel (3.0.31) and 3.0.101 by TeamCanjica, so they will hit 'mainstream' in some time when they release another build.
This thread is over
/Update
Hi,
I've been working on this kernel for some time with improving undervolting in mind. It's based on CoCore Refresh r10 by CoCafe and of course the credit goes to him where it's due.
Main changes:
- rewritten liveOPP internals.
It improved stability a lot - it now allows to use 300/500/700/900 MHz frequencies with no problem and it allows to undervolt low frequencies even more. Freqs >1GHz are now stable at varm=0x32 (at least on my phone), which also saves a lot of power.
Freqs <=400 MHz now use 0x12 (0.925V) voltage by default - It's the original voltage for 400MHz and you can go even lower when undervolting
- rewritten Mali booster algorithm.
It's far from perfect yet, but it eliminated instability due to the fact, that CoCafe's mali booster and "original" booster (switching between APE 50/100 OPP) were working independently and could cause a crash when the original algorithm switched to APE_50_OPP while mali boost was active. APE_50_OPP voltage is 1V by default (0x18), so when clock is boosted to i.e. 700MHz and it switched to 50 OPP, the result was 350MHz @ 1V, which mihgt be too low.
- allow to set APE and DDR OPP with liveOPP
echo apeopp=25/50/100 > arm_stepXX and echo ddropp=...
before the kernel would set ape/ddr opp to 100 for freqs above 400MHz
- allow changing ape_50_opp voltage
echo 0xXX > /sys/kernel/mali/mali_gpu_vape_50_opp
- make wlan/mmc boost tunables available through sysfs in /sys/kernel/performance/*
- Memory split changed to 2G/2G and switch highmem off - it's not needed with this split
- removed some unnecessary drivers and moved others to modules to reduce kernel size
- changed kernel compression to LZO
- 631MB available memory
- 7800ms kernel boot time
Download & install:
Mediafire
That's partition image - flash it with dd:
Code:
dd if=kernel.mk-r1-release.img of=/dev/block/mmcblk0p15
It's also good to create a symlink from /system/lib/modules to /lib/modules - it'll allow modules to autoload, enable modprobe to work and also you can use KoControl app to manage module loading.
Source:
GitHub
TODO:
- create a package for flashing with recovery and place modules (7MB) in /system/lib/modules instead of a ramdisk
- touchbooster has a bug that causes it to limit max freq to 1000MHz on boost.
- figure out how to enable setting of minimal cpu freq - now touchboost always resets it to 100MHz
- add interactive gov from Zwliew kernel
- create more power optimized, auto tuning 'foreground' governor (long story)
My voltage settings
(default kernel voltages are more conservative - set those from init scripts and test them for stability!):
100 - 0x0f
200 - 0x10
300 - 0x11
400 - 0x12
500 - 0x14
600 - 0x18
700 - 0x1d
800 - 0x24
900 - 0x28
1000 - 0x2f
1050..1250 - 0x32
Mali gpu voltage
Default voltage from CoCafe is way too high - idx0 vape could be just 1V since that's the voltage, when mali is running at 1/2 speed (200MHz by default).
My settings (for safety they are 3 steps higher than the lowest working voltage for given freq).
#0 - 0x17
#5 - 0x1c
#9 - 0x23
I don't overclock the gpu - my low index is set to 0 (200MHz), and hi (boosted) to 5(400MHz), which is the original mali freq. That gives mi 100MHz when working at half speed. I don't use any fancy UI effects, so it's enough - when not plaing a game, mali is only working at 100/200MHz and only boosts when loaded. Params:
boost_low idx=0
boost_low threshold=30
boost_delay 2000
boost_high idx=5
boost_high threshold=220
Default kernel settings are left unchanged - set those manually from init scripts.
I place the thread here because I'm not allowed to post in developer forums (<10 messages limit).
MK
Wow. Thanks for your work, mate!
Most people are using CM or CM/AOSP based ROMs nowadays, but there are only a few people (like me) who still use Jellybean. So, I'll try your kernel very soon and I'll post a review after using it.
You joined XDA on 2010 and yet, this is your first post. That just doesn't feel right.. Anyways, keep up the good work, mate. :good:
Good to see another kernel developer for our phone! I'm on stock rom now, I will try it out
Sami Kabir;5571pro. [B said:
Wow. Thanks for your work, mate! [/B]
Most people are using CM or CM/AOSP based ROMs nowadays, but there are only a few people (like me) who still use Jellybean. So, I'll try your kernel very soon and I'll post a review after( using it.
Click to expand...
Click to collapse
The code is on github and there's no problem with merging it with some cm kernel. When I'll try my with some 4.4 again (so far each one had something broken and didn't suit me), I'll probably do it
You joined XDA on 2010 and yet, this is your first post. That just doesn't feel right.. Anyways, keep up the good work, mate. :good:
Click to expand...
Click to collapse
To keep it short let just say that I'm not a sociable type of guy... but when I have something of value, I try to share...
One more thing (most probably know it, but for those who don't) - 99% of "user experience" depends on the settings of governor, mali and touch booster - if you screw this up, no kernel will work smoothly. I had this problem with my first vanilla jb - it sucked as hell(ondemand), but when I set sampling_down_factor to 3-4 suddenly it was very smooth. Default gov params aren't always the best. Thats one of the reasons I'll try to write a governor that tunes itself and adjusts itself to the app currently in foreground - but that's just an idea and it'll take me some time to refresh all the math needed for it...
Anyway - enjoy the kernel.
Hmm I really wanna test this kernel, but I'm currently on Vanir
I definitely gonna follow your thread, it's good to know Janice is still alive and kicking
Reinkaos said:
Hmm I really wanna test this kernel, but I'm currently on Vanir
I definitely gonna follow your thread, it's good to know Janice is still alive and kicking
Click to expand...
Click to collapse
You can always ask rom's devs to merge my changes - it's just a few commits.
And how is that rom working for you? At the time I was checking up 4.4 roms each one of them sucked in a different way. Carbon was the closest (in fact it was the only one acceptable) to being useful (feature- and ui-wise), but it had some process spinning in the background and It was draining my batt (it was unkillable because it was a part of lock screen I think - the bug was known, but no fix available at that time).
If it's similar to carbon I might give it a try...
mkaluza said:
You can always ask rom's devs to merge my changes - it's just a few commits.
And how is that rom working for you? At the time I was checking up 4.4 roms each one of them sucked in a different way. Carbon was the closest (in fact it was the only one acceptable) to being useful (feature- and ui-wise), but it had some process spinning in the background and It was draining my batt (it was unkillable because it was a part of lock screen I think - the bug was known, but no fix available at that time).
If it's similar to carbon I might give it a try...
Click to expand...
Click to collapse
Well I use to be a Carbon die-hard fan before, but since the dev have got himself another device, so I just had to change rom.
And then I try Vanir. Surprisingly it's pretty stable, and we have official support by the Vanir team too.
Feature-wise its just as good as Carbon, but I kinda miss the pie, since Vanir doesn't have it.
And I think Vanir have a bit more features than Carbon do.
Anyway can you go lower than those cpu voltage on your OP? Or is it really not stable?
Mine's 1000 is at 0x2c, 800 at 0x20, and that's the lowest I can go.
And thanks for the gpu voltage :good: , I actually use that value now :laugh:
aioreu the
Reinkaos said:
Well I use to be a Carbon die-hard fan before, but since the dev have got himself another device, so I just had to change rom.
Click to expand...
Click to collapse
It's a pity... but I understand that's only the S Advance branch of Carbon thats dead - the rom itself is being developed further?
And then I try Vanir. Surprisingly it's pretty stable, and we have official support by the Vanir team too.
Feature-wise its just as good as Carbon, but I kinda miss the pie, since Vanir doesn't have it.
And I think Vanir have a bit more features than Carbon do.
Click to expand...
Click to collapse
I didn't like the pie ;P But if you say it's ok, I'll give it a try when I'm in the mood to reinstall everything on the phone...
Anyway can you go lower than those cpu voltage on your OP? Or is it really not stable?
Mine's 1000 is at 0x2c, 800 at 0x20, and that's the lowest I can go.
Click to expand...
Click to collapse
Actually I didn't recheck those two and focused on lower freqs - these were the limits with older LiveOPP, but now I can go to 0x22 and 0x2c.
In fact, 0x24 and 0x2f are already undervolted values - original are 0x28 and 0x32. But every bit counts, especially on higher freqs.
Thanks for the tip
But what's more interesting - 900MHz works at 0x23 (didn't test that before - just took a voltage halfway between 800 and 1000)... there's something wrong with this ARM_100_OPP, but I don't know what yet... Will test the rest again later and post my results.
And thanks for the gpu voltage :good: , I actually use that value now :laugh:
Click to expand...
Click to collapse
Your welcome
When I have time, I'll try to write how to quickly check undervolting limits for both cpu and gpu.
Mk
mkaluza said:
It's a pity... but I understand that's only the S Advance branch of Carbon thats dead - the rom itself is being developed further?
Click to expand...
Click to collapse
Yes, only for our device. It's not really dead yet.
The dev has been kind enough compiling new one once in a while.
I didn't like the pie ;P But if you say it's ok, I'll give it a try when I'm in the mood to reinstall everything on the phone...
Click to expand...
Click to collapse
Yeah, I could understand that. Too much of a hassle. Got to reinstall everything back again.
But you know, I always do clean flash, even with nightlies. Imagine backing up, factory reset and restoring everything in every 3-4 days.
But now I get really used to it
Actually I didn't recheck those two and focused on lower freqs - these were the limits with older LiveOPP, but now I can go to 0x22 and 0x2c.
In fact, 0x24 and 0x2f are already undervolted values - original are 0x28 and 0x32. But every bit counts, especially on higher freqs.
Thanks for the tip
But what's more interesting - 900MHz works at 0x23 (didn't test that before - just took a voltage halfway between 800 and 1000)... there's something wrong with this ARM_100_OPP, but I don't know what yet... Will test the rest again later and post my results.
Click to expand...
Click to collapse
No problem man, thought that information would be useful to you.
Yeah, it would be really nice to go lower, especially on 1000 and 800.
I'm gonna test the rest, and later I would let you know the lowest working voltage that I can go.
And honestly, I have no idea about kernel stuffs :silly: The least that I can do is to play around with it
Your welcome
When I have time, I'll try to write how to quickly check undervolting limits for both cpu and gpu.
Mk
Click to expand...
Click to collapse
Yes, please do. I would really appreciate that :fingers-crossed:
Reinkaos said:
Yes, only for our device. It's not really dead yet.
The dev has been kind enough compiling new one once in a while.
Click to expand...
Click to collapse
He also left a repo with build scripts and manual, so I'll try to build the rom.
Yeah, I could understand that. Too much of a hassle. Got to reinstall everything back again.
But you know, I always do clean flash, even with nightlies. Imagine backing up, factory reset and restoring everything in every 3-4 days.
But now I get really used to it
Click to expand...
Click to collapse
That's hardcore ;P I have patience to do it 1-2 times a year
Yeah, it would be really nice to go lower, especially on 1000 and 800.
I'm gonna test the rest, and later I would let you know the lowest working voltage that I can go.
Click to expand...
Click to collapse
mine crashed at 1000MHz/0x2c - I'm on 0x2d now and it seems ok
And honestly, I have no idea about kernel stuffs :silly: The least that I can do is to play around with it
Click to expand...
Click to collapse
You could always learn It's fun, all the info is there to read for free... all it takes is will and time
Yes, please do. I would really appreciate that :fingers-crossed:
Click to expand...
Click to collapse
I still cant post links, so you need to go to my github (mkaluza), open the i9070_kernel_CoCore-E repo and go to wiki on the right - there is a page "Undervolting janice". Hope this helps.
Mk
mkaluza said:
He also left a repo with build scripts and manual, so I'll try to build the rom.
Click to expand...
Click to collapse
Well that's a good news :good:
That's hardcore ;P I have patience to do it 1-2 times a year
Click to expand...
Click to collapse
LOL yeah
mine crashed at 1000MHz/0x2c - I'm on 0x2d now and it seems ok
Click to expand...
Click to collapse
I'm not sure if mine is really stable, gonna test it with your guide on github
You could always learn It's fun, all the info is there to read for free... all it takes is will and time
Click to expand...
Click to collapse
Yeah, I am learning right now
I still cant post links, so you need to go to my github (mkaluza), open the i9070_kernel_CoCore-E repo and go to wiki on the right - there is a page "Undervolting janice". Hope this helps.
Mk
Click to expand...
Click to collapse
So there are scripts that will provide me with some infos when doing UV-ing
And I'm not familiar with registers though, I only do it via liveopp, but still I'll try this
Thanks for the guide
Anyway I got a question about gpu, lets say my mali low_boost is 400 and high_boost is 480,
does it use the two freq only or it use the other freq in between 400 and 480 too?
P.S. hey you could just spam in OT threads to get 10 posts
Reinkaos said:
I'm not sure if mine is really stable, gonna test it with your guide on github
Click to expand...
Click to collapse
If you don't get random reboots/crashes than it is - when following my guide, the resulting voltage should be stable, but it isn't always so... I'ts just a starting point that can save you some initial crashes or the other way around - if it doesn't pass freq_jump test, then it isn't stable for sure
Anyway I got a question about gpu, lets say my mali low_boost is 400 and high_boost is 480,
does it use the two freq only or it use the other freq in between 400 and 480 too?
Click to expand...
Click to collapse
Only those two - three actually - also 200MHz (that is low_boost/2), but with ape_50_opp voltage, not the one from dvfs_config. There's not much point in doing any smarter gov because gpu intensive apps usually load it at 100% no matter how much power it has - they just have more fps then.
.P.S. hey you could just spam in OT threads to get 10 posts
Click to expand...
Click to collapse
Yeah, maybe, but if those are the rules, then I try to respect them - because I respect the community. (not because I'm some kind of by-the-book guy ;P I ride motorcycle and have already broken so many rules, that they would put me behind bars for life if anybody kept the count ;P).
mkaluza said:
I ride motorcycle and have already broken so many rules, that they would put me behind bars for life if anybody kept the count ;P).
Click to expand...
Click to collapse
You like adrenaline, heh
PS: Sorry for OT
mkaluza said:
If you don't get random reboots/crashes than it is - when following my guide, the resulting voltage should be stable, but it isn't always so... I'ts just a starting point that can save you some initial crashes or the other way around - if it doesn't pass freq_jump test, then it isn't stable for sure
Click to expand...
Click to collapse
Hey, just letting you know, about opptop script, we don't have prcmu-qos folder in /debug. I thought maybe it have a different name, but I couldn't find ape_requirements and ddr_requirements. The others are working fine
Only those two - three actually - also 200MHz (that is low_boost/2), but with ape_50_opp voltage, not the one from dvfs_config. There's not much point in doing any smarter gov because gpu intensive apps usually load it at 100% no matter how much power it has - they just have more fps then.
Click to expand...
Click to collapse
Thanks for the infos :good:
Yeah, maybe, but if those are the rules, then I try to respect them - because I respect the community. (not because I'm some kind of by-the-book guy ;P I ride motorcycle and have already broken so many rules, that they would put me behind bars for life if anybody kept the count ;P).
Click to expand...
Click to collapse
LOL, I'm curious though, what bike do yo own? Must be a real badass one
Force said:
You like adrenaline, heh
PS: Sorry for OT
Click to expand...
Click to collapse
I'ts more about freedom and versatility, but yeah sometimes I like to push it too
Reinkaos said:
Hey, just letting you know, about opptop script, we don't have prcmu-qos folder in /debug. I thought maybe it have a different name, but I couldn't find ape_requirements and ddr_requirements. The others are working fine
Click to expand...
Click to collapse
I forgot... this feature was written by me, so it's available only on my kernel for the moment. But it's not really that important - it was more for debugging purposes for me, now I left it as informative.
I'm trying to build Carbon rom for out phone since last night... when/if I'm done, I'll patch the kernel with my stuff and push it somewhere. What is your kernel version? I think that both carbon and vanir use the same, or at least similar one.
LOL, I'm curious though, what bike do yo own? Must be a real badass one
Click to expand...
Click to collapse
Not really I't an old BMW F650 - only 48 ponies (of which some might have already died of old age ;P). But in reality you can do most of the fun stuff with as little as 125cc Anything bigger is usefull for longer trips/highways/trips with passenger/etc... I mostly ride small country roads and light offroad, so I rarely go over 100km/h, so no badass machine is needed something like 350cc would be best I think. Actually - it's not the bike you ride, but how you ride it... and on narrow roads with many turns a bigger bike is event sometimes harder to ride...
mkaluza said:
I forgot... this feature was written by me, so it's available only on my kernel for the moment. But it's not really that important - it was more for debugging purposes for me, now I left it as informative.
I'm trying to build Carbon rom for out phone since last night... when/if I'm done, I'll patch the kernel with my stuff and push it somewhere. What is your kernel version? I think that both carbon and vanir use the same, or at least similar one.
Click to expand...
Click to collapse
Well ok then. Vanir got a 3.0.101 kernel. It's the same I think? I'll flash and test it when you're done, definitely.
Not really I't an old BMW F650 - only 48 ponies (of which some might have already died of old age ;P). But in reality you can do most of the fun stuff with as little as 125cc Anything bigger is usefull for longer trips/highways/trips with passenger/etc... I mostly ride small country roads and light offroad, so I rarely go over 100km/h, so no badass machine is needed something like 350cc would be best I think. Actually - it's not the bike you ride, but how you ride it... and on narrow roads with many turns a bigger bike is event sometimes harder to ride...
Click to expand...
Click to collapse
lol the biggest one I ever been on is about 130 cc. It's small, enough that you could squeeze through traffics
I don't know much about bike, but AFAIK those superbike need different kind of handling too.
Let's speak just about this kernel as for this is meant this thread
Please anyone tell me how to find the kernel link . I`m a noob at this part :silly: Thanks
pictorul20 said:
Please anyone tell me how to find the kernel link . I`m a noob at this part :silly: Thanks
Click to expand...
Click to collapse
Go here and see download link at top of page: https://github.com/mkaluza/i9070_kernel_CoCore-E
Download link : http://goo.gl/FvqPlg
Then check OP to see how to install it.
Force said:
Go here and see download link at top of page: https://github.com/mkaluza/i9070_kernel_CoCore-E
Download link : http://goo.gl/FvqPlg
Then check OP to see how to install it.
Click to expand...
Click to collapse
Many Thanks.
Hi,
I'm finding the Play's microlags quite annoying. I'm using squid's CM port and with kernel adiutor I found out that all little cores are turned off be default, no matter which governor i use (I guess on purpose). It seems that as the battery empties, the little cores are being turned on and the big ones are turned off - which causes even way more mircolags.
I can't influence these settings. Does anyone know why or how to change this?
tempe
Buy another device, helps
tempe222 said:
Hi,
I'm finding the Play's microlags quite annoying. I'm using squid's CM port and with kernel adiutor I found out that all little cores are turned off be default, no matter which governor i use (I guess on purpose). It seems that as the battery empties, the little cores are being turned on and the big ones are turned off - which causes even way more mircolags.
I can't influence these settings. Does anyone know why or how to change this?
tempe
Click to expand...
Click to collapse
flash stock 6.0
tempe222 said:
Hi,
I'm finding the Play's microlags quite annoying. I'm using squid's CM port and with kernel adiutor I found out that all little cores are turned off be default, no matter which governor i use (I guess on purpose). It seems that as the battery empties, the little cores are being turned on and the big ones are turned off - which causes even way more mircolags.
I can't influence these settings. Does anyone know why or how to change this?
tempe
Click to expand...
Click to collapse
Better ask this in that thread. You would get relevant answers.
Sent from my XT1562 using Tapatalk
Thanks, but...
1. I can't write in the thread since I don't have enough posts for developers' threads yet
2. AFAIK, there is no German stock 6.0, or is there?
3. Is there no other way? Is this intended by CM or what?
tempe222 said:
Thanks, but...
1. I can't write in the thread since I don't have enough posts for developers' threads yet
2. AFAIK, there is no German stock 6.0, or is there?
3. Is there no other way? Is this intended by CM or what?
Click to expand...
Click to collapse
Hi. Please head to this thread http://forum.xda-developers.com/moto-x-play/general/moto-x-play-marshmallow-6-0-ota-t3267061 if you have not yet come across it already. I had the same issues and it has been completely solved. The phone is very smooth now.