From: Mark Brown <broonie(a)linaro.org>
There is no need to use a normal per-CPU workqueue for delayed power downs
as they're not timing or performance critical and waking up a core for them
would defeat some of the point.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
drivers/regulator/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index b6efead..6ef476f 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1891,8 +1891,9 @@ int regulator_disable_deferred(struct regulator *regulator, int ms)
rdev->deferred_disables++;
mutex_unlock(&rdev->mutex);
- ret = schedule_delayed_work(&rdev->disable_work,
- msecs_to_jiffies(ms));
+ ret = queue_delayed_work(system_power_efficient_wq,
+ &rdev->disable_work,
+ msecs_to_jiffies(ms));
if (ret < 0)
return ret;
else
--
1.8.3.2
From: Mark Brown <broonie(a)linaro.org>
There is no need to use a normal per-CPU workqueue for delayed power downs
as they're not timing or performance critical and waking up a core for them
would defeat some of the point.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
sound/soc/soc-pcm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index b6c6403..f4f68cb 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -411,8 +411,9 @@ static int soc_pcm_close(struct snd_pcm_substream *substream)
} else {
/* start delayed pop wq here for playback streams */
rtd->pop_wait = 1;
- schedule_delayed_work(&rtd->delayed_work,
- msecs_to_jiffies(rtd->pmdown_time));
+ queue_delayed_work(system_power_efficient_wq,
+ &rtd->delayed_work,
+ msecs_to_jiffies(rtd->pmdown_time));
}
} else {
/* capture streams can be powered down now */
--
1.8.3.2
From: Mark Brown <broonie(a)linaro.org>
The jack detection code holds runtime PM references when required so
there is no need for suspend to do any checks.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
drivers/mfd/wm8994-core.c | 14 --------------
1 file changed, 14 deletions(-)
diff --git a/drivers/mfd/wm8994-core.c b/drivers/mfd/wm8994-core.c
index 781115e..e8ecb8e 100644
--- a/drivers/mfd/wm8994-core.c
+++ b/drivers/mfd/wm8994-core.c
@@ -245,20 +245,6 @@ static int wm8994_suspend(struct device *dev)
break;
}
- switch (wm8994->type) {
- case WM1811:
- ret = wm8994_reg_read(wm8994, WM8994_ANTIPOP_2);
- if (ret < 0) {
- dev_err(dev, "Failed to read jackdet: %d\n", ret);
- } else if (ret & WM1811_JACKDET_MODE_MASK) {
- dev_dbg(dev, "CODEC still active, ignoring suspend\n");
- return 0;
- }
- break;
- default:
- break;
- }
-
/* Disable LDO pulldowns while the device is suspended if we
* don't know that something will be driving them. */
if (!wm8994->ldo_ena_always_driven)
--
1.8.3.2
Hi All,
This series patches extend Pawel's patches to
Versatile Express HDLCD DVI output support.
Before apply this patches, please apply Pawel's patches first.
This series patches implements base on Linaro release 13.06 branch "ll_20130621.0".
here is Pawel's patches
[1] http://lists.freedesktop.org/archives/dri-devel/2013-April/037519.html
Show Liu (2):
Fixed for compatible with kernel 3.10.0-rc6
CDFv2 for VExpress HDLCD DVI output support
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 6 +-
drivers/video/Kconfig | 2 +
drivers/video/arm-hdlcd.c | 116 +++++++++++++++++++++++++---
drivers/video/fbmon.c | 12 ++-
drivers/video/vexpress-dvimode.c | 11 +++
drivers/video/vexpress-muxfpga.c | 8 +-
include/linux/arm-hdlcd.h | 6 ++
7 files changed, 142 insertions(+), 19 deletions(-)
--
1.7.9.5
Hi Viresh,
Sorry for the delay in sending these patches, but I have discovered that
ARM's servers have been blocking my emails sent through the old non-disclaimer
server, so early messages have not reached you.
Here is a set of patches that we would like to add to your tree (while you are
still maintaining it?). They improve the HMP behaviour, specially when running
under Android on TC2.
I'm attaching the emails and also an archive, to work around the broken Exchange
server.
Best regards,
Liviu
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
Adding linaro-kernel to get others involved in it.
On 17 July 2013 05:58, 이가람 <wind351(a)gmail.com> wrote:
> Hello. My name is Karam Lee in Korea.
>
> I am obviously interested in your "Queue work on power efficient wq" patch.
>
> This is an interesting field for me, and I think the idea is good.
>
> So I want to try to test the patch, Can you explain to me how you did it in
> detail?
>
> What tool did you use to draw the results?
>
> If you give me an answer, I will appreciate your kindness.
I copied below from my cover-letter only, where numbers are
given. We used ARM Versatile express with TC2 for our tests which had
a on board hwmon to get us energy numbers for A7 and A15 clusters.
Test was simple, just run some audio in background and monitor power
numbers for that time.
I used to run mytrace.sh (attached), which also takes some trace for
me, which I used to analyse with kernelshark then to see how wakeups
are happening on my board.
-------x--------------x--------------
Setup:
-----
- ARM Vexpress TC2 - big.LITTLE CPU
- Core 0-1: A15, 2-4: A7
- rootfs: linaro-ubuntu-devel
This patchset has been tested on a big LITTLE system (heterogeneous) but is
useful for all other homogeneous systems as well. During these tests audio was
played in background using aplay.
Results:
-------
Cluster A15 Energy Cluster A7 Energy Total
------------------------- ----------------------- ------
Without this patchset (Energy in Joules):
---------------------------------------------------
0.151162 2.183545 2.334707
0.223730 2.687067 2.910797
0.289687 2.732702 3.022389
0.454198 2.745908 3.200106
0.495552 2.746465 3.242017
Average:
0.322866 2.619137 2.942003
With this patchset (Energy in Joules):
-----------------------------------------------
0.226421 2.283658 2.510079
0.151361 2.236656 2.388017
0.197726 2.249849 2.447575
0.221915 2.229446 2.451361
0.347098 2.257707 2.604805
Average:
0.2289042 2.2514632 2.4803674
Above tests are repeated multiple times and events are tracked using trace-cmd
and analysed using kernelshark. And it was easily noticeable that idle time for
many cpus has increased considerably, which eventually saved some power.