yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Original Android Development] Harsh:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Where is it throttling and giving you slow speed/ shutters? Hope it's not benchmarks ;)

For me there is nothing more intensive than NFS, and it runs smooth even when playing for an hour straight.

Sent from my Nexus 4
[Nexus 4 Original Android Development] more2come:
No, not benchmarks! :D When I'm playing Beach Buggy Blitz for a while, it tends to get a little sluggish. When I check CPU stats, it throttled down to around 1.1 GHz, utilizing 2-3 cores.
[Nexus 4 Original Android Development] grisha1:
AW: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Ski Challenge, same behavior as above. Does not happen with motley...

by N4 via Tapatalk
[Nexus 4 Original Android Development] Harsh:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Installing both games and will see. If it throttle, maybe I can raise by 5 degrees.

Sent from my Nexus 4
[Nexus 4 Original Android Development] grisha1:
AW: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Careful, it's highly addictive. Your kernel development will suffer :p

by N4 via Tapatalk
[Nexus 4 Original Android Development] zevim2005:
When i change the minimum frequency on tricksterMOD from 1026 to 384 and apply it change,but when i entry tricksterMOD again its back to 1026? what could it be?
[Nexus 4 Original Android Development] more2come:
That might be due to Qualcomm's mpdecision. Touching the screen boosts the minimum clock frequency to increase UI fluidity.
[Nexus 4 Original Android Development] pitjago74:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

You have to apply after you change the minimum.....LOW works perfect On my "nominal"

www.teregalounpoema.com
[Nexus 4 Original Android Development] -Asskicker-:
My phone is getting a bit hot lately, after using it for about half an hour on 3G. I checked with System Tuner and the CPU gets around 45 degrees.

And it just feels hot in my hand and when I put it back in my pocket.

Is that normal, or is there something going on?
[Nexus 4 Original Android Development] gianton:
Harsh,

Could you please upload a boot.img of the Jan 28 LOW rel?

Thanks
[Nexus 4 Original Android Development] ckret:
just take the boot.img out of the zip file

easy as that
[Nexus 4 Original Android Development] gianton:
There is not a boot.img in the .zip file.
[Nexus 4 Original Android Development] Harsh:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

I did not make boot image of low one.

:confused:

With pack one when I get to my computer.

Zip is anykernel type, so no boot image inside. Only kernel zimage.

Sent from my Nexus 4
[Nexus 4 Original Android Development] gianton:
Thanks my friend. BTW with my faster binned CPU the LOW rel is rock stable (tested with navigation 2+ hours, games, browsing, calls, skype etc.).
[Nexus 4 Original Android Development] zevim2005:
so,what can i do to fix?
[Nexus 4 Original Android Development] albundy2010:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Its not broken. Use another kernel that doesn't use it. Which is all of them I belie
[Nexus 4 Original Android Development] ftarules:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

I'm getting the best battery life I've had with this phone so far. Granted it's all on Wi-Fi but I couldn't get this kind of battery life with any of the other kernels. Thanks. Didn't adjust any settings. Just your default ones that came out of the box.
[Nexus 4 Original Android Development] Harsh:
Here is download link from google drive

https://docs.google.com/open?id=0B4HkPoHdupAmRk1FajBiZzhrdzQ

Its always in my signature google drive and dev-host for now. Mediafire later if needed.
[Nexus 4 Original Android Development] JmPTaz09:
Latest kernel running well with rasbean jelly ROM; very nice! Underclocked to 1.35ghz and still really smooth; will see if I can pull some good battery life. :beer:

Colors look really nice on my device also!
[Nexus 4 Original Android Development] zhuozhi211:
Battery Life on Build 2712

Might be irrelevant already since there is a newer build now!

Anyway this was my 1st full cycle with Harsh kernel... again on the older Build 2712.

My Setting:

Kernel: Default Harsh Build 2712, NO tweak was made

ROM: Stock Deodexed

Data: WIFI on at home, Mobile Data outside from home, NO data at night (when sleep)

Other Connections: NFC on during the day, base station location service (no GPS)

Brightness: Manual at 20% during the day, 15% evening, 10% at night

General Usage: G Reader, Gmail, Whatsapp, Facebook, XDA, browsing, a few calls...

** automated via AutomateIt Pro **

Result

From Full Charged to 4% - 21 hours (9 hours was over night)

Screen On Time - 3 hours

