yashsingh1/xdaforums huggingface dataset:
[Galaxy Tab 7.7 Android Development] UpInTheAir:
Benchmark scores low after OC ??

Well here you go........... I always said that your benchmark scores could actually be worse off with HIGH OC. Observed my CPU regularly drop to 800 MHz after hitting a thermal limit.

Here's the proof !

https://github.com/UpInTheAir/P6800_JB_SkyHigh_Kernel/blob/master/arch/arm/mach-exynos/mach-px.c

#ifdef CONFIG_EXYNOS4_SETUP_THERMAL
/* below temperature base on the celcius degree */
struct s5p_platform_tmu px_tmu_data __initdata = {
.ts = {
[COLOR="Red"].stop_1st_throttle = 61,
.start_1st_throttle = 64,[/COLOR]
.stop_2nd_throttle = 87,
.start_2nd_throttle = 103,
.start_tripping = 110,
.start_emergency = 120,
.stop_mem_throttle = 80,
.start_mem_throttle = 85,
},
.cpufreq = {
.limit_1st_throttle = [COLOR="Red"]800000[/COLOR], /* 800MHz in KHz order */
.limit_2nd_throttle = 200000, /* 200MHz in KHz order */

With some undervolt and governor tuning, little OC impact will be felt on battery. Not everyone fixes their CPU to max with performance governor :rolleyes: so, providing your hardware can handle it, some OC should be OK for everyday use as the CPU only briefly scales to max freq with the 'right' governor.

As you can see, this could be easily changed to allow (cheat) in benchmarks. This won't make much difference to everyday use, but IMO shouldn't be touched. My silicon may not handle it.

Cheers,

UITA :)
[Galaxy Tab 7.7 Android Development] UpInTheAir:
Skipping official release of 2.9.0 (no reported issues), but starting on 3.0.0 instead. :)

Edit: No time to release 2.9.0 and update OP etc (taking care of my own device), so why stop when I'm on a roll?! :cool:

Have increased USB charging rate from stock 500 to 650 mA,.... Providing no negative feedback on this in v3.0.0, maybe increase further (750 mA) in subsequent releases.

Edit: FYI I have no issues [MENTION=322487]1000[/MENTION] mA, but older USB devices may cause problems trying to draw too much current.
[Galaxy Tab 7.7 Android Development] UpInTheAir:
Screen UV

Anyone know a btter way to test actual screen current/watts draw ?

I have been trying to UV the screen of my device and havn't found others who have done it to our device model.

I think I might have found what needs to be changed in the mach-px.c file, but is really only guesswork. Through trial & error, changed max/min values from 3300000 to 3000000. (3.3v to 3.0v)

#ifdef CONFIG_REGULATOR_[B]MAX8997[/B]
L),
.
.
.
REGULATOR_INIT(ldo1, "VADC_3.3V_C210", [COLOR="Red"]3000000[/COLOR], [COLOR="Red"]3000000[/COLOR], 1,
REGULATOR_CHANGE_STATUS, 0);

I have changed the values, compiled & flashed kernel and tested on screen with Battery Monitor Widget Pro app (widget showing mA, mW) and set "history update rate to 10 secs).

I test with full screen brightness with unmodded and modded kernel with very little difference (using above test method)

Anyone with a better (more accurate) way to test if the changes (current / mW draw) I made actually work? Or even if I'm on the right track with code changes?

Edit: I do think it is doing something, because screen doesn't like to turn on again once off and sleep (sure it's way too much UV). Tab is still powered though, because get the sound when plug in the charger!

Edit 2 : I'll back off the UV to 100 mV (3.2V max/min) and see how it performs..........

Edit 3: Still not sure what exactly it affects, need more testing, so will leave out for the moment. Not giving up though... ;)

Thanks,

UITA
[Galaxy Tab 7.7 Android Development] edan1979:
UITA... currently not at home... will test the new build soon... ^_^
[Galaxy Tab 7.7 Android Development] UpInTheAir:
No worries. :)
[Galaxy Tab 7.7 Android Development] UpInTheAir:
Next release soon !!

v3.1.0 sent for testing. :cool:

If all goes well, I will officially release it as it'll be the last for a while. :)

You can get a sneek preview of change-log by viewing the github commits since v2.7.0 (14th June) & unofficial v2.8.0 (16th June). Release v3.1.0 will include everything since v2.7.0.

BTW, commit "decrease touch sensitivity threshold" means touch sensitivity is increased for both use on battery & charge ;)

Edit: v3.1.0 will also include in-built CIFS & NFS network filesystem support (not tested) +++ more

