Tomasz Figa | 23 Apr 18:46 2014

[PATCH v3 0/3] Generic Device Tree based power domain look-up

Up till now there was no single generic method to bind devices to their
power domains using Device Tree. Each platform has been doing this using
its own way, example of which are Exynos power domain bindings [1] and
look-up code [2].

This series is intended to change this and provide generic DT bindings for
power domain specification and generic code performing look-up of power
domains and binding them to devices.

First two patches are the most important part of this series, as they
introduce $subject. Patch 3 converts mach-exynos to use the new generic
method. Further patches are adding one more user of the new code,
mach-s3c64xx, with first 3 patches (4-6) required to clean-up its power
domain driver a bit and last 3 patches (9-11) adding display support for
Mini6410 board, including a node for display controller (FIMD) which is
a power domain consumer.

The design of DT bindings and provider code is heavily inspired by
implementation of clock providers in Common Clock Framework, while
the code binding devices to power domains by my Exynos power domain
implementation (now removed by this series ;)).

Successfully tested on Exynos4210-based Trats and Exynos4412-based Trats2
boards using MFC, 

[1] Documentation/devicetree/bindings/arm/exynos/power_domain.txt
[2] arch/arm/mach-exynos/pm_domains.c

Changes since v2:
(http://thread.gmane.org/gmane.linux.kernel/1658926)
(Continue reading)

Leela Krishna Amudala | 23 Apr 07:52 2014

[PATCH V2] ARM: EXYNOS: cpu hotplug: use v7_exit_coherency_flush macro for cache disabling

A common macro v7_exit_coherency_flush available which does the below tasks in
the seqeunce.
-clearing C bit
-clearing L1 cache
-exit SMP
-instruction and data synchronization

So removing the local functions which does the same thing and use the macro instead.

Signed-off-by: Leela Krishna Amudala <leela.krishna <at> linaro.org>
Acked-by: Nicolas Pitre <nico <at> linaro.org>
---
Changes since V1:
	- removed unwanted primary_part variable in exynos_cpu_die()
	- given more description in commit message
	  suggested by Daniel Lezcano <daniel.lezcano <at> linaro.org>

 arch/arm/mach-exynos/hotplug.c |   63 +---------------------------------------
 1 file changed, 1 insertion(+), 62 deletions(-)

diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..9ca692d 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
 <at>  <at>  -24,56 +24,6  <at>  <at> 
 #include "common.h"
 #include "regs-pmu.h"

-static inline void cpu_enter_lowpower_a9(void)
-{
(Continue reading)

Stratos Karafotis | 22 Apr 21:40 2014
Picon

[PATCH] cpufreq: Kconfig: Fix spelling errors

Fix 4 spelling errors in help sections.

Signed-off-by: Stratos Karafotis <stratosk <at> semaphore.gr>
---
 drivers/cpufreq/Kconfig.arm | 4 ++--
 drivers/cpufreq/Kconfig.x86 | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 5805035..6e05a1e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
 <at>  <at>  -85,7 +85,7  <at>  <at>  config ARM_EXYNOS_CPU_FREQ_BOOST_SW
 	  It allows usage of special frequencies for Samsung Exynos
 	  processors if thermal conditions are appropriate.

-	  It reguires, for safe operation, thermal framework with properly
+	  It requires, for safe operation, thermal framework with properly
 	  defined trip points.

 	  If in doubt, say N.
 <at>  <at>  -186,7 +186,7  <at>  <at>  config ARM_S3C2416_CPUFREQ
 	  S3C2450 SoC. The S3C2416 supports changing the rate of the
 	  armdiv clock source and also entering a so called dynamic
 	  voltage scaling mode in which it is possible to reduce the
-	  core voltage of the cpu.
+	  core voltage of the CPU.

 	  If in doubt, say N.

(Continue reading)

Lee Jones | 22 Apr 13:29 2014

Re: [PATCH v4 5/8] mfd: db8500-prcmu: Use cpufreq_for_each_entry macro for iteration

> > > The cpufreq core now supports the cpufreq_for_each_entry macro helper 
> > > for iteration over the cpufreq_frequency_table, so use it. 
> > > 
> > > It should have no functional changes. 
> >
> > > Signed-off-by: Stratos Karafotis <stratosk <at> semaphore.gr> 
> > > --- 
> >
> > It would be good to have a changelog which describes the differences 
> > between the versions, so we can keep track. 
> >
> > >  drivers/mfd/db8500-prcmu.c | 19 ++++++++----------- 
> > >  1 file changed, 8 insertions(+), 11 deletions(-) 
> >
> > So it looks like I already applied v2 of this patch to my tree. What 
> > changed in v3 and v4? Should I remove that patch from MFD and apply 
> > this one instead?
> 
> I'm sorry for the confusion.
> I sent v3 only for patches 1/8 and 3/8.
> So, I was asked by Rafael to resend the entire series as v4
> in order to be clear which is the latest version in each patch.
> Unfortunately, I omit the change log :(
> 
> The specific patch (5/8) is unchanged since v2.
> 
> I'm sorry for the inconvenience.

That's okay, thanks for clarifying.

(Continue reading)

Chen Gang | 22 Apr 03:29 2014
Picon

[PATCH v2] kernel/power/hibernate.c: use 'u64' instead of 's64' to avoid warning

For do_div(), it need 'u64' type, which means the outside must be sure
of 'start' is not bigger than 'stop', or it will report warning.

Even if 'start' was really bigger than 'stop', it would print incorrect
information, but for kernel, it still can continue, so use WARN_ON() is
enough.

The related warning (with allmodconfig for unicore32):

    CC      kernel/power/hibernate.o
  kernel/power/hibernate.c: In function ‘swsusp_show_speed’:
  kernel/power/hibernate.c:237: warning: comparison of distinct pointer types lacks a cast

Signed-off-by: Chen Gang <gang.chen.5i5j <at> gmail.com>
---
 kernel/power/hibernate.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index f4f2073..d5117d5 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
 <at>  <at>  -228,12 +228,13  <at>  <at>  static void platform_recover(int platform_mode)
 void swsusp_show_speed(struct timeval *start, struct timeval *stop,
 			unsigned nr_pages, char *msg)
 {
-	s64 elapsed_centisecs64;
+	u64 elapsed_centisecs64;
 	int centisecs;
 	int k;
(Continue reading)

Sebastian Capella | 22 Apr 02:30 2014

[PATCH v2] PM / Hibernate: no kernel_power_off when pm_power_off NULL

Reboot logic in kernel/reboot will avoid calling kernel_power_off
when pm_power_off is null, and instead uses kernel_halt.  Change
hibernate's power_down to follow the behavior in the reboot call.

Calling the notifier twice (once for SYS_POWER_OFF and again for
SYS_HALT) causes a panic during hibernation on Kirkwood
Openblocks A6 board.

Signed-off-by: Sebastian Capella <sebastian.capella <at> linaro.org>
Reported-by: Ezequiel Garcia <ezequiel.garcia <at> free-electrons.com>
Cc: Len Brown <len.brown <at> intel.com>
Cc: Pavel Machek <pavel <at> ucw.cz>
Cc: "Rafael J. Wysocki" <rjw <at> rjwysocki.net>
Cc: Russell King <linux <at> arm.linux.org.uk>
Cc: One Thousand Gnomes <gnomes <at> lxorguk.ukuu.org.uk>

---
 kernel/power/hibernate.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index f4f2073..7642932 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
 <at>  <at>  -595,7 +595,8  <at>  <at>  static void power_down(void)
 	case HIBERNATION_PLATFORM:
 		hibernation_platform_enter();
 	case HIBERNATION_SHUTDOWN:
-		kernel_power_off();
+		if (pm_power_off)
(Continue reading)

Chen Gang | 21 Apr 15:40 2014
Picon

[PATCH] kernel/power/hibernate.c: be sure of 'start' is not bigger than 'stop'

For do_div(), it need 'u64' type, which means the outside must be sure
of 'start' is not bigger than 'stop', or it will report warning.

The related warning (with allmodconfig for unicore32):

    CC      kernel/power/hibernate.o
  kernel/power/hibernate.c: In function ‘swsusp_show_speed’:
  kernel/power/hibernate.c:237: warning: comparison of distinct pointer types lacks a cast

Signed-off-by: Chen Gang <gang.chen.5i5j <at> gmail.com>
---
 kernel/power/hibernate.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index f4f2073..0dec9b7 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
 <at>  <at>  -228,12 +228,17  <at>  <at>  static void platform_recover(int platform_mode)
 void swsusp_show_speed(struct timeval *start, struct timeval *stop,
 			unsigned nr_pages, char *msg)
 {
-	s64 elapsed_centisecs64;
+	u64 elapsed_centisecs64;
 	int centisecs;
 	int k;
 	int kps;

 	elapsed_centisecs64 = timeval_to_ns(stop) - timeval_to_ns(start);
+	if ((s64)elapsed_centisecs64 < 0) {
(Continue reading)

Sravan | 21 Apr 14:07 2014

avoid adding devices without pm_ops to dpm list

Hello,

I have come across below code which looks can be optimized to reduce 
suspend/resume latencies.

During device registration at boot up, device_add() is called.
In this device_add() function, device_pm_add() is called without 
checking if the device has pm_ops or not.
Thus dpm_list is generated with all devices even if some devices don't 
have pm_ops.

device_add() -> device_pm_add()-> generate dpm_list

During suspend/resume process, suspend/resume APIs are called for 
devices present in dpm_list.
due to this, suspend/resume APIs for devices without pm_ops also called 
and just return with NULL.

Can we optimize this code by adding *ONLY* devices with pm_ops to 
dpm_list and ignore remaining?
It will help reduce suspend/resume latencies. I observed 10mS savings 
with my debug code. It may change based on number of devices without pm_ops.

Let me know your opinion/suggestions on this.

---
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
(Continue reading)

Viresh Kumar | 21 Apr 07:37 2014

Should we get cpufreq <at> vger.kernel.org removed?

We always want people to use: linux-pm <at> vger.kernel.org for
any cpufreq work. And sometimes people just send mails to
cpufreq <at> vger.kernel.org, as MAINTAINERS file tells them to.

Should we get the cpufreq mailing list removed physically and
from MAINTAINERS file to make life simple?

--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Viresh Kumar | 21 Apr 07:14 2014

Re: cpufreq framework questions.

On 18 April 2014 07:51, Yipeng Yao <ypyao <at> marvell.com> wrote:
> I’m a s/w engineer of Marvell and currently we meet some issues when doing
> cpu frequency changing on our boards.
>
> When we doing stress test of CPUHOTPLUG + cpufreq governor changing, it will
> report some errors.
>
> In cpufreq.c, it calls __cpufreq_governor(policy, CPUFREQ_GOV_STOP) when we
> are doing cpufreq governor chaging. It also calls __cpufreq_governor(policy,
> CPUFREQ_GOV_STOP) when we are doing cpu hotplug. And it seems that there is
> no lock to protect this mutex situation. So we can see “Failed to stop
> governor” shown as log.

This happened because Governor is already stopped and can't be stopped again.
And so -EBUSY is returned.

The sequence of events must be:
- Change cpufreq governor -> cpufreq_set_policy() ->
__cpufreq_governor(policy, CPUFREQ_GOV_STOP)

- CPU Hotplug in or out -> __cpufreq_governor(policy, CPUFREQ_GOV_STOP).

And this failed with a return value of -EBUSY ..

 <at> Rafael/Srivatsa: Should we retry indefinitely in case -EBUSY is returned
there?

 <at> Srivatsa: What will the hotplug core do with these errors?
 <at> Rafael: subsys_interface layer doesn't check return value of add_dev()
at all, but it expects them to return errors. Should we get that fixed?
(Continue reading)

Rafael J. Wysocki | 20 Apr 23:43 2014
Picon

[PATCH] PM / suspend: Make cpuidle work in the "freeze" state

From: Rafael J. Wysocki <rafael.j.wysocki <at> intel.com>

The "freeze" system sleep state introduced by commit 7e73c5ae6e79
(PM: Introduce suspend state PM_SUSPEND_FREEZE) requires cpuidle
to be functional when freeze_enter() is executed to work correctly
(that is, to be able to save any more energy than runtime idle),
but that is impossible after commit 8651f97bd951d (PM / cpuidle:
System resume hang fix with cpuidle) which caused cpuidle to be
paused in dpm_suspend_noirq() and resumed in dpm_resume_noirq().

To avoid that problem, add cpuidle_resume() and cpuidle_pause()
to the beginning and the end of freeze_enter(), respectively.

Reported-by: Zhang Rui <rui.zhang <at> intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki <at> intel.com>
---
 kernel/power/suspend.c |    3 +++
 1 file changed, 3 insertions(+)

Index: linux-pm/kernel/power/suspend.c
===================================================================
--- linux-pm.orig/kernel/power/suspend.c
+++ linux-pm/kernel/power/suspend.c
 <at>  <at>  -14,6 +14,7  <at>  <at> 
 #include <linux/init.h>
 #include <linux/console.h>
 #include <linux/cpu.h>
+#include <linux/cpuidle.h>
 #include <linux/syscalls.h>
 #include <linux/gfp.h>
(Continue reading)


Gmane