Stand By battery drain - about 10% 9 hours over night

I think it scored fair in term of battery life. Though as someone pointed out the stand by time can be better...

Positive thing was that I did not get another hang (screen touch dead) since the last one. General usage was smooth, screen color setting was pleasing.

AGAIN, it was on the older build. I hope the later Build 2812 will be better! Flashing it NOW!
[Nexus 4 Original Android Development] Birba:
I'm running your latest kernel. While charging cpu is always at 1512mhz, no deep sleep.

Is that normal?
[Nexus 4 Original Android Development] JmPTaz09:
You don't get deep sleep while charging and I just checked and mine is not staying at 1.5 while charging; it is scaling normally. You may want to reflash and clear any kernel control apps you have.
[Nexus 4 Original Android Development] Harsh:
It must be some of your apps, i got 90% deep sleep for testing.

New version uploaded, hopefully should give better battery on HSDPA network, thats what caf said :fingers-crossed:

Changelog Build 2912:

test for HSDPA battery consumption

Probably last version for year 2012 (going Paris tomorrow)

Happy New Year....​

Download link in OP, my signature Dev-Host and also in google drive.

Happy New Year guys and girls ....
[Nexus 4 Original Android Development] aragorn7:
@lightningstalon: I can second zhuozhi211's results except I would say that the battery life is GREAT rather than just a fair. ;) My sense is that battery life tests all depend on usage and every user is different. My N4 with Harsh's kernel is great combination and a daily driver for me. My two cents fwiw.
[Nexus 4 Original Android Development] evie12604:
Looks like you've not used it. What's screen on time?
[Nexus 4 Original Android Development] JmPTaz09:
All is well so far on the 2912 kernel so far; thanks and happy new years to come :beer:
[Nexus 4 Original Android Development] Harsh:
New version 3012 uploaded

Changelog Build 3012

better 3g battery proven from last version

Better cpufrequency management

Changes to Omdemand for above :good:

last version for year 2012

Happy New Year.... Once again :laugh:​

Download link in OP as always, also in my dev-host folder and google drive too.

Been using kernel with above changes since morning 9 hours standby, 2h 33m 59s screen on and still 67% battery remaining. :cowboy:

Using mostly Browser and Tapatalk and just 1 race on NFSMW. No changes to frequency or anything, just sweep2wake disabled for testing.
[Nexus 4 Original Android Development] yyz71:
Nice and smooth:good:
[Nexus 4 Original Android Development] mgear356:
Weird that I am getting auto restarts on 3013 version.. It's up fine but reboots after 2mins+ of usage
[Nexus 4 Original Android Development] jarjar124:
is that 2h 33m on wifi??
[Nexus 4 Original Android Development] Harsh:
can you get me dmesg last_kmsg as you got 2 mins to use. And also keep logcat running after boot. we could find your problems.

Yes...
[Nexus 4 Original Android Development] eep2378:
@Harsh. Nice work on 3012. Feels smooth and stable. I'm noticing that only the 384mhz step is being used(cpu spy)? Flashed stock kernel first.
[Nexus 4 Original Android Development] Harsh:
It should use all steps as its using still same mpdecision (stock binary) which jump to 1 GHz on touch.

But when its smooth, I would not mind 384 mhz either :D
[Nexus 4 Original Android Development] eep2378:
I'm not sure if it CPU spy not reporting correctly(never happened before).

Sent from the Nodes of Ranvier
[Nexus 4 Original Android Development] Harsh:
For me is going to all frequencies.

Check this trickster mod screenshot.

Note: trickster mod updated to have lot more. Vibration strength, sweep2wake, voltage, color and lot more. I use it to disable sweep2wake when testing.

Sent from my Nexus 4
[Nexus 4 Original Android Development] eep2378:
Hmm.....checked system tuner and I'm seeing the same thing

Edit: Just checked trickster mod and indeed, the other freq are being used. It seems its being reported a little differently as before. Example, when leaving phone unused for a bit and checking deep sleep. It sleeps like normal and reports deep sleep numbers and 384mhz ONLY. Before it would show the former as well as all the other unused frequencies(up to the set max freq).
[Nexus 4 Original Android Development] Harsh:
I am glad it works. Let me know how you experience battery life in this kernel.

Sent from my Nexus 4
[Nexus 4 Original Android Development] zevim2005:
I think that donate version have the option to lock frequency....im trying now.
[Nexus 4 Original Android Development] undercover:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

