Hi Luis,
On 2016-11-08 23:14, Luis R. Rodriguez wrote:
On Mon, Oct 10, 2016 at 03:32:06PM +0200, Marek Szyprowski wrote:
Hi Luis
On 2016-10-06 19:37, Luis R. Rodriguez wrote:
On Thu, Sep 29, 2016 at 10:12:31AM +0200, Marek Szyprowski wrote:
This patch uses recently introduced device links to track the runtime pm
state of the master's device. This way each SYSMMU controller is runtime
activated when its master's device is active
instead of?
instead of keeping SYSMMU controller runtime active all the time.
I thought Rafael's work was for suspend/resume, not for runtime suspend.
Is it for both ?
Yes, it solves both problems, although the suspend/resume was easy to
workaround
just by using LATE_SLEEP_OPS.
Because as far as I can tell this was painted to help
with suspend/resume ?
It also helped to remove the suspend/resume workaround.
BTW what is the master device of a SYSMMU? I have no clue about these
IOMMU devices here.
Here is a more detailed description of IOMMU hardware I wrote a few days ago
for Ulf:
http://www.mail-archive.com/linux-kernel@xxxxxxxxxxxxxxx/msg1231006.html
In short: there is a SYSMMU controller and its master device - a device,
which performs DMA operations. That SYSMMU sits in between system memory
and the master device, so it performs mapping of DMA addresses to physical
memory addresses on each DMA operation.
So you seek a run time power optimization ? Or a fix on suspend? Or both?
The main reason for using device links was to implement proper runtime power
optimization.
and can save/restore its state instead of being enabled all the time.
I take it this means currently even if the master device is disabled
(whatever that is) all SYSMMU controllers are kept enabled, is that right?
The issue here is this wastes power? Or what is the issue?
Yes, the issue here is the fact that SYSMMU is kept active all the time,
what in turn prevent the power domain for turning off even if master device
doesn't do anything and is already suspended. This directly (some clocks
enabled) and in-directly (leakage current) causes power looses.
Thanks for the confirmation so really the biggest concern here was run time PM.
This way SYSMMU controllers no
longer prevents respective power domains to be turned off when master's
device is not used.
So when the master device is idle we want to also remove power from the
controllers ? How much power does this save on a typical device in the
market BTW ?
The main purpose of this patchset is to let power domains to be turned off,
because with the current code all domains are all the time turned on,
because
SYSMMU controllers prevent them from turning them off.
I see.. I think the audio folks already addressed this with DAPM, but granted
this was for audio. Then I was also referred to the DRM / Audio component
framework, has this been looked into? v4l folks have v4l async stuff but
its not clear if that help with run time PM. I'm mentioning these given it'd be
silly to re-invent the wheel, additionally if we now have a generic solution
everyone can jump on board with there is quite a bit of work we can do to
dump a lot of old legacy crap.
Right, probably some workarounds here and there can be removed. However
components
and v4l-async solutions are for resolving only probe and registration
issues and they
are some kind of pool for grouping devices and triggering special
callback once all
requested devices in the pool have probed.
If you want I can measure the power consumption of the idle board with all
domains enabled and disabled if you want to see the numbers. On the other
board
disabling most power domains in idle state (the clocks were already
disabled)
gave me about 20mA savings (at 3.7V), what is a significant value for the
battery powered device.
Thanks, this means nothing to me, however it would be value-add to the commit log
as anyone reviewing this can understand what the goal / savings was for exactly.
Signed-off-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
---
drivers/iommu/exynos-iommu.c | 225 ++++++++++++++++++-------------------------
1 file changed, 94 insertions(+), 131 deletions(-)
I'm reviewing the device link patches now but since this is a demo of
use of that I'll note the changes here are pretty large and it makes
it terribly difficult for review. Is there any way this patch can be split
up in to logical atomic pieces that only do one task upon change ?
I will try to split it a bit, but I cannot promise that much can be done
to improve readability for someone not very familiar with the driver
internals.
I've heard this before, I don't buy it but lets see!
Somehow I managed to split this all-in-one patch into several smaller
changes
in v5 and v6 was posted yesterday ago.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
