A quick poll of the ARM platforms that implement CPU Hotplug support
shows that every platform treats CPU 0 as a special case that cannot be
hotplugged. In fact every platform has identical code for
platform_cpu_die which returns -EPERM in the case of CPU 0.
The user-facing sysfs interfaces should reflect this by not populating
an 'online' entry for CPU 0 at all. This better reflects reality by
making it clear to users that CPU 0 cannot be hotplugged.
This patch prevents CPU 0 from being marked as hotpluggable on all ARM
platforms during CPU registration. This in turn prevents the creation
of an 'online' sysfs interface for that CPU.
Signed-off-by: Mike Turquette <mturquette(a)ti.com>
---
arch/arm/kernel/setup.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index ed11fb0..a5fc969 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -940,7 +940,8 @@ static int __init topology_init(void)
for_each_possible_cpu(cpu) {
struct cpuinfo_arm *cpuinfo = &per_cpu(cpu_data, cpu);
- cpuinfo->cpu.hotpluggable = 1;
+ if (cpu)
+ cpuinfo->cpu.hotpluggable = 1;
register_cpu(&cpuinfo->cpu, cpu);
}
--
1.7.4.1
This patch series introduces a new cpumask which tracks CPUs that
support hotplugging. The purpose of this patch series is to provide a
simple method for kernel code to know which CPUs can be hotplugged and
which ones cannot. Potential users of this code might be a thermal
mitigation technique which uses hotplug to lower temperature, or a power
capping mechanism which uses hotplug to lower power consumption.
All the of usual cpumask helper functions are created for this new mask.
The second patch in this series simply sets the bit for elligible CPUs
while they are being registered. The cpumask itself is static after
boot and should not change (like the possbile mask).
Mike Turquette (2):
cpumask: introduce cpumask for hotpluggable CPUs
cpu: update cpu_hotpluggable_mask in register_cpu
drivers/base/cpu.c | 4 +++-
include/linux/cpumask.h | 27 ++++++++++++++++++++++-----
kernel/cpu.c | 18 ++++++++++++++++++
3 files changed, 43 insertions(+), 6 deletions(-)
--
1.7.4.1
Key Points for wider discussion
=======================
JPEG pictures now can be viewed on Android platform with
libjpeg-turbo successfully.
Toolchain now supports CLooG-ISL and OpenMP.
Team Highlights
=======================
Move to Android 2.3.5 is proceeding good.
libvpx 0.9.6, x264, ffmpeg is building for Android.
Linaro Android for Samsung Origen board is building (but not booting yet).
ADB and androidscreencast is working on Snowball.
Miscellaneous
=======================
Mathieu Poirier is with us!
Zach on vacation from 21st-24th, Tony on 11:th.
Code complete planned for the 18:th.
Hi there. One of our goals in toolchain is to give good support to
the Android group. I've written a page from the toolchain perspective
on what is Android, how do you build it, and how you do common
toolchainy tasks like reproduce a compiler fault:
https://wiki.linaro.org/MichaelHope/Sandbox/AndroidAndToolchain
Comments are welcome. It needs sections on how the compiler is
configured, running a program using adb, and basic debugging.
-- Michael
Hi,
while working on some improvements, I noticed that our Android
toolchain binaries are built as 32-bit x86.
Is there any reason for this (other than "we inherited it from AOSP")?
While it doesn't matter much, it doesn't make much sense to me -
Android can't currently be built on 32-bit machines (so it's not about
having one binary that will work for mostly everyone - but I suspect
that's exactly where it started back in the times of Android 1.0), so
why introduce dependencies on a 32-bit libc and slow things down
slightly?
If nobody complains, I'll remove the "-m32" flag from the Android
toolchain builds - let's see how much we can speed up the build
process itself without putting any real work into it...
ttyl
bero
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Amit,
Here is the example output with the test description. The email wraps
the lines, actually each test are one line output.
Let me know if it is ok for you.
Thanks
-- Daniel
[ ... ]
###
### cpufreq_04:
### test the change of the frequency is effective in 'userspace' mode
###
cpufreq_04.0/cpu0 checking setting frequency '2.6 GHz'...
PASS
cpufreq_04.1/cpu0 checking setting frequency '2.6 GHz'...
PASS
cpufreq_04.2/cpu0 checking setting frequency '2.0 GHz'...
PASS
cpufreq_04.3/cpu0 checking setting frequency '1.6 GHz'...
PASS
cpufreq_04.4/cpu0 checking setting frequency '1.2 GHz'...
PASS
cpufreq_04.5/cpu0 checking setting frequency '800.0 MHz'...
PASS
cpufreq_04.0/cpu1 checking setting frequency '2.6 GHz'...
PASS
cpufreq_04.1/cpu1 checking setting frequency '2.6 GHz'...
PASS
cpufreq_04.2/cpu1 checking setting frequency '2.0 GHz'...
PASS
cpufreq_04.3/cpu1 checking setting frequency '1.6 GHz'...
PASS
cpufreq_04.4/cpu1 checking setting frequency '1.2 GHz'...
PASS
cpufreq_04.5/cpu1 checking setting frequency '800.0 MHz'...
PASS
###
### cpufreq_05:
### test 'ondemand' and 'conservative' trigger correctly the
configuration directory
###
cpufreq_05.0/cpu1 checking 'ondemand' directory exists...
PASS
cpufreq_05.0/cpu1 checking 'conservative' directory exists...
PASS
cpufreq_05.0/cpu1 checking 'ondemand' directory is not there...
PASS
cpufreq_05.1/cpu1 checking 'conservative' directory is not there...
PASS
cpufreq_05.2/cpu1 checking 'ondemand' directory exists...
PASS
cpufreq_05.3/cpu1 checking 'conservative' directory exists...
PASS
###
### cpufreq_06:
### test the change of the frequencies affect the performances of a test
program
###
cpufreq_06.0/cpu0 checking deviation for frequency 2.6 GHz...
PASS
cpufreq_06.1/cpu0 checking deviation for frequency 2.6 GHz...
FAIL
cpufreq_06.2/cpu0 checking deviation for frequency 2.0 GHz...
FAIL
cpufreq_06.3/cpu0 checking deviation for frequency 1.6 GHz...
PASS
cpufreq_06.4/cpu0 checking deviation for frequency 1.2 GHz...
FAIL
cpufreq_06.5/cpu0 checking deviation for frequency 800.0 MHz...
FAIL
cpufreq_06.0/cpu1 checking deviation for frequency 2.6 GHz...
PASS
cpufreq_06.1/cpu1 checking deviation for frequency 2.6 GHz...
FAIL
cpufreq_06.2/cpu1 checking deviation for frequency 2.0 GHz...
FAIL
cpufreq_06.3/cpu1 checking deviation for frequency 1.6 GHz...
PASS
cpufreq_06.4/cpu1 checking deviation for frequency 1.2 GHz...
FAIL
cpufreq_06.5/cpu1 checking deviation for frequency 800.0 MHz...
FAIL
###
### cpufreq_07:
### test the load of the cpu affects the frequency with 'ondemand'
###
cpufreq_07.0/cpu0 checking 'ondemand' increase frequency on load...
PASS
cpufreq_07.1/cpu0 checking 'ondemand' decrease frequency on idle...
FAIL
cpufreq_07.0/cpu1 checking 'ondemand' increase frequency on load...
PASS
cpufreq_07.1/cpu1 checking 'ondemand' decrease frequency on idle...
PASS
###
### cpufreq_08:
### test the load of the cpu does not affect the frequency with 'userspace'
###
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOQu00AAoJEAKBbMCpUGYAK70IAJMaNajxLrAR4tLlv4aFyFHl
DB9M0pX4OgLmxVJ18zGR5oOr/IzjXXMZTrJrfQJre0DLzCi/yur0wJntJFEUbUy/
M/xHJFBEEY8GX7wxws5LGaR9b/ASGfax4LZVo85CAldaHCl6QzTXolsj/IRvB/r+
uVoCToUMWQT2oaOwW7q9U1ItBPgFb0yTrqTcz1jgC3IMFPNh867sRH/z+UFfHzF6
yBaZ34E5bNO/VGQuGOmWp5vEl//KlvGmGAKPWb/KxHD0gEwVoF+2gf+fWvdOf9sD
CC23Hc5FnqrP5SaRLwHRuO7NcxIX2ooUADn6ojN3SJm0nN/qx3qMyTMqakfkxgk=
=4oGS
-----END PGP SIGNATURE-----