Srinivas Pandruvada | 5 May 00:07 2016

[PATCH] cpufreq: intel_pstate: Ignore _PPC processing under HWP

When HWP (hardware P states) feature is active, the ACPI _PSS and _PPC
is not used. So ignore processing for _PPC limits.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada <at>>
 drivers/cpufreq/intel_pstate.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 97a8278..0620fa6 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
 <at>  <at>  -378,6 +378,9  <at>  <at>  static void intel_pstate_init_acpi_perf_limits(struct cpufreq_policy *policy)
 	int ret;
 	int i;

+	if (hwp_active)
+		return;
 	if (!intel_pstate_get_ppc_enable_status())



To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at>
More majordomo info at

(Continue reading)

Rafael J. Wysocki | 4 May 23:03 2016

Re: [PATCH v5 0/4] PCI: Add support for suspending (including runtime) of PCIe ports

On Friday, April 29, 2016 11:51:55 AM Mika Westerberg wrote:
> Current Linux PCI core does not do any kind of power management to PCIe
> ports. This means that we waste energy and consume laptop battery even if
> the port has nothing connected to. These patches aim to change that to the
> right direction.
> Previous versions of the patches can be found below:
>   v1:
>   v2:
>   v3:
>   v4:
> This assumes that recent (starting from 2015) PCIe ports are capable of
> transition to D3hot/D3cold. We add a new flag to struct pci_dev 'bridge_d3'
> that is set whenever the PCI core thinks the port can be put to D3. The
> check in pci_pm_suspend_noirq() is then extended to cover devices where
> 'bridge_d3' is set.
> We then add two new functions pci_bridge_d3_device_changed/removed(). These
> are used to set and clear 'bridge_d3' whenever there is a change in device
> power management policy (or if the device is removed). For example when
> userspace forbids the device to enter D3cold pci_bridge_d3_device_changed()
> will clear 'bridge_d3' of the upstream bridge.
> For all PCI ports where 'bridge_d3' is set we also enable and unblock
> runtime PM automatically. Only exception is when the PCIe port claims to
> support hotplug. More information about that is in the changelog of
> patch [4/4].
(Continue reading)

Rafael J. Wysocki | 4 May 23:01 2016

Re: [PATCH v5 2/4] PCI: Put PCIe ports into D3 during suspend

On Friday, April 29, 2016 11:51:57 AM Mika Westerberg wrote:
> Currently the Linux PCI core does not touch power state of PCI bridges and
> PCIe ports when system suspend is entered. Leaving them in D0 consumes
> power which is not good thing in portable devices such as laptops. This may
> also prevent the CPU from entering deeper C-states.
> With recent PCIe hardware we can power down the ports to save power given
> that we take into account few restrictions:
>   - The PCIe port hardware is recent enough, starting from 2015.
>   - Devices connected to PCIe ports are effectively in D3cold once the port
>     is transitioned to D3 (the config space is not accessible anymore and
>     the link may be powered down).
>   - Devices behind the PCIe port need to be allowed to transition to D3cold
>     and back. There is a way both drivers and userspace can forbid this.
>   - If the device behind the PCIe port is capable of waking the system it
>     needs to be able to do so from D3cold.
> This patch adds a new flag to struct pci_device called 'bridge_d3'. This
> flag is set and cleared by the PCI core whenever there is a change in power
> management state of any of the devices behind the PCIe port. When system
> later on is suspended we only need to check this flag and if it is true
> transition the port to D3 otherwise we leave it in D0.
> Also provide override mechanism via command line parameter
> "pcie_port_pm=[off|force]" that can be used to disable or enable the
> feature regardless of the BIOS manufacturing date.
(Continue reading)

Viresh Kumar | 4 May 15:19 2016

[PATCH] PM / OPP: Remove useless check

Regulators are optional for devices using OPPs and the OPP core
shouldn't be printing any errors for such missing regulators.

It was fine before the commit 0c717d0f9cb4, but that failed to update
this part of the code to remove an 'always true' check and an extra
unwanted print message.

Fix that now.

Fixes: 0c717d0f9cb4 ("PM / OPP: Initialize regulator pointer to an error value")
Reported-by: Marc Gonzalez <marc_gonzalez <at>>
Signed-off-by: Viresh Kumar <viresh.kumar <at>>
 drivers/base/power/opp/core.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 433b60092972..d8f4cc22856c 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
 <at>  <at>  -259,9 +259,6  <at>  <at>  unsigned long dev_pm_opp_get_max_volt_latency(struct device *dev)
 	reg = opp_table->regulator;
 	if (IS_ERR(reg)) {
 		/* Regulator may not be required for device */
-		if (reg)
-			dev_err(dev, "%s: Invalid regulator (%ld)\n", __func__,
-				PTR_ERR(reg));
 		return 0;
(Continue reading)

Mason | 4 May 15:06 2016

cpu cpu0: dev_pm_opp_get_max_volt_latency: Invalid regulator (-6)


I'm using next-20160428

I've enabled the generic cpufreq-dt driver.

I'm hitting this dev_err in drivers/base/power/opp/core.c

	reg = opp_table->regulator;
	if (IS_ERR(reg)) {
		/* Regulator may not be required for device */
		if (reg)
			dev_err(dev, "%s: Invalid regulator (%ld)\n", __func__, PTR_ERR(reg));

Apparent call stack:

Relevant commit
655c9df961751  PM / OPP: Introduce dev_pm_opp_get_max_volt_latency()

My platform's DT

		cpu0: cpu <at> 0 {
			compatible = "arm,cortex-a9";
			next-level-cache = <&l2cc>;
			device_type = "cpu";
			reg = <0>;
			clocks = <&clkgen CPU_CLK>;
(Continue reading)

Krzysztof Kozlowski | 4 May 15:05 2016

[GIT PULL] ARM: dts: exynos: Devfreq for v4.7


Topic branch with DTS changes for v4.7, adding nodes for new generic
devfreq driver. The devfreq driver will support Exynos3250, 4210, 4212,
4412 and 542x.

This is a long work of Chanwoo Choi, recently merged (including
documentation of bindings) by devfreq maintainer, MyungJoo Ham:

This pull request includes dependency: changes coming from clk tree
with a clk-v4.7-exynos542x tag.

Below you will find full log. At the end - only commits existing
in my tree.

Best regards,

Cc: myungjoo.ham <at>
Cc: cw00.choi <at>
Cc: linux-pm <at>
Cc: rjw <at>

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:

  Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)

are available in the git repository at:

(Continue reading)

Eduardo Valentin | 4 May 08:02 2016

[PATCH 00/31] thermal: reorganizing thermal core


Here is a series of patches I am proposing to add to thermal core
with the intent to have a better code organization. It started
as an RFC for sysfs handling [1]. But now, on top of the sysfs
organization, I added a code split as well.

The only change in behavior is that now, thermal zones with empty
.type will not be allowed to be registered.

After this series, thermal core is split into the following files:
- thermal_sysfs.c: contains the functions handling the sysfs nodes
- thermal_helpers.c: groups functions that do not need to touch thermal
core internal data structures, such as internal lists, and list locks.
- thermal_core.c: functions to handle the lifecycle of the subsystem,
its governors, cooling devices, thermal zone devices, and their

I don't expect any impact on userspace.

Please give your inputs.


Eduardo Valentin (31):
  thermal: core: prevent zones with no types to be registered
  thermal: core: group thermal_zone DEVICE_ATTR's declarations
  thermal: core: group device_create_file() calls that are always
  thermal: core: use dev.groups to manage always present tz attributes
(Continue reading)

Prarit Bhargava | 3 May 20:11 2016

Re: [PATCH 0/3] idle, Honor Hardware Disabled States

On 04/29/2016 05:36 AM, Len Brown wrote:

> But above is all cosmetic.  The real "bug" that users are running into is
> that they can't get into deep c-states when they are enabled.
> Linux (and Intel) need to do a much better job enabling diagnosis of
> that condition.
Okay, I geddit.

Acked-by: Prarit Bhargava <prarit <at>>

To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at>
More majordomo info at

Eric Engestrom | 3 May 15:14 2016
Eric Engestrom <eric.engestrom <at>>

Subject: [PATCH] Fix CONFIG_PM_OPP without CONFIG_OF build failure

[PATCH] Fix CONFIG_PM_OPP without CONFIG_OF build failure

From: Rufus Hamade <rufus.hamade <at>>

A few `#ifdef CONFIG_OF` were missing or misplaced, resulting in a few
"unused function" warnings in core.c, and preventing the build of cpu.c
because of the redefinition of `dev_pm_opp_set_sharing_cpus()`.

Signed-off-by: Rufus Hamade <rufus.hamade <at>>
Reviewed-by: Eric Engestrom <eric.engestrom <at>>
Tested-by: Eric Engestrom <eric.engestrom <at>>
 drivers/base/power/opp/core.c | 6 ++++++
 drivers/base/power/opp/cpu.c  | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 433b600..bc5448c 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
 <at>  <at>  -53,6 +53,7  <at>  <at>  static struct opp_device *_find_opp_dev(const struct device *dev,
 	return NULL;

+#ifdef CONFIG_OF
 static struct opp_table *_managed_opp(const struct device_node *np)
 	struct opp_table *opp_table;
 <at>  <at>  -72,6 +73,7  <at>  <at>  static struct opp_table *_managed_opp(const struct device_node *np)

 	return NULL;
(Continue reading)

Pramod Gurav | 3 May 11:37 2016

[PATCH v2 1/2] dmaengine: qcom-bam-dma: Add pm_runtime support

Adds pm_runtime support for BAM DMA so that clock
is enabled only when there is a transaction going on to help
save power.

Signed-off-by: Pramod Gurav <pramod.gurav <at>>
Changes since v1:
- Removed unnecessary extra line additions and remavals

 drivers/dma/qcom/bam_dma.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 86 insertions(+)

diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
index 5b427c4..f2a8b17 100644
--- a/drivers/dma/qcom/bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
 <at>  <at>  -48,6 +48,7  <at>  <at> 
 #include <linux/of_dma.h>
 #include <linux/clk.h>
 #include <linux/dmaengine.h>
+#include <linux/pm_runtime.h>

 #include "../dmaengine.h"
 #include "../virt-dma.h"
 <at>  <at>  -58,6 +59,8  <at>  <at>  struct bam_desc_hw {
 	u16 flags;

(Continue reading)

Baolin Wang | 3 May 05:30 2016

[RESEND PATCH v10 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

Currently the Linux kernel does not provide any standard integration of this
feature that integrates the USB subsystem with the system power regulation
provided by PMICs meaning that either vendors must add this in their kernels
or USB gadget devices based on Linux (such as mobile phones) may not behave
as they should. Thus provide a standard framework for doing this in kernel.

Now introduce one user with wm831x_power to support and test the usb charger,
which is pending testing. Moreover there may be other potential users will use
it in future.

Changes since v9:
 - Remove some redundant sysfs attributes.
 - Change the SDP charger default current if gadget is SS.
 - Remove the 'get_charger_type' callback in gadget->ops.

Baolin Wang (4):
  gadget: Introduce the usb charger framework
  gadget: Support for the usb charger framework
  gadget: Integrate with the usb gadget supporting for usb charger
  power: wm831x_power: Support USB charger current limit management

 drivers/power/wm831x_power.c      |   69 ++++
 drivers/usb/gadget/Kconfig        |    7 +
 drivers/usb/gadget/udc/Makefile   |    1 +
 drivers/usb/gadget/udc/charger.c  |  766 +++++++++++++++++++++++++++++++++++++
 drivers/usb/gadget/udc/udc-core.c |   11 +
 include/linux/mfd/wm831x/pdata.h  |    3 +
 include/linux/usb/charger.h       |  173 +++++++++
 include/linux/usb/gadget.h        |   13 +
 include/uapi/linux/usb/charger.h  |   31 ++
(Continue reading)