remoteproc: add autosuspend support

In order to save power the rproc should be tunred off when it is not
in use. However going to suspend and resuming is a heavy task with a
big latency for most of the remote processors. For that reason, a
remoteproc should go to suspend only after some time of inactivity,
this auto suspend timeout is specified by the remoteproc itself
(it comes from the resource table in the firmware).

Remoteproc module is using autosuspend feature of PM runtime framework
in order to accomplish that. Remoteproc module will update the last busy
mark every time there is messaging with the remoteproc, so as you can
see it is not accurate but it gives a very good approximation of how long
the remoteproc has been idle. A new parameter in the suspend operation
for the low level drivers is added @auto_suspend flag which tells you if
the suspend comes from a autosuspend if @auto_suspend is true otherwise
it is a system suspend. In the case of auto_suspend, the low lever driver
is responsible of confirming that the remoteproc is actually idle and
then suspend the device. IF the remoteproc  is not idle, the low level
driver has the flexibility of return -EBUSY which tells to the PM
framework that the remoteproc is actually doing something and then the auto
suspend is aborted and there will be another attempt to suspend only
after a time equal to the auto suspend timeout has happened.

Please note that the system suspend needs to be performed even if the
remoteproc is not idle.

Once it is autosuspended the remote processor will be waken up every
time the host needs to send it a message, it is done in the
rproc_virtio_notify function.

The autosuspend timeout comes from the firmware, in case of the firmware
does not provide an autosuspend timeout the remoteproc module will use
a default timeout of 5 seconds. If the timeout in the firmware is
negative that means that remoteproc does not support autosuspend.

In case of autosuspend support, PM runtime framework allows to change
the autosuspend timeout at runtime using a sysfs entry available to each
remote processor.

Example:
echo 4000 > /sys/class/rproc/remoteproc0/power/autosuspend_delay_ms

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>

1 files changed, 11 insertions, 3 deletions

diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index eff5bd738de5..0e6c3f11c933 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -169,14 +169,14 @@ drivers:
  * @start:	power on the device and boot it
  * @stop:	power off the device
  * @kick:	kick a virtqueue (virtqueue id given as a parameter)
- * @suspend:	suspend the device
+ * @suspend:	suspend the device (auto_suspend flag as a parameter)
  * @resume:	resume the device
  */
 struct rproc_ops {
 	int (*start)(struct rproc *rproc);
 	int (*stop)(struct rproc *rproc);
 	void (*kick)(struct rproc *rproc, int vqid);
-	int (*suspend)(struct rproc *rproc);
+	int (*suspend)(struct rproc *rproc, bool auto_suspend);
 	int (*resume)(struct rproc *rproc);
 };
 
@@ -202,7 +202,15 @@ too expensive) to go through the existing virtqueues and look for new buffers
 in the used rings.
 
 The ->suspend() handler takes an rproc handle and it should save the context
-of that rproc and then put it in a low power state.
+of that rproc and then put it in a low power state. If @auto_suspend flag is
+true, that means it comes from a auto suspend request. This kind of request
+is not a mandatory suspend  which means you can abort suspend without any
+issue. In order to abort this auto suspend you just need to return -EBUSY.
+This will abort auto suspend and another attempt will be done only after
+another inactivity timeout. So, in this cause if the remoteproc is not really
+idle it should abort autosuspend. It is responsibility of the low lever
+driver to confirm when the remoteproc is really idle and when it is ok to
+suspend and when no suspend.
 On success, 0 is returned, and on failure, an appropriate error code.
 
 The ->resume() handler takes an rproc handle and it should restore the context