2019-05-27 13:55:21 +07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2011-10-20 23:53:35 +07:00
|
|
|
/*
|
|
|
|
* OMAP Remote Processor driver
|
|
|
|
*
|
2020-03-24 18:00:22 +07:00
|
|
|
* Copyright (C) 2011-2020 Texas Instruments Incorporated - http://www.ti.com/
|
2011-10-20 23:53:35 +07:00
|
|
|
* Copyright (C) 2011 Google, Inc.
|
|
|
|
*
|
|
|
|
* Ohad Ben-Cohen <ohad@wizery.com>
|
|
|
|
* Brian Swetland <swetland@google.com>
|
|
|
|
* Fernando Guzman Lugo <fernando.lugo@ti.com>
|
|
|
|
* Mark Grosen <mgrosen@ti.com>
|
|
|
|
* Suman Anna <s-anna@ti.com>
|
|
|
|
* Hari Kanigeri <h-kanigeri2@ti.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
#include <linux/clk.h>
|
|
|
|
#include <linux/clk/ti.h>
|
2011-10-20 23:53:35 +07:00
|
|
|
#include <linux/err.h>
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
#include <linux/io.h>
|
2020-03-24 18:00:22 +07:00
|
|
|
#include <linux/of_device.h>
|
2020-03-24 18:00:26 +07:00
|
|
|
#include <linux/of_reserved_mem.h>
|
2011-10-20 23:53:35 +07:00
|
|
|
#include <linux/platform_device.h>
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
#include <linux/pm_runtime.h>
|
2011-10-20 23:53:35 +07:00
|
|
|
#include <linux/dma-mapping.h>
|
|
|
|
#include <linux/remoteproc.h>
|
2014-11-04 06:05:50 +07:00
|
|
|
#include <linux/mailbox_client.h>
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
#include <linux/omap-iommu.h>
|
2013-03-13 05:55:29 +07:00
|
|
|
#include <linux/omap-mailbox.h>
|
2020-03-24 18:00:22 +07:00
|
|
|
#include <linux/regmap.h>
|
|
|
|
#include <linux/mfd/syscon.h>
|
|
|
|
#include <linux/reset.h>
|
2020-03-24 18:00:30 +07:00
|
|
|
#include <clocksource/timer-ti-dm.h>
|
|
|
|
|
|
|
|
#include <linux/platform_data/dmtimer-omap.h>
|
2011-10-20 23:53:35 +07:00
|
|
|
|
|
|
|
#include "omap_remoteproc.h"
|
|
|
|
#include "remoteproc_internal.h"
|
|
|
|
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
/* default auto-suspend delay (ms) */
|
|
|
|
#define DEFAULT_AUTOSUSPEND_DELAY 10000
|
|
|
|
|
2020-03-24 18:00:22 +07:00
|
|
|
/**
|
|
|
|
* struct omap_rproc_boot_data - boot data structure for the DSP omap rprocs
|
|
|
|
* @syscon: regmap handle for the system control configuration module
|
|
|
|
* @boot_reg: boot register offset within the @syscon regmap
|
2020-03-24 18:00:27 +07:00
|
|
|
* @boot_reg_shift: bit-field shift required for the boot address value in
|
|
|
|
* @boot_reg
|
2020-03-24 18:00:22 +07:00
|
|
|
*/
|
|
|
|
struct omap_rproc_boot_data {
|
|
|
|
struct regmap *syscon;
|
|
|
|
unsigned int boot_reg;
|
2020-03-24 18:00:27 +07:00
|
|
|
unsigned int boot_reg_shift;
|
2020-03-24 18:00:22 +07:00
|
|
|
};
|
|
|
|
|
2020-03-24 18:00:24 +07:00
|
|
|
/**
|
|
|
|
* struct omap_rproc_mem - internal memory structure
|
|
|
|
* @cpu_addr: MPU virtual address of the memory region
|
|
|
|
* @bus_addr: bus address used to access the memory region
|
|
|
|
* @dev_addr: device address of the memory region from DSP view
|
|
|
|
* @size: size of the memory region
|
|
|
|
*/
|
|
|
|
struct omap_rproc_mem {
|
|
|
|
void __iomem *cpu_addr;
|
|
|
|
phys_addr_t bus_addr;
|
|
|
|
u32 dev_addr;
|
|
|
|
size_t size;
|
|
|
|
};
|
|
|
|
|
2020-03-24 18:00:30 +07:00
|
|
|
/**
|
|
|
|
* struct omap_rproc_timer - data structure for a timer used by a omap rproc
|
|
|
|
* @odt: timer pointer
|
|
|
|
* @timer_ops: OMAP dmtimer ops for @odt timer
|
|
|
|
*/
|
|
|
|
struct omap_rproc_timer {
|
|
|
|
struct omap_dm_timer *odt;
|
|
|
|
const struct omap_dm_timer_ops *timer_ops;
|
|
|
|
};
|
|
|
|
|
2011-10-20 23:53:35 +07:00
|
|
|
/**
|
|
|
|
* struct omap_rproc - omap remote processor state
|
2014-11-04 06:05:50 +07:00
|
|
|
* @mbox: mailbox channel handle
|
|
|
|
* @client: mailbox client to request the mailbox channel
|
2020-03-24 18:00:22 +07:00
|
|
|
* @boot_data: boot data structure for setting processor boot address
|
2020-03-24 18:00:24 +07:00
|
|
|
* @mem: internal memory regions data
|
|
|
|
* @num_mems: number of internal memory regions
|
2020-03-24 18:00:30 +07:00
|
|
|
* @num_timers: number of rproc timer(s)
|
|
|
|
* @timers: timer(s) info used by rproc
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
* @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
|
2011-10-20 23:53:35 +07:00
|
|
|
* @rproc: rproc handle
|
2020-03-24 18:00:22 +07:00
|
|
|
* @reset: reset handle
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
* @pm_comp: completion primitive to sync for suspend response
|
|
|
|
* @fck: functional clock for the remoteproc
|
|
|
|
* @suspend_acked: state machine flag to store the suspend request ack
|
2011-10-20 23:53:35 +07:00
|
|
|
*/
|
|
|
|
struct omap_rproc {
|
2014-11-04 06:05:50 +07:00
|
|
|
struct mbox_chan *mbox;
|
|
|
|
struct mbox_client client;
|
2020-03-24 18:00:22 +07:00
|
|
|
struct omap_rproc_boot_data *boot_data;
|
2020-03-24 18:00:24 +07:00
|
|
|
struct omap_rproc_mem *mem;
|
|
|
|
int num_mems;
|
2020-03-24 18:00:30 +07:00
|
|
|
int num_timers;
|
|
|
|
struct omap_rproc_timer *timers;
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
int autosuspend_delay;
|
|
|
|
bool need_resume;
|
2011-10-20 23:53:35 +07:00
|
|
|
struct rproc *rproc;
|
2020-03-24 18:00:22 +07:00
|
|
|
struct reset_control *reset;
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
struct completion pm_comp;
|
|
|
|
struct clk *fck;
|
|
|
|
bool suspend_acked;
|
2020-03-24 18:00:22 +07:00
|
|
|
};
|
|
|
|
|
2020-03-24 18:00:24 +07:00
|
|
|
/**
|
|
|
|
* struct omap_rproc_mem_data - memory definitions for an omap remote processor
|
|
|
|
* @name: name for this memory entry
|
|
|
|
* @dev_addr: device address for the memory entry
|
|
|
|
*/
|
|
|
|
struct omap_rproc_mem_data {
|
|
|
|
const char *name;
|
|
|
|
const u32 dev_addr;
|
|
|
|
};
|
|
|
|
|
2020-03-24 18:00:22 +07:00
|
|
|
/**
|
|
|
|
* struct omap_rproc_dev_data - device data for the omap remote processor
|
|
|
|
* @device_name: device name of the remote processor
|
2020-03-24 18:00:24 +07:00
|
|
|
* @mems: memory definitions for this remote processor
|
2020-03-24 18:00:22 +07:00
|
|
|
*/
|
|
|
|
struct omap_rproc_dev_data {
|
|
|
|
const char *device_name;
|
2020-03-24 18:00:24 +07:00
|
|
|
const struct omap_rproc_mem_data *mems;
|
2011-10-20 23:53:35 +07:00
|
|
|
};
|
|
|
|
|
2020-03-24 18:00:30 +07:00
|
|
|
/**
|
|
|
|
* omap_rproc_request_timer() - request a timer for a remoteproc
|
|
|
|
* @dev: device requesting the timer
|
|
|
|
* @np: device node pointer to the desired timer
|
|
|
|
* @timer: handle to a struct omap_rproc_timer to return the timer handle
|
|
|
|
*
|
|
|
|
* This helper function is used primarily to request a timer associated with
|
|
|
|
* a remoteproc. The returned handle is stored in the .odt field of the
|
|
|
|
* @timer structure passed in, and is used to invoke other timer specific
|
|
|
|
* ops (like starting a timer either during device initialization or during
|
|
|
|
* a resume operation, or for stopping/freeing a timer).
|
|
|
|
*
|
|
|
|
* Return: 0 on success, otherwise an appropriate failure
|
|
|
|
*/
|
|
|
|
static int omap_rproc_request_timer(struct device *dev, struct device_node *np,
|
|
|
|
struct omap_rproc_timer *timer)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
timer->odt = timer->timer_ops->request_by_node(np);
|
|
|
|
if (!timer->odt) {
|
|
|
|
dev_err(dev, "request for timer node %p failed\n", np);
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = timer->timer_ops->set_source(timer->odt, OMAP_TIMER_SRC_SYS_CLK);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "error setting OMAP_TIMER_SRC_SYS_CLK as source for timer node %p\n",
|
|
|
|
np);
|
|
|
|
timer->timer_ops->free(timer->odt);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* clean counter, remoteproc code will set the value */
|
|
|
|
timer->timer_ops->set_load(timer->odt, 0, 0);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* omap_rproc_start_timer() - start a timer for a remoteproc
|
|
|
|
* @timer: handle to a OMAP rproc timer
|
|
|
|
*
|
|
|
|
* This helper function is used to start a timer associated with a remoteproc,
|
|
|
|
* obtained using the request_timer ops. The helper function needs to be
|
|
|
|
* invoked by the driver to start the timer (during device initialization)
|
|
|
|
* or to just resume the timer.
|
|
|
|
*
|
|
|
|
* Return: 0 on success, otherwise a failure as returned by DMTimer ops
|
|
|
|
*/
|
|
|
|
static inline int omap_rproc_start_timer(struct omap_rproc_timer *timer)
|
|
|
|
{
|
|
|
|
return timer->timer_ops->start(timer->odt);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* omap_rproc_stop_timer() - stop a timer for a remoteproc
|
|
|
|
* @timer: handle to a OMAP rproc timer
|
|
|
|
*
|
|
|
|
* This helper function is used to disable a timer associated with a
|
|
|
|
* remoteproc, and needs to be called either during a device shutdown
|
|
|
|
* or suspend operation. The separate helper function allows the driver
|
|
|
|
* to just stop a timer without having to release the timer during a
|
|
|
|
* suspend operation.
|
|
|
|
*
|
|
|
|
* Return: 0 on success, otherwise a failure as returned by DMTimer ops
|
|
|
|
*/
|
|
|
|
static inline int omap_rproc_stop_timer(struct omap_rproc_timer *timer)
|
|
|
|
{
|
|
|
|
return timer->timer_ops->stop(timer->odt);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* omap_rproc_release_timer() - release a timer for a remoteproc
|
|
|
|
* @timer: handle to a OMAP rproc timer
|
|
|
|
*
|
|
|
|
* This helper function is used primarily to release a timer associated
|
|
|
|
* with a remoteproc. The dmtimer will be available for other clients to
|
|
|
|
* use once released.
|
|
|
|
*
|
|
|
|
* Return: 0 on success, otherwise a failure as returned by DMTimer ops
|
|
|
|
*/
|
|
|
|
static inline int omap_rproc_release_timer(struct omap_rproc_timer *timer)
|
|
|
|
{
|
|
|
|
return timer->timer_ops->free(timer->odt);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* omap_rproc_enable_timers() - enable the timers for a remoteproc
|
|
|
|
* @rproc: handle of a remote processor
|
|
|
|
* @configure: boolean flag used to acquire and configure the timer handle
|
|
|
|
*
|
|
|
|
* This function is used primarily to enable the timers associated with
|
|
|
|
* a remoteproc. The configure flag is provided to allow the driver to
|
|
|
|
* to either acquire and start a timer (during device initialization) or
|
|
|
|
* to just start a timer (during a resume operation).
|
|
|
|
*
|
|
|
|
* Return: 0 on success, otherwise an appropriate failure
|
|
|
|
*/
|
|
|
|
static int omap_rproc_enable_timers(struct rproc *rproc, bool configure)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
int ret = 0;
|
|
|
|
struct platform_device *tpdev;
|
|
|
|
struct dmtimer_platform_data *tpdata;
|
|
|
|
const struct omap_dm_timer_ops *timer_ops;
|
|
|
|
struct omap_rproc *oproc = rproc->priv;
|
|
|
|
struct omap_rproc_timer *timers = oproc->timers;
|
|
|
|
struct device *dev = rproc->dev.parent;
|
|
|
|
struct device_node *np = NULL;
|
|
|
|
|
|
|
|
if (!oproc->num_timers)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!configure)
|
|
|
|
goto start_timers;
|
|
|
|
|
|
|
|
for (i = 0; i < oproc->num_timers; i++) {
|
|
|
|
np = of_parse_phandle(dev->of_node, "ti,timers", i);
|
|
|
|
if (!np) {
|
|
|
|
ret = -ENXIO;
|
|
|
|
dev_err(dev, "device node lookup for timer at index %d failed: %d\n",
|
|
|
|
i, ret);
|
|
|
|
goto free_timers;
|
|
|
|
}
|
|
|
|
|
|
|
|
tpdev = of_find_device_by_node(np);
|
|
|
|
if (!tpdev) {
|
|
|
|
ret = -ENODEV;
|
|
|
|
dev_err(dev, "could not get timer platform device\n");
|
|
|
|
goto put_node;
|
|
|
|
}
|
|
|
|
|
|
|
|
tpdata = dev_get_platdata(&tpdev->dev);
|
|
|
|
put_device(&tpdev->dev);
|
|
|
|
if (!tpdata) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
dev_err(dev, "dmtimer pdata structure NULL\n");
|
|
|
|
goto put_node;
|
|
|
|
}
|
|
|
|
|
|
|
|
timer_ops = tpdata->timer_ops;
|
|
|
|
if (!timer_ops || !timer_ops->request_by_node ||
|
|
|
|
!timer_ops->set_source || !timer_ops->set_load ||
|
|
|
|
!timer_ops->free || !timer_ops->start ||
|
|
|
|
!timer_ops->stop) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
dev_err(dev, "device does not have required timer ops\n");
|
|
|
|
goto put_node;
|
|
|
|
}
|
|
|
|
|
|
|
|
timers[i].timer_ops = timer_ops;
|
|
|
|
ret = omap_rproc_request_timer(dev, np, &timers[i]);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "request for timer %p failed: %d\n", np,
|
|
|
|
ret);
|
|
|
|
goto put_node;
|
|
|
|
}
|
|
|
|
of_node_put(np);
|
|
|
|
}
|
|
|
|
|
|
|
|
start_timers:
|
|
|
|
for (i = 0; i < oproc->num_timers; i++) {
|
|
|
|
ret = omap_rproc_start_timer(&timers[i]);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "start timer %p failed failed: %d\n", np,
|
|
|
|
ret);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (ret) {
|
|
|
|
while (i >= 0) {
|
|
|
|
omap_rproc_stop_timer(&timers[i]);
|
|
|
|
i--;
|
|
|
|
}
|
|
|
|
goto put_node;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
put_node:
|
|
|
|
if (configure)
|
|
|
|
of_node_put(np);
|
|
|
|
free_timers:
|
|
|
|
while (i--) {
|
|
|
|
omap_rproc_release_timer(&timers[i]);
|
|
|
|
timers[i].odt = NULL;
|
|
|
|
timers[i].timer_ops = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* omap_rproc_disable_timers() - disable the timers for a remoteproc
|
|
|
|
* @rproc: handle of a remote processor
|
|
|
|
* @configure: boolean flag used to release the timer handle
|
|
|
|
*
|
|
|
|
* This function is used primarily to disable the timers associated with
|
|
|
|
* a remoteproc. The configure flag is provided to allow the driver to
|
|
|
|
* to either stop and release a timer (during device shutdown) or to just
|
|
|
|
* stop a timer (during a suspend operation).
|
|
|
|
*
|
|
|
|
* Return: 0 on success or no timers
|
|
|
|
*/
|
|
|
|
static int omap_rproc_disable_timers(struct rproc *rproc, bool configure)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct omap_rproc *oproc = rproc->priv;
|
|
|
|
struct omap_rproc_timer *timers = oproc->timers;
|
|
|
|
|
|
|
|
if (!oproc->num_timers)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
for (i = 0; i < oproc->num_timers; i++) {
|
|
|
|
omap_rproc_stop_timer(&timers[i]);
|
|
|
|
if (configure) {
|
|
|
|
omap_rproc_release_timer(&timers[i]);
|
|
|
|
timers[i].odt = NULL;
|
|
|
|
timers[i].timer_ops = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-10-20 23:53:35 +07:00
|
|
|
/**
|
|
|
|
* omap_rproc_mbox_callback() - inbound mailbox message handler
|
2014-11-04 06:05:50 +07:00
|
|
|
* @client: mailbox client pointer used for requesting the mailbox channel
|
2011-10-20 23:53:35 +07:00
|
|
|
* @data: mailbox payload
|
|
|
|
*
|
|
|
|
* This handler is invoked by omap's mailbox driver whenever a mailbox
|
|
|
|
* message is received. Usually, the mailbox payload simply contains
|
|
|
|
* the index of the virtqueue that is kicked by the remote processor,
|
|
|
|
* and we let remoteproc core handle it.
|
|
|
|
*
|
|
|
|
* In addition to virtqueue indices, we also have some out-of-band values
|
|
|
|
* that indicates different events. Those values are deliberately very
|
|
|
|
* big so they don't coincide with virtqueue indices.
|
|
|
|
*/
|
2014-11-04 06:05:50 +07:00
|
|
|
static void omap_rproc_mbox_callback(struct mbox_client *client, void *data)
|
2011-10-20 23:53:35 +07:00
|
|
|
{
|
2014-11-04 06:05:50 +07:00
|
|
|
struct omap_rproc *oproc = container_of(client, struct omap_rproc,
|
|
|
|
client);
|
remoteproc: maintain a generic child device for each rproc
For each registered rproc, maintain a generic remoteproc device whose
parent is the low level platform-specific device (commonly a pdev, but
it may certainly be any other type of device too).
With this in hand, the resulting device hierarchy might then look like:
omap-rproc.0
|
- remoteproc0 <---- new !
|
- virtio0
|
- virtio1
|
- rpmsg0
|
- rpmsg1
|
- rpmsg2
Where:
- omap-rproc.0 is the low level device that's bound to the
driver which invokes rproc_register()
- remoteproc0 is the result of this patch, and will be added by the
remoteproc framework when rproc_register() is invoked
- virtio0 and virtio1 are vdevs that are registered by remoteproc
when it realizes that they are supported by the firmware
of the physical remote processor represented by omap-rproc.0
- rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg
channels, and are registerd by the rpmsg bus when it gets notified
about their existence
Technically, this patch:
- changes 'struct rproc' to contain this generic remoteproc.x device
- creates a new "remoteproc" type, to which this new generic remoteproc.x
device belong to.
- adds a super simple enumeration method for the indices of the
remoteproc.x devices
- updates all dev_* messaging to use the generic remoteproc.x device
instead of the low level platform-specific device
- updates all dma_* allocations to use the parent of remoteproc.x (where
the platform-specific memory pools, most commonly CMA, are to be found)
Adding this generic device has several merits:
- we can now add remoteproc runtime PM support simply by hooking onto the
new "remoteproc" type
- all remoteproc log messages will now carry a common name prefix
instead of having a platform-specific one
- having a device as part of the rproc struct makes it possible to simplify
refcounting (see subsequent patch)
Thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting and
discussing these ideas in one of the remoteproc review threads and
to Fernando Guzman Lugo <fernando.lugo@ti.com> for trying them out
with the (upcoming) runtime PM support for remoteproc.
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-05-31 02:01:25 +07:00
|
|
|
struct device *dev = oproc->rproc->dev.parent;
|
2011-10-20 23:53:35 +07:00
|
|
|
const char *name = oproc->rproc->name;
|
2014-11-04 06:05:50 +07:00
|
|
|
u32 msg = (u32)data;
|
2011-10-20 23:53:35 +07:00
|
|
|
|
|
|
|
dev_dbg(dev, "mbox msg: 0x%x\n", msg);
|
|
|
|
|
|
|
|
switch (msg) {
|
|
|
|
case RP_MBOX_CRASH:
|
|
|
|
/* just log this for now. later, we'll also do recovery */
|
|
|
|
dev_err(dev, "omap rproc %s crashed\n", name);
|
|
|
|
break;
|
|
|
|
case RP_MBOX_ECHO_REPLY:
|
|
|
|
dev_info(dev, "received echo reply from %s\n", name);
|
|
|
|
break;
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
case RP_MBOX_SUSPEND_ACK:
|
|
|
|
/* Fall through */
|
|
|
|
case RP_MBOX_SUSPEND_CANCEL:
|
|
|
|
oproc->suspend_acked = msg == RP_MBOX_SUSPEND_ACK;
|
|
|
|
complete(&oproc->pm_comp);
|
|
|
|
break;
|
2011-10-20 23:53:35 +07:00
|
|
|
default:
|
2020-03-24 18:00:29 +07:00
|
|
|
if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
|
|
|
|
return;
|
|
|
|
if (msg > oproc->rproc->max_notifyid) {
|
|
|
|
dev_dbg(dev, "dropping unknown message 0x%x", msg);
|
|
|
|
return;
|
|
|
|
}
|
2012-02-13 17:24:50 +07:00
|
|
|
/* msg contains the index of the triggered vring */
|
2011-10-20 23:53:35 +07:00
|
|
|
if (rproc_vq_interrupt(oproc->rproc, msg) == IRQ_NONE)
|
|
|
|
dev_dbg(dev, "no message was found in vqid %d\n", msg);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* kick a virtqueue */
|
|
|
|
static void omap_rproc_kick(struct rproc *rproc, int vqid)
|
|
|
|
{
|
|
|
|
struct omap_rproc *oproc = rproc->priv;
|
remoteproc: maintain a generic child device for each rproc
For each registered rproc, maintain a generic remoteproc device whose
parent is the low level platform-specific device (commonly a pdev, but
it may certainly be any other type of device too).
With this in hand, the resulting device hierarchy might then look like:
omap-rproc.0
|
- remoteproc0 <---- new !
|
- virtio0
|
- virtio1
|
- rpmsg0
|
- rpmsg1
|
- rpmsg2
Where:
- omap-rproc.0 is the low level device that's bound to the
driver which invokes rproc_register()
- remoteproc0 is the result of this patch, and will be added by the
remoteproc framework when rproc_register() is invoked
- virtio0 and virtio1 are vdevs that are registered by remoteproc
when it realizes that they are supported by the firmware
of the physical remote processor represented by omap-rproc.0
- rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg
channels, and are registerd by the rpmsg bus when it gets notified
about their existence
Technically, this patch:
- changes 'struct rproc' to contain this generic remoteproc.x device
- creates a new "remoteproc" type, to which this new generic remoteproc.x
device belong to.
- adds a super simple enumeration method for the indices of the
remoteproc.x devices
- updates all dev_* messaging to use the generic remoteproc.x device
instead of the low level platform-specific device
- updates all dma_* allocations to use the parent of remoteproc.x (where
the platform-specific memory pools, most commonly CMA, are to be found)
Adding this generic device has several merits:
- we can now add remoteproc runtime PM support simply by hooking onto the
new "remoteproc" type
- all remoteproc log messages will now carry a common name prefix
instead of having a platform-specific one
- having a device as part of the rproc struct makes it possible to simplify
refcounting (see subsequent patch)
Thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting and
discussing these ideas in one of the remoteproc review threads and
to Fernando Guzman Lugo <fernando.lugo@ti.com> for trying them out
with the (upcoming) runtime PM support for remoteproc.
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-05-31 02:01:25 +07:00
|
|
|
struct device *dev = rproc->dev.parent;
|
2011-10-20 23:53:35 +07:00
|
|
|
int ret;
|
|
|
|
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
/* 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;
|
|
|
|
}
|
|
|
|
|
2011-10-20 23:53:35 +07:00
|
|
|
/* send the index of the triggered virtqueue in the mailbox payload */
|
2014-11-04 06:05:50 +07:00
|
|
|
ret = mbox_send_message(oproc->mbox, (void *)vqid);
|
|
|
|
if (ret < 0)
|
2016-08-13 06:42:23 +07:00
|
|
|
dev_err(dev, "failed to send mailbox message, status = %d\n",
|
|
|
|
ret);
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
|
|
|
|
pm_runtime_mark_last_busy(dev);
|
|
|
|
pm_runtime_put_autosuspend(dev);
|
2011-10-20 23:53:35 +07:00
|
|
|
}
|
|
|
|
|
2020-03-24 18:00:22 +07:00
|
|
|
/**
|
|
|
|
* omap_rproc_write_dsp_boot_addr() - set boot address for DSP remote processor
|
|
|
|
* @rproc: handle of a remote processor
|
|
|
|
*
|
|
|
|
* Set boot address for a supported DSP remote processor.
|
2020-03-24 18:00:23 +07:00
|
|
|
*
|
|
|
|
* Return: 0 on success, or -EINVAL if boot address is not aligned properly
|
2020-03-24 18:00:22 +07:00
|
|
|
*/
|
2020-03-24 18:00:23 +07:00
|
|
|
static int omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
|
2020-03-24 18:00:22 +07:00
|
|
|
{
|
2020-03-24 18:00:23 +07:00
|
|
|
struct device *dev = rproc->dev.parent;
|
2020-03-24 18:00:22 +07:00
|
|
|
struct omap_rproc *oproc = rproc->priv;
|
|
|
|
struct omap_rproc_boot_data *bdata = oproc->boot_data;
|
|
|
|
u32 offset = bdata->boot_reg;
|
2020-03-24 18:00:27 +07:00
|
|
|
u32 value;
|
|
|
|
u32 mask;
|
2020-03-24 18:00:22 +07:00
|
|
|
|
2020-03-24 18:00:23 +07:00
|
|
|
if (rproc->bootaddr & (SZ_1K - 1)) {
|
|
|
|
dev_err(dev, "invalid boot address 0x%llx, must be aligned on a 1KB boundary\n",
|
|
|
|
rproc->bootaddr);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2020-03-24 18:00:27 +07:00
|
|
|
value = rproc->bootaddr >> bdata->boot_reg_shift;
|
|
|
|
mask = ~(SZ_1K - 1) >> bdata->boot_reg_shift;
|
|
|
|
|
|
|
|
return regmap_update_bits(bdata->syscon, offset, mask, value);
|
2020-03-24 18:00:22 +07:00
|
|
|
}
|
|
|
|
|
2011-10-20 23:53:35 +07:00
|
|
|
/*
|
|
|
|
* Power up the remote processor.
|
|
|
|
*
|
|
|
|
* This function will be invoked only after the firmware for this rproc
|
|
|
|
* was loaded, parsed successfully, and all of its resource requirements
|
|
|
|
* were met.
|
|
|
|
*/
|
|
|
|
static int omap_rproc_start(struct rproc *rproc)
|
|
|
|
{
|
|
|
|
struct omap_rproc *oproc = rproc->priv;
|
remoteproc: maintain a generic child device for each rproc
For each registered rproc, maintain a generic remoteproc device whose
parent is the low level platform-specific device (commonly a pdev, but
it may certainly be any other type of device too).
With this in hand, the resulting device hierarchy might then look like:
omap-rproc.0
|
- remoteproc0 <---- new !
|
- virtio0
|
- virtio1
|
- rpmsg0
|
- rpmsg1
|
- rpmsg2
Where:
- omap-rproc.0 is the low level device that's bound to the
driver which invokes rproc_register()
- remoteproc0 is the result of this patch, and will be added by the
remoteproc framework when rproc_register() is invoked
- virtio0 and virtio1 are vdevs that are registered by remoteproc
when it realizes that they are supported by the firmware
of the physical remote processor represented by omap-rproc.0
- rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg
channels, and are registerd by the rpmsg bus when it gets notified
about their existence
Technically, this patch:
- changes 'struct rproc' to contain this generic remoteproc.x device
- creates a new "remoteproc" type, to which this new generic remoteproc.x
device belong to.
- adds a super simple enumeration method for the indices of the
remoteproc.x devices
- updates all dev_* messaging to use the generic remoteproc.x device
instead of the low level platform-specific device
- updates all dma_* allocations to use the parent of remoteproc.x (where
the platform-specific memory pools, most commonly CMA, are to be found)
Adding this generic device has several merits:
- we can now add remoteproc runtime PM support simply by hooking onto the
new "remoteproc" type
- all remoteproc log messages will now carry a common name prefix
instead of having a platform-specific one
- having a device as part of the rproc struct makes it possible to simplify
refcounting (see subsequent patch)
Thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting and
discussing these ideas in one of the remoteproc review threads and
to Fernando Guzman Lugo <fernando.lugo@ti.com> for trying them out
with the (upcoming) runtime PM support for remoteproc.
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-05-31 02:01:25 +07:00
|
|
|
struct device *dev = rproc->dev.parent;
|
2011-10-20 23:53:35 +07:00
|
|
|
int ret;
|
2014-11-04 06:05:50 +07:00
|
|
|
struct mbox_client *client = &oproc->client;
|
2011-10-20 23:53:35 +07:00
|
|
|
|
2020-03-24 18:00:23 +07:00
|
|
|
if (oproc->boot_data) {
|
|
|
|
ret = omap_rproc_write_dsp_boot_addr(rproc);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2012-08-15 22:25:48 +07:00
|
|
|
|
2014-11-04 06:05:50 +07:00
|
|
|
client->dev = dev;
|
|
|
|
client->tx_done = NULL;
|
|
|
|
client->rx_callback = omap_rproc_mbox_callback;
|
|
|
|
client->tx_block = false;
|
|
|
|
client->knows_txdone = false;
|
2011-10-20 23:53:35 +07:00
|
|
|
|
2020-03-24 18:00:22 +07:00
|
|
|
oproc->mbox = mbox_request_channel(client, 0);
|
2011-10-20 23:53:35 +07:00
|
|
|
if (IS_ERR(oproc->mbox)) {
|
2014-11-04 06:05:50 +07:00
|
|
|
ret = -EBUSY;
|
|
|
|
dev_err(dev, "mbox_request_channel failed: %ld\n",
|
|
|
|
PTR_ERR(oproc->mbox));
|
2011-10-20 23:53:35 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ping the remote processor. this is only for sanity-sake;
|
|
|
|
* there is no functional effect whatsoever.
|
|
|
|
*
|
|
|
|
* Note that the reply will _not_ arrive immediately: this message
|
|
|
|
* will wait in the mailbox fifo until the remote processor is booted.
|
|
|
|
*/
|
2014-11-04 06:05:50 +07:00
|
|
|
ret = mbox_send_message(oproc->mbox, (void *)RP_MBOX_ECHO_REQUEST);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(dev, "mbox_send_message failed: %d\n", ret);
|
2011-10-20 23:53:35 +07:00
|
|
|
goto put_mbox;
|
|
|
|
}
|
|
|
|
|
2020-03-24 18:00:30 +07:00
|
|
|
ret = omap_rproc_enable_timers(rproc, true);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "omap_rproc_enable_timers failed: %d\n", ret);
|
|
|
|
goto put_mbox;
|
|
|
|
}
|
|
|
|
|
2020-03-24 18:00:22 +07:00
|
|
|
ret = reset_control_deassert(oproc->reset);
|
2011-10-20 23:53:35 +07:00
|
|
|
if (ret) {
|
2020-03-24 18:00:22 +07:00
|
|
|
dev_err(dev, "reset control deassert failed: %d\n", ret);
|
2020-03-24 18:00:30 +07:00
|
|
|
goto disable_timers;
|
2011-10-20 23:53:35 +07:00
|
|
|
}
|
|
|
|
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
/*
|
|
|
|
* 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_use_autosuspend(dev);
|
|
|
|
pm_runtime_get_noresume(dev);
|
|
|
|
pm_runtime_enable(dev);
|
|
|
|
pm_runtime_mark_last_busy(dev);
|
|
|
|
pm_runtime_put_autosuspend(dev);
|
|
|
|
|
2011-10-20 23:53:35 +07:00
|
|
|
return 0;
|
|
|
|
|
2020-03-24 18:00:30 +07:00
|
|
|
disable_timers:
|
|
|
|
omap_rproc_disable_timers(rproc, true);
|
2011-10-20 23:53:35 +07:00
|
|
|
put_mbox:
|
2014-11-04 06:05:50 +07:00
|
|
|
mbox_free_channel(oproc->mbox);
|
2011-10-20 23:53:35 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* power off the remote processor */
|
|
|
|
static int omap_rproc_stop(struct rproc *rproc)
|
|
|
|
{
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
struct device *dev = rproc->dev.parent;
|
2011-10-20 23:53:35 +07:00
|
|
|
struct omap_rproc *oproc = rproc->priv;
|
|
|
|
int ret;
|
|
|
|
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
}
|
|
|
|
|
2020-03-24 18:00:22 +07:00
|
|
|
ret = reset_control_assert(oproc->reset);
|
2011-10-20 23:53:35 +07:00
|
|
|
if (ret)
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
goto out;
|
2011-10-20 23:53:35 +07:00
|
|
|
|
2020-03-24 18:00:30 +07:00
|
|
|
ret = omap_rproc_disable_timers(rproc, true);
|
|
|
|
if (ret)
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
goto enable_device;
|
2020-03-24 18:00:30 +07:00
|
|
|
|
2014-11-04 06:05:50 +07:00
|
|
|
mbox_free_channel(oproc->mbox);
|
2011-10-20 23:53:35 +07:00
|
|
|
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
/*
|
|
|
|
* 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);
|
|
|
|
|
2011-10-20 23:53:35 +07:00
|
|
|
return 0;
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
|
|
|
|
enable_device:
|
|
|
|
reset_control_deassert(oproc->reset);
|
|
|
|
out:
|
|
|
|
/* schedule the next auto-suspend */
|
|
|
|
pm_runtime_mark_last_busy(dev);
|
|
|
|
pm_runtime_put_autosuspend(dev);
|
|
|
|
return ret;
|
2011-10-20 23:53:35 +07:00
|
|
|
}
|
|
|
|
|
2020-03-24 18:00:25 +07:00
|
|
|
/**
|
|
|
|
* omap_rproc_da_to_va() - internal memory translation helper
|
|
|
|
* @rproc: remote processor to apply the address translation for
|
|
|
|
* @da: device address to translate
|
|
|
|
* @len: length of the memory buffer
|
|
|
|
*
|
|
|
|
* Custom function implementing the rproc .da_to_va ops to provide address
|
|
|
|
* translation (device address to kernel virtual address) for internal RAMs
|
|
|
|
* present in a DSP or IPU device). The translated addresses can be used
|
|
|
|
* either by the remoteproc core for loading, or by any rpmsg bus drivers.
|
|
|
|
*
|
|
|
|
* Return: translated virtual address in kernel memory space on success,
|
|
|
|
* or NULL on failure.
|
|
|
|
*/
|
|
|
|
static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
|
|
|
|
{
|
|
|
|
struct omap_rproc *oproc = rproc->priv;
|
|
|
|
int i;
|
|
|
|
u32 offset;
|
|
|
|
|
|
|
|
if (len <= 0)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (!oproc->num_mems)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
for (i = 0; i < oproc->num_mems; i++) {
|
|
|
|
if (da >= oproc->mem[i].dev_addr && da + len <=
|
|
|
|
oproc->mem[i].dev_addr + oproc->mem[i].size) {
|
|
|
|
offset = da - oproc->mem[i].dev_addr;
|
|
|
|
/* __force to make sparse happy with type conversion */
|
|
|
|
return (__force void *)(oproc->mem[i].cpu_addr +
|
|
|
|
offset);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-01-01 17:43:37 +07:00
|
|
|
static const struct rproc_ops omap_rproc_ops = {
|
2011-10-20 23:53:35 +07:00
|
|
|
.start = omap_rproc_start,
|
|
|
|
.stop = omap_rproc_stop,
|
|
|
|
.kick = omap_rproc_kick,
|
2020-03-24 18:00:25 +07:00
|
|
|
.da_to_va = omap_rproc_da_to_va,
|
2011-10-20 23:53:35 +07:00
|
|
|
};
|
|
|
|
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
#ifdef CONFIG_PM
|
|
|
|
static bool _is_rproc_in_standby(struct omap_rproc *oproc)
|
|
|
|
{
|
|
|
|
return ti_clk_is_in_standby(oproc->fck);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 1 sec is long enough time to let the remoteproc side suspend the device */
|
|
|
|
#define DEF_SUSPEND_TIMEOUT 1000
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
static int _omap_rproc_suspend(struct rproc *rproc, bool auto_suspend)
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
{
|
|
|
|
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;
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
u32 suspend_msg = auto_suspend ?
|
|
|
|
RP_MBOX_SUSPEND_AUTO : RP_MBOX_SUSPEND_SYSTEM;
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
reinit_completion(&oproc->pm_comp);
|
|
|
|
oproc->suspend_acked = false;
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
ret = mbox_send_message(oproc->mbox, (void *)suspend_msg);
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = wait_for_completion_timeout(&oproc->pm_comp, to);
|
|
|
|
if (!oproc->suspend_acked)
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The remoteproc side is returning the ACK message before saving the
|
|
|
|
* context, because the context saving is performed within a SYS/BIOS
|
|
|
|
* function, and it cannot have any inter-dependencies against the IPC
|
|
|
|
* layer. Also, as the SYS/BIOS needs to preserve properly the processor
|
|
|
|
* register set, sending this ACK or signalling the completion of the
|
|
|
|
* context save through a shared memory variable can never be the
|
|
|
|
* absolute last thing to be executed on the remoteproc side, and the
|
|
|
|
* MPU cannot use the ACK message as a sync point to put the remoteproc
|
|
|
|
* into reset. The only way to ensure that the remote processor has
|
|
|
|
* completed saving the context is to check that the module has reached
|
|
|
|
* STANDBY state (after saving the context, the SYS/BIOS executes the
|
|
|
|
* appropriate target-specific WFI instruction causing the module to
|
|
|
|
* enter STANDBY).
|
|
|
|
*/
|
|
|
|
while (!_is_rproc_in_standby(oproc)) {
|
|
|
|
if (time_after(jiffies, ta))
|
|
|
|
return -ETIME;
|
|
|
|
schedule();
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = reset_control_assert(oproc->reset);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "reset assert during suspend failed %d\n", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = omap_rproc_disable_timers(rproc, false);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "disabling timers during suspend failed %d\n",
|
|
|
|
ret);
|
|
|
|
goto enable_device;
|
|
|
|
}
|
|
|
|
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
return 0;
|
|
|
|
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
enable_timers:
|
|
|
|
/* ignore errors on re-enabling code */
|
|
|
|
omap_rproc_enable_timers(rproc, false);
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
enable_device:
|
|
|
|
reset_control_deassert(oproc->reset);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
static int _omap_rproc_resume(struct rproc *rproc, bool auto_suspend)
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
{
|
|
|
|
struct device *dev = rproc->dev.parent;
|
|
|
|
struct omap_rproc *oproc = rproc->priv;
|
|
|
|
int ret;
|
|
|
|
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
/* 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);
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
goto suspend_iommu;
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = omap_rproc_enable_timers(rproc, false);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "enabling timers during resume failed %d\n", ret);
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
goto suspend_iommu;
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
ret = reset_control_deassert(oproc->reset);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "reset deassert during resume failed %d\n", ret);
|
|
|
|
goto disable_timers;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
disable_timers:
|
|
|
|
omap_rproc_disable_timers(rproc, false);
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
suspend_iommu:
|
|
|
|
if (auto_suspend)
|
|
|
|
omap_iommu_domain_deactivate(rproc->domain);
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
out:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
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);
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
struct omap_rproc *oproc = rproc->priv;
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
mutex_lock(&rproc->lock);
|
|
|
|
if (rproc->state == RPROC_OFFLINE)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (rproc->state == RPROC_SUSPENDED)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (rproc->state != RPROC_RUNNING) {
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
ret = _omap_rproc_suspend(rproc, false);
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "suspend failed %d\n", ret);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
/*
|
|
|
|
* remoteproc is running at the time of system suspend, so remember
|
|
|
|
* it so as to wake it up during system resume
|
|
|
|
*/
|
|
|
|
oproc->need_resume = true;
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
rproc->state = RPROC_SUSPENDED;
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
out:
|
|
|
|
mutex_unlock(&rproc->lock);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
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);
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
struct omap_rproc *oproc = rproc->priv;
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
mutex_lock(&rproc->lock);
|
|
|
|
if (rproc->state == RPROC_OFFLINE)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (rproc->state != RPROC_SUSPENDED) {
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
/*
|
|
|
|
* 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);
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "resume failed %d\n", ret);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
oproc->need_resume = false;
|
|
|
|
rproc->state = RPROC_RUNNING;
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
mutex_lock(&rproc->lock);
|
|
|
|
if (rproc->state == RPROC_CRASHED) {
|
|
|
|
dev_dbg(dev, "rproc cannot be runtime suspended when crashed!\n");
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (WARN_ON(rproc->state != RPROC_RUNNING)) {
|
|
|
|
dev_err(dev, "rproc cannot be runtime suspended when not running!\n");
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
mutex_unlock(&rproc->lock);
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
abort:
|
|
|
|
pm_runtime_mark_last_busy(dev);
|
|
|
|
out:
|
|
|
|
mutex_unlock(&rproc->lock);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int omap_rproc_runtime_resume(struct device *dev)
|
|
|
|
{
|
|
|
|
struct rproc *rproc = dev_get_drvdata(dev);
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(&rproc->lock);
|
|
|
|
if (WARN_ON(rproc->state != RPROC_SUSPENDED)) {
|
|
|
|
dev_err(dev, "rproc cannot be runtime resumed if not suspended! state=%d\n",
|
|
|
|
rproc->state);
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = _omap_rproc_resume(rproc, true);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "runtime resume failed %d\n", ret);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
rproc->state = RPROC_RUNNING;
|
|
|
|
out:
|
|
|
|
mutex_unlock(&rproc->lock);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_PM */
|
|
|
|
|
2020-03-24 18:00:24 +07:00
|
|
|
static const struct omap_rproc_mem_data ipu_mems[] = {
|
|
|
|
{ .name = "l2ram", .dev_addr = 0x20000000 },
|
|
|
|
{ },
|
|
|
|
};
|
|
|
|
|
2020-03-24 18:00:27 +07:00
|
|
|
static const struct omap_rproc_mem_data dra7_dsp_mems[] = {
|
|
|
|
{ .name = "l2ram", .dev_addr = 0x800000 },
|
|
|
|
{ .name = "l1pram", .dev_addr = 0xe00000 },
|
|
|
|
{ .name = "l1dram", .dev_addr = 0xf00000 },
|
|
|
|
{ },
|
|
|
|
};
|
|
|
|
|
2020-03-24 18:00:22 +07:00
|
|
|
static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
|
|
|
|
.device_name = "dsp",
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct omap_rproc_dev_data omap4_ipu_dev_data = {
|
|
|
|
.device_name = "ipu",
|
2020-03-24 18:00:24 +07:00
|
|
|
.mems = ipu_mems,
|
2020-03-24 18:00:22 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
|
|
|
|
.device_name = "dsp",
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
|
|
|
|
.device_name = "ipu",
|
2020-03-24 18:00:24 +07:00
|
|
|
.mems = ipu_mems,
|
2020-03-24 18:00:22 +07:00
|
|
|
};
|
|
|
|
|
2020-03-24 18:00:27 +07:00
|
|
|
static const struct omap_rproc_dev_data dra7_dsp_dev_data = {
|
|
|
|
.device_name = "dsp",
|
|
|
|
.mems = dra7_dsp_mems,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct omap_rproc_dev_data dra7_ipu_dev_data = {
|
|
|
|
.device_name = "ipu",
|
|
|
|
.mems = ipu_mems,
|
|
|
|
};
|
|
|
|
|
2020-03-24 18:00:22 +07:00
|
|
|
static const struct of_device_id omap_rproc_of_match[] = {
|
|
|
|
{
|
|
|
|
.compatible = "ti,omap4-dsp",
|
|
|
|
.data = &omap4_dsp_dev_data,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.compatible = "ti,omap4-ipu",
|
|
|
|
.data = &omap4_ipu_dev_data,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.compatible = "ti,omap5-dsp",
|
|
|
|
.data = &omap5_dsp_dev_data,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.compatible = "ti,omap5-ipu",
|
|
|
|
.data = &omap5_ipu_dev_data,
|
|
|
|
},
|
2020-03-24 18:00:27 +07:00
|
|
|
{
|
|
|
|
.compatible = "ti,dra7-dsp",
|
|
|
|
.data = &dra7_dsp_dev_data,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.compatible = "ti,dra7-ipu",
|
|
|
|
.data = &dra7_ipu_dev_data,
|
|
|
|
},
|
2020-03-24 18:00:22 +07:00
|
|
|
{
|
|
|
|
/* end */
|
|
|
|
},
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(of, omap_rproc_of_match);
|
|
|
|
|
|
|
|
static const char *omap_rproc_get_firmware(struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
const char *fw_name;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = of_property_read_string(pdev->dev.of_node, "firmware-name",
|
|
|
|
&fw_name);
|
|
|
|
if (ret)
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
|
|
|
|
return fw_name;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int omap_rproc_get_boot_data(struct platform_device *pdev,
|
|
|
|
struct rproc *rproc)
|
|
|
|
{
|
|
|
|
struct device_node *np = pdev->dev.of_node;
|
|
|
|
struct omap_rproc *oproc = rproc->priv;
|
|
|
|
const struct omap_rproc_dev_data *data;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
data = of_device_get_match_data(&pdev->dev);
|
|
|
|
if (!data)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
if (!of_property_read_bool(np, "ti,bootreg"))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
oproc->boot_data = devm_kzalloc(&pdev->dev, sizeof(*oproc->boot_data),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!oproc->boot_data)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
oproc->boot_data->syscon =
|
|
|
|
syscon_regmap_lookup_by_phandle(np, "ti,bootreg");
|
|
|
|
if (IS_ERR(oproc->boot_data->syscon)) {
|
|
|
|
ret = PTR_ERR(oproc->boot_data->syscon);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (of_property_read_u32_index(np, "ti,bootreg", 1,
|
|
|
|
&oproc->boot_data->boot_reg)) {
|
|
|
|
dev_err(&pdev->dev, "couldn't get the boot register\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2020-03-24 18:00:27 +07:00
|
|
|
of_property_read_u32_index(np, "ti,bootreg", 2,
|
|
|
|
&oproc->boot_data->boot_reg_shift);
|
|
|
|
|
2020-03-24 18:00:22 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-03-24 18:00:24 +07:00
|
|
|
static int omap_rproc_of_get_internal_memories(struct platform_device *pdev,
|
|
|
|
struct rproc *rproc)
|
|
|
|
{
|
|
|
|
struct omap_rproc *oproc = rproc->priv;
|
|
|
|
struct device *dev = &pdev->dev;
|
|
|
|
const struct omap_rproc_dev_data *data;
|
|
|
|
struct resource *res;
|
|
|
|
int num_mems;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
data = of_device_get_match_data(dev);
|
|
|
|
if (!data)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
if (!data->mems)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
num_mems = of_property_count_elems_of_size(dev->of_node, "reg",
|
|
|
|
sizeof(u32)) / 2;
|
|
|
|
|
|
|
|
oproc->mem = devm_kcalloc(dev, num_mems, sizeof(*oproc->mem),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!oproc->mem)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
for (i = 0; data->mems[i].name; i++) {
|
|
|
|
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
|
|
|
|
data->mems[i].name);
|
|
|
|
if (!res) {
|
|
|
|
dev_err(dev, "no memory defined for %s\n",
|
|
|
|
data->mems[i].name);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
oproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
|
|
|
|
if (IS_ERR(oproc->mem[i].cpu_addr)) {
|
|
|
|
dev_err(dev, "failed to parse and map %s memory\n",
|
|
|
|
data->mems[i].name);
|
|
|
|
return PTR_ERR(oproc->mem[i].cpu_addr);
|
|
|
|
}
|
|
|
|
oproc->mem[i].bus_addr = res->start;
|
|
|
|
oproc->mem[i].dev_addr = data->mems[i].dev_addr;
|
|
|
|
oproc->mem[i].size = resource_size(res);
|
|
|
|
|
|
|
|
dev_dbg(dev, "memory %8s: bus addr %pa size 0x%x va %pK da 0x%x\n",
|
|
|
|
data->mems[i].name, &oproc->mem[i].bus_addr,
|
|
|
|
oproc->mem[i].size, oproc->mem[i].cpu_addr,
|
|
|
|
oproc->mem[i].dev_addr);
|
|
|
|
}
|
|
|
|
oproc->num_mems = num_mems;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-03-24 18:00:30 +07:00
|
|
|
static int omap_rproc_of_get_timers(struct platform_device *pdev,
|
|
|
|
struct rproc *rproc)
|
|
|
|
{
|
|
|
|
struct device_node *np = pdev->dev.of_node;
|
|
|
|
struct omap_rproc *oproc = rproc->priv;
|
|
|
|
struct device *dev = &pdev->dev;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Timer nodes are directly used in client nodes as phandles, so
|
|
|
|
* retrieve the count using appropriate size
|
|
|
|
*/
|
|
|
|
oproc->num_timers = of_count_phandle_with_args(np, "ti,timers", NULL);
|
|
|
|
if (oproc->num_timers <= 0) {
|
|
|
|
dev_dbg(dev, "device does not have timers, status = %d\n",
|
|
|
|
oproc->num_timers);
|
|
|
|
oproc->num_timers = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (oproc->num_timers) {
|
|
|
|
oproc->timers = devm_kcalloc(dev, oproc->num_timers,
|
|
|
|
sizeof(*oproc->timers),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!oproc->timers)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
dev_dbg(dev, "device has %d tick timers\n", oproc->num_timers);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-12-22 06:14:44 +07:00
|
|
|
static int omap_rproc_probe(struct platform_device *pdev)
|
2011-10-20 23:53:35 +07:00
|
|
|
{
|
2020-03-24 18:00:22 +07:00
|
|
|
struct device_node *np = pdev->dev.of_node;
|
2011-10-20 23:53:35 +07:00
|
|
|
struct omap_rproc *oproc;
|
|
|
|
struct rproc *rproc;
|
2020-03-24 18:00:22 +07:00
|
|
|
const char *firmware;
|
2011-10-20 23:53:35 +07:00
|
|
|
int ret;
|
2020-03-24 18:00:22 +07:00
|
|
|
struct reset_control *reset;
|
|
|
|
|
|
|
|
if (!np) {
|
|
|
|
dev_err(&pdev->dev, "only DT-based devices are supported\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
reset = devm_reset_control_array_get_exclusive(&pdev->dev);
|
|
|
|
if (IS_ERR(reset))
|
|
|
|
return PTR_ERR(reset);
|
|
|
|
|
|
|
|
firmware = omap_rproc_get_firmware(pdev);
|
|
|
|
if (IS_ERR(firmware))
|
|
|
|
return PTR_ERR(firmware);
|
2011-10-20 23:53:35 +07:00
|
|
|
|
|
|
|
ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
|
|
|
|
if (ret) {
|
2012-05-21 20:31:12 +07:00
|
|
|
dev_err(&pdev->dev, "dma_set_coherent_mask: %d\n", ret);
|
2011-10-20 23:53:35 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-03-24 18:00:22 +07:00
|
|
|
rproc = rproc_alloc(&pdev->dev, dev_name(&pdev->dev), &omap_rproc_ops,
|
|
|
|
firmware, sizeof(*oproc));
|
2011-10-20 23:53:35 +07:00
|
|
|
if (!rproc)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
oproc = rproc->priv;
|
|
|
|
oproc->rproc = rproc;
|
2020-03-24 18:00:22 +07:00
|
|
|
oproc->reset = reset;
|
2015-01-10 04:21:58 +07:00
|
|
|
/* All existing OMAP IPU and DSP processors have an MMU */
|
|
|
|
rproc->has_iommu = true;
|
2011-10-20 23:53:35 +07:00
|
|
|
|
2020-03-24 18:00:24 +07:00
|
|
|
ret = omap_rproc_of_get_internal_memories(pdev, rproc);
|
|
|
|
if (ret)
|
|
|
|
goto free_rproc;
|
|
|
|
|
2020-03-24 18:00:22 +07:00
|
|
|
ret = omap_rproc_get_boot_data(pdev, rproc);
|
|
|
|
if (ret)
|
|
|
|
goto free_rproc;
|
2020-03-24 18:00:30 +07:00
|
|
|
|
|
|
|
ret = omap_rproc_of_get_timers(pdev, rproc);
|
|
|
|
if (ret)
|
|
|
|
goto free_rproc;
|
2020-03-24 18:00:22 +07:00
|
|
|
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
init_completion(&oproc->pm_comp);
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
oproc->autosuspend_delay = DEFAULT_AUTOSUSPEND_DELAY;
|
|
|
|
|
|
|
|
of_property_read_u32(pdev->dev.of_node, "ti,autosuspend-delay-ms",
|
|
|
|
&oproc->autosuspend_delay);
|
|
|
|
|
|
|
|
pm_runtime_set_autosuspend_delay(&pdev->dev, oproc->autosuspend_delay);
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
|
|
|
|
oproc->fck = devm_clk_get(&pdev->dev, 0);
|
|
|
|
if (IS_ERR(oproc->fck)) {
|
|
|
|
ret = PTR_ERR(oproc->fck);
|
|
|
|
goto free_rproc;
|
|
|
|
}
|
|
|
|
|
2020-03-24 18:00:26 +07:00
|
|
|
ret = of_reserved_mem_device_init(&pdev->dev);
|
|
|
|
if (ret) {
|
|
|
|
dev_warn(&pdev->dev, "device does not have specific CMA pool.\n");
|
|
|
|
dev_warn(&pdev->dev, "Typically this should be provided,\n");
|
|
|
|
dev_warn(&pdev->dev, "only omit if you know what you are doing.\n");
|
|
|
|
}
|
|
|
|
|
2011-10-20 23:53:35 +07:00
|
|
|
platform_set_drvdata(pdev, rproc);
|
|
|
|
|
2012-07-04 20:25:06 +07:00
|
|
|
ret = rproc_add(rproc);
|
2011-10-20 23:53:35 +07:00
|
|
|
if (ret)
|
2020-03-24 18:00:26 +07:00
|
|
|
goto release_mem;
|
2011-10-20 23:53:35 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2020-03-24 18:00:26 +07:00
|
|
|
release_mem:
|
|
|
|
of_reserved_mem_device_release(&pdev->dev);
|
2011-10-20 23:53:35 +07:00
|
|
|
free_rproc:
|
2016-10-03 07:46:38 +07:00
|
|
|
rproc_free(rproc);
|
2011-10-20 23:53:35 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-12-22 06:14:44 +07:00
|
|
|
static int omap_rproc_remove(struct platform_device *pdev)
|
2011-10-20 23:53:35 +07:00
|
|
|
{
|
|
|
|
struct rproc *rproc = platform_get_drvdata(pdev);
|
|
|
|
|
2012-07-04 20:25:06 +07:00
|
|
|
rproc_del(rproc);
|
2016-10-03 07:46:38 +07:00
|
|
|
rproc_free(rproc);
|
2020-03-24 18:00:26 +07:00
|
|
|
of_reserved_mem_device_release(&pdev->dev);
|
2012-07-02 15:41:16 +07:00
|
|
|
|
|
|
|
return 0;
|
2011-10-20 23:53:35 +07:00
|
|
|
}
|
|
|
|
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
static const struct dev_pm_ops omap_rproc_pm_ops = {
|
|
|
|
SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
|
remoteproc/omap: Add support for runtime auto-suspend/resume
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 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 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
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@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:32 +07:00
|
|
|
SET_RUNTIME_PM_OPS(omap_rproc_runtime_suspend,
|
|
|
|
omap_rproc_runtime_resume, NULL)
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
};
|
|
|
|
|
2011-10-20 23:53:35 +07:00
|
|
|
static struct platform_driver omap_rproc_driver = {
|
|
|
|
.probe = omap_rproc_probe,
|
2012-12-22 06:14:44 +07:00
|
|
|
.remove = omap_rproc_remove,
|
2011-10-20 23:53:35 +07:00
|
|
|
.driver = {
|
|
|
|
.name = "omap-rproc",
|
remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 18:00:31 +07:00
|
|
|
.pm = &omap_rproc_pm_ops,
|
2020-03-24 18:00:22 +07:00
|
|
|
.of_match_table = omap_rproc_of_match,
|
2011-10-20 23:53:35 +07:00
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2011-12-13 19:41:47 +07:00
|
|
|
module_platform_driver(omap_rproc_driver);
|
2011-10-20 23:53:35 +07:00
|
|
|
|
|
|
|
MODULE_LICENSE("GPL v2");
|
|
|
|
MODULE_DESCRIPTION("OMAP Remote Processor control driver");
|