yashsingh1/xdaforums huggingface dataset:
[Galaxy S II Original Android Development] Auridran:
This is because of vsync. For lack of further explanation, the framerate is basically capped at 60FPS. Gokhan has stated he has no desire to add the ability to remove vsync because it will add nothing to the user experience.

While I agree that it adds nothing to the experience to remove it, it would be nice to see the true horsepower behind our GPU after overclocking.
[Galaxy S II Original Android Development] bleuxeon:
yep I agree:)
[Galaxy S II Original Android Development] gokhanmoral:
after reading this, I enabled userspace governor and rechecked it.

I had the same problem, I mean the crash.

then I noticed I missed another point in your post. you are absolutely right.

I didn't check setting frequencies, I only checked changing maximum level (policy->max) while trying ondemand and my hacked test-ondemand (it's much like userspace).

the problem doesn't happen on load. it is as easy as using performance governor and setting the freq lower. the load biased me because I thought it was preventing the cpu to change freq while it wasn't happening at all.

so, a simple exynos4_target in CPUFREQ_NOTIFY did the job..

I will test it a bit more and commit.
[Galaxy S II Original Android Development] allgsmnetwork:
please fixed next version 1.6 GHz for stock rom,at 1.6 crash blocked software for gingerbread 2.6 no problem...

thanks :)
[Galaxy S II Original Android Development] netokee:
Fine, BLN is worked for me too, on Stock WXLPQ + SiyahKernel 3.0b7 ;)
[Galaxy S II Original Android Development] danielsf:
I agree it would be nice to see, but there are bigger fish to fry first :)
[Galaxy S II Original Android Development] T!b:
Will the 3.0rc1 be compatible with the latest MIUI ICS ?

Waiting for this time....
[Galaxy S II Original Android Development] stormtroopercs:
If its not in the changelog no.
[Galaxy S II Original Android Development] simone201:
So.....you found a kinda fix somehow? :):):):)

If yes, i am really excited.....:eek:

PS: check ur pm :)
[Galaxy S II Original Android Development] Ogy77:
I cant wait LOL,come on relrase that RC1,pleaseeeeeee Gokhy:D:D:D
[Galaxy S II Original Android Development] :
Does this Kernel work on AOKP roms as well?
[Galaxy S II Original Android Development] Entropy512:
Testing putting min/max enforcement via exynos_target in CPUFREQ_NOTIFY myself... That's a good idea.

I'm guessing 2.6.35 had different methods of min/max handling.

Edit: Still some work to do for me...

dmesg attached what I get if I run StabilityTest to peg the CPU and hop the max between 1200 and 1000. Also attached the patches I'm using

For whatever reason, exynos_getspeed is giving bogus info...
[Galaxy S II Original Android Development] noobsgs2:
So will "fixed CPU scaling problem and sleep-of-death issues with screen-scaling (script or SetCPU)" solve (or partially solve) that kernel main issue?
[Galaxy S II Original Android Development] alcurtis93:
Will android 4.0.4 be supported soon?

Latest hydrog3n rom.
[Galaxy S II Original Android Development] alcurtis93:
Android 4.0.4 support soon?
[Galaxy S II Original Android Development] stormtroopercs:
It works just fine?
[Galaxy S II Original Android Development] franciscofranco:
Can this bug be reproduced with cpu0 and cpu1 online or this only happens if cpu1 is down? Just trying to understand why it locks down by changing the frequencies...makes no sense.
[Galaxy S II Original Android Development] Vaedryn:
Yes, works with 4.0.4
[Galaxy S II Original Android Development] Entropy512:
Both. I'm going to attempt completely disabling hotplugging as an experiment (as opposed to using the sysfs luck function), but at least with sysfs locks, it doesn't matter whether CPU1 is on or off.

Seems like clk_get_rate for armclk is returning 1.2 GHz when it should be reporting 1.0 GHz - why it only does this as a result of changing the max policy I'm still trying to figure out.
[Galaxy S II Original Android Development] myfluxi:
Entropy, Gökhan, I think I got it fixed!

Please try: https://github.com/myfluxi/xxICSKernel/commit/0e2913836da5229b1441568ddf226b4790c397bb

:)
[Galaxy S II Original Android Development] Entropy512:
Interesting - rather then drop it right to max, drop it to min first then bump it up to the new max.

It would still be nice to know why clk_get_rate gives bogus info for armclk in this situation, but - ****it. This workaround should do the trick and I'm kind of tired of fighting this. We can revisit why clk_get_rate does stupid **** later.

Building and testing. I'm going to make it conditional on max being higher than current though.
[Galaxy S II Original Android Development] yeahtyeaht:
fluxi nicht mehr bei android-hilfe unterwegs? :D
[Galaxy S II Original Android Development] simone201:
I just love you myfluxi!!!! :D

Will add that to my sources tomorrow morning....hoping that works also for me :)

Inviato dal mio GT-I9100 usando Tapatalk
[Galaxy S II Original Android Development] Entropy512:
Something isn't right...

Updated patch I'm using, and a dmesg... It doesn't crash but straaaaaaaange **** is happening like the system thinking it is at 250 MHz...

General theme seems to be that clk_get_rate for armclk seems to lag a bit...

Time to instrument s5p_get_pll45xx ... Probably tomorrow... stuff to do tonight.
[Galaxy S II Original Android Development] myfluxi:
Updated a conditional as well.

Sure, it's a workaround but it's the best we have at the moment and allows us to move on. This sh*t stole my sleep.
[Galaxy S II Original Android Development] Entropy512:
Mine too... Problem is that while it solves crashing, I think it can cause the CPU to get stuck in "odd" states. In one case (see dmesg above), it got stuck at 250 MHz almost permanently until I changed max again.

I think that somehow one of the clock dividers for the APLL isn't getting set properly. I'm going to instrument the function I mentioned above to show all the divider values.
[Galaxy S II Original Android Development] bajee11:
Beta 7 works fine for me. using with hydrog3n-ICS 31.03
[Galaxy S II Original Android Development] Entropy512:
Finally fixed it... but my patch needs to be cleaned up and rewritten.

It may go beyond patching and just overhauling parts of this ****ty code so it never makes a bad decision involving the current M/P/S state again.

More tomorrow. I need to drink.
[Galaxy S II Original Android Development] gokhanmoral:
I've just seen your commits.

those are very similar to what I tried, but as Entropy said there is a strange behavior sometimes and I see 300 and 600 steps while I don't have them. that won't be too much problem for your case as you already have almost all combinations :)

and I guess it is related with trusting the policy->cur value rather than requerying the clock. obviously the sync problem causes a deadlock but this workaround may fail if there is already a limit or lock because you are calling exynos_target. I think setting the frequency directly would be better at that point. consider the case where the user sets 800-1200MHz limits and use 200-500 scroff profile. or a dvfs lock prevent you to set frequencies. but that will fix setting freq 2 steps below crash and probably setting the freq to 800MHz on boot.
[Galaxy S II Original Android Development] gokhanmoral:
yes :) that's it! :)

but still changing frequencies is tricky...

I removed my limits on locking and limiting the cpu frequencies because 200-500 was causing SOD again.

now I still have SOD and since those are non-debuggable deadlocks I am a little lost.
[Galaxy S II Original Android Development] suchevent:
same here. 4.0.4 and b7 seem to getting along just fine, despite some reports claiming that they are not.
[Galaxy S II Original Android Development] Entropy512:
I had one SoD tonight, but I think I know why.

but I need to go to bed now, 2 AM.

ok not quite oging to bed, since by the time I wake up it's probably going to be mid-evening for those in Europe due to the time difference (I'm likely to sleep well past noon EDT), two things:

1) A preliminary patch. It's not complete, as I need to handle changing the minimum frequency, and/or just utterly nuke the concept of old_index and always check the current m/p/s values in exynos4210_pms_change() instead of doing a table lookup with an index that could be wrong (even if it's the closest possible value, the current state may not be a valid step for some reason.)

2) Since GM just transitioned from hg to git, a fun workflow tip (it's how I generated this patch) for test kernels and preliminary patches for those not using gerrit:

Before starting your work (if you've already started, there are other options), do

git checkout -b some_branch_name

to start a new branch

Then do your work

Then, if you want to post up a patchset with that work

git format-patch previous-branch

(for GM, previous-branch might be master. For me, it's likely entropy_kernel_main, or if I'm doing CM9 stuff, ics)

You'll get a bunch of nicely formatted patch files. These can be applied to another tree with "git am file.patch"

If you already are a few commits into your "test effort", assuming you're on master and going to branch test:

git log --oneline

look for the id of the last commit you want to keep in the main branch

git checkout that-id-you-chose
git checkout -b test

Then you can cherry-pick your commits into test, and then

git checkout master
git reset --hard that-id-you-chose

This will throw away all the commits after that-id-you-chose on master, but the ones in test will still be on test. BE CAREFUL - a hard reset can throw away a lot of work if you're not careful!
[Galaxy S II Original Android Development] Karpfenhai:
All of you kernel devs are doing a great job, its much appreciated even if the most users are not showing their thanks..

Keep on going guys, you will get more than enough sleep after your death! ;) very deep sleep.. :D
[Galaxy S II Original Android Development] myfluxi:
This may be it!
[Galaxy S II Original Android Development] alcurtis93:
Samsung suck :| you kernel devs really shouldn't be having to do all this. Do Samsung employ idiots?
[Galaxy S II Original Android Development] gokhanmoral:
this is just great!

and the main root of the problem actually.

thank you very much Entropy512.

I missed this point. actually, modification in cpufreq_notify part was just a workaround.

and this also fixed 1000-1200 scron 200-500 scroff profile problem

I have edited the patch a bit to check policy->min as well

so, we all have struggled because of this part in freq_table.c:

if ((freq < policy->min) || (freq > policy->max))
continue;

sorry, I could not get the diff formatted as neat (I'll read about it and configure later) :)

here is what worked for me:

https://github.com/gokhanmoral/siyahkernel3/commit/e5596fa7edb121096e64ff15f6f2e645d7a446b4

EDIT: the question is that why samsung made that call to freq_table.c while he could easily scan the freq table to find the index..?
[Galaxy S II Original Android Development] alcurtis93:
GM can an Android 4.0.3 based kernel work on android 4.0.4 without losing any features present in the update? Surely some are kernel specific?
[Galaxy S II Original Android Development] Vaedryn:
You read answers?

SGS II Cyanogen (mod) 9
[Galaxy S II Original Android Development] MatMaul:
Hi,

Thx for this great kernel, used it on gb and I am happy to have it in ics now.

Sensitivity problems when scrolling has been fixed in the last experimental cm9 kernel, it would be cool to have it backported in your rc1.

Thanks !
[Galaxy S II Original Android Development] gokhanmoral:
I think you mean this commit: https://github.com/teamhacksung/and...mmit/451189bc47d3c68fa31ca39f9265be81d690db31

I'll make sure that I don't revert that one :)

I modified those levels a little bit to prevent flickering while scrolling when the device is being charged but that change can make those who use screen protectors unhappy. we'll see...
[Galaxy S II Original Android Development] Ogy77:
Mate can you say can we expect RC1,please if you can?
[Galaxy S II Original Android Development] Gawis:
Gorilla Glass isn't meant to be used with a screen protector :-)
[Galaxy S II Original Android Development] simone201:
@gokhanmoral & Entropy512:

weird, after applying the patch that gokhan has rebased on entropy's, i got a strange freeze after inserting PIN code, because i have removed the USB cable....

Should we need myfluxi's workaround anyway to ensure that it never freezes?
[Galaxy S II Original Android Development] gokhanmoral:
I could not find any time to fix bln problem (if you use the kernel on cm9) and also I need to modify usb part to be compatible on both variants.

I will fix bln now and then try to fix the other part.

if I can do that I will release rc1

but I think the usb modification will take more time (I will move the initialization of mtp part out and trigger it when I echo the rom type to /proc/sys/kernel/rom_feature_type which is a sysctl file that I use to determine if the rom is cm9 or samsung)
[Galaxy S II Original Android Development] gokhanmoral:
hmm, I did not apply fluxi's workaround.

I had similar code before Entropy512 suggested this fix, but I removed that part because Entropy512's fix make it useless. the main problem is that we receive wrong index when we modify policy min/max and Entropy512's fix is a better way of handling it instead of using a workaround to make them correct.

after applying that fix I even tried 1000-1200 screenon and 100-100 screenoff policies + ondemandx modifications. no freeze here.
[Galaxy S II Original Android Development] simone201:
Cool! I haven't applied fluxi's workarounds because Entropy's is way better to handle those kind of sync errors....anyway good work as always both you guys! :)

Meanwhile i have implemented the dec_cpu_load parameter in the lulzactive code, so now it scales way better down and faster up, making it more customizable and more battery friendly....i hope my way of implementing it is right :rolleyes:

Check it out in my repo gokhan, maybe u like it :D

PS: sometimes i try to do something by myself xD
[Galaxy S II Original Android Development] gokhanmoral:
it's good to see you experiment with the code :)

I knew this day would come ;)

I cannot comment on the effects of that change without testing it.

it may cause too many jumps up&down because you are scaling the cpu down one step when in noop region, but I am not sure.

tegrak based his governor on interactive governor. maybe you should also do the same and migrate the code to new interactive governor. that old idle notifier method doesn't seem so good in a v3.0 based kernel.

good job anyway. keep it up.
[Galaxy S II Original Android Development] simone201:
Thanks! :)

Yeah it scales a lot down, very good for battery (at least based on my tests)

One of my thought was to rebase lulz to the new interactive as you said, i think i will do that in the incoming week because i have some time (easter holidays)

AFAIK, that new patch in lulz is great, only a bit worse 3d benchmarks but the cpu scales really fast up&down :D
[Galaxy S II Original Android Development] romandd:
Hi, this kernel works with last MIUI v4 ics.

BLN works too?
[Galaxy S II Original Android Development] tolis626:
Gokhan,Entropy,Simeone,Myfluxy,you are all doing great guys. :D

Apart from being really happy to see that you solved the problem,I'd like to congratulate Entropy512 for his Elite Recognized Developer status.You sure do deserve it man. :)

Gokhan,I don't know if it's just my phone acting strange or something,but seeing as no one has posted anything about it,I thought I would.I tried HydroG3n ICS from 31/03 yesterday,and external sd wasn't accessible for some reason.It also seemed to break 1080p playback for stock Video Player and every player that uses default hardware decoding(DicePlayer for example),although they play fine using MX Player.Not a biggie,since I'm back to CM9,but I thought it'd be best if you knew. :)

EDIT:Also CM9 team patched their kernel up to 3.0.26.You might want to check that out. ;)
[Galaxy S II Original Android Development] AJ Newkirk:
Any chance you will be releasing a version for the i777 also?

My apologies if this has been covered before.....I did try a search but got no results :)
[Galaxy S II Original Android Development] Prasad:
+1! :D (filler)
[Galaxy S II Original Android Development] veyka:
Afaik yes once everything else is fixed, but most likely to make everything happy for the i777 they will need a src drop for it, due to differences in libs for audio, maybe it's been worked around, but i entropy is the chap to ask about that.
[Galaxy S II Original Android Development] tenchi0205:
gokhanmoral： siyah 3.0 b7 had disable the bootanimation?
[Galaxy S II Original Android Development] bandit79:
same here. flashed beta7 on 4.0.4 HyDr0G3N-ICS and now there is no bootanimation left and my external sdcard is not mounted?!
[Galaxy S II Original Android Development] Entropy512:
Nope - There were kernel changes for the Nexus devices, but those were minor fixes and nothing in userspace presented compatibility changes. Sometimes Samsung changes drive kernel compatibilty requirements changes (such as BTHID in newer Gingerbread bases starting with XWKK5), but those are not connected to Google changes usually.

For the most part, kernels will be compatible with almost any minor Android point release. Remember Gingerbread? With the exception of some initramfs changes for wifi (that may only have been I777...) and the BTHID fix, we had kernels that supported almost any Samsung release.

All worked around - Before I9100 source dropped we had a good idea of what was needed thanks to looking at what CONFIG_TARGET_LOCALE_NAATT changed on Gingerbread.

Samsung was nice and tagged "bare minimum" changes with CONFIG_TARGET_LOCALE_NAATT_TEMP

They missed a few things though - well, one in kernel sources:

1) They forgot to unmap the HOME GPIO when an ATT config was set. This would cause weird random behavior consistent with phantom HOME key presses because the GPIO was floating.

2) Not really kernel normally, but the microphone setup on I777 is different. In Gingerbread we just swapped libaudio, in ICS I spent most of last Saturday printk()ing the hell out of the MC1N2 driver to figure out what libaudio did different - by the end of the day I had an in-kernel workaround which is why CM9 receives I777 nightlies. Of course, two days later we got an I777 leak with libaudio - but I don't trust it - it's clearly old code, and at least it seems better to just maintain the kernel workaround at this point. It'll only break leaks - but the I777 leak is broken with source-built kernels just like source-built I9100 kernels don't like XXLPJ and earlier.

GM's patch is a good rewrite and fixes a bug I had (restoring max even when we never changed it), although I'm going to make some minor tweaks - instead of changing min=max=cur, I'm only going to touch the one that changed, to handle any possible remaining situation where the current frequency isn't on a real step.

Eventually I think I'm going to rewrite it to use the current CPU m/p/s values instead of doing lookup tables, that way it will ALWAYS make the right decisions on m/p/s changes.

I'm glad this crap seems finally over... I was hoping to write a new governor just for today's festivities but had too much else to do. :)
[Galaxy S II Original Android Development] eC1990ho:
So what exactly are the advantages of using this kernel over the stock cm9 one?
[Galaxy S II Original Android Development] dica:
Read the change log and the features then try it by yourself and u will know the answer

On wanamlite 10.2 is working

_______________________________

Wanamlite 10.2| Siyah 3 b7

Tapataking from SII
[Galaxy S II Original Android Development] pulser_g2:
Entropy or gm,

make[3]: *** [drivers/usb/gadget/built-in.o] Error 1

make[2]: *** [drivers/usb/gadget] Error 2

make[2]: *** Waiting for unfinished jobs....

When trying to build from the github using linario. Wondered if either of you has had this before... On vacation else I'd try fix it myself :p
[Galaxy S II Original Android Development] gokhanmoral:
oops.. I have still some unpushed fixes on that part.

I was trying to separate aosp mtp and samsung mtp and didnt commit that one.

pull again it should be fixed.
[Galaxy S II Original Android Development] SupraN0va:
wow, what do my eyes see,,Elite Recognized Developer''. Congrats Gokhan, if someone deserve it than you. Havent seen long time a talented Dev like you around who is so down to earth.:D
[Galaxy S II Original Android Development] tolis626:
Holy f*ck,I just noticed that one! :eek:

Congratulations to you too Gokhan.You,like Entropy,more that deserve the title.You have made an awesome device quasi-perfect.If anything human made could reach perfection,you'd have really good foundations for making it perfect.

So,believing I can speak in behalf of everyone in this forum,thank you for the endless hours you spent to help us enjoy our devices to the maximum. :)
[Galaxy S II Original Android Development] naveediftikhar:
hey gokhan..i found something strange...maybe u knw abt it..but the hotplug value if changes cause a huge amount of lag...m on wanam 10.3...ive uc'ed...uv'ed...on both gpu n cpu...n have no lag..but as soon as i vary the hot plug contants 30,20 to any other value using extweaks..*boom* lag..lot of it..dun knw y...maybe u can cure it aswell if its a kernel issue!
[Galaxy S II Original Android Development] pulser_g2:
Ta much :)

Cheers
[Galaxy S II Original Android Development] gokhanmoral:
it may be related with the old-famous cpu-scaling bug which is fixed because I tested it and cannot reproduce on rc1.

normally those two values should not cause any lag or crash. if you misconfigure them you won't get second core enabled or you will get both core enabled all the time.
[Galaxy S II Original Android Development] pulser_g2:
Got kernel building, but I don't think it's all pulling together OK...

I get constant force closes of Phone, and logcat isn't there...

I think the issue is the recovery and payload folders - I have made empty folders with these names, but it looks like it needs something in there?

There's no CM bootanimation either, if that helps...

The rest seems OK, so it's very much a "so near yet so far" :p

Build fix you made works well though!
[Galaxy S II Original Android Development] Vaedryn:
Gratulation Gokhan , absolutely earned :)

SGS II Cyanogen (mod) 9
[Galaxy S II Original Android Development] gokhanmoral:
hmm.. I don't use recovery and payload parts in the latest version in github.

I moved all files to initramfs.

some optimizations caused problems and I didn't want to spend any time fixing them.

in the next version I will move them back to the end of the kernel to have a faster boot but now the aim is to have a stable unified kernel so that I can continue implementing my dream :)

I am still working on usb gadget part.

after fixing it I will push all necessary changes.

I have just checked and except for those usb changes everything is pushed.

maybe you need to update initramfs3 clone as well?

if you are having force closes it means we will have another wave of repeatedly reported bugs tomorrow :)
[Galaxy S II Original Android Development] pulser_g2:
Yeah, USB is all good now.

I re-pulled initramfs as well, and it didn't help. I'll leave it for now, but it might help you to know this for future etc :)
[Galaxy S II Original Android Development] manyakurt:
Elite for Gökhan, recognized for xda, developer for us.
[Galaxy S II Original Android Development] gokhanmoral:
eek! I spent hours on USB part because of a tiny init line in init script (yeah, it was supposed to have inits but I forgot about that one).

I was setting rom_feature_type to 0 (used for samsung roms) and then 1, 2, 3...depending on the rom type...

and I debugged kernel code without having a single clue about why the USB part is initialized with samsung mtp...

why? because I init it so :)

damn...

I fixed the usb part. now it works on samsung and cm9 roms with only mtp difference.

since I don't have the cm9 repository and recovery source with me, I cannot release it now. I want to make an addition to recovery to let you choose different presets for tweaks.