Hello,
On 2014-12-17 03:43, amit daniel kachhap wrote:
On Tue, Dec 16, 2014 at 4:40 PM, Marek Szyprowski
<m.szyprowski@xxxxxxxxxxx> wrote:
Hello,
On 2014-12-13 17:51, Amit Daniel Kachhap wrote:
Instead of using bool to restore suspended devices initially, use flags
like GPD_DEV_SUSPEND_INIT, GPD_DEV_RESTORE_INIT and GPD_DEV_RESTORE_FORCE.
The first two flags will be similar to the existing true/false
functionality.
The third flag may be used to force restore of suspended devices
whenever their associated power domain is turned on.
Currently, PD power off function powers off all the associated unused
devices. The functionality added in this patch is similar to it.
This feature may be used for those devices which are always in ON state
if the PD associated with them is ON but may need local runtime resume
and suspend during PD On/Off. These devices (like clock) may not implement
complete pm_runtime calls such as pm_runtime_get/pm_runtime_put due to
subsystems interaction behaviour or any other reason.
The model works like,
DEV1 (Attaches itself with PD but no calls to pm_runtime_get and
/ pm_runtime_put. Its local runtime_suspend/resume is invoked via
/ GPD_DEV_RESTORE_FORCE option)
/
PD -- DEV2 (Implements complete PM runtime and calls pm_runtime_get and
\ pm_runtime_put. This in turn invokes PD On/Off)
\
DEV3 (Similar to DEV1)
Signed-off-by: Amit Daniel Kachhap <amit.daniel@xxxxxxxxxxx>
The idea of adding new gen_pd flag and reusing runtime pm calls intead of
additional
notifiers looks promising, but I have some doubts. I don't see any guarantee
that
devices with GPD_DEV_RESTORE_FORCE flag will be suspended after all "normal"
devices
and restored before them. Without such assumption it will be hard to use
this approach
for iommu related activities, because device might need to use (in its
suspend/resume
callbacks) the functionality provided by the other device with
GPD_DEV_RESTORE_FORCE
flag. Maybe some additional flags like suspend/resume priority (or more
flags) will
solve somehow this dependency.
Thanks for pointing this issue out. I agree that there is no priority
in suspending devices with this flag. But this works well in syncing
with power domain on/off as the devices of these types have only
dependency with power domain. BTW I tested this implementation with
your first version of IOMMU save/restore patches. Although i have not
posted those but they work fine. I can post those after cleaning them
up.
Right, they will work, but mainly because right now master devices don't
do any memory DMA operations in suspend/resume callbacks. However, to
propose
it as a generic solution, the priority and the order of operations
should be
somehow determined.
Here, the ordering between various devices is taken care as they are
probed at different point of time(clock then IOMMU). so the suspend
happens in reverse probe order and resume happens in probe order. I
will check more on this and get back.
Right now, it probably used the order of probing. Because iommu controllers
are probed earlier, so they are handled before the master devices.
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
