Zach reminded me that this month is compressed, so a linaro+android
kernel would be needed immediately for 11.12. As Andrey is just ramping
up in taking over for the Linaro Android kernel maintenance, I wanted to
just get a kernel out, using the older kernel workflow, so that we had
something current for 11.12.
Anyway. This is straight from Andy Green's
linaro-androidization-tracking branch, with a few small build fixes
added on that I found in my testing and the base android_*_defconfig
files.
You can find the tree here:
git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.2-agreen-rebase
The current sha is tagged as: linux-linaro-3.2-2011.12-0-android-0
Known issues:
There seems to be something in the androidization branch that is causing
problems on beagle xm and origen. In my testing beagle xm kernel ends up
hanging in mid-boot(after ~4 seconds). And the orgien board doesn't
show anything past "Uncompressing Linux... done, booting the kernel". If
I drop the androidization patches and go back to the v3.2-rc4 base, both
kernels boot until the Android userland environment starts and falls
over because the android features are missing. I mucked about for awhile
on both of these tonight, but wasn't able to solve either of them, so
I'd appreciate any help trying to narrow down what is wrong on Origen
(beagle is apparently lower priority).
Andy, one issue with the re-factored android patch tree: Its not very
bisect-able. If I jump back to a topic branch, frequently there are
missing dependencies that keep it from building. Any thoughts on how we
can better chase down these sorts of issues?
thanks
-john
Greetings,
I have disabled power saving features in linaro ubuntu 11.10 on a
PandaBoard, in order to prevent the screen going black, since there is no
mouse nor keyboard attached to the board (It is simply displaying videos,
in a closed loop). But when I reboot (Or power up after a time with the
board off) sometimes this works, and sometimes not. There seems not to be
any kind of rule for it to work, it can fail 5 or 6 times (going black
after 10 minutes, even when it is set to "never"), and later work ok for 3
or 4 reboots. And then, fail again.
Can anyone enlighten me a bit? Sorry for the joke, but my brain is almost
as dark as black the screen goes...
thanks in advance,
PATCH 1) [thermal: Add a new trip type to use cooling device instance number]
This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes
cooling device instance number and may be helpful for cpufreq cooling devices
to take the correct cooling action.
PATCH 2) [thermal: Add generic cpu cooling implementation]
This patch adds generic cpu cooling low level implementation through frequency
clipping and cpu hotplug. In future, other cpu related cooling devices may be
added here. An ACPI version of this already exists(drivers/acpi/processor_thermal.c).
But this will be useful for platforms like ARM using the generic thermal interface
along with the generic cpu cooling devices. The cooling device registration API's
return cooling device pointers which can be easily binded with the thermal zone
trip points.
Amit Daniel Kachhap (2):
thermal: Add a new trip type to use cooling device instance number
thermal: Add generic cpu cooling implementation
Documentation/thermal/cpu-cooling-api.txt | 52 +++++
Documentation/thermal/sysfs-api.txt | 4 +-
drivers/thermal/Kconfig | 11 +
drivers/thermal/Makefile | 1 +
drivers/thermal/cpu_cooling.c | 302 +++++++++++++++++++++++++++++
drivers/thermal/thermal_sys.c | 27 +++-
include/linux/cpu_cooling.h | 45 +++++
include/linux/thermal.h | 1 +
8 files changed, 440 insertions(+), 3 deletions(-)
create mode 100644 Documentation/thermal/cpu-cooling-api.txt
create mode 100644 drivers/thermal/cpu_cooling.c
create mode 100644 include/linux/cpu_cooling.h
The driver is based on clock and regulator APIs and support single core
and multi core ARM SoCs. For multi core, it assume all cores share the
same clock and voltage.
Thanks Arnd, Mark, Jamie, Shawn, Rob, for your review.
Changes in V6:
- add scaling_available_freqs
Changes in V5:
- add more comments
- rename trans-latency to clk-trans-latency, and it only describe clk
latency. Regulator latency is got from regulator_set_voltage_time.
Changes in v4:
- add depends on HAVE_CLK && OF && REGULATOR
- add set_cpu_freq fail check
- regulator_put wehn module exit
- add pr_fmt and convert all printk to pr_xxx
- use voltage range
- comment and doc fix
- add cpu_volts value pre-check in module init
- add helpfull module parameter max_freq
- remove compatible string check on Arnd's comment.
- remove generic-cpufreq to clk-reg-cpufreq
Changes in v3:
- move adjusting smp loops_per_jiffy to arm common code,
and also adjust global loops_per_jiffy.
- remove adjusting loops_per_jiffy in imx and omap cpufreq drivers.
- check compatible "generic-cpufreq" when module_init
- change printk to pr_xxx
- add generic-cpufreq DT binding doc
Changes in v2:
- add volatage change support
- change '_' in property name to '-'
- use initial value to calculate loops_per_jiffy
- fix reading cpu_volts property bug
- let cpufreq_frequency_table_cpuinfo routines handle cpu_freq_khz_max/min
- don't change freq in arm_cpufreq_exit, because every core share the same freq.
- use unsigned long describe frequency as much as possible. Because clk use
unsigned long, but cpufreq use unsigned int.
[PATCH V6 1/7] ARM: add cpufreq transiton notifier to adjust
[PATCH V6 2/7] arm/imx: cpufreq: remove loops_per_jiffy recalculate
[PATCH V6 3/7] cpufreq: OMAP: remove loops_per_jiffy recalculate for
[PATCH V6 4/7] cpufreq: add clk-reg cpufreq driver
[PATCH V6 5/7] dts/imx6q: add cpufreq property
[PATCH V6 6/7] arm/imx6q: register arm_clk as cpu to clkdev
[PATCH V6 7/7] arm/imx6q: select ARCH_HAS_CPUFREQ
Thanks
Richard
The driver support single core and multi core ARM SoCs. For multi core,
it assume all cores share the same clock and voltage.
Changes in v2:
- add volatage change support
- change '_' in property name to '-'
- use initial value to calculate loops_per_jiffy
- fix reading cpu_volts property bug
- let cpufreq_frequency_table_cpuinfo routines handle cpu_freq_khz_max/min
- don't change freq in arm_cpufreq_exit, because every core share the same freq.
- use unsigned long describe frequency as much as possible. Because clk use
unsigned long, but cpufreq use unsigned int.
[PATCH V2 1/4] cpufreq: add arm soc generic cpufreq driver
[PATCH V2 2/4] dts/imx6q: add cpufreq property
[PATCH V2 3/4] arm/imx6q: register arm_clk as cpu to clkdev
[PATCH V2 4/4] arm/imx6q: select ARCH_HAS_CPUFREQ
Thanks
Richard
From: Mike Turquette <mturquette(a)ti.com>
The common clk framework is an attempt to define a generic struct clk
which most platforms can use to build a clk tree and perform a set of
well-defined operations.
The previous patchset, v3, can be found at,
http://article.gmane.org/gmane.linux.kernel/1218622
New stuff in v4:
* clk rate change notifiers
* clk debug info via debugfs (instead of sysfs)
* lots of bug fixes
Stuff that is known to be missing in v4:
* basic mux and divider clk types
* fix for migrating clk_prepare_count/clk_enable_count in
clk_set_parent
* minor rework comments from v3
* Documentation/clk.txt needs love
All of the mising items above will be rolled into v5 ASAP. I wanted to
go ahead and push out the new notifier changes for review and gather
comments on those since those were a big gap in the v3 patchset.
Paul W. also had some good comments about the greater clk API, and the
opportunity to fix some of that stuff while this patchset is still under
discussion. I didn't address those here because they require more
thought, and more comments from reviewers.
Finally, OMAP4 support for the common struct clk will be posted
immediately after this patch series to LAKML and LOML, along with some
hack patches that show how to use the recursive clk_set_rate for
propagating rate changes up the tree for CPUfreq and how to use the new
clk rate change notifiers in a driver.
Mike Turquette (6):
clk: Kconfig: add entry for HAVE_CLK_PREPARE
Documentation: common clk API
clk: introduce the common clock framework
clk: introduce rate change notifiers
clk: basic gateable and fixed-rate clks
clk: export the clk tree topology to debugfs
Documentation/clk.txt | 312 +++++++++++++++
drivers/clk/Kconfig | 23 ++
drivers/clk/Makefile | 4 +-
drivers/clk/clk-basic.c | 208 ++++++++++
drivers/clk/clk.c | 992 +++++++++++++++++++++++++++++++++++++++++++++++
include/linux/clk.h | 230 +++++++++++-
6 files changed, 1765 insertions(+), 4 deletions(-)
create mode 100644 Documentation/clk.txt
create mode 100644 drivers/clk/clk-basic.c
create mode 100644 drivers/clk/clk.c
--
1.7.5.4
With a lot of small tasks, the softirq sched is nearly never called
when no_hz is enable. In this case the load_balance is mainly called with
the newly_idle mode which doesn't update the cpu_power.
Add a next_update field which ensure a maximum update period when
there is short activity
Signed-off-by: Vincent Guittot <vincent.guittot(a)linaro.org>
---
include/linux/sched.h | 1 +
kernel/sched/fair.c | 24 ++++++++++++++++--------
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 64527c4..7178446 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -903,6 +903,7 @@ struct sched_group_power {
* single CPU.
*/
unsigned int power, power_orig;
+ unsigned long next_update;
/*
* Number of busy cpus in this group.
*/
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index a4d2b7a..809f484 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -215,6 +215,8 @@ calc_delta_mine(unsigned long delta_exec, unsigned long weight,
const struct sched_class fair_sched_class;
+static unsigned long __read_mostly max_load_balance_interval = HZ/10;
+
/**************************************************************
* CFS operations on generic schedulable entities:
*/
@@ -3786,6 +3788,11 @@ void update_group_power(struct sched_domain *sd, int cpu)
struct sched_domain *child = sd->child;
struct sched_group *group, *sdg = sd->groups;
unsigned long power;
+ unsigned long interval;
+
+ interval = msecs_to_jiffies(sd->balance_interval);
+ interval = clamp(interval, 1UL, max_load_balance_interval);
+ sdg->sgp->next_update = jiffies + interval;
if (!child) {
update_cpu_power(sd, cpu);
@@ -3893,12 +3900,15 @@ static inline void update_sg_lb_stats(struct sched_domain *sd,
* domains. In the newly idle case, we will allow all the cpu's
* to do the newly idle load balance.
*/
- if (idle != CPU_NEWLY_IDLE && local_group) {
- if (balance_cpu != this_cpu) {
- *balance = 0;
- return;
- }
- update_group_power(sd, this_cpu);
+ if (local_group) {
+ if (idle != CPU_NEWLY_IDLE) {
+ if (balance_cpu != this_cpu) {
+ *balance = 0;
+ return;
+ }
+ update_group_power(sd, this_cpu);
+ } else if (time_after_eq(jiffies, group->sgp->next_update))
+ update_group_power(sd, this_cpu);
}
/* Adjust by relative CPU power of the group */
@@ -4917,8 +4927,6 @@ void select_nohz_load_balancer(int stop_tick)
static DEFINE_SPINLOCK(balancing);
-static unsigned long __read_mostly max_load_balance_interval = HZ/10;
-
/*
* Scale the max load_balance interval with the number of CPUs in the system.
* This trades load-balance latency on larger machines for less cross talk.
--
1.7.4.1