It's not normal. What version are you using? Check your UV, and make sure nothing is running in bg. Using it on 3G will heat it up, and 46c doesn't seem like too much tbh, I constantly run at 37-38 on wifi when in use. Not even talking about running games....

Edit. Just ran temple run 2 for 5 mins, temp stayed at 36c. Running - 100mV version with no extra UC.
[Nexus 4 Original Android Development] gianton:
I noticed the same issue with Trickster Mod app. Either don't use an app to control this kernel or use faux clock app (paid app in play).
[Nexus 4 Original Android Development] Harsh:
There is nothing to fix, its working perfect.

Yes indeed true.

Dont use anything to lock frequency, let it work as it is.

No need to lock frequencies in this kernel, right?
[Nexus 4 Original Android Development] clandes:
The only reason why I use Faux clock app is the gamma control. My screen never looked better *G* New kernel works as flawless and smooth as ever. Using it with AOKP gives me the best performance and battery life ever :good:
[Nexus 4 Original Android Development] gianton:
No not needed, but if you want to change the frequencies or UC with Trickster Mod app the min freq stays at 1026MHz even if you've had it applied at 384MHz.

2nd full discharge with Liquidsmooth Beta v3.2/Harsh Jan 28 LOW UV rel (stock settings).
[Nexus 4 Original Android Development] zevim2005:
ok understood
[Nexus 4 Original Android Development] Alex0901:
This doesn't work for me...

adb shell dmesg | grep PVS
[ 0.873920] acpuclk-8064 acpuclk-8064: ACPU PVS: FAST

see attachment..
[Nexus 4 Original Android Development] gianton:
"adb shell" not needed when you're in terminal.

Try:

su
dmesg | grep PVS
[Nexus 4 Original Android Development] Harsh:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Reboot phone and if you use terminal don't need to adb shell

Just type su and then dmesg | grep PVS

Sent from my Nexus 4
[Nexus 4 Original Android Development] Alex0901:
Does it mean I have a nominal Chip??
[Nexus 4 Original Android Development] gianton:
Not showing anything.

Try this:

su
dmesg | grep acpuclk

It should give you this:
[Nexus 4 Original Android Development] grisha1:
Reboot first may help. This doesn't say anything.
[Nexus 4 Original Android Development] more2come:
Should perform a fresh reboot before you try to access that system log.
[Nexus 4 Original Android Development] Alex0901:
Thx now it Works...

I have a Fast Chip..
[Nexus 4 Original Android Development] pitjago74:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

I do have the nominal....whats the difference??

www.teregalounpoema.com
[Nexus 4 Original Android Development] more2come:
Nice, consider yourself lucky, fast and faster have a higher UV-tolerance and tend to produce less heat <=> battery lasts a little longer!
[Nexus 4 Original Android Development] -Asskicker-:
Mine says: Faster, what does that mean?
[Nexus 4 Original Android Development] gianton:
Higher UV, more battery life, less heat with full load on CPU.
[Nexus 4 Original Android Development] trueblueram:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Edit
[Nexus 4 Original Android Development] :
You just quoted the answer and some other guy repeats the answer mindlessly :silly:
[Nexus 4 Original Android Development] Pedro Peguero Jr.:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Mines FAST :D
[Nexus 4 Original Android Development] -Asskicker-:
lol. I was wondering if "Faster" was even better than "Fast". :)

Logic dictates yes, but you never know...
[Nexus 4 Original Android Development] DowntownJeffBrown:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

I have a nominal too don't worry about it. Just means you can't UV as much.

Sent from my Nexus 4 using Xparent BlueTapatalk 2
[Nexus 4 Original Android Development] undercover:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Yup. Slow-nominal-fast-faster

Mine's faster too.
[Nexus 4 Original Android Development] -Asskicker-:
I saw that you monitor temperature frequently, how hot does your CPU get with normal usage?
[Nexus 4 Original Android Development] pitjago74:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

But I got the 28 LOW:D

www.teregalounpoema.com
[Nexus 4 Original Android Development] eep2378:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

No need to brag. :p;)
[Nexus 4 Original Android Development] undercover:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

AK, my temp hovers around 37-38 when using normally with - 100 to -150mV and doesn't raise that fast when using phone intensively. On stock it hovers at about 42 and shoots up in a heartbeat.
[Nexus 4 Original Android Development] DowntownJeffBrown:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

I can under volt to -50 to -75 and not see any I'll effects on a nominal bin. But I find that with Harshs kernel runs best for me when I just leave it alone.

Sent from my Nexus 4 using Xparent BlueTapatalk 2
[Nexus 4 Original Android Development] _motley:
I received your PM. I am not trying to be a jerk, I am just trying to explain something you are not understanding. I understand how you "feel" about two interfaces and think they are the same, but you still don't understand the checksum and how it affects users trying to use the interface (instead of an app that calculates the checksum on the fly). You are reading the code, not debugging it, so you don't see the difference.

For users it has to be simple and it has to be correct on every line. In the example you gave, you are 100% proving my point that you do not understand how it works. The checksum you give in your example is 383. This is

not

correct for faux's original interface. It will only work for my interface.

echo "383 114 21 118 0 0 0 80 48 2" >
/sys/devices/platform/mipi_lgit.1537/kgamma_r

For faux's interface it would need to be:

echo "127 114 21 118 0 0 0 80 48 2" >
/sys/devices/platform/mipi_lgit.1537/kgamma_r

Once you understand the 127 checksum, you will understand why I did what I did. If you understand C datatypes, you can easily run a simple test to understand what is happening when you use a char vs int in a running sum.

Again, I am am not trying to create bad vibes between us, but it is very frustrating when someone is bashing your work publicly, but they are not thinking clearly. I suggest you create a simple C program, debug it, and learn how it is working. Again, faux gets all the credit for the gamma control, I am just making it easy for people to use without an app.

According to harsh, the sysfs in his kernel is already there. This is true, but it is not easy to use from a script unless you understand how to calculate the checksum.
[Nexus 4 Original Android Development] Harsh:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

First of all I did not even change example. Is same as from your github just removed ed from red.

Second, believe or not, checksum is not for user, is for verification. And third, gamma can be changed even without those checksum calculation, just changing amp0 and amp1.

You stick to your logic, I stick to mine. Once again I quote changing checksum does not make it GENERIC. Instead of writing whole repetitive code you could have made one simple post in xda making user understand that if values of sum is higher than 255 than they need subtract 256 from it. Anyways you are giving them advanced **** to mess with and add up 9 values to get one, why not just tell them to use calculator and subtract 256 from their total.

Sent from my Nexus 4
[Nexus 4 Original Android Development] eep2378:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

I thought dev conference took place in gtalk? :p;):cool:

In any case, very interesting discussion, carry on :D
[Nexus 4 Original Android Development] _motley:
Understood, but the example was incorrect for faux's interface. It is confusing and would not work in the real world.

If users are creating scripts without an app, it still has to entered for each line correctly by the user, or it will not pass verification.

Please show us how to do this. It will not work. The checksum needs to be changed every time you change amp0 and amp1 for a gamma color line, or it will not store the values into the internal structure.

From the original code. amp0 and amp1 are included in the checksum calculation.

if (calc_checksum(kgamma)) {
kgamma[0] = 0xd0;
for (i=0; i<10; i++) {
//pr_info("kgamma_r_p [%d] => %d \n", i, kgamma[i]);
faux123_power_on_set_1[5].payload[i] = kgamma[i];
}

kgamma[0] = 0xd1;
for (i=0; i<10; i++) {
//pr_info("kgamma_r_n [%d] => %d \n", i, kgamma[i]);
faux123_power_on_set_1[6].payload[i] = kgamma[i];
}
}

Agreed, but why not be cool about it? This is your thread, but you decided to bash me in it. It is obvious to me that you didn't fully understand the interface and the checksum until I pointed it out. I'm sure you will argue differently because you don't want to admit it. I have children, I know when people are BS'ing their way threw things to save their pride. You may fool others, but you don't fool me. Maybe "generic" was not the correct term, I already agreed with you on that. What should I have called it? I have no idea...the commit title is silly to argue about. I needed a name to differentiate it from faux's interface that I wanted to keep intact as-is for his app or any other app that may want to use it.

I decided to make it easier for my users. I already have users that are not sure about using the new interface how it is now, let alone to worry about another calculation. A simple sum is easier for hackers and scripters to work with as they try different combinations via adb and still keeps them honest in thinking about what they are doing. This stuff may be advanced, but that is for owners of the device to decide. I am not forcing anyone to do gamma adjustments, UV, OC or whatever. They are responsible for their own actions and can decide this for themselves after they have read my disclaimer. If it was so dangerous and already so easy to hack, you wouldn't have allowed the interface into your kernel.
[Nexus 4 Original Android Development] Harsh:
Use this as a checksum routine

static bool calc_checksum(int intArr[]) {
int i = 0;
int chksum = 0;

if (intArr[5] > 31 || (intArr[6] > 31)) {
return false;
}

for (i=1; i<10; i++) {
if (intArr[i] > 255 || intArr[i] < 0) {
return false;
}
else
chksum++;
}

// true only if all 9 checked values are accepted
if (chksum == 9)
return true;
}

Just change this in faux's code and it would be REAL GENERIC gamma control. Can be used with app and also with script and all.

Only 9 values are changed, address remain as usual :D... isnt that simple solution?

No need to have double interface, no double coding. Just change checking mechanism a bit :D

And above value checking for amp0 and amp1 and also max 255 is your code. Beautiful
[Nexus 4 Original Android Development] _motley:
This is actually very much like what I did in my first test. But, I decided to keep his interface as-is and honor the checksum he passes and not just ignore it. Simple as that. If the interfaces change in the future, then fine, we don't need to worry about breaking or testing the faux interface during regression testing. They stand alone. You can disagree, that is fine with me. Just not sure why you felt the need to lash out at what I was doing with several invalid assumptions.

Since you didn't respond, I'm assuming you agree on the other points where your logic was incorrect. The the original interface can't be utilized without the checksum. And since you posted the code above, it sounds like you are also conceding on having the checksum being a bit simpler for users. Now we are getting somewhere...no apology necessary;)
[Nexus 4 Original Android Development] Harsh:
Hey I am replying :D...

First of all, i am against use of kgamma_red as name, if you implement your whole code as improvement to faux's code it would be fine.

Because when you use different names and double functions for same thing. It breaks the flow.

So instead of you copy pasting whole faux's code, and changing names for just checksum, you could have just improved faux's checksum. By this all could have same interface and also work on fauxclock.

What happens if someone set init.d script with gamma using your kgamma_red, and than use fauxclock to set new amp values? Which value persist after screen on/off cycle?

As you are creating whole new sysfs interface, it creates new control interface making it confusing to kernel itself, not just users.

And whats wrong in improving faux's checksum? nothing. Thats what community is for, improve on what we have.....

So instead of re-inventing wheel you could have just improved old code. And we all could benefit (cherry-picking)

This is perfectly working, and also generic checksum routine

static bool calc_checksum(int intArr[]) {
int i = 0;
int chksum = 0;
int final = 9;

if (intArr[5] > 31 || (intArr[6] > 31)) {
return false;
}

for (i=1; i<10; i++) {
if (intArr[i] < 256) {
chksum += 1;
}
}
if (chksum == final) {
return true;
} else {
return false;
}
}
[Nexus 4 Original Android Development] undercover:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Harsh I have a request if you have time and will to do it. Since day one of custom kernel I wanted to try stock kernel with custom voltage table. Or just plain -100/-150mv. Would you (or anyone else) be able to build that? I know I know, I'd be back on yours in no time due to wakelocks and optimisation, but I'm really really curious how it would run.

Ta :)
[Nexus 4 Original Android Development] Harsh:
Sure I build one. But no uv on default, would just enable voltage control, and you can lower them as you want to try. If that okay?

And guys, after some heated productive conversations with motley, we finally have sysfs interface for Gamma, which dont require to add or subtract anything. Also its no double, so 100% further adjustable and compatible with fauxclock.

If you make init.d script with gamma values 255,255,255 0,1,2 3,4,5 and open fauxclock it would display your gamma which was set by init.d script, and you can start adjusting from there. (no need of fauxclock though)

Its good thing sometime when devs argue, and end up with something better :D... Thanks to motley for his detailed reply and added checks in checksum routine :D
[Nexus 4 Original Android Development] xdviper:
Hey Harsh, Got the low kernel on my stock rom, running fine but, is it normal that the minimum clock is at 1.02ghz whenever I check it with System Tuner? I put it down to 384mhz and then it goes right back up to 1.02ghz. Is that normal?? I don't have any other cpu program installed except for System Tuner on this phone. Thanks.