Lina Iyer | 25 Oct 01:40 2014

[PATCH v9 0/9] cpuidle driver for QCOM SoCs: 8064, 8074, 8084

Changes since v8:
[ https://www.mail-archive.com/linux-arm-msm <at> vger.kernel.org/msg11473.html ]
- Flatten out the file structure - merge pm.c into spm.c after discussions
- Add a new function to set warm boot address, in scm-boot.c
- Support for 8064 (New)
- Tested on 8074, 8084. 8064 was tested with a WIP tree
- Address review comments from v8
- Looking into possiblility of  initializing the cpuidle device for a cpu,
only when the corresponding spm device is probed successfully.

Changes since v7:
[ https://www.mail-archive.com/linux-arm-msm <at> vger.kernel.org/msg11199.html ]
- Address review comments
- Tested on 8974 but not 8084
- WFI renamed to Standby
- Update commit text with original author and link to the downstream tree

Changes since v6:
[ https://www.mail-archive.com/linux-arm-msm <at> vger.kernel.org/msg11012.html ]
- SPM device nodes merged with existing SAW DT nodes
- SPM register information is handled within the driver
- Clean up from using 'msm' to 'qcom'
        - Shorten some enumerations as well
- Review comments from v6 addressed
- New: Support for 8084 SoC
        - Not tested. I do not have a board with this SoC, but the SPM
        configuration should be identical for WFI and SPC

Changes since v5:
[ https://www.mail-archive.com/linux-arm-msm <at> vger.kernel.org/msg10559.html ]
(Continue reading)

Lucas Stach | 24 Oct 15:05 2014
Picon

[PATCH v3] cpufreq: dt: disable unsupported OPPs

If the regulator connected to the CPU voltage plane doesn't
support an OPP specified voltage with the acceptable tolerance
it's better to just disable the OPP instead of constantly
failing the voltage scaling later on.

Includes as fix to move initialization of opp_freq outside
the loop in order to avoid an endless loop.
Signed-off-by: Geert Uytterhoeven <geert+renesas <at> glider.be>

Signed-off-by: Lucas Stach <l.stach <at> pengutronix.de>
Acked-by: Viresh Kumar <viresh.kumar <at> linaro.org>
---
v3:
- squash in fix from Geert Uytterhoeven
resend 2:
- no functional change, rebase against latest Linus tree
- added Viresh's ack
resend:
- no functional change, split out from the imx5 cpufreq series
v2:
- rebase on top of pm/linux-next
---
 drivers/cpufreq/cpufreq-dt.c | 66 +++++++++++++++++++++++++++-----------------
 1 file changed, 41 insertions(+), 25 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 92c162af5045..7789affa7eb8 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
 <at>  <at>  -187,6 +187,7  <at>  <at>  static int cpufreq_init(struct cpufreq_policy *policy)
(Continue reading)

Imre Deak | 24 Oct 09:43 2014
Picon

[PATCH] PM / Sleep: fix recovery during s2ram/hibernation

Atm, if one of the dev_pm_ops::freeze callbacks fails during the QUIESCE
phase we don't rollback things correctly calling the thaw and complete
callbacks. This could leave some devices in a suspended state in case of
an error during resuming from hibernation.

Also if an asynchronous suspend_late or freeze_late callback fails
during the SUSPEND, FREEZE or QUIESCE phases we don't propagate the
corresponding error correctly, in effect ignoring the error and
continuing the suspend-to-ram/hibernation. During suspend-to-ram this
could leave some devices without a valid saved context, leading to a
failure to reinitialize them during resume. During hibernation this
could leave some devices active interfeering with the creation /
restoration of the hibernation image. Also this could leave the
corresponding devices without a valid saved context and failure to
reinitialize them during resume.

Signed-off-by: Imre Deak <imre.deak <at> intel.com>
---
 drivers/base/power/main.c | 2 ++
 kernel/power/hibernate.c  | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 4497319..9717d5f 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
 <at>  <at>  -1266,6 +1266,8  <at>  <at>  int dpm_suspend_late(pm_message_t state)
 	}
 	mutex_unlock(&dpm_list_mtx);
 	async_synchronize_full();
(Continue reading)

Geert Uytterhoeven | 23 Oct 14:12 2014
Picon

[PATCH 1/2] PM / Domains: Make genpd parameter of pm_genpd_present() const

Signed-off-by: Geert Uytterhoeven <geert+renesas <at> glider.be>
---
 drivers/base/power/domain.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 40bc2f4072cc28ea..28d6e8bf746c4683 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
 <at>  <at>  -753,9 +753,9  <at>  <at>  static inline void genpd_power_off_work_fn(struct work_struct *work) {}
  * pm_genpd_present - Check if the given PM domain has been initialized.
  *  <at> genpd: PM domain to check.
  */
-static bool pm_genpd_present(struct generic_pm_domain *genpd)
+static bool pm_genpd_present(const struct generic_pm_domain *genpd)
 {
-	struct generic_pm_domain *gpd;
+	const struct generic_pm_domain *gpd;

 	if (IS_ERR_OR_NULL(genpd))
 		return false;
--

-- 
1.9.1

--
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

(Continue reading)

Geert Uytterhoeven | 23 Oct 13:31 2014
Picon

[PATCH/RFC] ARM: shmobile: sh7372: Keep D4 pm domain powered

The D4 power domain contains the Coresight-ETM hardware block.
As long as the ARM debug/perf code doesn't use resource management with
runtime PM support, the D4 power domain must be kept powered to avoid a
crash during resume from s2ram (dbg_cpu_pm_notify() calls
reset_ctrl_regs() unconditionally, causing an undefined instruction
oops).

Signed-off-by: Geert Uytterhoeven <geert+renesas <at> glider.be>
---
Untested on real hardware, but a similar workaround is needed on r8a7740.

 arch/arm/mach-shmobile/pm-sh7372.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-shmobile/pm-sh7372.c b/arch/arm/mach-shmobile/pm-sh7372.c
index 7e5c2676c48902f1..cedffdd4b476adb4 100644
--- a/arch/arm/mach-shmobile/pm-sh7372.c
+++ b/arch/arm/mach-shmobile/pm-sh7372.c
 <at>  <at>  -77,6 +77,16  <at>  <at> 

 #define PM_DOMAIN_ON_OFF_LATENCY_NS	250000

+static int sh7372_d4_pd_suspend(void)
+{
+	/*
+	 * The D4 domain contains the Coresight-ETM hardware block and
+	 * therefore it should only be turned off if the debug module is
+	 * not in use.
+	 */
+	return -EBUSY;
(Continue reading)

Daniel Lezcano | 23 Oct 11:01 2014

[PATCH V2 1/5] sched: idle: cpuidle: Check the latency req before idle

When the pmqos latency requirement is set to zero that means "poll in all the
cases".

That is correctly implemented on x86 but not on the other archs.

As how is written the code, if the latency request is zero, the governor will
return zero, so corresponding, for x86, to the poll function, but for the
others arch the default idle function. For example, on ARM this is wait-for-
interrupt with a latency of '1', so violating the constraint.

In order to fix that, do the latency requirement check *before* calling the
cpuidle framework in order to jump to the poll function without entering
cpuidle. That has several benefits:

 1. It clarifies and unifies the code
 2. It fixes x86 vs other archs behavior
 3. Factors out the call to the same function
 4. Prevent to enter the cpuidle framework with its expensive cost in
    calculation

As the latency_req is needed in all the cases, change the select API to take
the latency_req as parameter in case it is not equal to zero.

As a positive side effect, it introduces the latency constraint specified
externally, so one more step to the cpuidle/scheduler integration.

Signed-off-by: Daniel Lezcano <daniel.lezcano <at> linaro.org>
Acked-by: Nicolas Pitre <nico <at> linaro.org>
---
 drivers/cpuidle/cpuidle.c          |  5 +++--
(Continue reading)

Daniel Lezcano | 22 Oct 15:57 2014

[RFD PATCH 00/10] cpuidle: Predict the next events with the IO latencies

This patchset is not intended to be merged upstream as it is. It is a
proof of concept giving the rough idea of the concept.

In the discussions on how to make the scheduler energy aware, we tried
to make the different PM subsystems to communicate with the scheduler.

We realized that some code is duplicated across the PM subsystems and
the scheduler leading to an inconsistent way to integrate the PM
informations.

Ingo Molnar put a line in the sand [1] and clearly worded that no more
PM stuff will be integrated into the scheduler until the different PM
blocks are not redesigned to be part of the scheduler.

This patchset is a sub part of this integration work. How to integrate
Cpuidle with the scheduler ?

The idea is to get rid of the governors and let the scheduler to tell
the Cpuidle framework : "I expect to sleep <x> nsec and I have a <y>
nsec latency requirement" as stated by Peter Zijlstra [2].

How to achieve this ?

We want to prevent to just move code around and put the prediction of
the next event inside the scheduler directly with a legacy menu
governor. After investigating, it appears the menu governor is not
behaving in a stable way, it is erratic. Using the IO latencies +
the timers give much better results than the menu governor which takes
into account all the source of wakeups [3].

(Continue reading)

Puthikorn Voravootivat | 22 Oct 03:15 2014

[PATCH] bq27x00_battery: Call power_supply_changed only when capacity changed

In current driver, power_supply_changed() is called whenever any of
the battery attribute changed. This causes kernel to increases the
'/sys/power/wakeup_count' and make suspend not working correctly.

This patch change this behavior to call power_supply_changed()
only when the battery capacity changed.

Signed-off-by: Puthikorn Voravootivat <puthik <at> chromium.org>
Reviewed-by: David Riley <davidriley <at> chromium.org>
Reviewed-by: Benson Leung <bleung <at> chromium.org>
---
 drivers/power/bq27x00_battery.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/power/bq27x00_battery.c b/drivers/power/bq27x00_battery.c
index e3bacfe..7ab3de0 100644
--- a/drivers/power/bq27x00_battery.c
+++ b/drivers/power/bq27x00_battery.c
 <at>  <at>  -493,10 +493,11  <at>  <at>  static void bq27x00_update(struct bq27x00_device_info *di)
 			di->charge_design_full = bq27x00_battery_read_ilmd(di);
 	}

-	if (memcmp(&di->cache, &cache, sizeof(cache)) != 0) {
-		di->cache = cache;
+	if (di->cache.capacity != cache.capacity)
 		power_supply_changed(&di->bat);
-	}
+
+	if (memcmp(&di->cache, &cache, sizeof(cache)) != 0)
+		di->cache = cache;
(Continue reading)

Alexandre Belloni | 21 Oct 23:55 2014

[PATCH 0/8] ARM: at91: Remove mach/ includes from the reset driver

This series removes the mach/ headers dependency from the reset driver. It is
also laying some groundwork for the necessary power management support rework.

The first patch adds and export a function to shutdown the sdram from the sdramc
driver.

The second patch makes the sdramc driver usable from the board files.

The third patch actually registers the sdramc driver from the boards files.
The fourth patch does the same, only for sam9g45 and sam9rl to simplify future
merging as the board files have been removed. Simply drop that patch.

The fifth patch makes the at91-reset driver use the newly created
at91_ramc_shutdown() function and removes the mach/ headers inclusion.

Then the sixth and seven patch do some cleanup. Again, you can simply drop patch
7 when merging.

The last patch adds myself a the maintainer for those drivers.

Alexandre Belloni (8):
  memory: atmel-sdramc: export a shutdown function
  memory: atmel-sdramc: allow probing from pdata
  ARM: at91: sam9: probe the RAMC driver from pdata
  ARM: at91: sam9g45/sam9rl: probe the ramc driver
  power: reset: at91-reset: use at91_ramc_shutdown
  ARM: at91: sam9: remove useless resource for rstc
  ARM: at91: sam9g45/sam9rl: remove useless resources for rstc
  MAINTAINERS: add at91 power and memory entries

(Continue reading)

Michal Hocko | 21 Oct 09:27 2014
Picon

[PATCH 0/4 -v2] OOM vs. freezer interaction fixes

Hi Andrew, Rafael,

this has been originally discussed here [1] and previously posted here [2].
I have updated patches according to feedback from Oleg.

The first and third patch are regression fixes and they are a stable
material IMO. The second and fourth patch are simple cleanups.

The 1st patch is fixing a regression introduced in 3.3 since when OOM
killer is not able to kill any frozen task and live lock as a result.
The fix gets us back to the 3.2. As it turned out during the discussion [3]
this was still not 100% sufficient and that's why we need the 3rd patch.

I was thinking about the proper 1st vs. 3rd patch ordering because
the 1st patch basically opens a race window considerably reduced by the
later patch. This path is hard to do completely race free without a complete
synchronization of OOM path (including the allocator) and freezer which is not
worth the trouble.

Original patch from Cong Wang has covered this by checking
cgroup_freezing(current) in __refrigarator path [4]. But this approach
still suffers from OOM vs. PM freezer interaction (OOM killer would
still live lock waiting for a PM frozen task this time).

So I think the most straight forward way is to address only OOM vs.
frozen task interaction in the first patch, mark it for stable 3.3+ and
leave the race to a separate follow up patch which is applicable to
stable 3.2+ (before a3201227f803 made it inefficient).

Switching 1st and 3rd patches would make some sense as well but then
(Continue reading)

Daniel Lezcano | 20 Oct 18:25 2014

[PATCH 1/5] sched: idle: cpuidle: Check the latency req before idle

When the pmqos latency requirement is set to zero that means "poll in all the
cases".

That is correctly implemented on x86 but not on the other archs.

As how is written the code, if the latency request is zero, the governor will
return zero, so corresponding, for x86, to the poll function, but for the
others arch the default idle function. For example, on ARM this is wait-for-
interrupt with a latency of '1', so violating the constraint.

In order to fix that, do the latency requirement check *before* calling the
cpuidle framework in order to jump to the poll function without entering
cpuidle. That has several benefits:

 1. It clarifies and unifies the code
 2. It fixes x86 vs other archs behavior
 3. Factors out the call to the same function
 4. Prevent to enter the cpuidle framework with its expensive cost in
    calculation

As the latency_req is needed in all the cases, change the select API to take
the latency_req as parameter in case it is not equal to zero.

As a positive side effect, it introduces the latency constraint specified
externally, so one more step to the cpuidle/scheduler integration.

Signed-off-by: Daniel Lezcano <daniel.lezcano <at> linaro.org>
---
 drivers/cpuidle/cpuidle.c          |  5 +++--
 drivers/cpuidle/governors/ladder.c |  9 +--------
(Continue reading)


Gmane