yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Original Android Development] Joshr:
After 15 minutes on r140 I've had no drops in service yet.

Something else to not that may/may not be related: when calling my tmobile voicemail on r151 I couldn't get past the password prompt and it would only pick up one of the password numbers I was entering. I was able to use voicemail without a problem with r140.
[Nexus 4 Original Android Development] Danny.ns:
On stock, the CPU is lowered because the BATTERY temperature is above 39C. On stock, the phone doesnt really care about CPU or GPU temperature. It only cares about battery temperature. For example, again on stock, if battery temperature reaches 41C, the GPU clock is lowered to 200mhz (from 400mhz). This instantly halves the performance in games.

On francos kernel, the battery temp is ignored, and instead the cpu temperature is monitored. This is why your cpu is not down to ~1100 when you are playing vice city.
[Nexus 4 Original Android Development] mohitgalaxy3:
If you think brightness is low try adjusting according to your preference.

About colours I don't think that they are dull, they are perfect.

We are using too much punchy colors that even when I was working on it sometimes I felt the same but I have compared a lot and check gamma values they are just perfectly balanced and after using for a day. I don't find them dull/dark from a single point.
[Nexus 4 Original Android Development] fakudolan:
Rootbox!
[Nexus 4 Original Android Development] Drmol:
Hmm that's strange, I thought I read somewhere that it will start to throttle at about 55C CPU temperature. I probably misunderstood something.

So all in all that kind of heat should be perfectly safe for my phone hardware, correct?

Thanks again
[Nexus 4 Original Android Development] franciscofranco:
:)

Yes, of course its safe, its the temperature on the chip, not on the phone itself.
[Nexus 4 Original Android Development] blankit:
CPU can probably handle more heat than the battery.....the most logical reason for battery temp throttling is because overheating the battery reduces its lifespan considerably.
[Nexus 4 Original Android Development] trailblazerz11:
[MENTION=3292224]franciscofranco[/MENTION]

Seems main issue with new hotplug is medium tasks/ light games that are somewhat laggy with 1 core ideally needing another core but 2nd core is restricted to on touch.

My thoughts are that another threshold for counter to online the 2nd core like the 3rd and 4th. (i.e. counter about 4 online second core) would overcomplicate things and there would be overlap with the touch boost, causing 2nd core to be in quite a bit of chaos.

Simplest and in my opinion a path worth considering is simply have 2 cores always online when screen on. Wasn't there some conclusion in the quad core/ dual core experiments that simply onlining all cores wasn't all that bad for battery compared to constantly online/offline. I think morfic's kernel still just onlines all cores and doesn't bother with hotplug.

I modified your hotplug to implement 2 core always online and currently testing it to see how battery goes.

What are your thoughts on this franco?
[Nexus 4 Original Android Development] Drmol:
Thanks again guys, I'm still pretty new to all this so thanks for bearing with me lol. :D Seems like a great kernel, just bought the updater app myself. :)
[Nexus 4 Original Android Development] franciscofranco:
It seems that having 2 cores always online is a much better idea than adding another threshold level - I don't want extra complexity involved in such critical code path. Let me know how your experience worked out for you, I'm gonna do the same and see how it fares.
[Nexus 4 Original Android Development] rmead01:
If you are leaning towards having 2 cores online at all times, maybe there is a way to reduce how high the freq goes on both cores, since they can divide the work amongst themselves. That way, even though 2 cores are always on, they aren't both using a high freq demand unless really needed (gaming)
[Nexus 4 Original Android Development] franciscofranco:
Thats how it currently works, it barely hits max unless the cpu0 load is higher than 85%. And that dividing work between themselves is somewhat deceiving, it depends on the software implementation. Although I'm gonna reduce the input_boost_freq to 1026MHz during my test.
[Nexus 4 Original Android Development] rmead01:
cool. Been out of the code game for a long time. I just remember that on the r1111 opening candy crush was maxing all 4 cores even through there was low actual usage on them. Much prefer r151 where the cores come on when needed and drop when they don't. when you are staring at the level screen on candy crush, there really wasn't a need for 4 cores maxed. i've been enjoying where this has been going lately.
[Nexus 4 Original Android Development] -JFK-:
Hello,

Since R150, I have a lot of random reboot.

I have change nothing more than the Kernel with the same methode as usual.

If you ca have a look.

Thank you !
[Nexus 4 Original Android Development] trailblazerz11:
With 2 cores always on it seems report_load_at_max_freq() almost never goes past the DEFAULT_FIRST_LEVEL 70 (made me curious whether better performance from additional cores is related more to having more threads rather than more raw CPU power, which is odd since i thought android wasn't that great at optimizing multicores) , I've lowered it to 45-50 but not sure how to tune it properly. Don't wanna comment on performance until it better emulates r151.

Time to sleep for me though, I'll see how battery does tomorrow.

Thanks franco
[Nexus 4 Original Android Development] franciscofranco:
If you want to test, this is my diff:

diff --git a/arch/arm/kernel/mako_hotplug.c b/arch/arm/kernel/mako_hotplug.c
index f219d10..84e8c24 100644
--- a/arch/arm/kernel/mako_hotplug.c
+++ b/arch/arm/kernel/mako_hotplug.c
@@ -59,12 +59,10 @@ static void scale_interactive_tunables(unsigned int above_hispeed_delay,
static void decide_hotplug_func(struct work_struct *work)
{
int cpu;
- int cpu_boost;
- struct cpufreq_policy policy;

if (report_load_at_max_freq() >= stats.default_first_level)
{
- if (likely(counter) <= 50)
+ if (likely(counter < 50))
counter++;
}

@@ -74,27 +72,11 @@ static void decide_hotplug_func(struct work_struct *work)
counter--;
}

- if (is_touching)
- {
- for_each_possible_cpu(cpu_boost)
- {
- if (!cpu_online(cpu_boost) && cpu_boost < stats.cores_on_touch)
- {
- cpu_up(cpu_boost);
- /* we're interacting with the device, online cores are boosted
- to hispeed_freq at least for a sample */
- cpufreq_get_policy(&policy, cpu_boost);
- __cpufreq_driver_target(&policy, DEFAULT_CORE_ONLINE_BOOST,
- CPUFREQ_RELATION_H);
- }
- }
- }
-
if (counter >= 10)
{
for_each_possible_cpu(cpu)
{
- if (cpu && !cpu_online(cpu))
+ if (!cpu_online(cpu))
{
cpu_up(cpu);
}
@@ -105,11 +87,11 @@ static void decide_hotplug_func(struct work_struct *work)

else
{
- if (num_online_cpus() > 1 && !is_touching)
+ if (num_online_cpus() > 2)
{
for_each_online_cpu(cpu)
{
- if (cpu)
+ if (cpu > 1)
{
cpu_down(cpu);
}
@@ -119,7 +101,7 @@ static void decide_hotplug_func(struct work_struct *work)
}
}

- queue_delayed_work_on(0, wq, &decide_hotplug, msecs_to_jiffies(timer));
+ queue_delayed_work(wq, &decide_hotplug, msecs_to_jiffies(timer));
}

static void mako_hotplug_early_suspend(struct early_suspend *handler)
@@ -129,6 +111,7 @@ static void mako_hotplug_early_suspend(struct early_suspend *handler)
/* cancel the hotplug work when the screen is off and flush the WQ */
cancel_delayed_work_sync(&decide_hotplug);
flush_workqueue(wq);
+
pr_info("Early Suspend stopping Hotplug work...\n");

for_each_online_cpu(cpu)
@@ -167,7 +150,7 @@ static void mako_hotplug_late_resume(struct early_suspend *handler)
pr_info("Cpulimit: Late resume - restore cpu%d max frequency.\n", 0);

pr_info("Late Resume starting Hotplug work...\n");
- queue_delayed_work_on(0, wq, &decide_hotplug, HZ);
+ queue_delayed_work(wq, &decide_hotplug, HZ);
}

static struct early_suspend mako_hotplug_suspend =
@@ -226,7 +209,7 @@ int __init mako_hotplug_init(void)
return -ENOMEM;

INIT_DELAYED_WORK(&decide_hotplug, decide_hotplug_func);
- queue_delayed_work_on(0, wq, &decide_hotplug, HZ*25);
+ queue_delayed_work(wq, &decide_hotplug, HZ*25);

register_early_suspend(&mako_hotplug_suspend);

Also changed input_boost_freq to 1026MHz and First level threshold down to 60 to accomodate for less cpu0 load due to thread migration to cpu1 more often.
[Nexus 4 Original Android Development] Testraindrop:
Increase your voltage:

[ 1267.204467] msm_spm_drv_set_vdd: failed, remaining timeout 50us, vlevel 0xac

[ 1267.204620] saw_set_voltage: 8921_s6: msm_spm_set_vdd failed -5

[ 1267.204681] acpuclk-8064 acpuclk-8064: vdd_core (cpu1) decrease failed (-5)

[ 1267.214324] msm_spm_drv_set_vdd: failed, remaining timeout 50us, vlevel 0xac

[ 1267.214416] saw_set_voltage: 8821_s1: msm_spm_set_vdd failed -5

[ 1267.214477] acpuclk-8064 acpuclk-8064: vdd_core (cpu3) decrease failed (-5)
[Nexus 4 Original Android Development] franciscofranco:
[ 1267.204467] msm_spm_drv_set_vdd: failed, remaining timeout 50us, vlevel 0xac

[ 1267.204620] saw_set_voltage: 8921_s6: msm_spm_set_vdd failed -5

[ 1267.204681] acpuclk-8064 acpuclk-8064: vdd_core (cpu1) decrease failed (-5)

[ 1267.214324] msm_spm_drv_set_vdd: failed, remaining timeout 50us, vlevel 0xac

[ 1267.214416] saw_set_voltage: 8821_s1: msm_spm_set_vdd failed -5

[ 1267.214477] acpuclk-8064 acpuclk-8064: vdd_core (cpu3) decrease failed (-5)

Undervolting?
[Nexus 4 Original Android Development] trailblazerz11:
Thanks :)

I did mostly the same thing except I actually left cpu_boost(w/o the cpu_up) and didn't know what queue_delayed_work_on did.
[Nexus 4 Original Android Development] franciscofranco:
queue_delayed_work_on is simple, the _on part adds an extra argument to the queue_delayed_work function call where we can determine in which cpu the WQ queues que work. Since we're testing 2 cores always online we can let the system decide which core to run the work, probably the one with less load at X point in time.
[Nexus 4 Original Android Development] rmead01:
smells like r1222 in here ;)
[Nexus 4 Original Android Development] franciscofranco:
Sure, why not? :)
[Nexus 4 Original Android Development] rmead01:
lol, that's how rumors start.
[Nexus 4 Original Android Development] -JFK-:
Thank you.

Any idea why it happen since the r150 ?

It work just fine if I revert back to r148.
[Nexus 4 Original Android Development] franciscofranco:
Dunno, **** happens :)
[Nexus 4 Original Android Development] franciscofranco:
Here's r1222. Test away.
[Nexus 4 Original Android Development] ÜBER™:
Flashable
[Nexus 4 Original Android Development] goTouch:
Didn't imagine that change the input_boost_freq to 1350 would make such difference. I can say r151 with input_boost_freq at 1350 is one of the best francokernel version I ever used. I don't know the impact at battery life, but I'm very happy the way it is.
[Nexus 4 Original Android Development] Nummer35:
Recently got this antutu score: really Happy with this!!!! :eek:

Gesendet von meinem Nexus 4 mit Tapatalk 2
[Nexus 4 Original Android Development] GavinAshford:
I had a similar thing, I'm on O2 UK had never accessed my voicemail since they enforced a pin-code, but with the kernel's that kept disconnecting the radio (r150/r151 at least, possibly earlier, haven't tested in which it started) I had 2 people leave voicemails so I had to go in and setup a pin for the first time. I was typing and it was beeping on keyboard press but it just wouldn't accept it and kept saying it was invalid and try again (it seemed like the commands were not getting back to the other end). It took me like 20 attempts to do it (re-dialing each time) I'm guessing the last time I got a proper connection.
[Nexus 4 Original Android Development] prioxxx:
If you put the input boost freq to 1350,it affects the battery?

Sent from outer space
[Nexus 4 Original Android Development] goTouch:
It should. You are boosting the frequency in a higher level every time you touch the screen. But, maybe, this impact may be unnoticeable! Tomorrow I'm going to have some results.
[Nexus 4 Original Android Development] rmead01:
well I didn't have any issues with games on r151,

with the r1222 both cores stay online which was the goal. While gaming it seems decently distributed between the 2 cores, but rarely did 4 cores ever come online. I also burned through about 8-10% of batter playing 1 level of candy crush, 1 round of jetpack joyride, and 1 run through of into the dead.

Not sure what battery would normally be like because i'm not huge on gaming, but for the 5-10 mins i was playing it seems like a high loss.

personally, I think there has got to be a better way to help these low resource games without sacrificing standby. I just think 2 cores always online even for simple tasks has to take a toll on the battery somewhere.
[Nexus 4 Original Android Development] franciscofranco:
You just flashed it, just give it some time.
[Nexus 4 Original Android Development] rmead01:
you're the boss :highfive::good:

I was more referring to the 2 cores always on. It may have no impact, but gut feeling tells me over time it will. I'll put in some good normal use/idle time today with traveling.
[Nexus 4 Original Android Development] cmhjr:
Had similar problem last night with about 15% left on the battery. Would ask for Sim unlock code and after putting in code correctly it would appear after about a minute again. Could not find anything in log.

After it repeated a few times I just restarted phone and has not happened since. I am on stock except for kernel.
[Nexus 4 Original Android Development] psubadger:
I feel like an ungrateful user of such a fun kernel, but I figured that I should share some of the cell network problems that I've been having. Starting somewhere around the 143/146 range, I would have occasions where the cell signal would drop out (empty triangle with outline icon) where I know that I get strong service, and would reconnect in a few seconds. If this were the only problem, I would have left well enough alone, but it seems to have a nasty habit of happening when I'm in a phone call, so naturally the call gets dropped and I can't call back for a bit. Switching back to the Milestone fixes the problem, and the r148+ releases have helped, but the service interruptions are still frequent enough for me to revert to the Milestone. FWIW, I'm in the US, on ATT, and am running the stock ROM.

If there is a more rigorous way for me to test this, let me know and I'll gladly check, but otherwise, I'll try with newer nightlies, and can report if it's 100% fixed.
[Nexus 4 Original Android Development] manulemaboul:
I think input boost shouldn't be needed anymore with 2 cores always on.

Setted it to min freq, so far I see no differences.

Envoyé depuis mon Nexus 4
[Nexus 4 Original Android Development] kelah:
r1222 is really awesome. Absolutely smooth UI but cpu rarely ramps freqs over 1024.

Also I tried input_boost 702 and it is still smooth.

Franco, is it possible that thread stick on cpu0 (on r151) because cpu1 plugged in after thread started? Otherwise I don't know why r151 is little lagy with input_boost 1024 and r1222 is smooth with 702.
[Nexus 4 Original Android Development] franciscofranco:
I wouldn't say its not needed, but I'm sure its just fine using 702MHz.

Yes, that might be true.
[Nexus 4 Original Android Development] orangestrawberry:
On three UK. Lots of signal drops recently with Franco nightlies.

Just flashed to stock as I was getting a few other issues and still having signal drops so I doubt it's a kernel issue at all.

---------- Post added at 06:52 PM ---------- Previous post was at 06:51 PM ----------

And many thanks to Franco for his commitment to keep refining his work.

---------- Post added at 06:52 PM ---------- Previous post was at 06:52 PM ----------

And many thanks to Franco for his commitment to keep refining his work.

---------- Post added at 06:52 PM ---------- Previous post was at 06:52 PM ----------

And many thanks to Franco for his commitment to keep refining his work.

---------- Post added at 06:53 PM ---------- Previous post was at 06:52 PM ----------

And many thanks to Franco for his commitment to keep refining his work.

---------- Post added at 06:53 PM ---------- Previous post was at 06:53 PM ----------

And many thanks to Franco for his commitment to keep refining his work.
[Nexus 4 Original Android Development] baza14:
Could you do something with your quotes, please? It's not first time nor third time I see this.
[Nexus 4 Original Android Development] orangestrawberry:
Wow, you're right. Not done that before tapatalk beta!
[Nexus 4 Original Android Development] javacody:
I'm getting lots of signal drops with the latest nightlies as well. TMobile USA.
[Nexus 4 Original Android Development] zephiK:
It's a tapatalk 4 bug with quoting and editing.
[Nexus 4 Original Android Development] z3r0_x:
R1222 is indeed really smooth, even smoother than r151 with bumped up frequencies! Good job! Can't comment on the batter drain though
[Nexus 4 Original Android Development] David_Vaz:
I'm loves this kernel <3 xD
[Nexus 4 Original Android Development] zadrozny91:
What is r1222? Is it newer than r151? And where can I download it from?
[Nexus 4 Original Android Development] PetritH:
its a test kernel, its newer than r151, look few pages back franco posted the boot.img
[Nexus 4 Original Android Development] int abacus:
page 3558 for r1222... r151 is an official nightly... r1222 is for testing
[Nexus 4 Original Android Development] Testraindrop:
Franco I think 2 Cores with lower frequency is beneficial to one core at higher frequency,at least thats my feeling (I don't care if I lose 1% more battery because of it).

And with Android 4.3 it will be even more beneficial, the guys said at the IO that they will be running multiple threads for UI stuff :)
[Nexus 4 Original Android Development] lorolouis:
It looks like most people care how smooth the animations and games are with newest kernel ...

The rest of us - we obviously ask too much :) to be sure we cam use our N4 as a phone, too.

