linaro-kernel

linaro-kernel@lists.linaro.org

10095 discussions

[PATCH 1/2] cpufreq: Remove extra variables

by Viresh Kumar

We call cpufreq_cpu_get() in cpufreq_add_dev_symlink() to increase usage refcount of policy and not to get policy for a cpu. So, we don't really need to capture the return value of this routine and call put for it later for failure cases. We can simply use policy passed as an argument to this routine. Moreover debug print is rewritten to make it more clear. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- drivers/cpufreq/cpufreq.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 170d344..35e1a03 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -813,19 +813,18 @@ static int cpufreq_add_dev_symlink(unsigned int cpu, int ret = 0; for_each_cpu(j, policy->cpus) { - struct cpufreq_policy *managed_policy; struct device *cpu_dev; if (j == cpu) continue; - pr_debug("CPU %u already managed, adding link\n", j); - managed_policy = cpufreq_cpu_get(cpu); + pr_debug("Adding link for CPU: %u\n", j); + cpufreq_cpu_get(cpu); cpu_dev = get_cpu_device(j); ret = sysfs_create_link(&cpu_dev->kobj, &policy->kobj, "cpufreq"); if (ret) { - cpufreq_cpu_put(managed_policy); + cpufreq_cpu_put(policy); return ret; } } -- 1.7.12.rc2.18.g61b472e

11 years, 11 months

HMP behavior bad when port the patch set to latest kernel

by Lei Wen

Hi list, I am trying to porting linaro MP patches to other kernel branches, and find some regression due to latest kernel change. The regression is while we test over Linaro 13.06 release with MP3 scenario, we find CA7 is always busy, while one core of CA15 is occasionally raise up with the average of 2% cpu usage ratio, another core is kept silence most of time. But when switch to our backported branch, we find both core in CA15 becomes active, and keep the usage ratio around 2%. With further checking, I find one recent merged patch in mainline cause this: https://lkml.org/lkml/2013/6/27/152 This patch mainly change the initial load for the new born task to the largest one, so that it cause hmp make the decision to move all such task to the big cluster. Since cpu3(The first cpu of CA15) is getting busy now, cpu4 is raise up to share the load as consequence. And it make ALL 5 cpus are used in the MP3 scenario, which should make power result looks bad than before... What is your opinion for this regression, especially for how HMP should act with the increased load raising up with the merged patch? Actually, I have one patch which would forbid the new born task to the faster cluster. Not sure it would cause any other side affect. Comments welcomes. :) --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -840,10 +840,26 @@ void init_task_runnable_average(struct task_struct *p) p->se.avg.runnable_avg_period = slice; __update_task_entity_contrib(&p->se); } + +static inline bool task_is_new_born(struct task_struct *p) +{ + u32 slice; + + /* tribble the times for the new born task */ + slice = sched_slice(task_cfs_rq(p), &p->se) >> 8; + + return p->se.avg.runnable_avg_period < slice; +} + #else void init_task_runnable_average(struct task_struct *p) { } + +static inline bool task_is_new_born(struct task_struct *p) +{ + return true; +} #endif /* @@ -6331,7 +6347,7 @@ static unsigned int hmp_up_migration(int cpu, struct sched_entity *se) < hmp_next_up_threshold) return 0; - if (se->avg.load_avg_ratio > hmp_up_threshold) { + if (!task_is_new_born(p) && se->avg.load_avg_ratio > hmp_up_threshold) { /* Target domain load < ~94% */ if (hmp_domain_min_load(hmp_faster_domain(cpu), NULL) > NICE_0_LOAD-64) Thanks, Lei

11 years, 11 months

[PATCH 0/7] Add DT nodes for FIMD and DP controller for Exynos5420 SoC

by Vikas Sajjan

