From: "hongbo.zhang" <hongbo.zhang(a)linaro.com>
This patch set is to upstream ST-Ericsson thermal driver and fix some bugs
of thermal layer at the same time.
All of these patches are based on v3.7-rc1.
[PATCH 1/5] Thermal: do bind operation after thermal zone or cooling
device register returns.
In the previous bind function, cdev->get_max_state(cdev, &max_state) is called
before the registration function finishes, but at this moment, the parameter
cdev at thermal driver layer isn't ready--it will get ready only after its
registration, so the the get_max_state callback cannot tell the max_state
according to the cdev input.
This problem can be fixed by separating the bind operation out of registration
and doing it when registration completely finished.
There is no such problem with the current exynos thermal driver because it
regsters cooling device before thermal zone device. As a generic thermal layer
any sequence should be supported, thermal zone first or cooling device first,
this will be also helpful to add/remove cooling device dynamically.
[PATCH 2/5] Thermal: add indent for code alignment.
[PATCH 3/5] Thermal: fix empty list checking method.
[PATCH 4/5] Thermal: make sure cpufreq cooling register after
Bug fix for generic cpufreq cooling layer as described in the commit logs.
[PATCH 5/5] Thermal: Add ST-Ericsson db8500 thermal dirver.
This patch is to add ST-Ericsson into the latest kervel version.
Thermal: do bind operation after thermal zone or cooling device
Thermal: add indent for code alignment.
Thermal: fix empty list checking method.
Thermal: make sure cpufreq cooling register after cpufreq driver
Thermal: Add ST-Ericsson db8500 thermal dirver.
arch/arm/boot/dts/dbx5x0.dtsi | 11 +
arch/arm/configs/u8500_defconfig | 4 +
arch/arm/mach-ux500/board-mop500.c | 73 ++++
drivers/thermal/Kconfig | 20 ++
drivers/thermal/Makefile | 2 +
drivers/thermal/cpu_cooling.c | 19 +-
drivers/thermal/db8500_cpufreq_cooling.c | 118 +++++++
drivers/thermal/db8500_thermal.c | 507 +++++++++++++++++++++++++++
drivers/thermal/thermal_sys.c | 86 +++--
include/linux/platform_data/db8500_thermal.h | 39 +++
10 files changed, 847 insertions(+), 32 deletions(-)
create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c
create mode 100644 drivers/thermal/db8500_thermal.c
create mode 100644 include/linux/platform_data/db8500_thermal.h
The discussion about having different cpus on the system with
different latencies bring us to a first attemp by adding a
pointer in the cpuidle_device to the states array.
But as Rafael suggested, it would make more sense to create a
driver per cpu .
This patch adds support for multiple cpuidle drivers.
It creates a per cpu cpuidle driver pointer.
In order to not break the different drivers, the function cpuidle_register_driver
assign for each cpu, the driver.
The multiple driver support is optional and if it is not set, the cpuide driver
core code remains the same (except some code reorganisation).
I did the following tests compiled, booted, tested without/with CONFIG_CPU_IDLE,
Tested on Core2 Duo T9500 with acpi_idle [and intel_idle]
Tested on ARM Dual Cortex-A9 U8500 (aka Snowball)
V1 tested on Tegra3 and Vexpress TC2
* fixed sysfs output : /sys/devices/system/cpu/cpu[0-9]/driver/name
* fixed ifdefs in driver.c
* fixed register_driver function loop when unregistering
* removed WARN under spinlock
* fixed changelog for patch [2/4]
* changed cpuidle_get_cpu_driver function parameter
* removed cpuidle_for_each_driver function
* replaced smp_processor_id() by get_cpu/put_cpu
* refreshed patchset
Daniel Lezcano (4):
cpuidle: move driver's refcount to cpuidle
cpuidle: move driver checking within the lock section
cpuidle: prepare the driver core to be multi drivers aware
cpuidle: support multiple drivers
drivers/cpuidle/Kconfig | 9 ++
drivers/cpuidle/cpuidle.c | 36 +++++---
drivers/cpuidle/cpuidle.h | 4 +-
drivers/cpuidle/driver.c | 209 ++++++++++++++++++++++++++++++++++++++------
drivers/cpuidle/sysfs.c | 174 ++++++++++++++++++++++++++++++++++++--
include/linux/cpuidle.h | 8 ++-
6 files changed, 388 insertions(+), 52 deletions(-)
Currently when none of CONFIG_NET_DSA_TAG_DSA, CONFIG_NET_DSA_TAG_EDSA and
CONFIG_NET_DSA_TAG_TRAILER is defined, we get following compilation warnings:
net/dsa/slave.c:51:12: warning: 'dsa_slave_init' defined but not used [-Wunused-function]
net/dsa/slave.c:60:12: warning: 'dsa_slave_open' defined but not used [-Wunused-function]
net/dsa/slave.c:98:12: warning: 'dsa_slave_close' defined but not used [-Wunused-function]
net/dsa/slave.c:116:13: warning: 'dsa_slave_change_rx_flags' defined but not used [-Wunused-function]
net/dsa/slave.c:127:13: warning: 'dsa_slave_set_rx_mode' defined but not used [-Wunused-function]
net/dsa/slave.c:136:12: warning: 'dsa_slave_set_mac_address' defined but not used [-Wunused-function]
net/dsa/slave.c:164:12: warning: 'dsa_slave_ioctl' defined but not used [-Wunused-function]
Fix them by enclosing these routines under #ifdef,endif.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
net/dsa/slave.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index e32083d..5606fae 100644
@@ -48,6 +48,8 @@ void dsa_slave_mii_bus_init(struct dsa_switch *ds)
/* slave device handling ****************************************************/
+#if defined(CONFIG_NET_DSA_TAG_DSA) || defined(CONFIG_NET_DSA_TAG_EDSA) || \
static int dsa_slave_init(struct net_device *dev)
struct dsa_slave_priv *p = netdev_priv(dev);
@@ -170,6 +172,8 @@ static int dsa_slave_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
+#endif /* defined(CONFIG_NET_DSA_TAG_DSA) || defined(CONFIG_NET_DSA_TAG_EDSA ||
+ defined(CONFIG_NET_DSA_TAG_TRAILER) */
/* ethtool operations *******************************************************/
this patch series implements Xen support for ARMv7 with virtualization
extensions. It allows a Linux guest to boot as dom0 and
as domU on Xen on ARM. PV console, disk and network frontends and
backends are all working correctly.
It has been tested on a Versatile Express Cortex A15 emulator, using the
latest Xen ARM developement branch
(git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus
the "ARM hypercall ABI: 64 bit ready" patch series
(http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc
tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546).
The patch marked with [HACK] shouldn't be applied and is part of the
series only because it is needed to create domUs.
I am also attaching to this email the dts'es that I am currently using
for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
and it is appended in binary form to the guest kernel image. I am not
sure where they are supposed to live yet, so I am just attaching them
here so that people can actually try out this series if they want to.
Comments are very welcome!
Changes in v3:
- move patches that have been picked up by Konrad at the end of the
- improve comments;
- add a doc to describe the Xen Device Tree format;
- do not use xen_ulong_t for multicalls and apic_physbase;
- add a patch at the end of the series to use the new __HVC macro;
- add missing pvclock-abi.h include to ia64 header files;
- do not use an anonymous union in struct xen_add_to_physmap.
Changes in v2:
- fix up many comments and commit messages;
- remove the early_printk patches: rely on the emulated serial for now;
- remove the xen_guest_init patch: without any PV early_printk, we don't
need any early call to xen_guest_init, we can rely on core_initcall
- define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
at the moment is unused;
- use ldm instead of pop in the hypercall wrappers;
- return -ENOSYS rather than -1 from the unimplemented grant_table
- remove the pvclock ifdef in the Xen headers;
- remove include linux/types.h from xen/interface/xen.h;
- replace pr_info with pr_debug in xen_guest_init;
- add a new patch to introduce xen_ulong_t and use it top replace all
the occurences of unsigned long in the public Xen interface;
- explicitely size all the pointers to 64 bit on ARM, so that the
hypercall ABI is "64 bit ready";
- clean up xenbus_init;
- make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI;
- mark Xen guest support on ARM as EXPERIMENTAL;
- introduce GRANT_TABLE_PHYSADDR;
- remove unneeded initialization of boot_max_nr_grant_frames;
- add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c;
- return -EINVAL from xen_remap_domain_mfn_range if
- retain binary compatibility in xen_add_to_physmap: use a union to
Ian Campbell (1):
[HACK] xen/arm: implement xen_remap_domain_mfn_range
Stefano Stabellini (24):
arm: initial Xen support
xen/arm: page.h definitions
xen/arm: empty implementation of grant_table arch specific functions
docs: Xen ARM DT bindings
xen/arm: Xen detection and shared_info page mapping
xen/arm: Introduce xen_pfn_t for pfn and mfn types
xen/arm: Introduce xen_ulong_t for unsigned long
xen/arm: compile and run xenbus
xen: do not compile manage, balloon, pci, acpi and cpu_hotplug on ARM
xen/arm: introduce CONFIG_XEN on ARM
xen/arm: get privilege status
xen/arm: initialize grant_table on ARM
xen/arm: receive Xen events on ARM
xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
xen: allow privcmd for HVM guests
xen/arm: compile blkfront and blkback
xen/arm: compile netback
arm/v2m: initialize arch_timers even if v2m_timer is not present
xen/arm: use the __HVC macro
xen: missing includes
xen: update xen_add_to_physmap interface
Documentation/devicetree/bindings/arm/xen.txt | 22 +++
arch/arm/Kconfig | 10 +
arch/arm/Makefile | 1 +
arch/arm/include/asm/hypervisor.h | 6 +
arch/arm/include/asm/sync_bitops.h | 27 +++
arch/arm/include/asm/xen/events.h | 18 ++
arch/arm/include/asm/xen/hypercall.h | 69 +++++++
arch/arm/include/asm/xen/hypervisor.h | 19 ++
arch/arm/include/asm/xen/interface.h | 73 ++++++++
arch/arm/include/asm/xen/page.h | 82 ++++++++
arch/arm/mach-vexpress/v2m.c | 11 +-
arch/arm/xen/Makefile | 1 +
arch/arm/xen/enlighten.c | 245 +++++++++++++++++++++++++
arch/arm/xen/grant-table.c | 53 ++++++
arch/arm/xen/hypercall.S | 102 ++++++++++
arch/ia64/include/asm/xen/interface.h | 8 +-
arch/x86/include/asm/xen/interface.h | 8 +
arch/x86/xen/enlighten.c | 1 +
arch/x86/xen/irq.c | 1 +
arch/x86/xen/mmu.c | 3 +
arch/x86/xen/xen-ops.h | 1 -
drivers/block/xen-blkback/blkback.c | 1 +
drivers/net/xen-netback/netback.c | 1 +
drivers/net/xen-netfront.c | 1 +
drivers/tty/hvc/hvc_xen.c | 2 +
drivers/xen/Makefile | 11 +-
drivers/xen/events.c | 18 ++-
drivers/xen/grant-table.c | 1 +
drivers/xen/privcmd.c | 20 +-
drivers/xen/xenbus/xenbus_comms.c | 2 +-
drivers/xen/xenbus/xenbus_probe.c | 62 +++++--
drivers/xen/xenbus/xenbus_probe_frontend.c | 1 +
drivers/xen/xenbus/xenbus_xs.c | 1 +
drivers/xen/xenfs/super.c | 7 +
include/xen/events.h | 2 +
include/xen/interface/features.h | 3 +
include/xen/interface/grant_table.h | 4 +-
include/xen/interface/io/protocols.h | 3 +
include/xen/interface/memory.h | 32 ++-
include/xen/interface/physdev.h | 2 +-
include/xen/interface/platform.h | 4 +-
include/xen/interface/version.h | 2 +-
include/xen/interface/xen.h | 7 +-
include/xen/privcmd.h | 3 +-
include/xen/xen.h | 2 +-
45 files changed, 885 insertions(+), 68 deletions(-)
A branch based on 3.5-rc7 is available here (the __HVC patch is missing
from this branch because it depends on "ARM: opcodes: Facilitate custom
opcode injection" http://marc.info/?l=linux-arm-kernel&m=134442896128124):
After a fair amount of dicking about I have managed to build a
cross-toolchain for arm64/aarch64 which installs on Ubuntu Quantal. It
even builds packages, although it has at least one notable limitation,
and I have no idea if it produces working code yet :-)
The main limitation is that the default library search paths have come
out as the old dpkg-cross ones, not the new multiarch ones. If someone
can tell me where to fix that it would be very helpful and I'll try
and put an updated one in the repo.
In the meantime you can work round it effectively using
/etc/dpkg/buildflags. (see wiki page below for details)
The cross-toolchain only supports C, C++ and fortran with no extras
like libssp, libmudflap etc, because there is no architecture support
for them yet.
I started a port page to keep track of things here:
And if you want to set up a quantal chroot and see if you can build
things, details are here:
The bottom line is that you can debootstrap (or sbuild-createchroot) a
quantal chroot, add the bootstrap repo and do 'apt-get install
crossbuild-essential-arm64' and get a working cross-build environment.
The repo is here:
That should be useable for both dpkg-cross style bulding or
The repo also contains updated dpkg-cross, multiarch python, multiarch
perl, updated dpkg with buildprofile/staging support, sbuild (although
in fact I think stock sbuild should work OK), and dose-builddebcheck
which can tell you what things are currently cross-buildable from
available binaries and sources. Most of that is pretty new and not
very well tested but 'it works for me'.
More arm64 packages will be along soon (dose3 currently indicates 40
more buildabale packages), but there is plenty still to fix for a full
debootstrap-able arm64 package set.
Anyone keen to help with bootstrapping the port is very welcome. There
will be a session about it at UDS next week, and a more general one on
distro bootrapping at the Armv8 minisummit a the co-located linaro
connect. And I'll be giving a talk about this stuff at Linxconf-Europe
in Barcelona the week after.
I think that's all for now. Enjoy, and tell me what breaks :-)
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
(Cc:ing linaro-dev@ where we usually discuss technical stuff)
On Wed, Oct 31, 2012, sundar.subramaniyan(a)gmail.com wrote:
> This is great. Just tried the pre-compiled image and works like a charm.
> It took a little longer than two minutes though on my i3/4Gig machine.
> Haven't yet tried compiling anything yet but how do i get started with
> porting some libraries to armv8? Just compile with the toolchain and run?
This page gives some ideas on how to rebuild the filesystem and how to
fix some common issues:
Perhaps you want to try to build this or that software you care about,
or just try "bitbake world" to build as many things as possible and see
what breaks :-)
This is V2 of my sched_select_cpu() work.
In order to save power, it would be useful to schedule work onto non-IDLE cpus
instead of waking up an IDLE one.
To achieve this, we need scheduler to guide kernel frameworks (like: timers &
workqueues) on which is the most preferred CPU that must be used for these
This patchset is about implementing this concept.
- The first patch adds sched_select_cpu() routine which returns the preferred
cpu which is non-idle.
- Second patch removes idle_cpu() calls from timer & hrtimer.
- Third patch is about adapting this change in workqueue framework.
Earlier discussions over v1 can be found here:
Earlier discussions over this concept were done at last LPC:
Module created for testing this behavior is present here:
Following are the steps followed in test module:
1. Run single work on each cpu
2. This work will start a timer after x (tested with 10) jiffies of delay
3. Timer routine queues a work... (This may be called from idle or non-idle cpu)
and starts the same timer again STEP 3 is done for n number of times (i.e.
queuing n works, one after other)
4. All works will call a single routine, which will count following per cpu:
- Total works processed by a CPU
- Total works processed by a CPU, which are queued from it
- Total works processed by a CPU, which aren't queued from it
- ARM Vexpress TC2 - big.LITTLE CPU
- Core 0-1: A15, 2-4: A7
- rootfs: linaro-ubuntu-nano
Without Workqueue Modification, i.e. PATCH 3/3:
[ 2493.022335] Workqueue Analyser: works processsed by CPU0, Total: 1000, Own: 0, migrated: 0
[ 2493.047789] Workqueue Analyser: works processsed by CPU1, Total: 1000, Own: 0, migrated: 0
[ 2493.072918] Workqueue Analyser: works processsed by CPU2, Total: 1000, Own: 0, migrated: 0
[ 2493.098576] Workqueue Analyser: works processsed by CPU3, Total: 1000, Own: 0, migrated: 0
[ 2493.123702] Workqueue Analyser: works processsed by CPU4, Total: 1000, Own: 0, migrated: 0
With Workqueue Modification, i.e. PATCH 3/3:
[ 2493.022335] Workqueue Analyser: works processsed by CPU0, Total: 1002, Own: 999, migrated: 3
[ 2493.047789] Workqueue Analyser: works processsed by CPU1, Total: 998, Own: 997, migrated: 1
[ 2493.072918] Workqueue Analyser: works processsed by CPU2, Total: 1013, Own: 996, migrated: 17
[ 2493.098576] Workqueue Analyser: works processsed by CPU3, Total: 998, Own: 993, migrated: 5
[ 2493.123702] Workqueue Analyser: works processsed by CPU4, Total: 989, Own: 987, migrated: 2
- New SD_* macros removed now and earlier ones used
- sched_select_cpu() rewritten and it includes the check on current cpu's
- cpu_idle() calls from timer and hrtimer removed now.
- Patch 2/3 from V1, removed as it doesn't apply to latest workqueue branch from
- CONFIG_MIGRATE_WQ removed and so is wq_select_cpu()
- sched_select_cpu() called only from __queue_work()
- got tejun/for-3.7 branch in my tree, before making workqueue changes.
Viresh Kumar (3):
sched: Create sched_select_cpu() to give preferred CPU for power
timer: hrtimer: Don't check idle_cpu() before calling
workqueue: Schedule work on non-idle cpu instead of current one
include/linux/sched.h | 16 ++++++++++--
kernel/hrtimer.c | 2 +-
kernel/sched/core.c | 69 +++++++++++++++++++++++++++++++--------------------
kernel/timer.c | 9 ++++---
kernel/workqueue.c | 2 +-
5 files changed, 63 insertions(+), 35 deletions(-)
__cpufreq_driver_target() must not pass target frequency beyond the limits of
Today most of cpufreq platform drivers are doing this check in their target
routines. Why not move it to __cpufreq_driver_target().
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
Resend doesn't contain any change, but fixed commit log
drivers/cpufreq/cpufreq.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 28dc134..2f5ac2d 100644
@@ -1470,12 +1470,19 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
unsigned int relation)
int retval = -EINVAL;
+ unsigned int old_target_freq = target_freq;
- pr_debug("target for CPU %u: %u kHz, relation %u\n", policy->cpu,
- target_freq, relation);
+ /* Make sure that target_freq is within supported range */
+ if (target_freq > policy->max)
+ target_freq = policy->max;
+ if (target_freq < policy->min)
+ target_freq = policy->min;
+ pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
+ policy->cpu, target_freq, relation, old_target_freq);
if (target_freq == policy->cur)