[KERNEL] [Y300/G510] Stock Huawei

[Guest ZolaIII]

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 July 16, 2014 by ZolaIII

[Guest]

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

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

[Guest Vule991]

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

[Guest Romagnolo1973]

 

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

[Guest fonz93]

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

[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

Edited July 16, 2014 by Guest

[Guest Romagnolo1973]

My idea of the problem so far so good was right

Thanks for the explaination for no tech people as me

[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

[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.

[Guest fonz93]

About D0,D1,D2,D4 there is an explanation but for Windows Mobile 6.5 :(, don't know if it is the same on Android

 

http://msdn.microsoft.com/en-us/library/aa932261.aspx

[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"

 

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

Edited July 16, 2014 by Guest

[Guest AssaSsiNMiLeS]

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

 

Question: Is FRandom used as default with this Kernel?

Edited July 16, 2014 by AssaSsiNMiLeS

[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).

[Guest thetonyxx]

why min freq is 245mhz? :blink:

[Guest ZolaIII]

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.

[Guest ZolaIII]

Amsterdam server... playing tricks again.

Edited July 16, 2014 by ZolaIII

[Guest thetonyxx]

Amsterdam server...

so what? :D

[Guest luca020400]

I think the double post caused by cloudflare hosted in Amsterdam

I hate cloudflare

[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 July 17, 2014 by Guest

[Guest SaurabhRCk]

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! :)

[Guest spanitzer]

Stock Rom

[Guest]

I'm using B199 stock with some updates integrated from B209

[Guest jor1196]

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

[Guest]

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

Edited July 18, 2014 by Guest

[Guest SammichPG]

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.