This is targetted for 3.10-rc1 or linux-next just after the merge window.
All patches are pushed here for others to apply:
http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/h…
Currently, there can't be multiple instances of single governor_type. If we have
a multi-package system, where we have multiple instances of struct policy (per
package), we can't have multiple instances of same governor. i.e. We can't have
multiple instances of ondemand governor for multiple packages.
Governors directory in sysfs is created at /sys/devices/system/cpu/cpufreq/
governor-name/. Which again reflects that there can be only one instance of a
governor_type in the system.
This is a bottleneck for multicluster system, where we want different packages
to use same governor type, but with different tunables.
This patchset is inclined towards fixing this issue. Now we will create
governors directory in cpu/cpu*/cpufreq/<gov> for platforms which have multiple
struct policy alive at any moment. For others the interface is kept same:
cpu/cpufreq/<gov>.
V1->V2:
- Few patches from V1 are already picked up by Rafael for 3.9-rc1
- Last two patches are new
- Added dbs_data->exit() routines to free up memory used for struct tuners.
@Rafael: I don't really want to have following patch: "cpufreq: Add Kconfig
option to enable/disable have_multiple_policies" and added it because of comment
from Borislov against which nobody else replied :)
I still want to have your opinion on the same.
Viresh Kumar (4):
cpufreq: Add per policy governor-init/exit infrastructure
cpufreq: governor: Implement per policy instances of governors
cpufreq: Add Kconfig option to enable/disable have_multiple_policies
cpufreq: Get rid of "struct global_attr"
drivers/cpufreq/Kconfig | 3 +
drivers/cpufreq/acpi-cpufreq.c | 9 +-
drivers/cpufreq/cpufreq.c | 27 +++--
drivers/cpufreq/cpufreq_conservative.c | 148 +++++++++++++---------
drivers/cpufreq/cpufreq_governor.c | 159 ++++++++++++++----------
drivers/cpufreq/cpufreq_governor.h | 43 +++++--
drivers/cpufreq/cpufreq_ondemand.c | 216 +++++++++++++++++++--------------
drivers/cpufreq/intel_pstate.c | 30 ++---
include/linux/cpufreq.h | 44 ++++---
9 files changed, 402 insertions(+), 277 deletions(-)
--
1.7.12.rc2.18.g61b472e
Hi; does anybody else think it would be a good idea to move all
the kernel patch email traffic off linaro-dev and onto a more
kernel-specific mailing list (eg, linaro-kernel, maybe) ?
A quick eyeball of a few pages of my gmail folder for linaro-dev
shows that something like 75% of it is kernel devs patchbombing
the list. You don't see huge floods of patches here for gcc or
QEMU or any of the many other projects Linaro contributes to,
so why all the kernel patches?
I think that moving these off to their own list would allow
those who have a genuine interest in kernel internals to read
and review these patches, and reduce the noise level on this
(Linaro's most generic list) for everybody else.
NB: I'm not suggesting "no kernel discussion here"; I just
would like actual patchmail to go elsewhere...
thanks
-- PMM
Hi,
I am working on identifying the different wakeup sources from the
interrupts and I have a question regarding the timer broadcast.
The broadcast timer is setup to the next event and that will wake up any
idle cpu belonging to the "broadcast cpumask", right ?
The cpu which has been woken up will look for each cpu the next-event
and send an IPI to wake it up.
Although, it is possible the sender of this IPI may not be concerned by
the timer expiration and has been woken up just for sending the IPI, right ?
If this is correct, is it possible to setup the timer irq affinity to a
cpu which will be concerned by the timer expiration ? so we prevent an
unnecessary wake up for a cpu.
For example, let's say we have a 2 cpus system.
cpu0, cpu1 are idle
The next event is for cpu1 but cpu0 is wake up by the broadcast timer,
after checking it has nothing to do except send a IPI_TIMER to cpu1 and
then goes to idle again.
Wouldn't be worth to set the broadcast timer affinity to cpu1, so cpu0
is not wake up ?
Did I missed something or does it sound correct ?
Thanks
-- Daniel
--
<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
Calendar Week 8, 2013: Here is test result summary for Linux Linaro ubuntu
Quantal image on following boards:
1) ARM Versatile Express A9;
2) Samsung Arndale;
3) TI Panda 4430;
4) TI Panda 4460;
5) ST Ericsson Snowball.
Synopsis: Kernel version on TI Panda platform has been upgraded to
"3.8.0-1-linaro-omap",
but many issues occurred on TI Panda 4430 and even boot failed on TI Panda
4460. Boot loader on STE Snowball has been upgraded to "U-Boot 2013.01.-rc1
".
1. ARM Versatile Express A9 + Linux Linaro Quantal (Column L):
https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdFNmV…
It keeps exactly same status from calendar week 50 last year: only "Halt" &
"Device Tree" test failed, all other features work well.
2. Samsung Arndale + Linux Linaro Quantal (Column F):
https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AgB-fT5LL31CdGZJS…
Ethernet backs to work and DS-5 works well too. A kernel panic is occurred
during the Power Management test, HDMI display is still unavailable. All
other features work well.
3. TI Panda 4430 + Linux Linaro Quantal (Column L):
https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZ…
Kernel has been upgraded from 3.4 to 3.8 but this causes many issues. HDMI,
DVI-D, Ethernet, WiFi and USB Host failed. Also, there is a kernel panic
occurred during the power management test. ARM DS-5 test is blocked since
network is unavailable.
4. TI Panda 4460 + Linux Linaro Quantal (Column L):
https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZ…
Kernel has been upgraded from 3.4 to 3.8 but this causes boot failed on TI
Panda 4460 board. All rest test is blocked.
5. ST Ericsson Snowball + Linux Linaro Quantal (Column L):
https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdFJ4X…
Boot loader has been upgraded to the latest version "U-Boot 2013.01.-rc1"
and this upgrade fixed Ethernet and Device Tree. Now we have SD MMC, HDMI
display, Reboot and Power Management test failed.
For the previous week test summary (Calendar Week 7), please refer to
attachment.
Thank you.
Best Regards
Botao Sun
After some time investigating why I wasn't seeing some kernel section
mismatch errors that someone else was seeing, I found the cause was that
in Linaro we build Thumb2 kernels in the main, and modpost.c doesn't
have support for any of the Thumb relocation types in addend_arm_rel().
I thought I would spread this knowledge, because lack of section
mismatch warnings means we might miss some nasty bugs when developing
code.
If this is old news, then sorry for the noise.
--
Tixy