Cheers,

UITA
[Galaxy Tab 7.7 Android Development] deani77:
Just installed your kernel. Try lulzactiveq with sio now. Hope that green tint problem will not occured so often even though I can eliminate it by off and on my screen. :thumbup:
[Galaxy Tab 7.7 Android Development] UpInTheAir:
I suppose if it's still there, keep the "default" pegasusQ, which isn't too bad anyway....

I just haven't made lulzactiveq the default because of compile issue. Unfortunately, I don't have time to look into it for quite some time.
[Galaxy Tab 7.7 Android Development] partola1:
About issue

ALL your kernels is amazing except one small issue - Voodoo Louder not work with this kernels. I'm always waiting for a new version, checking it and returns to stock kernel. This is trouble with audio subsystem? Can you to fix this?
[Galaxy Tab 7.7 Android Development] UpInTheAir:
There is no issue with voodoo louder with with kernel. voodoo module needs to be implemented within the kernel for it to work..... There is nothing in any change-log to indicate such. ;)

I have tried to port voodoo sound and also boeffla sound mods quite a few times, but no luck. I'm not even sure what our device sound chip/driver actually is. Spent allot of time on this already for something I don't really care :)

But hey, I did put in A LOT of effort, and it's still in OP "to do" list. ;)
[Galaxy Tab 7.7 Android Development] partola1:
Thanks for your answer. Vodoo Sound and Voodoo Louder is different produkts. Voodoo Sound can't be implemented in P6800 due to not compatible sound chip (voodoo sound work with wolfson chip). Voodoo louder work with Yamaha chip so it is compatible with P6800. Voodoo louder is working fine with stock kernels without any implementation. But with your kernels not only sound not changes, but also interface not working properly. Text labels indicate 1E+05 against +9db for example. And progress bar not showing anyway. I think this is kernel problem and this problem may be pop up in another programs. Who know? Stock kernel compiled by you is working fully properly. That is strange.
[Galaxy Tab 7.7 Android Development] UpInTheAir:
If the app is working fine with stock kernel, I don't know, maybe something on config file.....

I know the module is written for wolfson, but still tried to port it. Just don't know the exact chip model. There are many variants, and looking for the exact number (determining which variants are made during compile is not that easy. Tried a few guesses, but resulted in not working or not compile at all.

The sound mod is not that important to me, but seems important enough for you to reject using the kernel. That's up to you..... I think there are ways to mod the ROM to boost gain such as I9500.

If you want to try and help yourself out, do a little bit of research of gitHub for voodoo louder information. Sorry, I don't have anymore time to invest into it, so if you find a confirmed way, please let me know. :)

BTW, the stock kernels are stock. Just extracted zImage and packaged for flashing. ;)
[Galaxy Tab 7.7 Android Development] UpInTheAir:
Voodoo Louder app

Just as I suspected about config file..........

Interesting article !

http://techie-buzz.com/android/voodoo-louder-now-available-for-galaxy-s2-note.html

But how ? I don't know yet. At the bottom of my list, unless someone finds the answer before I get around to it oneday ;)

EDIT : found something here https://github.com/HomuHomu/Homura-kernel/commit/f588f9655f217c146c8e28f4a587d067fc5498be, don't expect miracles. I'm going away on family holiday tomorrow.

BTW, been trying to port UltraKSM to my ICS kernel. No luck yet with compling though.........

.
[Galaxy Tab 7.7 Android Development] UpInTheAir:
v3.2.1 TEST VERSION

v3.2.1 TEST VERSION ONLY

Test for Voodoo Loud app compatibility

Unofficial Change-Log

:

* mc1n2_voodoo.ko module made and installed to /lib/modules

* Should be already loaded because /sbin/SkyHigh.sh

# Voodoo Louder
insmod /lib/modules/mc1n2_voodoo.ko
sleep 1

* Check in Android Terminal Emulator app

su
lsmod

* Hopefully the output will include the mc1n2_voodoo.ko module

* If not, try test the Voodoo Louder app & check terminal emulator again.

I have gone out of my way to research and compile for those requesting it. I haven't the time to test the method on my P6810, so all up to you. Those with the app, please give feedback. I don't want to have wasted my time. As simple as it seems, it wasn't just cut and paste. The info sourced was for SGS2 which didn't work for our device. Thanks

Download

:

REMOVED - apparently

Cheers,

UITA
[Galaxy Tab 7.7 Android Development] partola1:
No, not working jet
[Galaxy Tab 7.7 Android Development] UpInTheAir:
I don't normally do this (and don't expect it),....Come on, I spent A LOT of free time here for no gratitude. But I do expect more than a one liner response ! This is YOUR request ;)

Is the module located in /lib/modules ?

So, does the module load (post result of terminal emulator output before & after running Voodoo Louder app)?

If your answer is yes to both questions, sorry, can't help you any further.
[Galaxy Tab 7.7 Android Development] lomniom:
I got connection time out in Play Store. What zhould i do? Dalvic and cache cleared, still got the problem. Internetbrowser doing ok though. Is anything i miss here?
[Galaxy Tab 7.7 Android Development] UpInTheAir:
I'm not sure what to do with kernel?

Are you trying to download the Voodoo Louder app?

The app it's FREE to install, but PAID to use features. The app might tell you kernel is supported, but features might not actually work properly after paying/unlocking.

Can't imagine market issues anything to do with the kernel. Suggestion for possible kernel issues in previous change-log or read Post #3. You could also wipe Google Play data in settings/applications before...

Also try 3G and stock kernel first
[Galaxy Tab 7.7 Android Development] edan1979:
errr... i dont have problem with voodo louder... its always working... even with stock kernel...
[Galaxy Tab 7.7 Android Development] UpInTheAir:
So no Voodoo Louder "issues" with v3.2.0 as described by partola1 ?

BTW , just released v2.7.0 for my P6810. I might be the only one using it though :p

* Updated dynamic fsync from v1.0 to v1.2

* Enabled KSM (no luck yet with porting UltraKSM). Those users can go and play with the latest KSM tweaking in the V6SuperCharger thread. Sorry, just ran out of time to implement the changes for P6800. Away on holidays :cool:
[Galaxy Tab 7.7 Android Development] sg10:
voodoo louder 3.5 ? I'm curious because I also have the same problem like partola1.

BTW voodoo louder works fine with custom kernel version 0.7

I skip few version but 1.2 had the problem

stock kernel works just fine.

Thank you
[Galaxy Tab 7.7 Android Development] edan1979:
Yup. Using 3.5 with latest kernel
[Galaxy Tab 7.7 Android Development] frogeed79:
How you make it work?
[Galaxy Tab 7.7 Android Development] edan1979:
i just follow the guide in the apps.

edit:

regarding the 3.2 kernel

can somebody else confirm the screen color problem like last time. just got it but... when only using lulzactive. other governer work ok.
[Galaxy Tab 7.7 Android Development] UpInTheAir:
I just can't reproduce any lulzactiveq issue on my P6810 ICS firmware. So far, IMO is the best battery/balanced.

Try having a play with the new ZZMove 0.6 governor instead. I have already tweaked it slightly, but may need further optimisation yet. Maybe someone can come up with further battery/balanced optimisation values.
[Galaxy Tab 7.7 Android Development] deani77:
It exceed beyond my limit... My setting was 100 -1400mhz but look like it use 100-1800mhz but not much battery drain. Wondering if this CPU Spy apps give the wrong data.
[Galaxy Tab 7.7 Android Development] UpInTheAir:
Nothing wrong with CPU Spy app. You could reset the app data and check again.

As quoted from 3.2.0 change-log ;

Even so, under "normal" user habit, with the slight SkyHigh default CPU UV + improved scaling, along with improved GPU scaling, UV and UC, should show better battery results than stock.

Just too make sure, that value is 2 hours + ? or 2 mins.?

Check your battery stats for apps going "wild". You can also use Cool Tool app to monitor your live CPU frequency and process, better battery stats app as well.

Edit: tried to fix the bug quite a few times, but no luck. Almost given up, ......might in future ask a real kernel dev to take a look at my source changes. But it doesn't impact battery a great deal anyway.

Although it does scale to 1800 very briefly, 1400 use should be greater than the 1800, but your screenshot shows the opposite..... What Control app you using?

Edit 2: your screenshot also shows allot of unused CPU frequencies too, with that much boot time, there should be something registered in all of the frequencies. Have you adjusted any governor settings? Also make sure your using just the one CPU control app, and clear data in any other installed app, uninstall or freeze.

Example here:
[Galaxy Tab 7.7 Android Development] deani77:
That value was 2 hours...

I'm using Trickster Mod... Only change governor to lulactiveq and lowered voltage. Other was on kernel default...

Only weird at stay but in real life it not effected much my battery life. Still can get 2 days per charging on normal use.

Sent from my Carbonized and T133 N4
[Galaxy Tab 7.7 Android Development] bonuzzz:
del
[Galaxy Tab 7.7 Android Development] theerachai:
I can confirm there is still screen color problem but just only sometime. Don't know what is the cause and can't be reproduced . It just happen by itself.
[Galaxy Tab 7.7 Android Development] sas_sas:
yes, sometimes while lulzactiveq and maybe with 100 mhz is selected..
[Galaxy Tab 7.7 Android Development] UpInTheAir:
Could you please try running the tab on lulzactiveq + 200 MHz min for a couple days, or at least until you have a screen glitch?
[Galaxy Tab 7.7 Android Development] deani77:
I have green screen with lulactiveq and 100mhz. Will raise it to 200mhz then report back

Sent from my Carbonized and T133 N4
[Galaxy Tab 7.7 Android Development] sas_sas:
As a matter of fact I shifted 200-1400 Mhz after I faced color glitch then nothing happened.

In order to make sure, two days ago I returned to 100-1400 Mhz again but I have not had any wrong by now while I am lulzactiveq and sio..

Yes, under some condition there is color trouble but I can not specify what the real conditions are...
[Galaxy Tab 7.7 Android Development] grazy:
So far have not got any green screen.

I'm using lulzactiveq + row + 100-1400Mhz with UV -25.
[Galaxy Tab 7.7 Android Development] UpInTheAir:
SkyHigh default is -25 mV from stock frequencies 200-1400 MHz. So you UV another -25 mV ?

I really think the screen issue with lulzactiveq could be device dependant, meaning slight hardware differences.

You also mention you use lulzactiveq with scheduler ROW. Screen issues reported haves been with SIO.......

Any users having screen issue with lulzactiveq/ROW @ 100 or 200 MHz min ?
[Galaxy Tab 7.7 Android Development] deani77:
Report on lulzactiveq with min 200mhz... till now I have not faced green tint since nearly 24 hours... but I put my max to 1200mhz since when I set it to 1400mhz it will jump to 1800mhz
[Galaxy Tab 7.7 Android Development] UpInTheAir:
Thanks. If you could please keep your current min settings @ 200 MHz and report again in another couple days. If you get screen issue before that (under normal use), please report then. :)

ref :The 1800 MHz bug

As I replied to you a page or so back....... Its quoted in change-logs. Its known, and unable to fix it anytime soon. Shouldn't cause any real issue though as its "momentary".
[Galaxy Tab 7.7 Android Development] deani77:
As I'm not using my Tab for heavy games. 1200mhz was adequate for my daily use... Only use it for Subway Surfer, Temple Run 2, normal web surfing and GPS Navigation

Sent from my Nexus 4
[Galaxy Tab 7.7 Android Development] stenny:
FIRST, your kernel was great and i do not have any issue as other user do. The only problem is after using your kernel, i cannot change any setting or tweak via init.d. Even have trickster also set on boot with my modify. I also try to alter /sbin/skyhigh.sh, but it will always change back to default after reboot. Please can you make it changeable?

Thanks.
[Galaxy Tab 7.7 Android Development] UpInTheAir:
Ha Ha Ha "was" great, what has changed ? :p

Firstly, quote from FAQ & Post #3................

ISSUES?

1 Remove any kernel related init.d tweaks

2 Wipe your CPU control app(s) data (menu > settings > applications > "your control app(s)" > clear data/cache)

3 Use only ONE CPU control app !

4 Open SuperSU app > settings > full unroot

5 Boot into recovery and wipe cache & dalvik cache

6 Flash SkyHigh Kernel

7 Reboot

About Trickster Mod app :

** Open app and ensure SU permission is granted **

1. Make your changes

2. Apply (tap the "✔")

3. Enable (I use notification as well)

4. Reboot, you can see the notification after start-up

You'll have to explain more what you are trying to do and how. We can't read minds ;) User can't modify initramfs, so anything you do to SkyHigh.sh will never stick.

We know init.d scripts work, because we know the test script works. Search earlier in the thread. If the test script works for you, and yours doesn't, then (more than likely) your script is FUBAR or you're trying to make changes the kernel doesn't support.

Cheers,

UITA
[Galaxy Tab 7.7 Android Development] deani77:
2nd day with lulzactiveq/sio but this time I raised my max to 1600mhz but min still 200mhz. No green tint for me so far...
[Galaxy Tab 7.7 Android Development] schen:
Stenny, there is quite a discussion between me and UITA with regad to the issue that you cannot change certain value using init.d tweaks. One of them being the sdcard cache size. possible some other values cannot be change also using initD. You can change min and max cpu frequency for sure though. CPU voltage can also be change using init.d. I remember I can change the governor but not the io scheduler. This is base on my short time using the kernel. I tried until v 2.70. I dont know why UITA fail to point you to our comversation several pages back while spending time quoting pge #3 that I think not related to the issue.

UITA, rather than quoting post no 3 why dont you spell out which parameter in the initfram.fs that we CANNOT chage. This way wil put this issue to rest. Otherwise several page down the road there will be another question like this.

Thank you.
[Galaxy Tab 7.7 Android Development] UpInTheAir:
You are full of garbage! Seems you don't know when to stop trolling, do you?

Have you even tried 3.2.0 ???? Read and try understand various changelogs.... gitHub sources are accessible too. :)

For your convenience: ;)

http://xdaforums.com/showpost.php?p=43831754&postcount=237

The external cache is still set at 1664 by initramfs and internal is now 1024 (gitHub sources). Internal is NOT set from intramfs anymore ! Changes are hard-coded. Its actually dynamic with 16GB set at 1024. :cool:

Again, for your convenience: ;)

https://github.com/UpInTheAir/P6800...mmit/777795204133f78fd27c50ddb8d02cf628dba521

init.d DOES work, just some are INCOMPETENT :rolleyes: Others use and test it successfully...... I just "fail to point" out the users that troll, fail to follow said advice and have know idea what they are saying or doing. The "issue" is at "rest". :)

I have "spelt it out". As far as I'm aware, you cannot directly alter the kernel install script on ANY kernel (changes will revert on boot), UNLESS you use an appropriate init.d script or other app to do it. Do you now get it? I am not responsible for scripts that don't work, poorly written, or incompatible with ROM or kernel.

BTW, Post #3 isn't there to make up the numbers, it's there for a reason :banghead: particularly for naive, inexperienced users to try help themselves first. What you "think", I couldn't care less anymore. :)

Stenny didn't even elaborate on his "problem" as per my reply. We're only guessing and "we can't read minds"..... ;)
[Galaxy Tab 7.7 Android Development] UpInTheAir:
Ref: CPU 100 MHz UC step

I will be home from holidays in a couple weeks, and surely look to further update this P6800 kernel to at least the same state of my P6810. I'll be looking for other nice tweaks and fixes too. ;)

Sure, every device hardware is not manufactured exactly the same and "some" kernel changes may affect each user's device differently. So, I am 'considering' removing the 1700 & 1800 MHz freq (until I can fix the bug). Rest assured, I haven't yet given up on the 1800 bug, but it's quite time consuming, and other things take priority. Also on the 'hit list' is removal of 100 MHz freq, it may be (for some) more trouble than it's worth. Myself, have had a couple recent lockup on my P6810, and believe it's the culprit. For daily use, I now personally use 200-1400/1600.

Any comments or useful suggestions on these proposals? I could just leave them there and let user decide? (Obviously I need to adjust my published 'recommendations', which I'll do today :) )
[Galaxy Tab 7.7 Android Development] deani77:
It was nice if you can make it 200-1600mhz... I think it was optimum range for P6800. 1800mhz was to high for aging P6800.

Just an opinion...

Sent from my Nexus 4
[Galaxy Tab 7.7 Android Development] UpInTheAir:
I tend to agree. 1800 was more for "show", rather than useful :D

I do believe OC 1600 is workable for 99% of devices though. Benchmarks will most likely still hit the thermal limit and throttle to 800 MHz (briefly), but useful for 'actual' day-to-day use.

ATM, even if I cap the max CPU at 1600 MHz, the bug will just follow from 1800 to 1600 MHz.... unless I can fix it. But will at least save a few seconds of battery. :) Just lucky the bug is just momentary, and very little negative effect.
[Galaxy Tab 7.7 Android Development] deani77:
This was Antut Benchmark with ondemand government at 200-1600mhz

Another report, had another green tint while scroll through apps drawer. Was at 200-1600mhz
[Galaxy Tab 7.7 Android Development] UpInTheAir:
Running consecutive benchmarks or stress testing CPU most likely will increase CPU temp and then cause thermal limiting.

Ref: screen tint

To be sure, which governor? Still lulzactiveq ?

If I can't fix it, lulzactiveq will be removed from future P6800 release. It works quite well on my tab, so can't replicate the problem. Try playing with zzmove instead. Probably still needs a little more tweaking though....
[Galaxy Tab 7.7 Android Development] deani77:
Yes, on lulactiveq gov... But no screen tint problem on other gov. Now I using ondemand.

Sent from my Nexus 4