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 [1].
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,
with/without CONFIG_CPU_IDLE_MULTIPLE_DRIVERS.
Tested on Core2 Duo T9500 with acpi_idle [and intel_idle]
Tested on ARM Dual Cortex-A9 U8500 (aka Snowball)
[1] http://www.spinics.net/lists/linux-acpi/msg37921.html
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 | 24 ++++--
drivers/cpuidle/driver.c | 194 ++++++++++++++++++++++++++++++++++++++-------
drivers/cpuidle/sysfs.c | 50 +++++++++---
include/linux/cpuidle.h | 9 ++-
5 files changed, 238 insertions(+), 48 deletions(-)
--
1.7.5.4
Hi,
We are potentially interested in contributing to the alsa UCM for Android initiative.
Is there still some activities around that?
Thanks
Regards,
Sebastien
[cid:image001.png@01CDA7CF.6B9F6710]
Sebastien Le Duc | Tel: +33 476 58 54 14 | Mobile: +33 684 43 07 00
APE | Audio Technical Leader
ST online: www.st.com<http://www.st.com/> | Follow us on twitter: @st_world<http://twitter.com/#!/ST_World>
Following is the declaration of name field in struct cpufreq_driver:
char name[CPUFREQ_NAME_LEN];
where CPUFREQ_NAME_LEN is 16.
So, length of drivers name must be <=15 (one position for '\0').
Current name is crossing this limit and so name doesn't get printed properly
when we do:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
This patch renames driver-name to fix this issue.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
drivers/cpufreq/vexpress_bL_cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/vexpress_bL_cpufreq.c b/drivers/cpufreq/vexpress_bL_cpufreq.c
index 8b7ec18..541fc40 100644
--- a/drivers/cpufreq/vexpress_bL_cpufreq.c
+++ b/drivers/cpufreq/vexpress_bL_cpufreq.c
@@ -244,7 +244,7 @@ static struct cpufreq_driver vexpress_cpufreq_driver = {
.target = vexpress_cpufreq_set_target,
.get = vexpress_cpufreq_get,
.init = vexpress_cpufreq_init,
- .name = "cpufreq_vexpress",
+ .name = "vexpress-bL",
.attr = vexpress_cpufreq_attr,
};
--
1.7.12.rc2.18.g61b472e
Hi all,
I found an interesting health failure today on origen07
http://validation.linaro.org/lava-server/scheduler/job/35016/log_file
When you look at the log, you see that the board starts off at the u-boot prompt. It then tries to do a "reboot", which (obviously) fails. So naturally, it then does a hard reset, and this is where it does something very odd: It interrupts the boot and tries to boot the previously installed test image. I haven't yet looked at the dispatcher code to figure out why (that's my next job).
What then started alarm bells ringing was that I saw this:
1261680 bytes read
reading uInitrd
1532597 bytes read
reading board.dtb
** Unable to read "board.dtb" from mmc 0:5 **
So whatever the test image was, it was expecting a device tree blob, which I would have assumed would have to have been installed during deploy_linaro_image() being that if there is one it should just be part of the test boot deployment.
So I looked at the log from the previous job:
http://validation.linaro.org/lava-server/scheduler/job/34938/log_file#entry…
and sure enough, you'll see at that mark the same issue.
So there are two things:
1) There's some twisted logic in the dispatcher that's making it do odd things if it starts off in u-boot
2) Do we have an issue with dtbs not being handled properly by lava, or is it just that the hwpack was incomplete?
Thanks
Dave
Hi All,
There's a scheduled downtime for 30 min, tomorrow (Thursday) at 19:00UTC.
We plan to increase the disk space available on people.linaro.org.
Thanks.
Cheers,
--
Fathi Boudra
Linaro Release Manager | LAVA Project Manager
Linaro.org | Open source software for ARM SoCs
Hi All,
Sorry for asking one of the most basic question of cpufreq :(
I couldn't get the difference between affected (policy->cpus) and
related cpus (policy->related_cpus) in cpufreq...
As per Documentation/code:
affected_cpus(policy->cpus):
- List of CPUs that require software coordination of frequency.
- Processors part of affected_cpus share policy struct
- Policy limits the frequencies that the processor can work with.
related_cpus(policy->related_cpus):
- List of CPUs that need some sort of frequency coordination, whether
software or hardware.
- Processors part of related_cpus share governer.
- Governer sets the rules, about when to change limits specified by policy.
Correct?
So, now comes the real question:
- In which scenario's should we populate affected and related cpus?
- Should related cpus will always be a superset of affected cpus?
--
Viresh
Hi Viresh,
Please pull the following changes(v2) for the multiple CPU PMU support
(re-based to v3.6).
Changes v1->v2:
1. Incorporated review comments from Will for few patches(which he will
be queuing for v3.8)
2. Dropped "ARM: perf: register the init functions with the bindings",
still looking for alternate to list in implementation.
3. Added per-process event tracking support on multi-PMUs.
Re-factored the original patch "ARM: perf: add support for
per-cluster/multiple PMUs"
4. Fixed the bug reported by Tixy for non-FDT case
----------------------------------------------------------------
The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9:
Linux 3.6 (2012-09-30 16:47:46 -0700)
are available in the git repository at:
ssh://username@pdsw-ci.cambridge.arm.com:29418/kernel.git multi_pmu_v2
for you to fetch changes up to bd7fc4c65bd8ed994ded5aa0feeef91190fbd7be:
ARM: perf: save/restore pmu registers in pm notifier (2012-10-09
18:20:45 +0100)
----------------------------------------------------------------
Axel Lin (1):
ARM: ux500: Fix build error due to missing include of asm/pmu.h
in cpu-db8500.c
Jon Hunter (1):
ARM: PMU: Add runtime PM Support
Lorenzo Pieralisi (1):
ARM: kernel: provide cluster to logical cpu mask mapping API
Marc Zyngier (1):
ARM: perf: add guest vs host discrimination
Mark Rutland (1):
ARM: perf: register cpu_notifier at driver init
Sudeep KarkadaNagesha (11):
ARM: pmu: remove arm_pmu_type enumeration
ARM: perf: move irq registration into pmu implementation
ARM: perf: allocate CPU PMU dynamically at probe time
ARM: perf: consistently use struct perf_event in arm_pmu functions
ARM: perf: check ARMv7 counter validity on a per-pmu basis
ARM: perf: replace global CPU PMU pointer with per-cpu pointers
ARM: perf: register CPU PMUs with idr types
ARM: perf: set cpu affinity to support multiple PMUs
ARM: perf: set cpu affinity for the irqs correctly
ARM: perf: remove spaces in CPU PMU names
ARM: perf: save/restore pmu registers in pm notifier
Will Deacon (8):
ARM: perf: add devicetree bindings for 11MPcore, A5, A7 and A15 PMUs
ARM: pmu: remove unused reservation mechanism
ARM: perf: remove mysterious compiler barrier
ARM: perf: probe devicetree in preference to current CPU
ARM: perf: prepare for moving CPU PMU code into separate file
ARM: perf: move CPU-specific PMU handling code into separate file
ARM: perf: return NOTIFY_DONE from cpu notifier when no available PMU
ARM: perf: consistently use arm_pmu->name for PMU name
Documentation/devicetree/bindings/arm/pmu.txt | 7 +
MAINTAINERS | 1 -
arch/arm/Kconfig | 8 +-
arch/arm/include/asm/perf_event.h | 14 +-
arch/arm/include/asm/pmu.h | 111 +++----
arch/arm/include/asm/topology.h | 3 +
arch/arm/kernel/Makefile | 3 +-
arch/arm/kernel/perf_event.c | 444
+++++++------------------
arch/arm/kernel/perf_event_cpu.c | 380 +++++++++++++++++++++
arch/arm/kernel/perf_event_v6.c | 134 ++++----
arch/arm/kernel/perf_event_v7.c | 307 +++++++++--------
arch/arm/kernel/perf_event_xscale.c | 163 ++++-----
arch/arm/kernel/pmu.c | 36 --
arch/arm/kernel/topology.c | 27 ++
arch/arm/mach-bcmring/arch.c | 3 +-
arch/arm/mach-omap2/devices.c | 3 +-
arch/arm/mach-pxa/devices.c | 3 +-
arch/arm/mach-realview/realview_eb.c | 3 +-
arch/arm/mach-realview/realview_pb1176.c | 3 +-
arch/arm/mach-realview/realview_pb11mp.c | 3 +-
arch/arm/mach-realview/realview_pba8.c | 3 +-
arch/arm/mach-realview/realview_pbx.c | 3 +-
arch/arm/mach-tegra/devices.c | 3 +-
arch/arm/mach-ux500/cpu-db8500.c | 4 +-
arch/arm/mach-vexpress/ct-ca9x4.c | 3 +-
arch/arm/plat-iop/pmu.c | 3 +-
arch/arm/plat-samsung/devs.c | 3 +-
27 files changed, 942 insertions(+), 736 deletions(-)
create mode 100644 arch/arm/kernel/perf_event_cpu.c
delete mode 100644 arch/arm/kernel/pmu.c
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.