We have the state index passed as parameter to the 'enter' function.
Most of the drivers assign their 'enter' functions several times in
the cpuidle_state structure, as we have the index, we can delegate
to the driver to handle their own callback array.
That will have the benefit of removing multiple lines of code in the
different drivers.
In order to smoothly modify the driver, the 'enter' function are in
the driver structure and in the cpuidle state structure. That will
let the time to modify the different drivers one by one.
So the 'cpuidle_enter' function checks if the 'enter' callback is
assigned in the driver structure and use it, otherwise it invokes
the 'enter' assigned to the cpuidle_state.
Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
---
drivers/cpuidle/cpuidle.c | 4 +++-
include/linux/cpuidle.h | 1 +
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index d90519c..155dee7 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -46,7 +46,9 @@ static inline int cpuidle_enter(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index)
{
struct cpuidle_state *target_state = &drv->states[index];
- return target_state->enter(dev, drv, index);
+
+ return drv->enter(dev, drv, index) ? drv->enter(dev, drv, index) :
+ target_state->enter(dev, drv, index);
}
static inline int cpuidle_enter_tk(struct cpuidle_device *dev,
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 6c26a3d..d82e169 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -130,6 +130,7 @@ struct cpuidle_driver {
struct cpuidle_state states[CPUIDLE_STATE_MAX];
int state_count;
int safe_state_index;
+ int (*enter)(struct cpuidle_device *, struct cpuidle_driver *, int);
};
#ifdef CONFIG_CPU_IDLE
--
1.7.5.4
This patchset creates an arch_scale_freq_power function for ARM, which is used
to set the relative capacity of each core of a big.LITTLE system.
Vincent Guittot (4):
ARM: topology: Add arch_scale_freq_power function
ARM: topology: factorize the update of sibling masks
ARM: topology: Update cpu_power according to DT information
sched: cpu_power: enable ARCH_POWER
arch/arm/include/asm/topology.h | 2 +
arch/arm/kernel/topology.c | 203 +++++++++++++++++++++++++++++++++++----
kernel/sched/features.h | 2 +-
3 files changed, 185 insertions(+), 22 deletions(-)
--
1.7.9.5
There's an interaction between Linaro GCC or FSF GCC 4.7 and Linux
kernels before 3.2 which causes the kernel to halt straight after
showing 'Uncompressing Linux'. The question comes up every couple of
months so I've blogged about it:
http://seabright.co.nz/2012/06/11/kernel-not-booting-with-linaro-gcc/
"""
Is your ARM Linux kernel not booting when building with Linaro GCC or
FSF GCC 4.7? Does it halt shortly after showing ‘Uncompressing Linux’?
You may have run into an interaction between older kernels and the new
unaligned access support in GCC. This affects Linaro GCC from
4.6-2011.11 onwards, GCC from 4.7.0 on, and kernels earlier than 3.2
including the Galaxy Nexus Icecream Sandwich release.
The work-around is to add -mno-unaligned-access to KBUILD_CFLAGS in
the top level kernel Makefile or to backport
8428e84d42179c2a00f5f6450866e70d802d1d05 from the current kernel tree.
ARMv6K and later processors have hardware support for doing unaligned
loads and stores which is faster than the old byte-by-byte/recombine
that was done in software. Later versions of GCC use this to do
quicker loads when working on known unaligned data, such as when
working on a protocol buffer or a packed structure.
The CPU can be configured to trap on unaligned access. This trap is
off at reset, but pre 3.2 kernels turn this on during the initial
boot. An interaction between -fconserve-stack and -munaligned-access
on a char buffer lead to an unaligned access, which causes a trap,
which causes the kernel to halt.
This does not affect userspace programs as they run with the trap turned off.
"""
-- Michael
Release Dates and Deliveries
========================
Toolchain June 14
WG/LT's June 21
12.06 RC's June 25
12.06 Release June 28
--
David Zinman
Linaro Release Manager | Project Manager
Linaro.org | Open source software for ARM SoCs
+ all written in usermode
+ no new proc files
+ configuration based on text file so easy to adapt to the non-omap proletarians
+ gui alignment still needs work
+ sample config files for PD and VDD in the patch but lots of
registers and domains still need to be added
+ same code does power and voltage domains
+ diff attached
+ screenshots attached
--
- evt
(Eric van Tassell)
twitter: evt_texelsoft
linked-in: linkedin.com/in/evttxl
Hi all,
I need some help in choosing right version of rootfs for my environment.
I have a development board with ST SoC with Cortex-A9 dual core and VFPv3-D16. Kernel version available to me is 2.6.37.
I am using Debian 6 arm-hf port, but would like to try Linaro rootfs.
1. What is the version of linaro filesytem I should pick (optimum for -mfpu=vfp and -mfloat-abi=hard) ?
2. I don't have a hwpack, is it possible to use vexpress or similar rootfs.
Regards,
Suresh
I have created an git repo for the kernel config fragments we produced a
while ago, this is at git://git.linaro.org/kernel/configs.git
The config-core-tracking branch in this repo is intended to be added to
the linux-linaro-core-tracking branch and so be available in all Linaro
kernels. This currently provides three config fragment files:
linaro/configs/linaro-base.conf
Config options common to all Linaro kernels
linaro/configs/ubuntu.conf
Config options for all Ubuntu kernels
linaro/configs/android.conf
Config options for all Android kernels
In addition to these, a board specific config fragment is required to
produce a final kernel config. This may be made available by a Landing
Team's kernel tree (I have done this for vexpress [1]) or; for
experimental purposes, or to support legacy platforms, I have a separate
config-boards-tracking branch of the new configs.git. (Currently this
contains the Origen and iMX5 fragments produced a while ago.)
To create an Ubuntu kernel config from these fragments for a device
called $BOARD, you need to run a command like:
ARCH=arm scripts/kconfig/merge_config.sh \
linaro/configs/linaro-base.conf linaro/configs/ubuntu.conf \
linaro/configs/$BOARD.conf
For Android, s/ubuntu/android/ in the above.
At some point soonish, I hope to come up with a mechanism whereby
Android builds have the option to dynamically generate their kernel
config as above. John Rigby is planning on adding a similar option to
the Ubuntu packaging jobs.
Hopefully this work will enable:
- easier management of system wide config settings required by working
group output or Linaro policy
- place board specific configuration in the hands of the people
maintaining that boards kernel
- more consistent kernel builds, so teams can test in the same
environment as Linaro's final releases
I intend to maintain git://git.linaro.org/kernel/configs.git and will
keep separate non 'tracking' branches for older kernel versions (I
currently have branches for 3.4).
--
Tixy
[1] http://git.linaro.org/gitweb?p=landing-teams/working/arm/kernel.git;a=short…
Hey Andrey, Zach,
So I'm back from my vacation, and have found that the Android team
has released a -compat tree for their 3.4 kernel. Basically this tree
re-adds some items like earlysuspend and classic wakelocks in order to
provide better compatibility with old (and by old, I really mean
current as far as we see - so ICS and earlier) Android userland.
Since we're still shipping ICS, and have no access to whatever the
Android 5.0 userland will be, it seems merging in the -compat tree would
make sense.
However, I know Tixy and others have already tried to address the lack
of earlysuspend in the android-3.3+ kernels, so I wanted to double check
that this wouldn't cause additional pain (since those adjustments might
need to be reverted).
So I just wanted to check first with folks to make sure there are no
objections to merging in the -compat changes, and that the timing of
merging in these changes isn't problematic (I can happily hold off till
this months release is done, so we don't risk any last minute gotchas).
thanks
-john