Geert Uytterhoeven | 29 Aug 15:50 2014

[PATCH 00/11] ARM: shmobile: r8a7740/armadillo legacy prototype pm domain support

	Hi Simon, Magnus,

This series contains prototype patches to improve pm domain support for
r8a7740/armadillo800eva, mimicking (parts of) the existing pm domain support
for sh7372/mackerel.

More specifically, they
  - Add missing devices to existing pm domains,
  - Add missing pm domains, hooking up devices and subdomains,

There are a few things commented out, and a few rough edges or missing things
(cfr. the patches marked with "[WIP]", and the "FIXME" sections therein),
but the result does boot, and s2ram works.

Please note that DT/multi-platform support will be added later.

This series depends on my series "[PATCH 0/5] ARM: shmobile: pm domain
improvements and cleanups".

Thanks for your comments and suggestions!

Geert Uytterhoeven (11):
  ARM: shmobile: r8a7740: Add missing A3SP pm domain devices
  ARM: shmobile: r8a7740: Add missing A4S pm domain devices
  [WIP] ARM: shmobile: armadillo800eva legacy: Add missing A3SP pm
    domain devices
  ARM: shmobile: armadillo800eva legacy: Add missing A4S pm domain
  ARM: shmobile: r8a7740: Add A3RV pm domain support
  ARM: shmobile: r8a7740: Add A3SG pm domain support
(Continue reading)

Geert Uytterhoeven | 29 Aug 15:13 2014

[PATCH] PM / Domains: Make const

Signed-off-by: Geert Uytterhoeven <geert+renesas <at>>
 include/linux/pm_domain.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 7c1d252b20c0..ebc4c76ffb73 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
 <at>  <at>  -60,7 +60,7  <at>  <at>  struct generic_pm_domain {
 	struct mutex lock;
 	struct dev_power_governor *gov;
 	struct work_struct power_off_work;
-	char *name;
+	const char *name;
 	unsigned int in_progress;	/* Number of devices being suspended now */
 	atomic_t sd_count;	/* Number of subdomains with power "on" */
 	enum gpd_status status;	/* Current state of the domain */


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

Jingoo Han | 29 Aug 05:45 2014

[PATCH] charger-manager: Remove casting the return value which is a void pointer

Casting the return value which is a void pointer is redundant.
The conversion from void pointer to any other pointer type is
guaranteed by the C programming language.

Signed-off-by: Jingoo Han <jg1.han <at>>
 drivers/power/charger-manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 9e4dab46eefd..1b87702c1753 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
 <at>  <at>  -1656,7 +1656,7  <at>  <at>  static inline struct charger_desc *cm_get_drv_data(struct platform_device *pdev)
 	if (pdev->dev.of_node)
 		return of_cm_parse_desc(&pdev->dev);
-	return (struct charger_desc *)dev_get_platdata(&pdev->dev);
+	return dev_get_platdata(&pdev->dev);

 static int charger_manager_probe(struct platform_device *pdev)


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)


cpufreq_governor_lock contention

While running heavy storage IO to test scsi-mq in 3-17.0-rc1,
cpufreq_governor_lock shows up as the third highest contended lock 
- about 21 million contentions in a 12 hour test run.

It looks like that might be from a patch in January that added
the calls in gov_queue_work:

Could this be modified to run lockless?

From /proc/lock_stat (very wide lines), the top 4 were:
                              class name    con-bounces    contentions   waittime-min   waittime-max waittime-total   waittime-avg   
acq-bounces   acquisitions   holdtime-min   holdtime-max holdtime-total   holdtime-avg

                   async_umap_flush_lock:    5328638171     5328649297           0.08         524.83 153171738163.9         148.18    14311039119   
15023422962           0.09        1405.42 18458469940.63           8.63
                   async_umap_flush_lock     5328649297          [<ffffffff814ed355>] add_unmap+0x35/0xf0
                   async_umap_flush_lock             10          [<ffffffff814ed42a>] flush_unmaps_timeout+0x1a/0x40
                   async_umap_flush_lock     5328649287          [<ffffffff814ed355>] add_unmap+0x35/0xf0                                     261           4012                                     72539.44


                  &(&__ctx->lock)->rlock:     147426205      148262954           0.09        1119.96  2169366898.55          14.63     1029612354   
30151514252           0.07        1688.77 39760142571.97         458.37
(Continue reading)

Shilpasri G Bhat | 28 Aug 16:06 2014

[PATCH v2] cpufreq: powernv: Set the cpus to nominal frequency during reboot/kexec

