Re: [PATCHv3 13/15] remoteproc/omap: add support for runtime auto-suspend/resume

From: Tero Kristo
Date: Thu Jan 02 2020 - 07:50:37 EST


On 20/12/2019 20:44, Suman Anna wrote:
On 12/20/19 5:24 AM, Tero Kristo wrote:
On 20/12/2019 05:24, Suman Anna wrote:
Hi Tero,

On 12/19/19 5:43 PM, Mathieu Poirier wrote:
On Fri, Dec 13, 2019 at 02:55:35PM +0200, Tero Kristo wrote:
From: Suman Anna <s-anna@xxxxxx>

This patch enhances the PM support in the OMAP remoteproc driver to
support the runtime auto-suspend. A remoteproc may not be required to
be running all the time, and typically will need to be active only
during certain usecases. As such, to save power, it should be turned
off during potential long periods of inactivity between usecases.
This suspend and resume of the device is a relatively heavy process
in terms of latencies, so a remoteproc should be suspended only after
a certain period of prolonged inactivity. The OMAP remoteproc driver
leverages the runtime pm framework's auto_suspend feature to accomplish
this functionality. This feature is automatically enabled when a remote
processor has successfully booted. The 'autosuspend_delay_ms' for each
device dictates the inactivity period/time to wait for before
suspending the device.

The runtime auto-suspend design relies on marking the last busy time
on every communication (virtqueue kick) to and from the remote
processor.
When there has been no activity for 'autosuspend_delay_ms' time, the
runtime PM framework invokes the driver's runtime pm suspend callback
to suspend the device. The remote processor will be woken up on the
initiation of the next communication message through the runtime pm
resume callback. The current auto-suspend design also allows a remote
processor to deny a auto-suspend attempt, if it wishes to, by sending a
NACK response to the initial suspend request message sent to the remote
processor as part of the suspend process. The auto-suspend request is
also only attempted if the remote processor is idled and in standby at
the time of inactivity timer expiry. This choice is made to avoid
unnecessary messaging, and the auto-suspend is simply rescheduled to
be attempted again after a further lapse of autosuspend_delay_ms.

The runtime pm callbacks functionality in this patch reuses most of the
core logic from the suspend/resume support code, and make use of an
additional auto_suspend flag to differentiate the logic in common code
from system suspend. The system suspend/resume sequences are also
updated
to reflect the proper pm_runtime statuses, and also to really perform a
suspend/resume only if the remoteproc has not been auto-suspended at
the
time of request. The remote processor is left in suspended state on a
system resume if it has been auto-suspended before, and will be
woken up
only when a usecase needs to run. The other significant change in this
patch is to reset the remoteproc device's pm_domain so as to avoid
conflicts with the ordering sequences in the device pm_domain's runtime
callbacks and the reset management and clock management implemented
within the runtime callbacks in the driver.

The OMAP remoteproc driver currently uses a default value of 10 seconds
for all OMAP remoteprocs, and a different value can be chosen either by
choosing a positive value for the 'autosuspend_delay' in the device's
omap_rproc_fw_data in the driver match data or by updating the
'autosuspend_delay_ms' field at runtime through the sysfs interface.
ÂÂÂÂ Eg: To use 25 seconds for IPU2 on DRA7xx,
ÂÂÂÂÂÂ echo 25000 >
/sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms

The runtime suspend feature can also be similarly enabled or
disabled by
writing 'auto' or 'on' to the device's 'control' power field. The
default
is enabled.
ÂÂÂÂ Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
ÂÂÂÂÂÂ echo on > /sys/bus/platform/devices/55020000.ipu/power/control

Signed-off-by: Suman Anna <s-anna@xxxxxx>
[t-kristo@xxxxxx: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@xxxxxx>
---
 drivers/remoteproc/omap_remoteproc.c | 220
++++++++++++++++++++++++++-
 1 file changed, 214 insertions(+), 6 deletions(-)

diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index 0a9b9f7d20da..463d6f60947a 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -20,6 +20,7 @@
 #include <linux/of_device.h>
 #include <linux/of_reserved_mem.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/dma-mapping.h>
 #include <linux/remoteproc.h>
 #include <linux/mailbox_client.h>
@@ -37,6 +38,9 @@
 #include "omap_remoteproc.h"
 #include "remoteproc_internal.h"
 +/* default auto-suspend delay (ms) */
+#define DEFAULT_AUTOSUSPEND_DELAYÂÂÂÂÂÂÂ 10000
+
 /**
ÂÂ * struct omap_rproc_boot_data - boot data structure for the DSP
omap rprocs
ÂÂ * @syscon: regmap handle for the system control configuration module
@@ -83,6 +87,8 @@ struct omap_rproc_timer {
ÂÂ * @num_mems: number of internal memory regions
ÂÂ * @num_timers: number of rproc timer(s)
ÂÂ * @timers: timer(s) info used by rproc
+ * @autosuspend_delay: auto-suspend delay value to be used for
runtime pm
+ * @need_resume: if true a resume is needed in the system resume
callback
ÂÂ * @rproc: rproc handle
ÂÂ * @reset: reset handle
ÂÂ * @pm_comp: completion primitive to sync for suspend response
@@ -97,6 +103,8 @@ struct omap_rproc {
ÂÂÂÂÂ int num_mems;
ÂÂÂÂÂ int num_timers;
ÂÂÂÂÂ struct omap_rproc_timer *timers;
+ÂÂÂ int autosuspend_delay;
+ÂÂÂ bool need_resume;
ÂÂÂÂÂ struct rproc *rproc;
ÂÂÂÂÂ struct reset_control *reset;
ÂÂÂÂÂ struct completion pm_comp;
@@ -111,6 +119,7 @@ struct omap_rproc {
ÂÂ * @boot_reg_shift: bit shift for the boot register mask
ÂÂ * @mem_names: memory names for this remote processor
ÂÂ * @dev_addrs: device addresses corresponding to the memory names
+ * @autosuspend_delay: custom auto-suspend delay value in milliseconds
ÂÂ */
 struct omap_rproc_dev_data {
ÂÂÂÂÂ const char *device_name;
@@ -118,6 +127,7 @@ struct omap_rproc_dev_data {
ÂÂÂÂÂ int boot_reg_shift;
ÂÂÂÂÂ const char * const *mem_names;
ÂÂÂÂÂ const u32 *dev_addrs;
+ÂÂÂ int autosuspend_delay;
 };
  /**
@@ -384,11 +394,23 @@ static void omap_rproc_kick(struct rproc
*rproc, int vqid)
ÂÂÂÂÂ struct device *dev = rproc->dev.parent;
ÂÂÂÂÂ int ret;
 + /* wake up the rproc before kicking it */
+ÂÂÂ ret = pm_runtime_get_sync(dev);
+ÂÂÂ if (WARN_ON(ret < 0)) {
+ÂÂÂÂÂÂÂ dev_err(dev, "pm_runtime_get_sync() failed during kick, ret
= %d\n",
+ÂÂÂÂÂÂÂÂÂÂÂ ret);
+ÂÂÂÂÂÂÂ pm_runtime_put_noidle(dev);
+ÂÂÂÂÂÂÂ return;
+ÂÂÂ }
+
ÂÂÂÂÂ /* send the index of the triggered virtqueue in the mailbox
payload */
ÂÂÂÂÂ ret = mbox_send_message(oproc->mbox, (void *)vqid);
ÂÂÂÂÂ if (ret < 0)
ÂÂÂÂÂÂÂÂÂ dev_err(dev, "failed to send mailbox message, status = %d\n",
ÂÂÂÂÂÂÂÂÂÂÂÂÂ ret);
+
+ÂÂÂ pm_runtime_mark_last_busy(dev);
+ÂÂÂ pm_runtime_put_autosuspend(dev);
 }
  /**
@@ -473,6 +495,19 @@ static int omap_rproc_start(struct rproc *rproc)
ÂÂÂÂÂÂÂÂÂ goto put_mbox;
ÂÂÂÂÂ }
 + /*
+ÂÂÂÂ * remote processor is up, so update the runtime pm status and
+ÂÂÂÂ * enable the auto-suspend. The device usage count is incremented
+ÂÂÂÂ * manually for balancing it for auto-suspend
+ÂÂÂÂ */
+ÂÂÂ pm_runtime_set_active(dev);
+ÂÂÂ pm_runtime_set_autosuspend_delay(dev, oproc->autosuspend_delay);
+ÂÂÂ pm_runtime_use_autosuspend(dev);
+ÂÂÂ pm_runtime_get(dev);
+ÂÂÂ pm_runtime_enable(dev);
+ÂÂÂ pm_runtime_mark_last_busy(dev);
+ÂÂÂ pm_runtime_put_autosuspend(dev);
+
ÂÂÂÂÂ reset_control_deassert(oproc->reset);

I see that you have flipped the reset call and all the pm_runtime calls
(w.r.t my original code sequence) and pm_runtime_get instead of
pm_runtime_get_noresume(). Is there a reason for it? What is the backend
that gets exercised with pm_runtime?

PM runtime nowadays exercises ti-sysc, and we can't deassert reset
before we enable the clocks for the device. Thus, these are flipped.

But the remoteprocs are not being added under a ti-sysc node from what I
have seen so far, only the MMUs. Even if that were the case, you would
have to actually revise the above pm_runtime call sequences, as
replacing get_noresume() with get() are not equivalent.

Well yes, but IOMMUs get exercised via the PM runtime calls of the remoteproc driver, which effectively enable the clkctrl part.

Anyways, I've done some local cleanup for the PM runtime handling of OMAP remoteproc, I'll post v4 shortly.



In the old incarnation of this code, PM runtime just exercised the
hacked up functionality implemented for omap rproc alone.

Ha ha, it hadn't been easy to come up with that carefully crafted to
deal with default hwmod code around reset issues. The logic enabled the
clocking and reset independently while powering up and managed the
pm_runtime status appropriately originally.

Yeah, it is not quite that simple yet either, as we have the hard dependencies between reset + clkctrl still around... :)

-Tero




 Â return 0;
@@ -485,9 +520,26 @@ static int omap_rproc_start(struct rproc *rproc)
 /* power off the remote processor */
 static int omap_rproc_stop(struct rproc *rproc)
 {
+ÂÂÂ struct device *dev = rproc->dev.parent;
ÂÂÂÂÂ struct omap_rproc *oproc = rproc->priv;
ÂÂÂÂÂ int ret;
 + /*
+ÂÂÂÂ * cancel any possible scheduled runtime suspend by incrementing
+ÂÂÂÂ * the device usage count, and resuming the device. The remoteproc
+ÂÂÂÂ * also needs to be woken up if suspended, to avoid the remoteproc
+ÂÂÂÂ * OS to continue to remember any context that it has saved, and
+ÂÂÂÂ * avoid potential issues in misindentifying a subsequent device
+ÂÂÂÂ * reboot as a power restore boot
+ÂÂÂÂ */
+ÂÂÂ ret = pm_runtime_get_sync(dev);
+ÂÂÂ if (ret < 0) {
+ÂÂÂÂÂÂÂ pm_runtime_put_noidle(dev);
+ÂÂÂÂÂÂÂ return ret;
+ÂÂÂ }
+
+ÂÂÂ pm_runtime_put_sync(dev);
+

I didn't have this call either. And get_sync() followed by put_sync() is
essentially a no-op. Am I missing something here?

Hmm right, but you did have the device_shutdown() here, somehow this
appears to simulate that, but you are right, it is just a no-op. I don't
know if this code has actually ever done anything useful. Let me
experiment with this one a bit and see what happens. It looks like it
should be removed completely.

Yes, I did have the device_shutdown() here (turn off clocks and reset).
The processor had to be woken up before shutting down (see the comments
above the code hunk).



ÂÂÂÂÂ reset_control_assert(oproc->reset);

Overall, the previous design relied on get_sync and put_sync calling the
driver's callbacks once started and used regular clock and reset
management outside of those during powering up (first time) and actual
shut down.


 Â ret = omap_rproc_disable_timers(rproc, true);
@@ -496,6 +548,15 @@ static int omap_rproc_stop(struct rproc *rproc)
 Â mbox_free_channel(oproc->mbox);
 + /*
+ÂÂÂÂ * update the runtime pm states and status now that the remoteproc
+ÂÂÂÂ * has stopped
+ÂÂÂÂ */
+ÂÂÂ pm_runtime_disable(dev);
+ÂÂÂ pm_runtime_dont_use_autosuspend(dev);
+ÂÂÂ pm_runtime_put_noidle(dev);
+ÂÂÂ pm_runtime_set_suspended(dev);
+
ÂÂÂÂÂ return 0;
 }
 @@ -552,17 +613,19 @@ static bool _is_rproc_in_standby(struct
omap_rproc *oproc)
  /* 1 sec is long enough time to let the remoteproc side suspend
the device */
 #define DEF_SUSPEND_TIMEOUT 1000
-static int _omap_rproc_suspend(struct rproc *rproc)
+static int _omap_rproc_suspend(struct rproc *rproc, bool auto_suspend)
 {
ÂÂÂÂÂ struct device *dev = rproc->dev.parent;
ÂÂÂÂÂ struct omap_rproc *oproc = rproc->priv;
ÂÂÂÂÂ unsigned long to = msecs_to_jiffies(DEF_SUSPEND_TIMEOUT);
ÂÂÂÂÂ unsigned long ta = jiffies + to;
+ÂÂÂ u32 suspend_msg = auto_suspend ?
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ RP_MBOX_SUSPEND_AUTO : RP_MBOX_SUSPEND_SYSTEM;
ÂÂÂÂÂ int ret;
 Â reinit_completion(&oproc->pm_comp);
ÂÂÂÂÂ oproc->suspend_acked = false;
-ÂÂÂ ret = mbox_send_message(oproc->mbox, (void
*)RP_MBOX_SUSPEND_SYSTEM);
+ÂÂÂ ret = mbox_send_message(oproc->mbox, (void *)suspend_msg);
ÂÂÂÂÂ if (ret < 0) {
ÂÂÂÂÂÂÂÂÂ dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
ÂÂÂÂÂÂÂÂÂ return ret;
@@ -602,25 +665,55 @@ static int _omap_rproc_suspend(struct rproc
*rproc)
ÂÂÂÂÂÂÂÂÂ goto enable_device;
ÂÂÂÂÂ }
 + /*
+ÂÂÂÂ * IOMMUs would have to be disabled specifically for runtime
suspend.
+ÂÂÂÂ * They are handled automatically through System PM callbacks for
+ÂÂÂÂ * regular system suspend
+ÂÂÂÂ */
+ÂÂÂ if (auto_suspend) {
+ÂÂÂÂÂÂÂ ret = omap_iommu_domain_deactivate(rproc->domain);
+ÂÂÂÂÂÂÂ if (ret) {
+ÂÂÂÂÂÂÂÂÂÂÂ dev_err(dev, "iommu domain deactivate failed %d\n",
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ ret);
+ÂÂÂÂÂÂÂÂÂÂÂ goto enable_timers;
+ÂÂÂÂÂÂÂ }
+ÂÂÂ }
+
ÂÂÂÂÂ return 0;

blank line here, and remove the one before enable_device.

Hmm why? I don't think there is any coding guideline that would dictate
this. However, I'll fix this as this is effectively your file anyways.

Thanks, easier for readability between the success and failure paths.

regards
Suman


-Tero


regards
Suman

+enable_timers:
+ÂÂÂ /* ignore errors on re-enabling code */
+ÂÂÂ omap_rproc_enable_timers(rproc, false);
  enable_device:
ÂÂÂÂÂ reset_control_deassert(oproc->reset);
ÂÂÂÂÂ return ret;
 }
 -static int _omap_rproc_resume(struct rproc *rproc)
+static int _omap_rproc_resume(struct rproc *rproc, bool auto_suspend)
 {
ÂÂÂÂÂ struct device *dev = rproc->dev.parent;
ÂÂÂÂÂ struct omap_rproc *oproc = rproc->priv;
ÂÂÂÂÂ int ret;
 + /*
+ÂÂÂÂ * IOMMUs would have to be enabled specifically for runtime
resume.
+ÂÂÂÂ * They would have been already enabled automatically through
System
+ÂÂÂÂ * PM callbacks for regular system resume
+ÂÂÂÂ */
+ÂÂÂ if (auto_suspend) {
+ÂÂÂÂÂÂÂ ret = omap_iommu_domain_activate(rproc->domain);
+ÂÂÂÂÂÂÂ if (ret) {
+ÂÂÂÂÂÂÂÂÂÂÂ dev_err(dev, "omap_iommu activate failed %d\n", ret);
+ÂÂÂÂÂÂÂÂÂÂÂ goto out;
+ÂÂÂÂÂÂÂ }
+ÂÂÂ }
+
ÂÂÂÂÂ /* boot address could be lost after suspend, so restore it */
ÂÂÂÂÂ if (oproc->boot_data) {
ÂÂÂÂÂÂÂÂÂ ret = omap_rproc_write_dsp_boot_addr(rproc);
ÂÂÂÂÂÂÂÂÂ if (ret) {
ÂÂÂÂÂÂÂÂÂÂÂÂÂ dev_err(dev, "boot address restore failed %d\n", ret);
-ÂÂÂÂÂÂÂÂÂÂÂ goto out;
+ÂÂÂÂÂÂÂÂÂÂÂ goto suspend_iommu;

The same needs to be done if omap_rproc_enable_timers() fails.

ÂÂÂÂÂÂÂÂÂ }
ÂÂÂÂÂ }
 @@ -633,6 +726,12 @@ static int _omap_rproc_resume(struct rproc
*rproc)
 Â reset_control_deassert(oproc->reset);
 + return 0;
+
+suspend_iommu:
+ÂÂÂ if (auto_suspend)
+ÂÂÂÂÂÂÂ omap_iommu_domain_deactivate(rproc->domain);
+
 out:
ÂÂÂÂÂ return ret;
 }
@@ -641,6 +740,7 @@ static int __maybe_unused
omap_rproc_suspend(struct device *dev)
 {
ÂÂÂÂÂ struct platform_device *pdev = to_platform_device(dev);
ÂÂÂÂÂ struct rproc *rproc = platform_get_drvdata(pdev);
+ÂÂÂ struct omap_rproc *oproc = rproc->priv;
ÂÂÂÂÂ int ret = 0;
 Â mutex_lock(&rproc->lock);
@@ -655,13 +755,25 @@ static int __maybe_unused
omap_rproc_suspend(struct device *dev)
ÂÂÂÂÂÂÂÂÂ goto out;
ÂÂÂÂÂ }
 - ret = _omap_rproc_suspend(rproc);
+ÂÂÂ ret = _omap_rproc_suspend(rproc, false);
ÂÂÂÂÂ if (ret) {
ÂÂÂÂÂÂÂÂÂ dev_err(dev, "suspend failed %d\n", ret);
ÂÂÂÂÂÂÂÂÂ goto out;
ÂÂÂÂÂ }
 + /*
+ÂÂÂÂ * remoteproc is running at the time of system suspend, so
remember
+ÂÂÂÂ * it so as to wake it up during system resume
+ÂÂÂÂ */
+ÂÂÂ oproc->need_resume = 1;

Please use 'true' to be consistent with the type and
omap_rproc_resume().

ÂÂÂÂÂ rproc->state = RPROC_SUSPENDED;
+
+ÂÂÂ /*
+ÂÂÂÂ * update the runtime pm status to be suspended, without
decrementing
+ÂÂÂÂ * the device usage count
+ÂÂÂÂ */
+ÂÂÂ pm_runtime_disable(dev);
+ÂÂÂ pm_runtime_set_suspended(dev);
 out:
ÂÂÂÂÂ mutex_unlock(&rproc->lock);
ÂÂÂÂÂ return ret;
@@ -671,6 +783,7 @@ static int __maybe_unused
omap_rproc_resume(struct device *dev)
 {
ÂÂÂÂÂ struct platform_device *pdev = to_platform_device(dev);
ÂÂÂÂÂ struct rproc *rproc = platform_get_drvdata(pdev);
+ÂÂÂ struct omap_rproc *oproc = rproc->priv;
ÂÂÂÂÂ int ret = 0;
 Â mutex_lock(&rproc->lock);
@@ -682,17 +795,91 @@ static int __maybe_unused
omap_rproc_resume(struct device *dev)
ÂÂÂÂÂÂÂÂÂ goto out;
ÂÂÂÂÂ }
 - ret = _omap_rproc_resume(rproc);
+ÂÂÂ /*
+ÂÂÂÂ * remoteproc was auto-suspended at the time of system suspend,
+ÂÂÂÂ * so no need to wake-up the processor (leave it in suspended
+ÂÂÂÂ * state, will be woken up during a subsequent runtime_resume)
+ÂÂÂÂ */
+ÂÂÂ if (!oproc->need_resume)
+ÂÂÂÂÂÂÂ goto out;
+
+ÂÂÂ ret = _omap_rproc_resume(rproc, false);
ÂÂÂÂÂ if (ret) {
ÂÂÂÂÂÂÂÂÂ dev_err(dev, "resume failed %d\n", ret);
ÂÂÂÂÂÂÂÂÂ goto out;
ÂÂÂÂÂ }
+ÂÂÂ oproc->need_resume = false;
 Â rproc->state = RPROC_RUNNING;
+
+ÂÂÂ /*
+ÂÂÂÂ * update the runtime pm status to be active, without incrementing
+ÂÂÂÂ * the device usage count
+ÂÂÂÂ */
+ÂÂÂ pm_runtime_set_active(dev);
+ÂÂÂ pm_runtime_enable(dev);
+ÂÂÂ pm_runtime_mark_last_busy(dev);
 out:
ÂÂÂÂÂ mutex_unlock(&rproc->lock);
ÂÂÂÂÂ return ret;
 }
