The usual cpuidle initialization routines register the driver and
then register a cpuidle device per cpu.
By default, most drivers initialize the device state count with the
driver state count.
We can then add a new function 'cpuidle_register' where we register
the driver and the devices. These devices can be defined in a global
static variable in cpuidle.c. We will be able to factor out and
remove a lot of duplicate lines of code.
As we still have some drivers, with different initialization routines,
we keep 'cpuidle_register_driver' and 'cpuidle_register_device' as low
level initialization routines to do some specific operations on the
cpuidle devices.
Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
---
drivers/cpuidle/cpuidle.c | 42 ++++++++++++++++++++++++++++++++++++++++++
include/linux/cpuidle.h | 3 +++
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 87411ce..4d1f79b 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -23,6 +23,7 @@
#include "cpuidle.h"
DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
+DEFINE_PER_CPU(struct cpuidle_device, cpuidle_device);
DEFINE_MUTEX(cpuidle_lock);
LIST_HEAD(cpuidle_detected_devices);
@@ -419,6 +420,47 @@ int cpuidle_register_device(struct cpuidle_device *dev)
EXPORT_SYMBOL_GPL(cpuidle_register_device);
+/*
+ * cpuidle_register : register cpuidle driver and devices
+ * Note this function must be called after smp_init.
+ * @drv : the cpuidle driver
+ * Returns 0 on success, < 0 otherwise
+ */
+int cpuidle_register(struct cpuidle_driver *drv)
+{
+ int ret, cpu, i;
+ struct cpuidle_device *dev;
+
+ ret = cpuidle_register_driver(drv);
+ if (ret)
+ return ret;
+
+ for_each_online_cpu(cpu) {
+ dev = &per_cpu(cpuidle_device, cpu);
+ dev->cpu = cpu;
+
+ ret = cpuidle_register_device(dev);
+ if (ret)
+ goto out_unregister;
+ }
+
+out:
+ return ret;
+
+out_unregister:
+ for_each_online_cpu(i) {
+ if (i == cpu)
+ break;
+ dev = &per_cpu(cpuidle_device, i);
+ cpuidle_unregister_device(dev);
+ }
+
+ cpuidle_unregister_driver(drv);
+
+ goto out;
+}
+EXPORT_SYMBOL_GPL(cpuidle_register);
+
/**
* cpuidle_unregister_device - unregisters a CPU's idle PM feature
* @dev: the cpu
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 6c26a3d..3475294 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -135,6 +135,7 @@ struct cpuidle_driver {
#ifdef CONFIG_CPU_IDLE
extern void disable_cpuidle(void);
extern int cpuidle_idle_call(void);
+extern int cpuidle_register(struct cpuidle_driver *drv);
extern int cpuidle_register_driver(struct cpuidle_driver *drv);
struct cpuidle_driver *cpuidle_get_driver(void);
extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
@@ -154,6 +155,8 @@ extern int cpuidle_play_dead(void);
#else
static inline void disable_cpuidle(void) { }
static inline int cpuidle_idle_call(void) { return -ENODEV; }
+static inline int cpuidle_register(struct cpuidle_driver *drv)
+{return -ENODEV; }
static inline int cpuidle_register_driver(struct cpuidle_driver *drv)
{return -ENODEV; }
static inline struct cpuidle_driver *cpuidle_get_driver(void) {return NULL; }
--
1.7.5.4
Hi, All
Can we share the document for connect session in somewhere?
When we attend the sessions remotely, most of the time we can't see the
slides that talked about in the room.
So like if we can share the document in google docs, and provide the link
for it in the Etherpad,
then remote person can also see the slides.
And by looking the document quickly, some questions can be prepared for
talking about,
this will make the sessions more efficient I think.
Thanks,
Yongqin Liu
http://connect.linaro.org/events/event/linaro-connect-q2-12/#getinvolved
has no info on how to access connect remotely. Who knows about this
and where is it written down?
If it's hangouts for example I need to sort out a machine with a
camera, relevant proprietary software and a google+ account. It'd be
good not to be scrambling to do that at 1am monday morning.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Just wanted to share an update. I got an SD mux card in the mail
yesterday that we've been talking about for LAVA. This device can allow
LAVA to work without having to use the master images we've all grown to
dislike. Its also nice for personal use because you aren't swapping out
SD cards all day long.
I played with the device last night and made some progress. It seems to
be working just fine, there was only one hiccup trying to get right set
of commands to power down my USB hub properly. I was then able to get
this semi-working in our new "lava-core" branch[1].
The branch can flash an image using the mux, boot the device, install
lava-test, power down, and repeat as needed. I'll be taking this to
Connect with me and I'm really excited about getting some hacking time
with the team to start making this work even better.
If you are interested, we'll be having a session on SD mux at Connect[2].
Thanks to Zach and David!
-andy
1: <https://code.launchpad.net/~doanac/lava-core/demo3-sdmux-device>
2: <http://summit.linaro.org/lcq2-12/meeting/20670/sd-mux-based-automation/>
Hi
LAVA is good for doing some tests but every time I use it I wonder why
it is so slow. So I looked more at problem.
Job which I started is going on pandaboard for 48 minutes already. So
far it did nothing related with tests which I want to run. Instead if
fetched some image, booted and started installing lot of Python packages...
This got me to idea - why not make *-lava variants of images which would
have all packages needed by LAVA infrastructure preinstalled? It would
take some minutes of Jenkins but less then LAVA one probably. Especially
when bigger set of jobs is to be run.
Opinions?
Hey Arnd,
So it looks like something has gone awry in the 3.5 pull with
Panda's mmc functionality. Trying to boot the current 3.5-rc tree, the
boot fails after not finding the root device. Looking at the boot log
I'm seeing:
omap_hsmmc: probe of omap_hsmmc.0 failed with error -22
With the same config on 3.4 it boots up fine. I also tried w/ the
omap2plus_defconfig and see the same behavior.
Before I start bisecting down, I just wanted to raise the issue here in
case there's a known fix.
thanks
-john
Good day all,
A new set of startup files have been released [1]. As with uboot, the
statup files reside in the boot sector on the emmc card and as such
requires the usage of riff for the update.
Instructions to update the startup files for Android can be found here [2].
This new set provides:
. support for new power management features.
. graceful reboot.
. a new flash layout.
. improvement on a lot of improvement reported on launchpad.
The new startup files are compatible with earlier release. It is highly
recommended to use them in conjunction with the forthcoming 12.05 release.
Best regards,
Mathieu.
[1].http://igloocommunity.org/download/linaro/startupfiles/latest/
[2].http://www.igloocommunity.org/support/Android_Getting_started_with_ICS#B…
http://xania.org/201205/gcc-explorer
Could we get Matt to provide a cross-compiler environment too? He's
already using gcc-linaro anyway.. ;-)
We could also host a version ourselves under a cool linaro.org hostname.
--
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs
