[DEV-Notice] Dual Core Support In OC Kernels.

---

This thread was created to try to consolidate all the issues from Faux123's thread, since he started looking into the information I will quote some of his posts here.

I am trying to get to the bottom of this issue and see if we can get this resolved so we can get proper kernel support. Since currently Kernels that are available only appear to affect one CPU and its governor.

Below is a list of commands you can run from ADB and report the issue
(make sure to include the ROM, Kernel, and command output)

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq
cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq
cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

cat /sys/devices/system/cpu/cpu0/online
cat /sys/devices/system/cpu/cpu1/online

----------------------------------------------------------------------

So here are some to the posts between me and Faux123 about the issue with further detail.

Originally Posted by BrokenWall

So I installed your latest kernel on Senseless 1.3

Settings: MIN and MAX set to 1512Mhz with Performance gov

When running CF-Bench and letting it run I ran the following commands in an ADB Shell.

#cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1512000
#cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq
972000
#cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq
384000

#cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
#cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
ondemand

Also you have to run a test that will stress both cores, because CPU1 doesn't show available unless under load, so benches like Quadrant don't even stress the second CPU

Originally Posted by BrokenWall

The issue is that MSM8260 is not the same style Symmetric CPU that Tegra and SGSII use, instead the MSM8260 is a asymmetric multiprocessing unit. if you watch the CPU1 cur freq during benchmarking you will see that it will never hit the maximum speed of 1512Mhz

During linpack the score for multi-threaded goes up but it does not go in line with what should be possible at the proper speeds.

...

I have been testing this multiple times, I am not a developer nor do I claim to be. But I can tell you I know hardware, and I research the issues, and this issue is related to any kernel at the moment by ANY dev.

==================

Quote from Fuax123 after he looked into the issue.

Originally Posted by faux123

Ok, you are correct. I finally got my lazy ass off the chair and downloaded available snapdragon documentations online (I Hate qualcomm for making it so difficult to find any technical information regarding their chipsets). This is a quote from the document: "The 8x60 incorporates an asynchronous dual CPU core SMP (aSMP) micro-architecture"

I hate Qualcomm for trying to say their chipset is better than > SMP chipset yet they still use the acronym aSMP to confuse people What da heck is "asynchronous dual CPU core SMP", this is the absolute WORST BS marketing term....

Anyways, I am still blaming the OC apps (SetCPU, CPUMaster, OC Daemon etc) for not correctly set the CPU scaling properties for the 2nd CPU. Maybe all the authors for these apps were as confused as me by STUPID Qualcomm marketing terms and thought they were dealing with SMP but in fact, they were dealing with 2 separate independent CPUs on a single die. One can simply do:

echo smartass > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

to set the cpu1's scaling governor to the same governor as CPU0 so both cpus can operate using "similar" governors for better "synchronous" operations.

Maybe you should contact the authors for the OC apps and have them fix their apps I am not sure what needs to be fixed on the kernel side...

And the final note:

Originally Posted by BrokenWall

So I tried this, you are unable to modify or create this file while CPU1 is asleep. Our problem is that the way the SoC is that no matter if you do it manually or with any overclock software, it will not affect CPU1 speeds.

We need to find a way for CPU1 to stay awake, or else we will just have a single fast core and a second core at default speeds..

I tried creating the files needed to set the CPU1 speed directly and it deleted them after the CPU went asleep.

while at idle on homescreen:

cat /sys/devices/system/cpu/cpu0/online = 1
cat /sys/devices/system/cpu/cpu1/online = 0

underload on CF-Bench:

cat /sys/devices/system/cpu/cpu0/online = 1
cat /sys/devices/system/cpu/cpu1/online = 1

after bench is over back on homescreen:

cat /sys/devices/system/cpu/cpu0/online = 1
cat /sys/devices/system/cpu/cpu1/online = 0

While the benchmark was running I was able to change the profile for the governor but was unable to manually overclock the CPU and even running any of the apps while the CPU1 was online still failed to set a speed.

I think it may be in fault to the software as well as HTC kernel drivers as well.

Originally Posted by faux123

I just read through kernel SMP and CPU Hot plugging. It seemed there might be a bug in CPU hot plugging for SMP operations (esp for such strange beast as the new aSMP snapdragons). Hot plugging support was originally designed as a fail safe for removing failed CPUs in a CPU farm, but recently, it has been used in SMP systems where they used the hot plugging capability to actively add/remove CPUs as means of power saving by talking an idling CPU "off line". According to Linux kernel documentation, the use of this feature for SMP power management was never intended and it is an on going experimental feature.

I briefly looked at the kernel cpufreq driver and saw nothing obvious. One way of resolving the cpu1's randomness with governors and scaling frequencies is to DISABLE the hot plug feature and just have cpu1 running at all times (idling is considered running) rather than declare cpu1 to be offline completely. The bug seemed to be when restoring the cpu1 back online, the governor and scaling frequencies are NOT restored properly (but from the kernel code, it looks fine the way the code was written. The kernel driver tried to restore the governor and frequencies from a saved data structure).

Originally Posted by faux123

It turned out it is not as easy to disable hotplug cpu from SMP. The kernel source has made some assumptions that if SMP is enabled, hotplug must be enabled. This has let to a few compilation errors. I am making edits to the kernel source to separate the 2 without breaking anything. Once I am able to cleanly separate them, I will make a test kernel with cpu hotplug disabled while SMP is running.

Originally Posted by faux123

I just read thru the entire MSM clocking / Power management code... Whew!

