Chen Yu | 27 Mar 11:08 2015
Picon

[PATCH v2] ACPI: Enable wakeup GPE in freeze mode

Currently, in freeze state, wakeup GPE for PCI devices are
handled properly because acpi_pci_sleep_wake() invokes acpi_enable_gpe()
to enable the wakeup GPE directly. But for the other wakeup-capable
devices in ACPI bus, acpi_enable_wakeup_devices() should be invoked
to update enable_for_wake mask in gpe_register_info structure, thus
acpi_enable_all_wakeup_gpes() can enable the wakeup GPE referred in
_PRW methods. And acpi_disable_wakeup_devices() will be called
before disable_irq_wake() in acpi_freeze_restore() to restore the mask.

This patch fixes a power button wakeup problem on Surface Pro 3,
on which platform power button uses EC to deliver event
(EC GPE is referred in _PRW).

Note: enabling EC GPE during freeze state may bring some risks
because EC events are expected to fire more frequently than others.
Thus it may bring the system out of freeze state unnecessarily.
(We already have comments about this in bugzilla)

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=84651

Reported-and-tested-by: Ethan Schoonover <es <at> ethanschoonover.com>
Tested-by: Peter Amidon <psa.pub.0 <at> picnicpark.org>
Tested-by: Yani Ioadnnou <yani.ioannou <at> gmail.com>
Tested-by: Mister Wardrop <mister.wardrop <at> gmail.com>
Tested-by: Anton Anikin <anton <at> anikin.name>
Tested-by: Keith McClelland <zismylaptop <at> gmail.com>
Reviewed-by: Zhang Rui <rui.zhang <at> intel.com>
Signed-off-by: Chen Yu <yu.c.chen <at> intel.com>
---
 drivers/acpi/sleep.c | 2 ++
(Continue reading)

Shilpasri G Bhat | 27 Mar 08:32 2015
Picon

[PATCH v3] cpufreq: powernv: Report cpu frequency throttling

The power and thermal safety of the system is taken care by an
On-Chip-Controller (OCC) which is real-time subsystem embedded within
the POWER8 processor. OCC continuously monitors the memory and core
temperature, the total system power, state of power supply and fan.

The cpu frequency can be throttled by OCC for the following reasons:
1)If a processor crosses its power and temperature limit then OCC will
  lower its Pmax to reduce the frequency and voltage.
2)If OCC crashes then the system is forced to Psafe frequency.
3)If OCC fails to recover then the kernel is not allowed to do any
  further frequency changes and the chip will remain in Psafe.

The user can see a drop in performance when frequency is throttled and
is unaware of throttling. So detect and report such a condition so
that user can check the OCC status to reboot the system or check for
power supply or fan failures.

The current status of the core is read from Power Management Status
Register(PMSR) to check if any of the throttling condition is occurred
and the appropriate throttling message is reported.

Signed-off-by: Shilpasri G Bhat <shilpa.bhat <at> linux.vnet.ibm.com>
---
Changes from V2:
-Changed commit log to add more details.
-Fixed multi-line comment to proper format

Changes from V1: Removed unused value of PMCR register

 drivers/cpufreq/powernv-cpufreq.c | 40 ++++++++++++++++++++++++++++++++++++++-
(Continue reading)

Eduardo Valentin | 27 Mar 01:02 2015
Picon

[RFP] LPC thermal track

Hello all,

I've created a proposal for a thermal microconference track on the LPC
2015 [1]. The basic idea is to get thermal developers together and
discuss the thermal role within the Linux environment, from kernel and
userspace perspective.

A initial proposal for the topics to be discussed are:
. Closed loop control governors
. Sensor API
. Thermal class: split of temperature sensor device and thermal driver
. Improvements on OF-thermal
. Devfreq vs. clock cooling
. Power model based policies
. User space tools
. User space governors

If you have interest, or if you have ideas on how to improve the
framework, reply to this email and add it to the wiki. 

Add your name in the list of participants as well. Also, if you feel
like giving a talk on the topic, let's add it to the topic list.

Currently I am simple checking what would be the level of interest to
have this topic as a LPC microconference.

BR,

Eduardo Valentin

(Continue reading)

Shilpasri G Bhat | 26 Mar 19:19 2015
Picon

[PATCH] cpufreq: powernv: Add checks to report cpu frequency throttling conditions

Cpu frequency can be throttled due to failures of components like OCC,
power supply and fan. It can also be throttled due to temperature and
power limit. We can detect the throttling by checking 1)if max frequency
is reduced, 2)if the core is put to safe frequency 3)if the SPR based
frequency management is disabled.

The current status of the core is read from Power Management Status
Register(PMSR) to check if any of the throttling condition is
occurred and the appropriate throttling message is reported.

Signed-off-by: Shilpasri G Bhat <shilpa.bhat <at> linux.vnet.ibm.com>
---
 drivers/cpufreq/powernv-cpufreq.c | 40 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
index 2dfd4fd..40fa1d3 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
 <at>  <at>  -36,7 +36,7  <at>  <at> 
 #define POWERNV_MAX_PSTATES	256

 static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
-static bool rebooting;
+static bool rebooting, throttled;

 /*
  * Note: The set of pstates consists of contiguous integers, the
 <at>  <at>  -294,6 +294,41  <at>  <at>  static inline unsigned int get_nominal_index(void)
 	return powernv_pstate_info.max - powernv_pstate_info.nominal;
(Continue reading)

Sascha Hauer | 26 Mar 16:53 2015
Picon

Thermal: Cleanups, fixes and hardware trip points

This series adds support for hardware trip points. It picks up earlier
work from Mikko Perttunen. Mikko implemented hardware trip points as part
of the device tree support. It was suggested back then to move the
functionality to the thermal core instead of putting more code into the
device tree support. This series does exactly that.

The majority of the patches are cleanups and fixes. Only the last two
patches actually implement the hardware trip points.

All comments welcome

Sascha

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

Javi Merino | 26 Mar 16:53 2015

[PATCH] thermal: export thermal_zone_parameters to sysfs

It's useful for tuning to be able to edit thermal_zone_parameters from
userspace.  Export them to the thermal_zone sysfs so that they can be
easily changed.

Cc: Zhang Rui <rui.zhang <at> intel.com>
Cc: Eduardo Valentin <edubezval <at> gmail.com>
Signed-off-by: Javi Merino <javi.merino <at> arm.com>
---

This patch was part of the power_allocator governor series[0] but
looks like it dropped off the radar.  No changes since the last
posting.  It applies on top of the linus branch in Eduardo's tree.

[0] http://article.gmane.org/gmane.linux.kernel/1897888

 Documentation/thermal/sysfs-api.txt |  52 +++++++++++++++++++
 drivers/thermal/thermal_core.c      | 101 ++++++++++++++++++++++++++++++++++++
 2 files changed, 153 insertions(+)

diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt
index fc7dfe10778b..7d44d7f1a71b 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
 <at>  <at>  -184,6 +184,12  <at>  <at>  Thermal zone device sys I/F, created once it's registered:
     |---trip_point_[0-*]_type:	Trip point type
     |---trip_point_[0-*]_hyst:	Hysteresis value for this trip point
     |---emul_temp:		Emulated temperature set node
+    |---sustainable_power:      Sustainable dissipatable power
+    |---k_po:                   Proportional term during temperature overshoot
+    |---k_pu:                   Proportional term during temperature undershoot
(Continue reading)

Sebastian Reichel | 26 Mar 15:59 2015

power/reset: at91: big endian fixes for atsama5d3x

Hi,

> power/reset: at91: big endian fixes for atsama5d3x
>
> Fix the passing of big endian data to routines that
> will be writing it to the bus in the wrong order.

Thanks, I applied your patch:

http://git.infradead.org/battery-2.6.git/commit/7be5ac2c32bd26c47a05367c0135cb6e67b3d452

-- Sebastian
Ben Dooks | 26 Mar 15:16 2015
Picon

[PATCH] power/reset: at91: big endian fixes for atsama5d3x

Fix the passing of big endian data to routines that will be writing
it to the bus in the wrong order.

Signed-off-by: Ben Dooks <ben.dooks <at> codethink.co.uk>
--
CC: Sebastian Reichel <sre <at> kernel.org> (maintainer:POWER SUPPLY CLAS...,commit_signer:2/5=40%)
CC: Dmitry Eremin-Solenikov <dbaryshkov <at> gmail.com> (maintainer:POWER SUPPLY CLAS...)
CC: David Woodhouse <dwmw2 <at> infradead.org> (maintainer:POWER SUPPLY CLAS...)
CC: Nicolas Ferre <nicolas.ferre <at> atmel.com> (commit_signer:3/5=60%)
CC: Alexandre Belloni <alexandre.belloni <at> free-electrons.com> (commit_signer:3/5=60%,authored:2/5=40%,removed_lines:4/18=22%)
CC: Maxime Ripard <maxime.ripard <at> free-electrons.com> (commit_signer:1/5=20%,authored:1/5=20%,added_lines:252/278=91%)
CC: Guenter Roeck <linux <at> roeck-us.net> (commit_signer:1/5=20%,authored:1/5=20%,added_lines:18/278=6%,removed_lines:10/18=56%)
CC: linux-pm <at> vger.kernel.org (open list:POWER SUPPLY CLAS...)
---
 drivers/power/reset/at91-reset.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c
index 13584e2..723fd2a 100644
--- a/drivers/power/reset/at91-reset.c
+++ b/drivers/power/reset/at91-reset.c
 <at>  <at>  -73,8 +73,8  <at>  <at>  static int at91sam9260_restart(struct notifier_block *this, unsigned long mode,
 		: "r" (at91_ramc_base[0]),
 		  "r" (at91_rstc_base),
 		  "r" (1),
-		  "r" (AT91_SDRAMC_LPCB_POWER_DOWN),
-		  "r" (AT91_RSTC_KEY | AT91_RSTC_PERRST | AT91_RSTC_PROCRST));
+		  "r" cpu_to_le32(AT91_SDRAMC_LPCB_POWER_DOWN),
+		  "r" cpu_to_le32(AT91_RSTC_KEY | AT91_RSTC_PERRST | AT91_RSTC_PROCRST));

(Continue reading)

Leo Yan | 26 Mar 12:48 2015

[PATCH v2] cpufreq: hisilicon: add acpu driver

Add acpu driver for hisilicon SoC, acpu is application processor
subsystem. Currently the acpu has the coupled clock domain for two
clusters, so this driver will directly use cpufreq-dt driver as
backend.

Signed-off-by: Leo Yan <leo.yan <at> linaro.org>
---
 drivers/cpufreq/Kconfig.arm         |  9 ++++++++
 drivers/cpufreq/Makefile            |  1 +
 drivers/cpufreq/hisi-acpu-cpufreq.c | 43 +++++++++++++++++++++++++++++++++++++
 3 files changed, 53 insertions(+)
 create mode 100644 drivers/cpufreq/hisi-acpu-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 1b06fc4..4f3dbc8 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
 <at>  <at>  -108,6 +108,15  <at>  <at>  config ARM_HIGHBANK_CPUFREQ

 	  If in doubt, say N.

+config ARM_HISI_ACPU_CPUFREQ
+	tristate "Hisilicon ACPU CPUfreq driver"
+	depends on ARCH_HISI && CPUFREQ_DT
+	select PM_OPP
+	help
+	  This enables the hisilicon ACPU CPUfreq driver.
+
+	  If in doubt, say N.
+
(Continue reading)

Mathias Krause | 25 Mar 22:16 2015

[PATCH] thermal/intel_powerclamp: add __init / __exit annotations

Mark the module init / exit functions with __init / __exit accodingly.
This allows making the intel_powerclamp_ids[] array __initconst, too, as
it only gets referenced from powerclamp_probe(). This is safe as
file2alias doesn't care about the section, but the symbol name for the
MODULE_DEVICE_TABLE alias.

Cc: Arjan van de Ven <arjan <at> linux.intel.com>
Cc: Jacob Pan <jacob.jun.pan <at> linux.intel.com>
Signed-off-by: Mathias Krause <minipli <at> googlemail.com>
---
 drivers/thermal/intel_powerclamp.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/intel_powerclamp.c b/drivers/thermal/intel_powerclamp.c
index 12623bc02f46..b0f7ced5c3ef 100644
--- a/drivers/thermal/intel_powerclamp.c
+++ b/drivers/thermal/intel_powerclamp.c
 <at>  <at>  -667,7 +667,7  <at>  <at>  static struct thermal_cooling_device_ops powerclamp_cooling_ops = {
 };

 /* runs on Nehalem and later */
-static const struct x86_cpu_id intel_powerclamp_ids[] = {
+static const struct x86_cpu_id intel_powerclamp_ids[] __initconst = {
 	{ X86_VENDOR_INTEL, 6, 0x1a},
 	{ X86_VENDOR_INTEL, 6, 0x1c},
 	{ X86_VENDOR_INTEL, 6, 0x1e},
 <at>  <at>  -694,7 +694,7  <at>  <at>  static const struct x86_cpu_id intel_powerclamp_ids[] = {
 };
 MODULE_DEVICE_TABLE(x86cpu, intel_powerclamp_ids);

(Continue reading)

Mathias Krause | 25 Mar 22:15 2015

[PATCH] powercap / RAPL: mark rapl_ids array as __initconst

The RAPL ids are only tested in rapl_init() which is itself an __init
function. For the MODULE_DEVICE_TABLE() file2alias doesn't care about
the section, just about the symbol name. Therefore it's safe to mark the
rapl_ids[] array as __initconst so its memory can be released after
initialization is done.

Cc: Jacob Pan <jacob.jun.pan <at> linux.intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada <at> linux.intel.com>
Signed-off-by: Mathias Krause <minipli <at> googlemail.com>
---
 drivers/powercap/intel_rapl.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
index 63d4033eb683..62f9b322fde0 100644
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
 <at>  <at>  -1054,7 +1054,7  <at>  <at>  static const struct rapl_defaults rapl_defaults_atom = {
 		.driver_data = (kernel_ulong_t)&_ops,	\
 		}

-static const struct x86_cpu_id rapl_ids[] = {
+static const struct x86_cpu_id rapl_ids[] __initconst = {
 	RAPL_CPU(0x2a, rapl_defaults_core),/* Sandy Bridge */
 	RAPL_CPU(0x2d, rapl_defaults_core),/* Sandy Bridge EP */
 	RAPL_CPU(0x37, rapl_defaults_atom),/* Valleyview */
--

-- 
1.7.10.4

--
(Continue reading)


Gmane