MyungJoo Ham | 27 Aug 12:58 2015

Re: [PATCH v5 5/5] PM / devfreq: drop comment about thermal setting max_freq

> The thermal infrastructure should use the devfreq cooling device, which
> uses the OPP library to disable OPPs as necessary.
> Fix a couple of typos in the same comment while we are at it.
> Cc: MyungJoo Ham <myungjoo.ham <at>>
> Signed-off-by: Javi Merino <javi.merino <at>>

Your patches (1/5, 5/5) are already merged in

and will be "pull-request"ed with other patches later.

Do your "V5" patches have updates from last patches?

Javi Merino | 27 Aug 12:55 2015

[PATCH v5 0/5] Devfreq cooling device

This series introduces a devfreq cooling device in the thermal
framework.  Devfreq is used for DVFS for devices other than the CPUs.
With a devfreq cooling device, the thermal framework can throttle them
to control temperature.  The cooling device has the power extensions,
so it can be used by all governors in the thermal framework, including
the power allocator governor.

Changes since v4:
  - Don't introduce a new function in the OPP library and instead fix
    dev_pm_opp_get_voltage() as suggested by Viresh Kumar
  - Don't allocate memory under RCU
  - Don't call dev_pm_opp_enable/disable under RCU
  - Generate the frequency table even if the power extensions were
    not provided

Changes since v3:
  - Made devfreq_update_stats() a static inline function
  - Add dev_pm_get_voltage_always() to get the voltage even for
    disabled OPPs
  - Don't rely on freq_table from the devfreq->profile being present
    and create our own
  - Don't use devm_k* to allocate memory
  - Move struct devfreq_cooling_register to devfreq_cooling.c

Javi Merino (4):
  PM / devfreq: cache the last call to get_dev_status()
  PM / OPP: get the voltage for all OPPs
  devfreq_cooling: add trace information
  PM / devfreq: drop comment about thermal setting max_freq

(Continue reading)

Sudeep Holla | 27 Aug 12:51 2015

Re: [PATCH] modify pl011 driver to work as wakeup source

On 27/08/15 09:25, Zhaoyang Huang wrote:
> Sudeep,
> Have you check if the pl011 can wakeup the system. I notice that the
> calling of dev_pm_set_wake_irq can set the node of <device>/power/wakeup
> to be enabled but can not wakeup the system.

Yes I did, and it does wakeup the system.

> By basic debugging, I find that when calling of dev_pm_set_wake_irq
> within pl011_probe, the real device which we operate is the
> /sys/devices/platform/7ff80000.uart instead of the ttyAMA0.

No, if you are expecting the wakeup by sending some character on the
console, then it's ttyAMA0 which uses the pl011 UART. May be you can
also generate wakeup by toggling RTS/CTS hardware flow signals.

> By checking the sysfs, I find that the value of
> "sys/devices/platform/7ff80000.uart/power/wakeup" is "enabled", which
> can also prove above information. However, the value of
> "dev.power.wakeup->wakeirq->irq" for uart is 24 which is the same with
> ttyAMA0.

Ah, you need to use /sys/class/tty/ttyAMA0/power/wakeup

(Continue reading)

Jon Hunter | 27 Aug 11:21 2015

[RFC PATCH] PM / Domains: Ensure subdomain is not in use before removing

The function pm_genpd_remove_subdomain() removes a subdomain from a
generic PM domain, however, it does not check if the subdomain has any
slave domains or device attached before doing so. Therefore, add a test
to verify that the subdomain does not have any slave domains associated
or any device attached before removing.

Signed-off-by: Jon Hunter <jonathanh <at>>
 drivers/base/power/domain.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 27888a90ca98..a3ed71d8129a 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
 <at>  <at>  -1469,6 +1469,11  <at>  <at>  int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,


+	if (!list_empty(&subdomain->slave_links) || subdomain->device_count) {
+		ret = -EBUSY;
+		goto out;
+	}
 	list_for_each_entry(link, &genpd->master_links, master_node) {
 		if (link->slave != subdomain)
 <at>  <at>  -1487,6 +1492,7  <at>  <at>  int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
(Continue reading)

Jon Hunter | 27 Aug 11:17 2015

[PATCH] PM / Domains: Fix typo in description of genpd_dev_pm_detach()

The function genpd_dev_pm_detach() detaches a device from a PM domain,
however, in the description, the "dev" argument for the function is
described as the device to "attach" instead of "detach". Correct this.

Signed-off-by: Jon Hunter <jonathanh <at>>
 drivers/base/power/domain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 7666a1cbaf95..27888a90ca98 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
 <at>  <at>  -1889,7 +1889,7  <at>  <at>  EXPORT_SYMBOL_GPL(of_genpd_get_from_provider);

  * genpd_dev_pm_detach - Detach a device from its PM domain.
- *  <at> dev: Device to attach.
+ *  <at> dev: Device to detach.
  *  <at> power_off: Currently not used
  * Try to locate a corresponding generic PM domain, which the device was


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)

Shilpasri G Bhat | 27 Aug 11:13 2015

[PATCH] cpufreq: powernv: Export frequency throttle state of the chip through sysfs

Create a sysfs 'throttle' attribute per-chip(per-numa-node) to reflect
the throttle state of the chip. The usersapce programs can poll on
this attribute to keep an eye on the throttle state. Currently we
print a log message to notify the user of throttling event. The
performance-sensitive applications can monitor the throttle state
using this attribute.

Following file is created in sysfs:
'throttle' attribute has the following values:
0 : frequency is unthrottled
1 : frequency is throttled

Suggested-by: Stewart Smith <stewart <at>>
Signed-off-by: Shilpasri G Bhat <shilpa.bhat <at>>
This patch is based on top of linux-next/master 

 drivers/cpufreq/powernv-cpufreq.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
index 64994e1..aed6c34 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
 <at>  <at>  -28,6 +28,8  <at>  <at> 
 #include <linux/of.h>
 #include <linux/reboot.h>
 #include <linux/slab.h>
+#include <linux/device.h>
(Continue reading)

Shilpasri G Bhat | 27 Aug 11:11 2015

[PATCH] cpufreq: powernv: Increase the verbosity of OCC console messages

Modify the OCC reset/load/active event message to make it clearer for
the user to understand the event and effect of the event.

Suggested-by: Stewart Smith <stewart <at>>
Signed-off-by: Shilpasri G Bhat <shilpa.bhat <at>>
This patch is based on top of linux-next/master

 drivers/cpufreq/powernv-cpufreq.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
index 546e056..64994e1 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
 <at>  <at>  -465,6 +465,7  <at>  <at>  static int powernv_cpufreq_occ_msg(struct notifier_block *nb,
 	switch (omsg.type) {
 	case OCC_RESET:
 		occ_reset = true;
+		pr_info("OCC (On Chip Controller - enforces hard thermal/power limits) Resetting\n");
 		 * powernv_cpufreq_throttle_check() is called in
 		 * target() callback which can detect the throttle state
 <at>  <at>  -474,12 +475,12  <at>  <at>  static int powernv_cpufreq_occ_msg(struct notifier_block *nb,
 		if (!throttled) {
 			throttled = true;
-			pr_crit("CPU Frequency is throttled\n");
+			pr_crit("CPU frequency is throttled for duration\n");
(Continue reading)

Sascha Hauer | 27 Aug 08:41 2015

[PATCH v7] Add Mediatek thermal support

This series adds support for the thermal sensors included in the
MT8173 SoC. Currently only basic temperature reading is supported
without any interrupt support.

The cpufreq driver for MT8173 is currently under review, so there's no
real cooling device available in mainline. Until this is available the
thermal driver can be tested with the following dts snippet. It creates
a fake gpio fan and a fake trip point which is so low that it can easily
be reached with a "cat /dev/zero > /dev/null" on the command line.

Please review and let me know what's missing to be included in mainline.

changes since v6:
- remove dot in Hanyi Wus name

changes since v5:
- update copyright
- remove unused defines

Changes since v4:
- give calibration constants more meaningful names (offset, slope)
- Use define instead of 0x00c for register access.

Changes since v3:
- add include/dt-bindings/thermal/mt8173.h for to be able to use sensor names
  in dts files
- fix disabling wrong clock in error path
- remove now unused reset-names property from binding document
- rename MT8173_NUM_BANKS -> MT8173_NUM_ZONES
(Continue reading)

Chen Yu | 27 Aug 05:18 2015

[PATCH] [v4] x86, suspend: Save/restore extra MSR registers for suspend

A bug is reported(
that, after resumed from S3, CPU is running at a low speed.
After investigation, it is found that, BIOS has modified the value
of THERM_CONTROL register during S3, and changes it from 0 to 0x10,
since value of 0x10 means CPU can only get 25% of the Duty Cycle,
this triggers the problem.

Here is a simple scenario to reproduce the issue:
1.Boot up the system
2.Get MSR with address 0x19a, it should be 0
3.Put the system into sleep, then wake it up
4.Get MSR with address 0x19a, it should be 0(actually it shows 0x10)

Although this is a BIOS issue, it would be more robust for linux to deal
with this situation. This patch fixes this issue by introducing a framework
to save/restore specified MSR registers(THERM_CONTROL in this case)
for suspend/resume.

When user encounters a problematic platform and needs to protect the
MSRs during suspending, he can simply add a quirk entry in
msr_save_dmi_table, and customizes MSR registers inside the quirk
callback, for example:

u32 msr_id_need_to_save[] = {MSR_ID0, MSR_ID1, MSR_ID2...};

and the quirk mechanism ensures that, once resumed from suspended,
the MSRs indicated by these IDs will be restored to their original values
before suspended.

Since both 64/32-bit kernels are affected, this patch covers 64/32-bit
(Continue reading)

Srinivas Pandruvada | 26 Aug 22:32 2015

[PATCH 0/5] Intel P states enhancements

This series enhances Intel P state drivers with the following features:
- When max_perf_pct is reduced in turbo range, we can change the turbo ratios
when platform allows. This is particularly useful in limiting performance with
HWP where whole range is turbo.
- Use Turbo Activation Ratio, when calculating max non turbo P state. This will
show now correct percentage in turbo range
- To calculate busy percent, the estimate is not correct when the max non turbo
is limited by tar, hence using physical max non turbo as before.
- Use ACPI _PSS and _PPC in intel_ptate driver.
- Avoid calculation for P state control value when cpufreq policy requests
frequency limits when matched in _PSS. Sometime calculations causes reduced
control value in boundary conditions.

Although they are independent patches, sending as series to help applying and

I appreciate review and testing on multiple platforms.

Srinivas Pandruvada (5):
  cpufreq: intel_p_state: Fix limiting turbo sub states
  cpufreq: intel_pstate: get P1 from TAR when available
  cpufreq: intel-pstate: Use separate max pstate for scaling
  cpufreq: intel_pstate: Use ACPI perf configuration
  cpufreq: intel_pstate: Avoid calculation for max/min

 arch/x86/include/asm/msr-index.h |   7 +
 drivers/cpufreq/Kconfig.x86      |   1 +
 drivers/cpufreq/intel_pstate.c   | 326 +++++++++++++++++++++++++++++++++++++--
 3 files changed, 324 insertions(+), 10 deletions(-)

(Continue reading)

Daniel Lezcano | 26 Aug 16:00 2015

Re: [PATCH] modify pl011 driver to work as wakeup source

On 08/26/2015 03:02 PM, Zhaoyang Huang wrote:
> The following functions don't work on pl011 for setting it as wakeup irq.
> device_init_wakeup(dev, true);	dev_pm_set_wake_irq(dev, irq);

Hi Zhaoyang,

if I understood correctly, dev_pm_set_wake_irq is the new API to set a 
wake up device up. You are the first one using it, so perhaps there is 
something missing.

I recommend you have a look at the slides [1] showed at the LPC2015.

I added Sudeep so he can give more informations about that.

   -- Daniel


> On 14 August 2015 at 18:58, Daniel Lezcano <daniel.lezcano <at>
> <mailto:daniel.lezcano <at>>> wrote:
>     On 08/14/2015 12:24 PM, Zhaoyang Huang wrote:
>         add IRQF_NO_SUSPEND flag when requiring irq line and call
>         the pm_system_wakeup when RX interrupt happens
>         Signed-off-by: Zhaoyang Huang <zhaoyang.huang <at>
>         <mailto:zhaoyang.huang <at>>>
(Continue reading)