The aSMP dual core CPU is not as straight forward as the old single core CPU in terms of Overclocking. It is a lot more complicated than simple frequency edits and setting the max frequencies. The new AVS (adaptive-voltage scaling, Power management all try to mess with the clocking scheme). All current overclocking schemes for this CPU have bugs and issues including mine (kanged from cayniarb).

I will revert all existing OC technique from my source code and start from scratch!

BTW, all CPU overclocking utilities have issues with this aSMP CPU. They will screw up the CPU1's governor and min/max frequencies, essentially crippling your dual core CPU to having only CPU0 switching properly and the other core (CPU1) will be stuck @ 972 MHz max with random governor running.

My recommendation for now. DO NOT use any overclocking app (SetCPU, CPUMaster) until either either the kernel is patched correctly or the apps are updated to work with aSMP CPU's quirkiness. Also the only governor that is patched correctly to work with the new aSMP CPU is the OnDemand Governor, all other governors have not been patched properly including my newly patched SmartAss governor. Further patches are required for the other governors to function properly with this new STRANGE beast

So this is a thread to bring attention to all developers so we can try to get to the bottom of this. The reason is that I see people on the forums talking about benchmarks and this and that.

Goals is to see if we can get the second core to stay on. if not, see if we can at least get the second core to abide by the OC and Governor settings.

As of right now the best kernel to use is the HTC Stock kernel, since it uses Ondemand by default for both cores. Other governors haven't been patch for proper aSMP support.

you can see the performance possible in the following post: http://forum.xda-developers.com/show...5&postcount=28

This is very interesting reading!

You might be also interested in one entry in ramdisk init.pyramid.rc

service mpdecision /system/bin/mpdecision --no_sleep --avg_comp --single_core_while_panel_off
user root
disabled

Originally Posted by mike1986.

This is very interesting reading!

You might be also interested in one entry in ramdisk init.pyramid.rc

service mpdecision /system/bin/mpdecision --no_sleep --avg_comp --single_core_while_panel_off
user root
disabled

Is this an option we can set outside of the RAMdisk and reboot? via ADB or terminal emulator?

Originally Posted by BrokenWall

Is this an option we can set outside of the RAMdisk and reboot? via ADB or terminal emulator?

No, you need to change it in ramdisk and flash the whole boot.img otherwise if you remove --single_core_while_panel_off it will be back after reboot.

BTW --single_core_while_panel_off was added in the latest 1.45 update, in 1.35 it was only:

service mpdecision /system/bin/mpdecision --no_sleep --avg_comp
user root
disabled

Originally Posted by mike1986.

No, you need to change it in ramdisk and flash the whole boot.img otherwise if you remove --single_core_while_panel_off it will be back after reboot.

BTW --single_core_while_panel_off was added in the latest 1.45 update, in 1.35 it was only:

service mpdecision /system/bin/mpdecision --no_sleep --avg_comp
user root
disabled

The problem that I have found on both 2.3.3 and 2.3.4 is that CPU1 turns off while idle at homescreen, not unless an application can stress both cores or the load gets heavy enough does CPU1 wake.

CF-Bench will bring CPU1 alive at the start of the bench and even register two cores, where the crappy Quadrant will only notice 1 core and will not always wake the second core.

And I noticed this problem with Faux123 Kernel, Unity Kernels (both 2.3.3 and 2.3.4 versions), and there was a third kernel that was affected. I am going to start checking other kernels. But it appears that all kernels based on HTC Source are setup this way and its over looked.

If someone could try building a test kernel with the listed changes it would be appreciated and I would be willing to test it and report the changes in this thread.

This is very interesting. I think with some research and a resolution this could greatly increase performance of the cpu and the battery. With both cores dividing the stress when needed and then only using one core while in idle or screen off could greatly improve battery life. I have a desk job and am always bored and testing things on my phone so I will be glad to test and return with any info I find. I'm subscribed.

I am so excited to see this issue get resolved cause I also noticed how CPU1 turns off all the time and it irritates me.

I'm a power user, so regardless of battery life I just want both my CPUs to always stay on at max freq.

Originally Posted by mike1986.

No, you need to change it in ramdisk and flash the whole boot.img otherwise if you remove --single_core_while_panel_off it will be back after reboot.

BTW --single_core_while_panel_off was added in the latest 1.45 update, in 1.35 it was only:

service mpdecision /system/bin/mpdecision --no_sleep --avg_comp
user root
disabled

I'm glad you put your attention to this immediately Mike. Cause your ROM is already amazing anyway and I can't wait to see it work with new kernels using better dual-core support.

@ OP: I agree the best kernel is the stock one, unfortunately the 2.3.4 stock kernel has a major bug that screws up 3D gaming. So if one wants to play games, you need to use a custom kernel otherwise you will notice horrid graphic rendering (i.e. Cordy)

Like faux123 noted, ive been doing a lot to rewrite and clean up the acpuclock-8x60.c file -- the frequency/voltage tables in particular, but really large pieces of it as well. There are some interesting items in there and nearby (mach-msm .h files) that may prove helpful here -- can't think of them off the top of my head and im not able to look right now, but this is *definitely* something i want to help resolve.

Qualcomm was always up front (e.i. liked to brag) about theirs being the first (and currently only) asynchronous dual-core chip for ARM. I've kinda been afraid that this was the issue all along and really just tried avoiding looking for it...

Intel and AMD chips are all (or i think all) asynchronous, so there should be no shortage of code to look at for this (granted, not *exactly* what we want, but thats the fun, right?).

Please come find me on IRC and get me off my a$$ to work on this.