[hlte][2014/DEC/07][CM11/12] Yank555.lu kernel v1.1c-beta6

[ezaechiel]

It's done with the log plug-in, thanks yank

Envoyé de mon SM-N9005 en utilisant Tapatalk

[zancum]

Hello

I compiled a kernel for TW rom, with your commit Hardlimit 2.0
Everything works as expected, except that, I can not change the value of:
/sys/kernel/cpufreq_hardlimit/wakeup_kick_freq
It's a bug in my port, or there is also in your kernel?


regards

[yank555]

Hello

I compiled a kernel for TW rom, with your commit Hardlimit 2.0
Everything works as expected, except that, I can not change the value of:
/sys/kernel/cpufreq_hardlimit/wakeup_kick_freq
It's a bug in my port, or there is also in your kernel?


regards

Oh... you're right

I'll have a look later tonight, guess a 2.0a is ahead of us

JP.

Send from my 'proudly eFused' Note 3 (n9005) running Temasek v85 on Yank555.lu htle v1.0b-beta8 (3.4.92) kernel.

[yank555]

Hello

I compiled a kernel for TW rom, with your commit Hardlimit 2.0
Everything works as expected, except that, I can not change the value of:
/sys/kernel/cpufreq_hardlimit/wakeup_kick_freq
It's a bug in my port, or there is also in your kernel?

regards

In fact, it's normal, wakeup kick freq. needs to be higher than screen off max and lower than screen on max.

But you're right, that's kind of stupid, who cares about screen off limits, wakeup kick only kicks in during wake up, hence screen on

v2.0a will be updated, wakeup kick freq. will need to be higher than screen on min and lower than screen on max, that pretty much makes sense, you don't wake to kick "out of the user requested range"

Thanx for letting me know !!

JP.

[yank555]

Hello

I compiled a kernel for TW rom, with your commit Hardlimit 2.0
Everything works as expected, except that, I can not change the value of:
/sys/kernel/cpufreq_hardlimit/wakeup_kick_freq
It's a bug in my port, or there is also in your kernel?

regards

Here is the 2.0a commit : https://github.com/yank555-lu/N3-CM-Uni ... 340301efc0

JP.

[zancum]

Hello

I compiled a kernel for TW rom, with your commit Hardlimit 2.0
Everything works as expected, except that, I can not change the value of:
/sys/kernel/cpufreq_hardlimit/wakeup_kick_freq
It's a bug in my port, or there is also in your kernel?

regards

Here is the 2.0a commit : https://github.com/yank555-lu/N3-CM-Uni ... 340301efc0

JP.

quick and deadly

Thanks for your work. Tomorrow i will try the new version

thanks


EDIT:
Done and perfect

[yank555]

CM11 Beta Kernel Update

On user request I've affed wireless charging to fast charge (untested by me as I cannot test this by lack of the necessary equipment...).

Hardlimit has a tiny bitsy update, nothing important, just wakeup_kick_freq sysfs refusing values below screen off max, this has been the case since wakeup kick was introduced.

Linux is updated to 3.4.92.

Changelog CM11-20140517-hlte v1.0b-beta8 (09/06/2014)

• updated CPU freq. HardLimit to v2.0a : fixed wakeup_kick_freq must be between screen on min and max, instead of screen on max and screen off max (Yank555.lu)
• updated Forced Fast Charge for AC/USB/WIRELESS to v1.2 - added wireless support (Yank555.lu)
• updated to kernel.org Linux 3.4.92

• Yank555.lu-CM11-hlte-v1.0b-beta8.zip

  (MD5 e81db8ec83f52f702ea41d7007bb76a9)

  (10.14 MiB) Downloaded 1049 times

[zancum]

Hello

I'm back. please do not kill the messenger.

In my port, I have a new bug. See, if you can reproduce it:
I always have a reboot, in these conditions:

1 - When screen on max frequency = 2.8 GHz
2 - Lock userspace DVFS = Refuse or Ignore

If you are running a test AnTuTu during "testing integer performance" before finalizing the 14% you have always a reboot.


Below, you have a dmesg, I hope it is useful.
https://dl.dropboxusercontent.com/u/12990963/dmesg


regards

[ezaechiel]

Hi yank, as we discussed before here is the sensor log after the phone app problem I had this morning with Cm M7 snapshot and yank kernel.

https://www.dropbox.com/s/n3hspxv2wwvtv ... sensor.txt

Thanks for your help

Envoyé de mon SM-N9005 en utilisant Tapatalk

[yank555]

Hello

I'm back. please do not kill the messenger.

In my port, I have a new bug. See, if you can reproduce it:
I always have a reboot, in these conditions:

1 - When screen on max frequency = 2.8 GHz
2 - Lock userspace DVFS = Refuse or Ignore

If you are running a test AnTuTu during "testing integer performance" before finalizing the 14% you have always a reboot.


Below, you have a dmesg, I hope it is useful.
https://dl.dropboxusercontent.com/u/12990963/dmesg


regards

Nothing very conclusive in last_kmsg from a quick look ...

I would just suppose 2.8 is too much to take, espacially on such an intense benchmark test.

You should use "Stability Test" from Playstore to validate what your CPU can take, but 2.8 is pretty much a lot, and even if is may be stable on normal use (that freq step will not so often be used), on intense tests what freq. step will likely be user for a longer time, that's where the instability will show (reboot).

JP.