This was a joke, of course.

This kernel is still the best of the bestest around (you may need to go 50 releases up an down to find yours, but it is still the best one, believe me)!

:good:
[Nexus 4 Original Android Development] sNoxious:
I'm sorry to ask this but what are the changes or improvement on the latest r1222 test kernel?

Sent from my Nexus 4
[Nexus 4 Original Android Development] manulemaboul:
Right, some lil stutters with 384, perfect with 702. :thumbup:

It doesn't even seems to drain more to have the 2nd core always on (but too soon to be sure), I wouldn't be surprised to see It draining less actualy.

I'm almost sure onlining a core does a current spike and drains more than leaving him online at min freq. :)

Envoyé depuis mon Nexus 4

---------- Post added at 09:54 PM ---------- Previous post was at 09:52 PM ----------

See ? Our beloved dev already anticipated 4.3 :p

Envoyé depuis mon Nexus 4
[Nexus 4 Original Android Development] vjales:
The main is insted of ever enabled only cpu0, it will be enabled cpu1 too. Resuming: cpu0 and cpu1 ever online. This can/will result on smaller frequencies for input_boost if I read right.

--EDIT--

In the first 5 minutes using the r1222 I just have 1 word to say: AMAZING! Keep up on this good job franco!
[Nexus 4 Original Android Development] DangerMUK:
Is it normal to get Phone Idle @ 20% over 8hrs36mins and being the top battery resource showing ?

First time I haven't had great battery from Franco Kernel (haven't installed any new/different apps since) and I'm on R151
[Nexus 4 Original Android Development] zephiK:
Unknown. It's a blind biased test
[Nexus 4 Original Android Development] ÜBER™:
:D
[Nexus 4 Original Android Development] chuimk:
WiFi performance

I only recently noticed the WiFi issue with my Nexus 4 and then found out about all the fuzz around it. I was playing with my home router configurations and say the RX rate practically locked at 6M while RX rate is at least around 50M.

During my research I found out that this was identified to be a problem with the WiFi Qualcomm drivers (apparently confirmed by Google engineers) and that some newer driver was unofficially released and integrated at least to one another kernel.

Searching through this (long) thread history, I understand that Franco chose to wait for the official Google fix as he has past issues with trying to use beta versions of the drivers. So, in the meantime, how are people dealing with this issue? I read about the change-MCastBcadtfilter-fix but does it really screw up battery life? Are there other solutions?

Thanks for any help...
[Nexus 4 Original Android Development] sNoxious:
There's a version of Franco's Kernels with Prima Drivers in it, you could try that if you want.

Sent from my Nexus 4
[Nexus 4 Original Android Development] z3r0_x:
There's Franco's kernel with Prima here: http://xdaforums.com/showthread.php?t=2272140

But for the love of god, if you flash back to normal Franco, flash the Reset Kernel first - too many people in this thread seem to forget this and whine about their WIFI not working. :silly:
[Nexus 4 Original Android Development] Luigiesin:
Hey Franco... So with the new test boot two cores stay on Ile all the time while screen on?

Seems like a good idea!

Sent from my Rock & Roll Nexus 4 \m/

ROM: PA 3.60

Kernel: Franco r146-Linaro

T-Mobile
[Nexus 4 Original Android Development] X DoZ3R:
Absolutly like the new test kernel :) smooth UI as hell, keep up the good work franco

Tapatalk 2-vel küldve az én Nexus 4-ről
[Nexus 4 Original Android Development] steviewevie:
Bear in mind that these patches were not specifically designed for the N4, they are for Qualcomm's chipset test platform.

Sent from my Nexus 4
[Nexus 4 Original Android Development] pikachukaki:
First of all curse you franco for not leting me at least for a day to test other kernels!second of all the 1222 its great im not sure how it will be for battery life to have 2cores on all the time!and something else i saw that while playing a game not heavy it was difficult to get 4cores enabled but now while im typing here all for cores are enabled and with pretty good load
[Nexus 4 Original Android Development] kelah:
Hm, I think r1222 is smoother (it have sompletely smooth animations), but r151 loading apps faster (and new activities in apps).

When you open apps from scratch, tap on "apps" in settings, open dialog in whatsapp, open image in gallery, tap recents button - with r1222 it is longer.

Franco, if threads are not stick on cpu0 with r1222 might it be UI animation rendering on boosted cpu0 and not boosted cpu1 loading apps? And because of that it loading longer.
[Nexus 4 Original Android Development] steviewevie:
Any Ingress players out there who have found specific optimisations work well for performance? I suspect that because there's so much going on in Ingress and the GPS and data connection that the defaults are fine.

Sent from my Nexus 4
[Nexus 4 Original Android Development] CaspaTheGhost:
You don't, its a myth.

Sent from my Nexus 4

---------- Post added at 01:17 AM ---------- Previous post was at 01:10 AM ----------

No, complete rubbish and the reason this myth still exists and always will exist is because of useless posts like this.

Sent from my Nexus 4
[Nexus 4 Original Android Development] TheByteSmasher:
Did you read what I said or only look to flame me? It does give accurate representation of battery from a given point. I didn't say anything about getting better battery life.
[Nexus 4 Original Android Development] slowpc:
R22 has been running since I got up this morning and so far ... its 8pm and with 45 minutes screen on , only down to 73% ! Even in a yellow/red area of signal quality.

Loving it so far!!! Like all of them!
[Nexus 4 Original Android Development] CMNein:
Final numbers are in, and please don't ask for screen capture evidence ;)

My msm_hsic wake lock has been reduced by 96%.

7 hours on r21 (on WiFi) = 25.X minutes wake lock

7 hours on r22 (on WiFi) = 56 seconds