+
+static int omap_rproc_runtime_suspend(struct device *dev)
+{
+ÂÂÂ struct rproc *rproc = dev_get_drvdata(dev);
+ÂÂÂ struct omap_rproc *oproc = rproc->priv;
+ÂÂÂ int ret;
+
+ÂÂÂ if (rproc->state == RPROC_CRASHED) {
+ÂÂÂÂÂÂÂ dev_dbg(dev, "rproc cannot be runtime suspended when
crashed!\n");
+ÂÂÂÂÂÂÂ return -EBUSY;
+ÂÂÂ }
+
+ÂÂÂ if (WARN_ON(rproc->state != RPROC_RUNNING)) {
+ÂÂÂÂÂÂÂ dev_err(dev, "rproc cannot be runtime suspended when not
running!\n");
+ÂÂÂÂÂÂÂ return -EBUSY;
+ÂÂÂ }
+
+ÂÂÂ /*
+ÂÂÂÂ * do not even attempt suspend if the remote processor is not
+ÂÂÂÂ * idled for runtime auto-suspend
+ÂÂÂÂ */
+ÂÂÂ if (!_is_rproc_in_standby(oproc)) {
+ÂÂÂÂÂÂÂ ret = -EBUSY;
+ÂÂÂÂÂÂÂ goto abort;
+ÂÂÂ }
+
+ÂÂÂ ret = _omap_rproc_suspend(rproc, true);
+ÂÂÂ if (ret)
+ÂÂÂÂÂÂÂ goto abort;
+
+ÂÂÂ rproc->state = RPROC_SUSPENDED;
+ÂÂÂ return 0;
+
+abort:
+ÂÂÂ pm_runtime_mark_last_busy(dev);
+ÂÂÂ return ret;
+}
+
+static int omap_rproc_runtime_resume(struct device *dev)
+{
+ÂÂÂ struct rproc *rproc = dev_get_drvdata(dev);
+ÂÂÂ int ret;
+
+ÂÂÂ if (WARN_ON(rproc->state != RPROC_SUSPENDED)) {
+ÂÂÂÂÂÂÂ dev_err(dev, "rproc cannot be runtime resumed if not
suspended!\n");
+ÂÂÂÂÂÂÂ return -EBUSY;
+ÂÂÂ }
+
+ÂÂÂ ret = _omap_rproc_resume(rproc, true);
+ÂÂÂ if (ret) {
+ÂÂÂÂÂÂÂ dev_err(dev, "runtime resume failed %d\n", ret);
+ÂÂÂÂÂÂÂ return ret;
+ÂÂÂ }
+
+ÂÂÂ rproc->state = RPROC_RUNNING;
+ÂÂÂ return 0;
+}
 #endif /* CONFIG_PM */
  static const char * const ipu_mem_names[] = {
@@ -778,6 +965,20 @@ static const struct of_device_id
omap_rproc_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, omap_rproc_of_match);
 +static int omap_rproc_get_autosuspend_delay(struct
platform_device *pdev)
+{
+ÂÂÂ const struct omap_rproc_dev_data *data;
+ÂÂÂ int delay;
+
+ÂÂÂ data = of_device_get_match_data(&pdev->dev);
+ÂÂÂ if (!data)
+ÂÂÂÂÂÂÂ return -ENODEV;

This check is done in omap_rproc_of_get_internal_memories() and
omap_rproc_get_boot_data(). I think it would be best to do it once
at the top
of the probe() function and be done with it.

That being said and as noted in a previous comment, I would push all
tuneables
to the DT. If the property is missing then things default to
DEFAULT_AUTOSUSPEND_DELAY.

+
+ÂÂÂ delay = data->autosuspend_delay;
+
+ÂÂÂ return (delay > 0) ? delay : DEFAULT_AUTOSUSPEND_DELAY;
+}
+
 static const char *omap_rproc_get_firmware(struct platform_device
*pdev)
 {
ÂÂÂÂÂ const char *fw_name;
@@ -953,6 +1154,11 @@ static int omap_rproc_probe(struct
platform_device *pdev)
ÂÂÂÂÂ }
 Â init_completion(&oproc->pm_comp);
+ÂÂÂ oproc->autosuspend_delay = omap_rproc_get_autosuspend_delay(pdev);
+ÂÂÂ if (oproc->autosuspend_delay < 0) {
+ÂÂÂÂÂÂÂ ret = oproc->autosuspend_delay;
+ÂÂÂÂÂÂÂ goto free_rproc;
+ÂÂÂ }
 Â oproc->fck = devm_clk_get(&pdev->dev, 0);
ÂÂÂÂÂ if (IS_ERR(oproc->fck)) {
@@ -994,6 +1200,8 @@ static int omap_rproc_remove(struct
platform_device *pdev)
  static const struct dev_pm_ops omap_rproc_pm_ops = {
ÂÂÂÂÂ SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
+ÂÂÂ SET_RUNTIME_PM_OPS(omap_rproc_runtime_suspend,
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ omap_rproc_runtime_resume, NULL)
 };
  static struct platform_driver omap_rproc_driver = {
--
2.17.1

--


--


--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki