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
I've added the linaro-dev list to the cc as I think my answer is useful
for everyone working with Linaro's kernels...
On Tue, 2013-02-19 at 21:54 +0530, Viresh Kumar wrote:
> On Feb 19, 2013 8:50 PM, "Dietmar Eggemann" <dietmar.eggemann(a)arm.com>
> wrote:
> >
> > there're a couple of config switches for android and ubuntu:
> >
> > There are 9 config switches for andoid and 4 for ubuntu.
> >
> > $ ./scripts/kconfig/merge_config.sh linaro/configs/linaro-base.conf
> > linaro/configs/vexpress.conf linaro/configs/big-LITTLE-MP.conf
> > linaro/configs/ubuntu-minimal.conf | grep "^Actual value" | wc -l
> >
> > $ ./scripts/kconfig/merge_config.sh linaro/configs/linaro-base.conf
> > linaro/configs/vexpress.conf linaro/configs/big-LITTLE-MP.conf
> > linaro/configs/android.conf | grep "^Actual value" | wc -l
> >
> > which have a problem:
> >
> > Value requested for CONFIG_FOO not in final .config
> > Requested value: # CONFIG_FOO is not set
> > Actual value:
> >
> > Value requested for CONFIG_BAR not in final
> > .config
> > Requested value: CONFIG_BAR=y
> > Actual value: # CONFIG_BAR is not set
> >
> > My question is: Is there anybody making sure that those config
> fragments
> > stay in sync with the release?
There isn't any one person making sure things stay in sync, though
occasionally I have a look; if you think there is a bug, you should let
me know or raise a bug in Launchpad (linaro-android or linaro-ubuntu
projects?).
Note however, there are always going to be warnings when building a
kernel config from a set of config fragments. The usual valid reasons
are:
1. The platform enables a feature which isn't supported by a particular
hardware device. E.g. Android has USB_G_ANDROID ("Android Composite
Gadget") which requires the device to support USB OTG, which some don't
(like Versatile Express).
2. The device wants to override a platform or Linaro default for
whatever reason.
3. We have redundant options there to avoid bugs and wasted effort when
people tweak other options.
For the specific case of the warnings we get for vexpress, I wouldn't
consider any of them to be bugs. These are...
1. For CONFIG_OABI_COMPAT, see commit message for when I added this:
http://git.linaro.org/gitweb?p=kernel/configs.git;a=commit;h=e1fccb9e6bf7dc…
2. For CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND we are deliberately
overriding the defaults in earlier platform configs. (That's part of the
usecase for config fragments, later, more specific config fragments
overriding earlier more generic ones.)
3. CONFIG_ENABLE_DEFAULT_TRACERS is there so Gator works. The fact that
the recent addition of CONFIG_FUNCTION_TRACER in linaro-base.conf causes
GENERIC_TRACER to be selected and disable ENABLE_DEFAULT_TRACERS (as
it's a subset of tracing) is unfortunate, but if we removed
ENABLE_DEFAULT_TRACERS then everything would break if anyone decided
that as function tracer bloats the kernel and make it slower we should
disable it again.
4. CONFIG_VEXPRESS_TC2_CPUIDLE is there so the old TC2 power management
drivers work should I or someone else decided to drop the new drivers
from there tree. (Unlikely, and once the driver code if properly
consolidated I'll remove this old config option).
5. The rest of the warnings are Android options which are set but
require features (like runtime power management or USB OTG) which aren't
actually enabled on vexpress.
Cheers
--
Tixy