This patchset adds DT nodes for FIMD and DP controller for Exynos5420 based SMDK. It moves all common properties of FIMD and DP controller DT node specific to Exynos5 Socs like 5250 and 5420 to exynos5.dtsi file. It also adds required PM domain DT nodes for exynos5420. Is rebased on branch kgene's "for-next" https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h… The DP PHY DT Node is based on Jingoo Han's inflight patchset at http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/66… Vikas Sajjan (6): ARM: dts: move display-timimg information inside FIMD DT node for exynos5250 ARM: dts: Update FIMD DT node for Exynos5 SoCs ARM: dts: Add FIMD DT node to exynos5420 DTS files ARM: dts: Update DP controller DT Node for Exynos5 based SoCs ARM: dts: Add DP controller DT node to exynos5420 SoC ARM: dts: add pin state information for DP HPD support to Exynos5420 Yadwinder Singh Brar (1): ARM: dts: Add basic PM domains for EXYNOS5420 arch/arm/boot/dts/exynos5.dtsi | 39 +++++++++++++++++++++++ arch/arm/boot/dts/exynos5250-arndale.dts | 9 ------ arch/arm/boot/dts/exynos5250-smdk5250.dts | 35 +++++++++------------ arch/arm/boot/dts/exynos5250.dtsi | 18 ++--------- arch/arm/boot/dts/exynos5420-pinctrl.dtsi | 7 +++++ arch/arm/boot/dts/exynos5420-smdk5420.dts | 23 ++++++++++++++ arch/arm/boot/dts/exynos5420.dtsi | 49 +++++++++++++++++++++++++++++ 7 files changed, 135 insertions(+), 45 deletions(-) -- 1.7.9.5

11 years, 11 months

[Question] The Secure Monitor Code For PSCI

by Leo Yan

hi, Now ARM has defined PSCI for Trustzone; So where we can get monitor code or trustzone's s/w on TC2 for the reference? when we go through TC2 and ARM64's code, they have already supported PSCI yet for the smp boot operations and low power modes, so it will be clear for us if we can see two portions' code to get clear the whole flow. Thx in advance. -- Thx, Leo Yan

11 years, 11 months

[PATCH] regulator: core: Add missing stub for regulator_get_exclusive()

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> Signed-off-by: Mark Brown <broonie(a)linaro.org> --- include/linux/regulator/consumer.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h index 3610df8..3b9b4da 100644 --- a/include/linux/regulator/consumer.h +++ b/include/linux/regulator/consumer.h @@ -217,6 +217,12 @@ devm_regulator_get(struct device *dev, const char *id) return NULL; } +static inline struct regulator *__must_check +devm_regulator_get_exclusive(struct device *dev, const char *id) +{ + return NULL; +} + static inline void regulator_put(struct regulator *regulator) { } -- 1.8.3.2

11 years, 11 months

[PATCH 01/11] spi: Provide core support for runtime PM during transfers

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> Most SPI drivers that implement runtime PM support use identical code to do so: they acquire a runtime PM lock in prepare_transfer_hardware() and then they release it in unprepare_transfer_hardware(). The variations in this are mostly missing error checking and the choice to use autosuspend. Since these runtime PM calls are normally the only thing in the prepare and unprepare callbacks and the autosuspend API transparently does the right thing on devices with autosuspend disabled factor all of this out into the core with a flag to enable the behaviour. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/spi/spi.c | 16 ++++++++++++++++ include/linux/spi/spi.h | 4 ++++ 2 files changed, 20 insertions(+) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 46c3f56..61f71b9 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -553,6 +553,10 @@ static void spi_pump_messages(struct kthread_work *work) master->unprepare_transfer_hardware(master)) dev_err(&master->dev, "failed to unprepare transfer hardware\n"); + if (master->auto_runtime_pm) { + pm_runtime_mark_last_busy(master->dev.parent); + pm_runtime_put_autosuspend(master->dev.parent); + } return; } @@ -572,11 +576,23 @@ static void spi_pump_messages(struct kthread_work *work) master->busy = true; spin_unlock_irqrestore(&master->queue_lock, flags); + if (!was_busy && master->auto_runtime_pm) { + ret = pm_runtime_get_sync(master->dev.parent); + if (ret < 0) { + dev_err(&master->dev, "Failed to power device: %d\n", + ret); + return; + } + } + if (!was_busy && master->prepare_transfer_hardware) { ret = master->prepare_transfer_hardware(master); if (ret) { dev_err(&master->dev, "failed to prepare transfer hardware\n"); + + if (master->auto_runtime_pm) + pm_runtime_put(master->dev.parent); return; } } diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index be40c97..d73059a 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -256,6 +256,8 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv) * @busy: message pump is busy * @running: message pump is running * @rt: whether this queue is set to run as a realtime task + * @auto_runtime_pm: the core should ensure a runtime PM reference is held + * while the hardware is prepared * @prepare_transfer_hardware: a message will soon arrive from the queue * so the subsystem requests the driver to prepare the transfer hardware * by issuing this call @@ -380,11 +382,13 @@ struct spi_master { bool busy; bool running; bool rt; + bool auto_runtime_pm; int (*prepare_transfer_hardware)(struct spi_master *master); int (*transfer_one_message)(struct spi_master *master, struct spi_message *mesg); int (*unprepare_transfer_hardware)(struct spi_master *master); + /* gpio chip select */ int *cs_gpios; }; -- 1.8.3.2

11 years, 11 months

[PATCH 1/3] cpu topology: remove stale arch_provides_topology_pointers and define_siblings_show_map/list()

by Hanjun Guo

arch_provides_topology_pointers was introduced in commit 23ca4bba3 (x86: cleanup early per cpu variables/accesses v4) to indicate pointers to the topology cpumask_t maps are valid to avoid copying data on to/off of the stack. But later in commit fbd59a8d (cpumask: Use topology_core_cpumask()/ topology_thread_cpumask()), the pointers to the topology struct cpumask maps are always valid. After that commit, the only difference is that there is a redundant "unsigned int cpu = dev->id;" if arch_provides_topology_pointers defined, but dev->id is type 'u32' which devolves to 'unsigned int' on all supported arches. So this arch_provides_topology_pointers define is pointless and only cause obfuscation now, remove it. Tested on x86 machine, topology information in sys/devices/system/cpu/ cpuX/topology/ is the same after appling this patch set. Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org> --- drivers/base/topology.c | 20 -------------------- 1 file changed, 20 deletions(-) diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 2f5919e..94ffee3 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -62,25 +62,6 @@ static ssize_t show_cpumap(int type, const struct cpumask *mask, char *buf) } #endif -#ifdef arch_provides_topology_pointers -#define define_siblings_show_map(name) \ -static ssize_t show_##name(struct device *dev, \ - struct device_attribute *attr, char *buf) \ -{ \ - unsigned int cpu = dev->id; \ - return show_cpumap(0, topology_##name(cpu), buf); \ -} - -#define define_siblings_show_list(name) \ -static ssize_t show_##name##_list(struct device *dev, \ - struct device_attribute *attr, \ - char *buf) \ -{ \ - unsigned int cpu = dev->id; \ - return show_cpumap(1, topology_##name(cpu), buf); \ -} - -#else #define define_siblings_show_map(name) \ static ssize_t show_##name(struct device *dev, \ struct device_attribute *attr, char *buf) \ @@ -95,7 +76,6 @@ static ssize_t show_##name##_list(struct device *dev, \ { \ return show_cpumap(1, topology_##name(dev->id), buf); \ } -#endif #define define_siblings_show_func(name) \ define_siblings_show_map(name); define_siblings_show_list(name) -- 1.7.9.5

11 years, 11 months

[PATCH 0/1] ARM: atomic64: fix endian-ness in atomic.h

by Victor Kamensky

Fixes atomic64_xxx functions endian-ness isussues as it was discussed on http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/185898.html Patch itself follows in separate email. This cover letter describes what testing has been done Tested on pandaboard for both cases: LE and BE, CONFIG_GENERIC_ATOMIC64 was forcefully disabled. In BE case it was tested on top of Ben's other BE patches covered by (updates for be8 patch series). The following tests passed: 1) CONFIG_ATOMIC64_SELFTEST 2) The following module produced identical output for both LE, BE, and GENERIC_ATOMIC64 #include <linux/module.h> #include <linux/moduleparam.h> #include <linux/atomic.h> atomic64_t a = {0}; #define STEP 0x40000000 void atomic64_add_test1 (void) { atomic64_add(STEP, &a); } void test_atomic64_add(void) { int i; printk("atomic64_add\n"); atomic64_set(&a, 0); printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 10; i++) { atomic64_add_test1(); printk("i = %2d: a = 0x%llx (%lld)\n", i, a.counter, a.counter); } } void atomic64_sub_test1 (void) { atomic64_sub(STEP, &a); } void test_atomic64_sub(void) { int i; printk("atomic64_sub\n"); /* value of a is set by previos test */ printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 20; i++) { atomic64_sub_test1(); printk("i = %2d: a = 0x%llx (%lld)\n", i, a.counter, a.counter); } } u64 atomic64_add_return_test1 (void) { return atomic64_add_return(STEP, &a); } void test_atomic64_add_return(void) { int i; u64 ret; printk("atomic64_add_return\n"); atomic64_set(&a, 0); printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 10; i++) { ret = atomic64_add_return_test1(); printk("i = %2d: a = 0x%llx (%lld), ret = %llx (%lld)\n", i, a.counter, a.counter, ret, ret); } } u64 atomic64_sub_return_test1 (void) { return atomic64_sub_return(STEP, &a); } void test_atomic64_sub_return(void) { int i; u64 ret; printk("atomic64_sub_return\n"); /* value of a is set by previos test */ printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 20; i++) { ret = atomic64_sub_return_test1(); printk("i = %2d: a = 0x%llx (%lld), ret = %llx (%lld)\n", i, a.counter, a.counter, ret, ret); } } void atomic64_dec_if_positive_test1 (void) { atomic64_dec_if_positive(&a); } void test1_atomic64_dec_if_positive (void) { int i; printk("atomic64_dec_if_positive test1\n"); atomic64_set(&a, 0x100000003); /* value of a is set by previos test */ printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 10; i++) { atomic64_dec_if_positive_test1(); printk("i = %2d: a = 0x%llx (%lld))\n", i, a.counter, a.counter); } } void test2_atomic64_dec_if_positive (void) { int i; printk("atomic64_dec_if_positive test2\n"); atomic64_set(&a, 0x3); /* value of a is set by previos test */ printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 10; i++) { atomic64_dec_if_positive_test1(); printk("i = %2d: a = 0x%llx (%lld))\n", i, a.counter, a.counter); } } void atomic64_add_unless_test1(long long u) { atomic64_add_unless(&a, STEP, u); } void test_atomic64_add_unless(void) { int i; u64 prev; printk("atomic64_add_unless\n"); atomic64_set(&a, 0); printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 10; i++) { prev = a.counter; atomic64_add_unless_test1(prev); printk("i = %2d: no change: prev = 0x%llx (%lld), a = 0x%llx (%lld)\n", i, prev, prev, a.counter, a.counter); atomic64_add_unless_test1(prev - 1); printk("i = %2d: change: prev = 0x%llx (%lld), a = 0x%llx (%lld)\n", i, prev, prev, a.counter, a.counter); } } int init_module (void) { test_atomic64_add(); test_atomic64_sub(); test_atomic64_add_return(); test_atomic64_sub_return(); test1_atomic64_dec_if_positive(); test2_atomic64_dec_if_positive(); test_atomic64_add_unless(); return 0; } void cleanup_module(void) { } MODULE_LICENSE("GPL"); Thanks, Victor Victor Kamensky (1): ARM: atomic64: fix endian-ness in atomic.h arch/arm/include/asm/atomic.h | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) -- 1.8.1.4

11 years, 11 months

RE: Arndale power management

by Comaschi, F.

Yes of course! Sorry for that ;) Best, Francesco ________________________________________ From: Mike Turquette [mturquette(a)linaro.org] Sent: Thursday, July 25, 2013 7:36 PM To: Comaschi, F. Subject: Re: Arndale power management Francesco, Can you reply to the list with your response? Please do not remove the list when responding. Regards, Mike On Wed, Jul 24, 2013 at 11:11 PM, Comaschi, F. <fcomaschi(a)tue.nl> wrote: > Dear Mike, > > thank you very much for your reply! > > the hack that you suggest is indeed what I have done so far just for testing. However, I was thinking, if we have some knowledge about the specific application that we are running, from a functional point of view (e.g., we are scanning a scene through a camera and we see that there's no movement, therefore we decide to lower the frequency), wouldn't it be useful to exploit this knowledge in order to implement our own DVFS policy in a more proactive way, rather than recurring to the available governors which I think are working in a more reactive way? > In that case, how would you suggest to interface with the OS from inside my application? Shall I make some "calls" to specific API's, or maybe writing my own governor? > > Thanks in advance for your attention! > > Best, > > Francesco > ________________________________________ > From: Mike Turquette [mturquette(a)linaro.org] > Sent: Thursday, July 25, 2013 3:58 AM > To: Viresh Kumar; Comaschi, F. > Cc: Lukasz Majewski; Lists linaro-kernel; cpufreq(a)vger.kernel.org; Chander Kashyap; Linux PM List > Subject: Re: Arndale power management > > Quoting Viresh Kumar (2013-07-15 23:43:03) >> Adding few more lists so that others can also help.. >> >> On 15 July 2013 20:00, Comaschi, F. <fcomaschi(a)tue.nl> wrote: >> > Dear Viresh, >> > >> > I am Francesco Comaschi, a researcher at Eindhoven University of Technology. My research group is interested in implementing custom power management policies on ARM-based platform (at the moment we are using an Arndale 5250 board featuring Exynos5 dual). We would like to make use of DVFS and to be able to measure power consumption on the board. >> >> Ok. >> >> > First of all, congratulations for the work that you and the other guys form the power management team are doing within the Linaro community, I always follow your progress, and so far you have been the only reliable source of information for everything I have been doing on the board. >> >> Thanks :) >> >> > If you do not mind, I would like to ask you a few questions: >> > 1) Is there a way to measure the board power consumption via software? I have read here: http://blogs.arm.com/software-enablement/925-linux-hwmon-power-management-a… that it is possible with the ARM Versatile boards, through the hwmon framework and lm_sensors. However, when I run lm_sensors on the Arndale board, no sensors were found. Do you know about any other possible ways to measure power in software? Maybe it is possible to communicate with the on-board PMIC? Maybe there are some registers where information about the power/voltage provided to the processor and the other components is available? >> >> On ARM Versatile express boards and the coretiles that come with it, >> we have sensors which are probed through hwmon framework in >> Linux. So, we have hardware IPs present on board which let us >> get some power figures per cluster for big LITTLE. >> >> I am not sure if Exynos have any such things on it. >> >> @Chander: Are you aware of any such features? >> >> > 2) Recently I have read Andy Green’s presentation “How to measure SoC power”. However, by measuring power on the PMIC input side through the ARM Energy Probe, probably I won't be able to see the effect of DVFS. Do you have any suggestions on how to measure the effect of DVFS, even through hardware measurements? >> >> You need probes on the voltage regulator which is feed the cores... >> But again, that is very much hardware specific. And I haven't worked >> on Exynos at all :) >> >> > 3) More in general, I do not know which is the best way to implement custom policies of DVFS. >> >> I didn't get you here. Are you talking about tuning of governors here? >> >> > Is it possible, maybe through appropriate API's, to access the cpu_idle and the cpu_freq framework from inside my application? Shall I work directly with the drivers of the PMIC? Is it possible to set the voltage directly from inside my application? > > Are you trying to create a DVFS policy from a userspace application? > Lots of people hack together something using the CPUfreq "userspace" > governor and writing to: > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor > > This is not something that should be shipped on a product but is useful > for learning and prototyping. It only affects the CPU and will not help > you craft DVFS policies on other peripherals/devices. > > Regards, > Mike > >> >> Something on the board must provide this to kernel. Kernel can't >> get it by itself. >> >> _______________________________________________ >> linaro-kernel mailing list >> linaro-kernel(a)lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-kernel

11 years, 11 months

[RFC][PATCH 0/9] sched: Power scheduler design proposal

by Morten Rasmussen

Hi, This patch set is an initial prototype aiming at the overall power-aware scheduler design proposal that I previously described <http://permalink.gmane.org/gmane.linux.kernel/1508480>. The patch set introduces a cpu capacity managing 'power scheduler' which lives by the side of the existing (process) scheduler. Its role is to monitor the system load and decide which cpus that should be available to the process scheduler. Long term the power scheduler is intended to replace the currently distributed uncoordinated power management policies and will interface a unified platform specific power driver obtain power topology information and handle idle and P-states. The power driver interface should be made flexible enough to support multiple platforms including Intel and ARM. This prototype supports very simple task packing and adds cpufreq wrapper governor that allows the power scheduler to drive P-state selection. The prototype policy is absolutely untuned, but this will be addressed in the future. Scalability improvements, such as avoid iterating over all cpus, will also be addressed in the future. Thanks, Morten Morten Rasmussen (9): sched: Introduce power scheduler sched: Redirect update_cpu_power to sched/power.c sched: Make select_idle_sibling() skip cpu with a cpu_power of 1 sched: Make periodic load-balance disregard cpus with a cpu_power of 1 sched: Make idle_balance() skip cpus with a cpu_power of 1 sched: power: add power_domain data structure sched: power: Add power driver interface sched: power: Add initial frequency scaling support to power scheduler sched: power: cpufreq: Initial schedpower cpufreq governor arch/arm/Kconfig | 2 + drivers/cpufreq/Kconfig | 8 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/cpufreq_schedpower.c | 119 +++++++++++++ include/linux/sched/power.h | 29 ++++ kernel/Kconfig.power | 3 + kernel/sched/Makefile | 1 + kernel/sched/fair.c | 43 +++-- kernel/sched/power.c | 307 ++++++++++++++++++++++++++++++++++ kernel/sched/sched.h | 24 +++ 10 files changed, 525 insertions(+), 12 deletions(-) create mode 100644 drivers/cpufreq/cpufreq_schedpower.c create mode 100644 include/linux/sched/power.h create mode 100644 kernel/Kconfig.power create mode 100644 kernel/sched/power.c -- 1.7.9.5

11 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel