Remoteproc and system suspend/resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm adding automatic runtime suspend/resume to the IPA
driver, and it interacts with a modem (qcom_q6v5_mss.c).

One of the things I'm trying to avoid is errors being
returned from pm_runtime_get_sync().  If I ignore the
possibility that my hardware produces an error when
powering up, the only condition that I expect could
produce an error here is if the *system* is suspended
at the time I call pm_runtime_get_sync().  And I would
like to preclude that if possible.

One of the things the IPA driver depends on is remoteproc
"SSR" notification; certain activities are triggered by
modem starting or modem crashed/shutdown events.

In one example, I need to call pm_runtime_get_sync()
when a QCOM_SSR_BEFORE_POWERUP notification arrives.
That notification is implemented by ssr_notify_prepare()
in the SSR subdevice, via rproc_prepare_subdevices().
That function is called from rproc_start() as well as
__rproc_attach().

Similarly, upon receipt of a QCOM_SSR_BEFORE_SHUTDOWN
notification I again need to call pm_runtime_get_sync().

It would be nice to know that the system was not
suspended (and a system suspend will not be initiated)
while I'm handling the SSR notifications.


I notice that rproc_report_crash() includes this:

        /* Prevent suspend while the remoteproc is being recovered */
        pm_stay_awake(rproc->dev.parent);
        /* . . . */
        schedule_work(&rproc->crash_handler);

And the crash handler work function contains this:

        if (!rproc->recovery_disabled)
                rproc_trigger_recovery(rproc);

        pm_relax(rproc->dev.parent);

In other words, if a crash occurs, system suspend is
prevented until recovery is complete.  And ultimately
that means that the SSR notification for a modem
remoteproc crash will not be run when the system
is suspended, and no system suspend will be started
before the notification handler completes.

But there is no such system suspend prevention in the
other cases I mention (attach and firmware boot).  So:
- Why does rproc_report_crash() call pm_stay_awake()?
- Why do other functions that cause state transitions
  of a remoteproc (like the modem) *not* call
  pm_stay_awake() until the transition is complete?
    - rproc_fw_boot(), rproc_attach, rproc_shutdown()
- Should all remoteproc transitions be prevented
  from occurring while the system is suspended,
  and protected from interruption by a system
  suspend while the transition is underway?

                    -Alex



[Index of Archives]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux