yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Android Development] bamsbamx:
Hey thracemerin, thanks for continuing motleys kernel!!!

Now i want to ask you for a little favour: i dont know to develop android kernels, but i want to add OTG support, so please, could you build your latest build with OTG support from Ziddeys kernel?? thanks!!!

If you arent able to do, could i add support for OTG without building a kernel? Maybe a flashable zip is sufficient for add OTG support for an installed kernel…

(Always i am refering to OTG, i mean OTG by using an Y-cable)
[Nexus 4 Android Development] MotoRaph:
What do you think about this http://xdaforums.com/showthread.php?t=2300873? Does this help with the delayed notifications problem?
[Nexus 4 Android Development] thracemerin:
Same as the solution I've had posted in post 3 since i started this thread and have had in my other thread for months, just someone trying to take credit for the discovery.
[Nexus 4 Android Development] Cuzz1369:
So I flashed b7 a few hrs ago coming from Franco. While using the sys monitor I notice a lot of jumping around n the CPU and the only core to settle is c1. c0, c2 and c3 are all over the place. Is this normal with the ondemand governer?

Carbonized and N4
[Nexus 4 Android Development] thracemerin:
Did you flash B1 then B7?
[Nexus 4 Android Development] Cuzz1369:
Yup. I even went as far to dirty flash rom , then b1 to b7. I switched to interactive and everything seems normal.

Carbonized and francofied N4

---------- Post added at 08:39 PM ---------- Previous post was at 08:38 PM ----------

Edited my first post as it was on demand sorry for the confusion

Carbonized and francofied N4
[Nexus 4 Android Development] thracemerin:
Oh, ondemand isn't very well optimized for this kernel, it probably needs a rework, I'd stick with interactive :)
[Nexus 4 Android Development] Cuzz1369:
My thoughts exactly. Nice kernel so far.

Carbonized N4
[Nexus 4 Android Development] thracemerin:
I tried to get it to merge and it's really not liking some of the changes I made to the USB controller to reduce msm_hsic_host wakelocks, gonna take a bit of work to get sorted.

Sadly, I don't think there's a way to do this by flashable zip without building the entire kernel, maybe an injectable module but you wouldn't want to not have USB control support to that's probably a bad idea.
[Nexus 4 Android Development] Cuzz1369:
If you read any part of that post you would see it does nothing for the delayed notifications.

Carbonized N4
[Nexus 4 Android Development] thracemerin:
He sets gEnableSuspend to 2 which solves delayed notifications for me, but I already knew it worked months ago. [MENTION=1946444]socali[/MENTION] found this solution originally.

The other stuff may or may not improve speed, I've never personally had issues with my WiFi speed so I never tried it, but I think its foolish to put firmware files from one device directly onto another especially if you look at his post showing the differences, there are a lot of settings in the N4 stock file that don't appear in the OG file and while I can't say that they're important, it seems to me that if they weren't they probably wouldn't be there.
[Nexus 4 Android Development] Cuzz1369:
You know better than I do but I did see the op say he didn't edit anything. He just extracted it from the lg optimus. I too have no problem with my WiFi so it isn't needed and I share your concern. A lot of people have trouble with WiFi I guess and don't mind breaking there phone to try and fix it.

Carbonized N4
[Nexus 4 Android Development] thracemerin:
The OG version has gEnableSuspend=2, he may not have set it that way, but its set that way.
[Nexus 4 Android Development] bamsbamx:
Well, thats sad :(

However, i am trying to follow the steps of ziddeys post, and I made this script...(maybe a miracle comes to us and it works :D ):

su

#create directories
mkdir /storage/usbdisk0 0000 system system
mkdir /usbdisk 0000 system system
mkdir /mnt/usbdisk 0000 system system

#mount them as read-write
busybox mount -o remount,rw /usbdisk 2>/dev/null
busybox mount -o remount,rw /mnt/usbdisk 2>/dev/null

#link them
ls -s /storage/usbdisk0 /usbdisk
ls -s /storage/usbdisk0 /mnt/usbdisk

exit

What do you think? I have not tested it yet, will report results :)
[Nexus 4 Android Development] Remoteconcern:
Hey guys. I've been looking at the hotplug driver recently, and the parameters for it. One of the things I liked about mpdecision was how effectively it online/offlined cores. Watching live CPU monitoring through an app like System Monitor shows that mpdecision onlines two cores when touched for two seconds, and then offlines all but one at idle. Motley's implementation of thalamus' hotplug driver appears to have a lot of overhead.

To try and reduce this core offline and online action, I changed these parameters:

#Decrease aggressiveness of bring cores online

echo '100' > /sys/module/auto_hotplug/parameters/disable_load_threshold

echo '250' > /sys/module/auto_hotplug/parameters/enable_load_threshold

echo '550' > /sys/module/auto_hotplug/parameters/enable_all_load_threshold

#Increase sampling rate

echo '30' > /sys/module/auto_hotplug/parameters/min_sampling_rate

echo '20' > /sys/module/auto_hotplug/parameters/sampling_periods

This means that cores are brought offline slightly earlier, one extra core is brought online less often, and all 4 are brought on much less often (my conclusion from running as a dual core device is that 4 cores are rarely needed - if we need them for the speed boost, this parameter will bring them all online under heavy load.)

The second lot of parameters increases the time between samples, meaning that by nature its less likely to change cores as often. I don't truly understand sampling periods, but I'm giving it a shot.

Naturally these parameters are more tuned to battery than performance - as motley kernel performs the best out of all kernels without mpdecision, I thought I would try and squeeze some more battery without affecting performance too badly by just controlling hotplugging some more. Hotplugging random off/onlining is only sure to decrease battery futher as the process itself is energetically expensive. I haven't noticed too much of a difference in UI performance, but I don't game.

Let me know if anyone uses these and what they think. I think there's improvements to be made here.
[Nexus 4 Android Development] ckret:
gonna implement them in my boot script and test it for some days
[Nexus 4 Android Development] thracemerin:
I've been hesitant to adjust the default hotplugging values because people are always saying that motley's implementation is the smoothest non-mpdecision kernel, but if we can find a new set that keeps the smoothness but gives us slightly better battery life I'm all for it.
[Nexus 4 Android Development] Remoteconcern:
Yep. I totally understand but there's definitely some improvements to be made.

The settings I have right now appear to be slightly too aggressive, I think I can detect a small stutter in animations every so once in a while. So I'll probably make them slightly less battery friendly and see if I can get the performance back. Will post more once I've done that.
[Nexus 4 Android Development] iPwn_:
I don't know about the overall effect on battery life, but I'm not seeing any loss in smoothness with the new hotplugging settings with hisped_freq in Interactive at 1350 MHz. (with boostpulse at 2 seconds).
[Nexus 4 Android Development] thracemerin:
Keep me updated, I'm running some tests on this stuff too :good:
[Nexus 4 Android Development] Remoteconcern:
My boost pulse is at default, at 0.2s I believe. It's fairly smooth but is quite a lot better at 0.5s, however I want to test the hotplug values with the default kernel settings really.

My usage isn't controlled today, so I can't comment on battery but from what I observed on the hot plug behaviour I think it should help.
[Nexus 4 Android Development] thracemerin:
I was away all week so there probably won't be an official build tomorrow since I had 0 minutes to work on it until today (and the latest alpha I built for myself is far from being ready even for a wider test), but if you grab me some numbers to test in the next few days I can always throw up an alpha for others to test :)
[Nexus 4 Android Development] Ace42:
Have you solved the bug with lower frequencies?
[Nexus 4 Android Development] thracemerin:
You mean where they don't seem to be being set? Unfortunately no, it may be a hardware restriction that can't be changed.
[Nexus 4 Android Development] Ace42:
Do you think other kernel devs will stop adding unsupported frequencies?
[Nexus 4 Android Development] sirxdroid:
They should if they are useless and don't work anyway :)
[Nexus 4 Android Development] thracemerin:
That depends, show-p1984 was the one who pointed out initially that it didn't seem to work yet he still has 162MHz available on his kernel, so I'm really not sure whether it does or not. What I can say is that there should be a performance loss and battery life gain with lower frequencies but neither of those things seem to happen in my testing.
[Nexus 4 Android Development] Ace42:
Two more question I promise, why was there never a 6xxmhz and would you add a entrophy toggle like faux?

And Thanks for being so cooperative, sometimes I receive responses that are well not so helpful. :highfive:
[Nexus 4 Android Development] thracemerin:
I'm not sure why there isn't a 6xxMHz frequency, but i figure since a lot of the intermediate steps aren't used a lot Qualcomm/LG/Google felt there wasn't any real need to add more steps.

I don't know what to think about all the entropy stuff that's been going around, some people say it makes their device faster, others say it's placebo, some say it makes your device less secure, others say more secure. I believe that on older devices with single or dual cores and lower clock speeds that some of these patches may in fact improve performance at least a little, but on a device with as much computing power as the N4 they are unlikely to have a measurable real world improvement, but I'll do some more research and see if they are worth putting in.

There's no need to worry that you're bothering me with questions, if I'm busy I wont respond :)
[Nexus 4 Android Development] rlaw:
#!/system/bin/sh

# disable eMMC entropy contribution

echo 0 > /sys/block/mmcblk0/queue/add_random

Not a toggle but you can throw this script in init.d
[Nexus 4 Android Development] Remoteconcern:
Here are the slightly updated parameters. Seem equally snappy with less random core changing. Battery life untested yet but I don't think it will be worse.
[Nexus 4 Android Development] thracemerin:
Serious question, does anyone use this kernel with fsync completely off? I'm curious because with dynamic fsync available it seems redundant and is being bothersome for some of the changes I'm trying to make, if you do use fsync off please say so so I don't remove a feature people use.
[Nexus 4 Android Development] efan3719:
I turn it off for the supposed performance increase but I probably wouldn't miss it if it was gone.
[Nexus 4 Android Development] Ace42:
I turned it off now since dynamic is enabled.
[Nexus 4 Android Development] thracemerin:
Well, with dynamic fsync on, it's technically off when the screen is on anyway.

To be more specific about my problem, the fsync system is barfing up all sorts of random errors when I try to build it with linaro 4.8.1 and I'm trying to see if it's worth my time to squash them all.
[Nexus 4 Android Development] IAmAN00bie:
It's not worth keeping, IMO. Only people who are really obsessed with benchmark scores would even use it. The very minimal performance gains you get don't even translate to real world improvements you would notice, but with the risk of data loss on a crash it's just not worth it.
[Nexus 4 Android Development] sirxdroid:
I even turn off the dynamic fsync. I value my data way more than benchmarks.
[Nexus 4 Android Development] thracemerin:
With the changes that faux made recently to dynamic fsync, i think its reasonably safe since it stores the caches when a reboot happens unexpectedly. I'm going to be adding them regardless of how this works out, its just easier if i can remove the fsync control.
[Nexus 4 Android Development] rlaw:
I do.
[Nexus 4 Android Development] thracemerin:
Do me a favor, switch to dynamic fsync and see if you notice a performance difference, I'm curious because I don't notice one.
[Nexus 4 Android Development] ctfrommn:
The only difference is in benchmark scores

Sent from my blazing bionic Nexus 4
[Nexus 4 Android Development] thracemerin:
In theory having it off should improve I/O performance overall, but it all depends on how much I/O you're using, generally under normal circumstances fsync on and fsync off will have little noticeable difference. With dynamic fsync you get the performance boost from no fsync while the screen is on, but when it goes off it syncs up thus protecting you from a corruption if you crash or SOD.
[Nexus 4 Android Development] ctfrommn:
Agree completely... I have it off all the time, but I've never seen a real world difference.

Sent from my blazing bionic Nexus 4
[Nexus 4 Android Development] thracemerin:
Benchmarking is really the only time the I/O gets pushed hard, unless you're transferring big files via MTP or something.
[Nexus 4 Android Development] Kocai:
I'm curious, if we set fsync off, dynamic fsync will be off too right. What if you remove fsync and then people who want fynsc off can just turn off dynamic fsync? Wouldn't that just be the same? I never have fsync off but I always think it's redundant to have both fsync and dynamic fsync since if we set fsync off, enabling dynamic fsync would be useless.
[Nexus 4 Android Development] karanrajpal14:
Well I don't use it. One more doubt, can someone explain what the values in touch screen filter do? I've searched around but I never found a proper explanation. Or maybe some tweaked values if someone's toyed around with them. Thanks!
[Nexus 4 Android Development] Remoteconcern:
I still use fsync off, but I've just changed it to dynamic. I don't bench so I don't even really know why I ran it off, other than I assumed it would be faster and I've never had data corrupt.

I think it's probably safe to remove the toggle short term, but I think it would be nice to have the option really.
[Nexus 4 Android Development] thracemerin:
Ok, so there won't be an official build this week since there were no alphas as I was out of town and I'm still working out a few issues on my private testing branch before I even release an alpha.

But, since I felt like providing something for you crack flashers, there is a new alpha in Post 4.

All this is is a proof of concept build compiled with gcc 4.8.1 from Linaro, I want to see if there are significant bugs or performance issues before I decide to stay with 4.8.1 in the future. It is exactly the same as Build 7 in every way except the couple of minor things I had to do to get it to boot, since I know that Build 7 had no major bugs, any that appear now will probably be toolchain related and I'll have to look into and squash them, so the more people who get involved in this effort the better :D

Anyway, happy flashing! :victory:
[Nexus 4 Android Development] caaznkid:
Anyone else not able to uv as much on b7 vs prior releases?
[Nexus 4 Android Development] thracemerin:
I found an issue where UV below 850mV wasn't being set due to a restriction in the system regulator, so even if you had 600mV set it was actually 850mV. I fixed the issue and I highly recommend resetting to default and redoing any testing on UV you did prior to b7.
[Nexus 4 Android Development] thracemerin:
Another question for long time users, is anyone having issues with 3G data drops or lockups? I guess people in other kernels using a similar set of patches for msm_hsic_host wakelocks are reporting problems and I'm trying to determine if it's the patches I used or something else those kernel authors have added.
[Nexus 4 Android Development] superleeds27:
Goo down again!
[Nexus 4 Android Development] thracemerin:
Yeah, so is dev-host.
[Nexus 4 Android Development] veyka:
I do get some network issues from time to time, though the new 54 radio seems to have helped make things a bit more reliable, tbh it is really hard to tell where the issue lies, network, radio, or kernel. I have not had any major data stalls (the old stuck arrow one before the full patch set was used) in a good while, so I don't think anything new is broken.

One thing, have you ever considered comparing franco's hotplug with the current implementation we use? It does sound like he's tightly bound it to bits of the interactive governor now though.

Ps good job Tapatalk on making the UI generally not suck (though you need to use the new style draw please), bad job on forgetting in thread search, and for forgetting to fix performance.
[Nexus 4 Android Development] thracemerin:
Yeah, network issues are particularly hard to nail down as there are so many variables involved that are outside of the device (tower position & line of sight, providers network structure and load, etc...) but I guess franco is saying in my other thread that he was having some issues in his thread and he thought he rebased his hsic_fix to my base and people continue to have the problems, so I'm not sure if it's something he did or something in the base patch set I figured out or what.

I've been thinking about franco's hotplugging system, but he tied it into both the interactive governor and the touchscreen driver which isn't necessary a problem, but it means that more things have to be rebased every time I want to make a change to those drivers.
[Nexus 4 Android Development] FeintDoxx:
I have been noticing some data drops recently. I may not have the best reception inside my house but it is still suffice but recently its been lacking.
[Nexus 4 Android Development] thracemerin:
Is B7 worse than B6? or is lately a longer term than that?
[Nexus 4 Android Development] Remoteconcern:
I had a data stall today after I read these messages. Had to toggle airplane mode. However haven't had one prior to that that I have noticed.

Ezekeel wrote a very simple hotplug driver for the nexus 7 which I think works quite well. It either has one core, or four cores online and it's quick and battery friendly. Maybe we could look further afield for a different implementation ? I'm not convinced that the hotplug driver we have now is great - I think mpdecision is still the best actually.
[Nexus 4 Android Development] thracemerin:
Yeah, I think all the mpdecision haters were wrong honestly, it may seem to be an awkward and bad implementation, but mpdecision + ondemand is one of the smoothest combinations from a UI perspective that I've seen, but people like to tweak every aspect of their phone to the point that having their hotplugging in a black box upsets them.
[Nexus 4 Android Development] ctfrommn:
I rarely use non mpdecision kernels anymore other than to play with. It doesn't get much better for daily driving. Franco's is probably the best non mpdecision implementation of it.

Sent from my blazing bionic Nexus 4
[Nexus 4 Android Development] thracemerin:
I'm not against going back to mpdecision, I kept thalamus' hotplug because that's what _motley had and I was trying to avoid taking a battering ram to the entire kernel.
[Nexus 4 Android Development] veyka:
I would also be interested in trying out a version with mpdesison/ondemand as well, it's been a while and I would miss other bits of the kernel to much to spend to much time on cm stock (Mostly colour and gamma stuff)
[Nexus 4 Android Development] thracemerin:
I would have to fix the ramdisk for this because mpdecision is stopped on boot by the ramdisk, but it's doable, auto_hotplug touches very little outside of itself.
[Nexus 4 Android Development] Ace42:
I don't see mpd being needed for a "smooth UI". If you use Sabermod and any non-mpd kernel and lets say two cores only @1.2Ghz it'll still be surprisingly smooth because of all the optimizations Sparksco has merged. Now take the same cpu setup and stick them into a stock rom or un-optimized rom and you'll have a laggy experience.

Also I wanted to know if you have not noticed the cons of MpD, personally when I used it on stock ROM battery was terrible, and the phone's abnormal temps irritated my hands. I like the non-mpd kernels, because I trust the devs with their implementations, and come on can we really put so much trust into the same people that created this mini furnace w/ all the USB wakelocks and terrible 3G drain? :cowboy:
[Nexus 4 Android Development] veyka:
We would need the thermal binary as well right? It would be nice to try maybe even have it as an option or at least as a test build if you get the time!
[Nexus 4 Android Development] thracemerin:
Sabermod itself includes a lot of Krait and other optimizations at the ROM level that allow the OS to be smoother, those would still exist on an mpdecision kernel and might in fact be better. The heat issues, etc... that a lot of people say are problematic on mpdecision can be mitigated as well with undervolting, etc...
[Nexus 4 Android Development] thracemerin:
I'm fairly certain that mpdecision doesn't work without thermald, and if it does who knows what the results might be.
[Nexus 4 Android Development] sirxdroid:
I agree completely with the mpdecision + ondemand combo being the smoothest experience. Let's see what Google has in store for the next kernel. They might switch to interactive, that's the default on the N7 for example.

To me it doesn't matter that mpdecision is closed source as long as it works as well as it does. Why would I want to use an open source daily driver that does not perform as well?

And there's the kitchen sink community kernel, if people want to play with different combos :)
[Nexus 4 Android Development] veyka:
Tbh, qcom know their stuff, and for the most part put out what people say is good code, a lot of the problems with the N4 are due to it using a SoC designed for tablets with a modem glued to it over the USB bus, lets hope when 4.3 hits it will have a working wifi driver (thats a big wtf tbh) and more work done on the HSIC issue.

Yeh, makes sense, well if you have time ;)
[Nexus 4 Android Development] FeintDoxx:
It seems to be worse from before when I B6. I'm going to test out radio .54 and see how things go I heard it helped reception with others. I'll keep you posted.
[Nexus 4 Android Development] thracemerin:
I did mess with the hsic patches again between B6 and B7 so its possible something got goofed, but the patches I added have been in my other kernel (stock with hsic fixes) for months with nobody complaining about it, so I don't know, signal issues are so random.

There was an article I read about mpdecision that said it did most of it's calculations and communications via a separate channel where in kernel hotplugging has to use the CPU,etc... So in kernel hotplugging routines add load to an already loaded system when they perform the operations necessary to online more cores, mpdecision doesn't need to do this.

As for the other stuff, I'm beginning to think we may have to wait for the N5 to fix the fact that they took a tablet SoC and tried to make it into a phone, there are just stupid hardware implementations that aren't going to be fixable on this SoC, doesn't mean we don't deserve the best possible solution, but the best possible isn't going to be a complete solution I don't think.
[Nexus 4 Android Development] sirxdroid:
Is there a secret core that mpdecision uses to make the calculations? :) Or maybe it uses the GPU :) From what I understand mpdecision runs as a separate process and talks to the kernel via unix sockets. If it's a process, it's gotta run on the CPU, I don't understand how mpdecision doesn't add the same load for the same calculations that would be performed in kernel.