Jump to content
Guest

[KERNEL] [Y300/G510] Stock Huawei

Recommended Posts

No as screen off is actually early suspended state. So it wont save anything. Powersave could produce additional lag when phone is waking from deep sleep (suspend state).

Edited by ZolaIII

Share this post


Link to post
Share on other sites

@modding33k Do you recommend minimum frequency at 245 Mhz? I'm using ondemand governor.

Share this post


Link to post
Share on other sites

 

In following thread it's explained why the available frequencies changed:

[KERNEL] [bUG REPORT] ACPUCLOCK-7627 frequency table selection

 

I saw this post in the bug thread but for me is like arabic language :-) too tecnical

But I understood that a 245 mhz setting for our Y300 is better than the old 196 (and 120 better than the old 96) because is matching exactly with our cpu voltage in the SOC. So in this terms your kernel is far better than Cexstel that use wrong frequency

Share this post


Link to post
Share on other sites

I saw this post in the bug thread but for me is like arabic language :-) too tecnical

But I understood that a 245 mhz setting for our Y300 is better than the old 196 (and 120 better than the old 96) because is matching exactly with our cpu voltage in the SOC. So in this terms your kernel is far better than Cexstel that use wrong frequency

 

Is not better, he is trying to say that is needed to fix a bug, i mean, the old table frequency was totally wrong, in the source code is present the 245 mhz frequency but wasn't used and i think this was causing a loop, so tha'ts why moddingg33k added the new table frequency, if wasn't for this bug i think he wouldn't change it

Share this post


Link to post
Share on other sites
Guest

@Vule991: it's safe to use 245 MHz CPU frequency. I would not recommend using it in screen-on scenarios for the already mentioned reasons. The CPU's frequency would jump up to MAX more often than necessary on that way. It can get used while screen is off however. For example during MP3-playback. Using any lower frequency than that won't really save energy in my oppinion, since all other lower frequencies available are using the same powerlevel anyway.

 

The clockdriver bug is easily explained. In short: Our kernel's cpu-clock-driver picks an pre-defined cpufrequency table, depending on the CPU and hardware values being detected. The bug described in the linked thread causes the driver to select the wrong frequency table, which isn't supposed for being used for the MSM8225 CPU on an MSM7x27a board. It's no critical problem at all, since the frequencies above 320 MHz matches each other in both tables - the wrong and the correct one:

 

Frequencies of the WRONG table: 19 MHz, 65 Mhz, 98 MHz, 196 Mhz, 320 Mhz, 480 Mhz, 600 Mhz, 700 Mhz, 1 GHz

Frequencies of the CORRECT table: 19 MHz, 61 MHz, 122 MHz, 245 MHz, 300 MHz, 320 MHz, 480 MHz, 600 MHz, 700 MHz, 1 GHz

 

 

The are more differences between both tables which I'm not really aware of. If you compare the values for D0, D1, D2, D4, U0, U1, U2, U4 you'll notice that they are *totally* different on both tables, see here: http://www.modaco.com/topic/372980-kernel-bug-report-acpuclock-7627-frequency-table-selection/#entry2218686 (really got no clue what those hardware values are good for ... but they have some meaning for sure).

 

It can't hurt to use the right table. That's the only thing I can say happy.png

Edited by Guest

Share this post


Link to post
Share on other sites
Guest

Currently this seems to be the only kernel on this forum which got the bugfix for the kernel's acpuclock driver applied. I've pmed chil360 and dazzozo about it.

 

I don't know if selecting the wrong table is actually any serious issue at all. It might be totally meaningless. Our Y300 devices worked without the fix, too all of the time.

 

This BUG is present on all stock kernel's shipped by Huawei. They will never fix it unless CodeAurora/Qualcomm detects it and fixes it themselves :D

Share this post


Link to post
Share on other sites
Guest

If someone got any info about the meaning of those D0, D1, D2, D4, U0, U1, U2, U4 values please send me a PM. That's the the only *real* difference when comparing both tables.

Share this post


Link to post
Share on other sites
Guest

Nice finding. I guess those D-states explained on Microsoft's website got the same/equal meaning on our frequency table.

 

This would mean the "wrong table" chose "wrong values for the CPU's power state" huh.png

 

I wonder whether it got any impact on battery drain or performance. Guess the answer might be: NO

Edited by Guest

Share this post


Link to post
Share on other sites

Why is the 600 MHz frequency from the table not available?

 

Question: Is FRandom used as default with this Kernel?

Edited by AssaSsiNMiLeS

Share this post


Link to post
Share on other sites
Guest

The scripts of the kernel's ramdisk replace the random/urandom devices with frandom/erandom. So yes, frandom is getting used by default.

 

600 MHz is only getting used during boot sequence. I left everything default. Dunno why it didn't get set enabled by the driver's developer(s).

Share this post


Link to post
Share on other sites

why min freq is 245mhz? :blink:

Well they probably did testing & find it as (fairly) optimal on given architecture & lithography process for most basic tasks against power consumption.

Share this post


Link to post
Share on other sites

I think the double post caused by cloudflare hosted in Amsterdam

I hate cloudflare

Share this post


Link to post
Share on other sites
Guest

Kernel build 17/07: http://www33.zippyshare.com/v/21017968/file.html

No changes worth mentioning. I've applied some filesystem related commits. Nothing which would improve anything in a noticeable way though. AnTuTu's scores are up a little bit.

Check my commit log if you are interested in technical details: https://github.com/moddingg33k/android_kernel_synopsis/commits/master

Edited by Guest

Share this post


Link to post
Share on other sites

Kernel build 17/07: http://www33.zippyshare.com/v/21017968/file.html

No changes worth mentioning. I've applied some filesystem related commits. Nothing which would improve anything in a noticeable way though. AnTuTu's scores are up a little bit.

Check my commit log if you are interested in technical details: https://github.com/moddingg33k/android_kernel_synopsis/commits/master

Which rom are you using to test all your builds? just curious! :)

Share this post


Link to post
Share on other sites
I like your work moddingg33k 
this encourages me to what I want to be 
I will engineer and information systems and other things more
 
thanks for all

Share this post


Link to post
Share on other sites
Guest

Thx jor :) I wish you good luck and success on your way.

Edited by Guest

Share this post


Link to post
Share on other sites

Just flashed your kernel on H3ROS rom and so far everything seems to work, I have installed performance control and the default zram amount goes back to 10% after every reboot. Maybe I'm doing something wrong. Another (most likely dumb) question, why is the y300 stuck at 1ghz instead of 1.2 like the g510? Aren't they using the same soc? 20% extra clock speed would be really welcome.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.