This patch ensures the cpus to kexec/reboot at nominal frequency.
Nominal frequency is the highest cpu frequency on PowerPC at
which the cores can run without getting throttled.

If the host kernel had set the cpus to a low pstate and then it
kexecs/reboots to a cpufreq disabled kernel it would cause the target
kernel to perform poorly. It will also increase the boot up time of
the target kernel. So set the cpus to high pstate, in this case to
nominal frequency before rebooting to avoid such scenarios.

The reboot notifier will set the cpus to nominal frequncy.

Changes v1->v2:
Invoke .target() driver callback to set the cpus to nominal frequency
in reboot notifier, instead of calling cpufreq_suspend() as suggested
by Viresh Kumar.
Modified the commit message.

Signed-off-by: Shilpasri G Bhat <shilpa.bhat <at>>
Reviewed-by: Preeti U Murthy <preeti <at>>
 drivers/cpufreq/powernv-cpufreq.c | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
index 379c083..ba27c49 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
 <at>  <at>  -26,6 +26,7  <at>  <at> 
 #include <linux/cpufreq.h>
(Continue reading)

Adam Thomson | 28 Aug 12:48 2014

[PATCH v2 0/7] Add initial support for DA9150 Charger & Fuel-Gauge IC

This patch set adds initial support for the Dialog DA9150 Integrated Charger &
Fuel-Gauge IC. The device also provides GPIO and GPADC functionality.

In this patch set the following is provided:
 - MFD Core support and DT bindings documentation.
 - IIO GPADC support and DT bindings documentation.
 - Power Supply Charger support and DT bindings documentation.
 - Update to MAINTAINERS file to add DA9150 files to Dialog support list.

To keep patch submission from being too large, support for GPIO and Fuel-Gauge
will come after initial support patches are accepted.

This patch set is baselined against the v3.17-rc2 kernel version.

Changes in v2:
 - Drop devicetree prefix patch as this is being dealt with separately.
 - IIO framework fix patch removed from set, has already been accepted/merged.
 - Use __ instead of _ for protecting #ifdefs in headers.
 - Moved private data & definitions to source files and remove unwanted headers.
 - Bug fix to EXPORT_SYMBOL for common functions in MFD core used by
   sub-devices, so they can be correctly built as kernel modules.
 - Removed unnecessary channels from GPADC IIO driver to simplify code.
 - For GPADC IIO driver, VBAT reading now provides scale and offset values as it
   is a linear scale.
 - GPADC read code refactored to make it tidier.
 - Remove use of flag to indicate GPADC availability. IIO framework should
   indicate need to defer if it's not yet instantiated.
 - Unwanted comments removed.
 - Removed conditional shutdown of device (Charger/MFD) as this is not needed.
 - Removed AC type supply from charger as device cannot differentiate. Now just
(Continue reading)

Geert Uytterhoeven | 28 Aug 10:12 2014

[PATCH v2] thermal: rcar: Add binding docs for new R-Car Gen2 SoCs

  - r8a7792 (R-Car V2H)
  - r8a7793 (R-Car M2-N)
  - r8a7794 (R-Car E2)

r8a7791 is now called "R-Car M2-W".

Signed-off-by: Geert Uytterhoeven <geert+renesas <at>>
v2: Drop RFC
 Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
index 0ef00be44b01..43404b197933 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
 <at>  <at>  -7,7 +7,10  <at>  <at>  Required properties:
 			    - "renesas,thermal-r8a73a4" (R-Mobile AP6)
 			    - "renesas,thermal-r8a7779" (R-Car H1)
 			    - "renesas,thermal-r8a7790" (R-Car H2)
-			    - "renesas,thermal-r8a7791" (R-Car M2)
+			    - "renesas,thermal-r8a7791" (R-Car M2-W)
+			    - "renesas,thermal-r8a7792" (R-Car V2H)
+			    - "renesas,thermal-r8a7793" (R-Car M2-N)
+			    - "renesas,thermal-r8a7794" (R-Car E2)
 - reg			: Address range of the thermal registers.
 			  The 1st reg will be recognized as common register
 			  if it has "interrupts".

(Continue reading)

Viresh Kumar | 28 Aug 07:52 2014

[PATCH V3 00/10] CPUFreq: cpufreq-cpu0 updates for 3.{17|18 ?}

Hi Rafael,

I am sending this again, but without the controversial part this time. I have
dropped last two patches which were about detecting clock sharing among CPUs.
Would fix up that later once other Maintainers get in sync about the bindings.

So, what's left here ? These are mostly updates/reorders which can be applied
the patches which I have dropped now. These are all well reviewed and tested
by others. Getting them in shouldn't break anything, I believe. Its better
people start using the updates we already have, otherwise they will keep on
sending fixes they get (The way Pramod Gurav tried it today).

Can we please get them in 3.17 if its still allowed? Or -next otherwise.


Rebased over: 3.17-rc2

git:// cpufreq/cpu0-updates-v3

V2->V3: Dropped few patches, nothing much.


Viresh Kumar (10):
  cpufreq: Add support for per-policy driver data
  cpufreq: cpu0: Update Module Author
  cpufreq: cpu0: don't validate clock on clk_put()
(Continue reading)

Lina Iyer | 27 Aug 22:14 2014

[PATCH v3 0/4] PM QoS: per-cpu PM QoS support

Changes since v2:
[ ]
- Amend commit texts

This patchset enables drivers to set per-cpu PM QoS. PM QoS requests currently
apply to all cpus. However, drivers may be interested in only a few cpu(s) that
need to gaurantee the QoS requirement. The reason being, some requests may be
needed only to allow a quicker response to an IRQ, while requests may apply to
a certain cpu or a cluster of cpus, as dictated by an usecase. For example, in
ARM architectures, it may be benefical to set a QoS requirement to handle use
cases on big/Little cluster, while the other cluster can be in the deepest idle
state it can be.

An intended application of this feature could be the cpuidle governor. For
example, governor can now look at a CPU_DMA_LATENCY request only for that cpu
when deciding the allowable C-States. In a clustered environment, the governor
would look at the QoS request for a set of cpus before deciding the cluster's
low power mode.

With these requirements in mind, the patches do the following -

- Reorganize the PM QoS and dev-PM QoS frameworks to pass around data structures
rather than member variables. Do not want to pass plist around. It is much more
scalable, if we pass the pm_qos_request object rather than its member.

- Enhance PM QoS framework to support the per-cpu requests. This is done by
adding a per-cpu array for each constraint. This array holds the per-cpu QoS
value for each constraint. The intelligence behind the per-cpu is on the driver.
The framework just adds the request against the list held by the constraint
structure. Adding a request adds the request to the list of requests
(Continue reading)

David Riley | 27 Aug 21:23 2014

[PATCH v2 0/1] gpio-restart restart handler

This driver builds upon Guenter Roeck's kernel restart handler patchset
to add a driver which registers a GPIO-based restart handler which restarts
the system by toggling a GPIO.

Changes are based off 3.17-rc2 with the following patches from v7 of 
Guenter's patchset:

Changes since v1:
	- Updated devicetree binding to make it less kernel specific
	- Changed priority property from u8 type to standard u32
	- Rename input property to open-source
	- Made delays configurable from binding
	- Removed unneeded BUG_ON
	- Used devm_gpiod_get flags parameter to configure initial direction

David Riley (1):
  power: Add simple gpio-restart driver

 .../devicetree/bindings/gpio/gpio-restart.txt      |  54 ++++++++
 drivers/power/reset/Kconfig                        |   8 ++
 drivers/power/reset/Makefile                       |   1 +
 drivers/power/reset/gpio-restart.c                 | 149 +++++++++++++++++++++
 4 files changed, 212 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-restart.txt
(Continue reading)

Tomeu Vizoso | 26 Aug 15:12 2014

[PATCH v4 0/3] PM QoS: Add support for memory bandwidth constraints


have rebased on top of linux-next and fixed some small issues (see individual
commit messages for details). Follows the original blurb:

Some device drivers need to sustain transfers to or from external memory at
given fixed rates for a period of time. If we wait for the devfreq drivers to
react to this load, the user is likely going to perceive glitches in the user

Some common scenarios that would benefit from it are display controllers
setting a new mode, USB drivers starting isochronous transfers, camera drivers
starting to capture and hw media codecs doing their thing.

I'm proposing adding a new PM_QOS_MEMORY_BANDWIDTH class that device drivers
can use to register their memory bandwidth needs right when they become known,
so the external memory clock can be set at the optimum frequency, thus
preventing glitches.

There have been similar proposals before [0], the first main concern being that
constraints need to refer to a global resource such as CPUs. If they referred
to a network NIC or to a UART, there would be no way of knowing how to actually
constrain each device because there would be a single list of requests.

In this case, the memory bus is a global resource just like the CPUs are, and
all requests in this class will apply to a single device driver in any
particular system.

The second serious concern was that constraints need to be defined in a way
generic enough so they can be consumed in a wide array of particular systems
(Continue reading)