WSL2-Linux-Kernel/drivers/remoteproc/omap_remoteproc.c

1400 строки
37 KiB
C
Исходник Обычный вид История

// SPDX-License-Identifier: GPL-2.0-only
/*
* OMAP Remote Processor driver
*
* Copyright (C) 2011-2020 Texas Instruments Incorporated - http://www.ti.com/
* 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 14:00:31 +03:00
#include <linux/clk.h>
#include <linux/clk/ti.h>
#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 14:00:31 +03:00
#include <linux/io.h>
#include <linux/of_device.h>
#include <linux/of_reserved_mem.h>
#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 14:00:32 +03:00
#include <linux/pm_runtime.h>
#include <linux/dma-mapping.h>
#include <linux/interrupt.h>
#include <linux/remoteproc.h>
mailbox/omap: adapt to the new mailbox framework The OMAP mailbox driver and its existing clients (remoteproc for OMAP4+) are adapted to use the generic mailbox framework. The main changes for the adaptation are: - The tasklet used for Tx is replaced with the state machine from the generic mailbox framework. The workqueue used for processing the received messages stays intact for minimizing the effects on the OMAP mailbox clients. - The existing exported client API, omap_mbox_get, omap_mbox_put and omap_mbox_send_msg are deleted, as the framework provides equivalent functionality. A OMAP-specific omap_mbox_request_channel is added though to support non-DT way of requesting mailboxes. - The OMAP mailbox driver is integrated with the mailbox framework through the proper implementations of mbox_chan_ops, except for .last_tx_done and .peek_data. The OMAP mailbox driver does not need these ops, as it is completely interrupt driven. - The OMAP mailbox driver uses a custom of_xlate controller ops that allows phandles for the pargs specifier instead of indexing to avoid any channel registration order dependencies. - The new framework does not support multiple clients operating on a single channel, so the reference counting logic is simplified. - The remoteproc driver (current client) is adapted to use the new API. The notifier callbacks used within this client is replaced with the regular callbacks from the newer framework. - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, with the signature modified to take in the new mbox_chan handle instead of the OMAP specific omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Signed-off-by: Suman Anna <s-anna@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-04 02:05:50 +03: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 14:00:31 +03:00
#include <linux/omap-iommu.h>
#include <linux/omap-mailbox.h>
#include <linux/regmap.h>
#include <linux/mfd/syscon.h>
#include <linux/reset.h>
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
#include <clocksource/timer-ti-dm.h>
#include <linux/platform_data/dmtimer-omap.h>
#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 14:00:32 +03:00
/* default auto-suspend delay (ms) */
#define DEFAULT_AUTOSUSPEND_DELAY 10000
/**
* struct omap_rproc_boot_data - boot data structure for the DSP omap rprocs
* @syscon: regmap handle for the system control configuration module
* @boot_reg: boot register offset within the @syscon regmap
remoteproc/omap: Add support for DRA7xx remote processors DRA7xx/AM57xx SoCs have two IPU and up to two DSP processor subsystems for offloading different computation algorithms. The IPU processor subsystem contains dual-core ARM Cortex-M4 processors, and is very similar to those on OMAP5. The DSP processor subsystem is based on the TI's standard TMS320C66x DSP CorePac core. Support has been added to the OMAP remoteproc driver through new DRA7xx specific compatibles for properly probing and booting all the different processor subsystem instances on DRA7xx/AM57xx SoCs - IPU1, IPU2, DSP1 & DSP2. A build dependency with SOC_DRA7XX is added to enable the driver to be built in DRA7xx-only configuration. The DSP boot address programming needed enhancement for DRA7xx as the boot register fields are different on DRA7 compared to OMAP4 and OMAP5 SoCs. The register on DRA7xx contains additional fields within the register and the boot address bit-field is right-shifted by 10 bits. The internal memory parsing logic has also been updated to compute the device addresses for the L2 RAM for DSP devices using relative addressing logic, and to parse two additional RAMs at L1 level - L1P and L1D. This allows the remoteproc driver to support loading into these regions for a small subset of firmware images requiring as such. The most common usage would be to use the L1 programmable RAMs as L1 Caches. The firmware lookup logic also has to be adjusted for DRA7xx as there are (can be) more than one instance of both the IPU and DSP remote processors for the first time in OMAP4+ SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> [t-kristo@ti.com: moved address translation quirks to pdata] 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-8-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:27 +03:00
* @boot_reg_shift: bit-field shift required for the boot address value in
* @boot_reg
*/
struct omap_rproc_boot_data {
struct regmap *syscon;
unsigned int boot_reg;
remoteproc/omap: Add support for DRA7xx remote processors DRA7xx/AM57xx SoCs have two IPU and up to two DSP processor subsystems for offloading different computation algorithms. The IPU processor subsystem contains dual-core ARM Cortex-M4 processors, and is very similar to those on OMAP5. The DSP processor subsystem is based on the TI's standard TMS320C66x DSP CorePac core. Support has been added to the OMAP remoteproc driver through new DRA7xx specific compatibles for properly probing and booting all the different processor subsystem instances on DRA7xx/AM57xx SoCs - IPU1, IPU2, DSP1 & DSP2. A build dependency with SOC_DRA7XX is added to enable the driver to be built in DRA7xx-only configuration. The DSP boot address programming needed enhancement for DRA7xx as the boot register fields are different on DRA7 compared to OMAP4 and OMAP5 SoCs. The register on DRA7xx contains additional fields within the register and the boot address bit-field is right-shifted by 10 bits. The internal memory parsing logic has also been updated to compute the device addresses for the L2 RAM for DSP devices using relative addressing logic, and to parse two additional RAMs at L1 level - L1P and L1D. This allows the remoteproc driver to support loading into these regions for a small subset of firmware images requiring as such. The most common usage would be to use the L1 programmable RAMs as L1 Caches. The firmware lookup logic also has to be adjusted for DRA7xx as there are (can be) more than one instance of both the IPU and DSP remote processors for the first time in OMAP4+ SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> [t-kristo@ti.com: moved address translation quirks to pdata] 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-8-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:27 +03:00
unsigned int boot_reg_shift;
};
/**
* 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;
};
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03: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
* @irq: timer irq
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
*/
struct omap_rproc_timer {
struct omap_dm_timer *odt;
const struct omap_dm_timer_ops *timer_ops;
int irq;
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
};
/**
* struct omap_rproc - omap remote processor state
mailbox/omap: adapt to the new mailbox framework The OMAP mailbox driver and its existing clients (remoteproc for OMAP4+) are adapted to use the generic mailbox framework. The main changes for the adaptation are: - The tasklet used for Tx is replaced with the state machine from the generic mailbox framework. The workqueue used for processing the received messages stays intact for minimizing the effects on the OMAP mailbox clients. - The existing exported client API, omap_mbox_get, omap_mbox_put and omap_mbox_send_msg are deleted, as the framework provides equivalent functionality. A OMAP-specific omap_mbox_request_channel is added though to support non-DT way of requesting mailboxes. - The OMAP mailbox driver is integrated with the mailbox framework through the proper implementations of mbox_chan_ops, except for .last_tx_done and .peek_data. The OMAP mailbox driver does not need these ops, as it is completely interrupt driven. - The OMAP mailbox driver uses a custom of_xlate controller ops that allows phandles for the pargs specifier instead of indexing to avoid any channel registration order dependencies. - The new framework does not support multiple clients operating on a single channel, so the reference counting logic is simplified. - The remoteproc driver (current client) is adapted to use the new API. The notifier callbacks used within this client is replaced with the regular callbacks from the newer framework. - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, with the signature modified to take in the new mbox_chan handle instead of the OMAP specific omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Signed-off-by: Suman Anna <s-anna@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-04 02:05:50 +03:00
* @mbox: mailbox channel handle
* @client: mailbox client to request the mailbox channel
* @boot_data: boot data structure for setting processor boot address
* @mem: internal memory regions data
* @num_mems: number of internal memory regions
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
* @num_timers: number of rproc timer(s)
* @num_wd_timers: number of rproc watchdog timers
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
* @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 14:00:32 +03: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
* @rproc: rproc handle
* @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 14:00:31 +03: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
*/
struct omap_rproc {
mailbox/omap: adapt to the new mailbox framework The OMAP mailbox driver and its existing clients (remoteproc for OMAP4+) are adapted to use the generic mailbox framework. The main changes for the adaptation are: - The tasklet used for Tx is replaced with the state machine from the generic mailbox framework. The workqueue used for processing the received messages stays intact for minimizing the effects on the OMAP mailbox clients. - The existing exported client API, omap_mbox_get, omap_mbox_put and omap_mbox_send_msg are deleted, as the framework provides equivalent functionality. A OMAP-specific omap_mbox_request_channel is added though to support non-DT way of requesting mailboxes. - The OMAP mailbox driver is integrated with the mailbox framework through the proper implementations of mbox_chan_ops, except for .last_tx_done and .peek_data. The OMAP mailbox driver does not need these ops, as it is completely interrupt driven. - The OMAP mailbox driver uses a custom of_xlate controller ops that allows phandles for the pargs specifier instead of indexing to avoid any channel registration order dependencies. - The new framework does not support multiple clients operating on a single channel, so the reference counting logic is simplified. - The remoteproc driver (current client) is adapted to use the new API. The notifier callbacks used within this client is replaced with the regular callbacks from the newer framework. - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, with the signature modified to take in the new mbox_chan handle instead of the OMAP specific omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Signed-off-by: Suman Anna <s-anna@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-04 02:05:50 +03:00
struct mbox_chan *mbox;
struct mbox_client client;
struct omap_rproc_boot_data *boot_data;
struct omap_rproc_mem *mem;
int num_mems;
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
int num_timers;
int num_wd_timers;
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
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 14:00:32 +03:00
int autosuspend_delay;
bool need_resume;
struct rproc *rproc;
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 14:00:31 +03:00
struct completion pm_comp;
struct clk *fck;
bool suspend_acked;
};
/**
* 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;
};
/**
* struct omap_rproc_dev_data - device data for the omap remote processor
* @device_name: device name of the remote processor
* @mems: memory definitions for this remote processor
*/
struct omap_rproc_dev_data {
const char *device_name;
const struct omap_rproc_mem_data *mems;
};
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03: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);
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
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_get_timer_irq() - get the irq for a timer
* @timer: handle to a OMAP rproc timer
*
* This function is used to get the irq associated with a watchdog timer. The
* function is called by the OMAP remoteproc driver to register a interrupt
* handler to handle watchdog events on the remote processor.
*
* Return: irq id on success, otherwise a failure as returned by DMTimer ops
*/
static inline int omap_rproc_get_timer_irq(struct omap_rproc_timer *timer)
{
return timer->timer_ops->get_irq(timer->odt);
}
/**
* omap_rproc_ack_timer_irq() - acknowledge a timer irq
* @timer: handle to a OMAP rproc timer
*
* This function is used to clear the irq associated with a watchdog timer. The
* The function is called by the OMAP remoteproc upon a watchdog event on the
* remote processor to clear the interrupt status of the watchdog timer.
*/
static inline void omap_rproc_ack_timer_irq(struct omap_rproc_timer *timer)
{
timer->timer_ops->write_status(timer->odt, OMAP_TIMER_INT_OVERFLOW);
}
/**
* omap_rproc_watchdog_isr() - Watchdog ISR handler for remoteproc device
* @irq: IRQ number associated with a watchdog timer
* @data: IRQ handler data
*
* This ISR routine executes the required necessary low-level code to
* acknowledge a watchdog timer interrupt. There can be multiple watchdog
* timers associated with a rproc (like IPUs which have 2 watchdog timers,
* one per Cortex M3/M4 core), so a lookup has to be performed to identify
* the timer to acknowledge its interrupt.
*
* The function also invokes rproc_report_crash to report the watchdog event
* to the remoteproc driver core, to trigger a recovery.
*
* Return: IRQ_HANDLED on success, otherwise IRQ_NONE
*/
static irqreturn_t omap_rproc_watchdog_isr(int irq, void *data)
{
struct rproc *rproc = data;
struct omap_rproc *oproc = rproc->priv;
struct device *dev = rproc->dev.parent;
struct omap_rproc_timer *timers = oproc->timers;
struct omap_rproc_timer *wd_timer = NULL;
int num_timers = oproc->num_timers + oproc->num_wd_timers;
int i;
for (i = oproc->num_timers; i < num_timers; i++) {
if (timers[i].irq > 0 && irq == timers[i].irq) {
wd_timer = &timers[i];
break;
}
}
if (!wd_timer) {
dev_err(dev, "invalid timer\n");
return IRQ_NONE;
}
omap_rproc_ack_timer_irq(wd_timer);
rproc_report_crash(rproc, RPROC_WATCHDOG);
return IRQ_HANDLED;
}
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
/**
* 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;
int num_timers = oproc->num_timers + oproc->num_wd_timers;
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
if (!num_timers)
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
return 0;
if (!configure)
goto start_timers;
for (i = 0; i < num_timers; i++) {
if (i < oproc->num_timers)
np = of_parse_phandle(dev->of_node, "ti,timers", i);
else
np = of_parse_phandle(dev->of_node,
"ti,watchdog-timers",
(i - oproc->num_timers));
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
if (!np) {
ret = -ENXIO;
dev_err(dev, "device node lookup for timer at index %d failed: %d\n",
i < oproc->num_timers ? i :
i - oproc->num_timers, ret);
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
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 || !timer_ops->get_irq ||
!timer_ops->write_status) {
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
ret = -EINVAL;
dev_err(dev, "device does not have required timer ops\n");
goto put_node;
}
timers[i].irq = -1;
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
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);
if (i >= oproc->num_timers) {
timers[i].irq = omap_rproc_get_timer_irq(&timers[i]);
if (timers[i].irq < 0) {
dev_err(dev, "get_irq for timer %p failed: %d\n",
np, timers[i].irq);
ret = -EBUSY;
goto free_timers;
}
ret = request_irq(timers[i].irq,
omap_rproc_watchdog_isr, IRQF_SHARED,
"rproc-wdt", rproc);
if (ret) {
dev_err(dev, "error requesting irq for timer %p\n",
np);
omap_rproc_release_timer(&timers[i]);
timers[i].odt = NULL;
timers[i].timer_ops = NULL;
timers[i].irq = -1;
goto free_timers;
}
}
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
}
start_timers:
for (i = 0; i < num_timers; i++) {
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
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--) {
if (i >= oproc->num_timers)
free_irq(timers[i].irq, rproc);
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
omap_rproc_release_timer(&timers[i]);
timers[i].odt = NULL;
timers[i].timer_ops = NULL;
timers[i].irq = -1;
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
}
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;
int num_timers = oproc->num_timers + oproc->num_wd_timers;
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
if (!num_timers)
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
return 0;
for (i = 0; i < num_timers; i++) {
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
omap_rproc_stop_timer(&timers[i]);
if (configure) {
if (i >= oproc->num_timers)
free_irq(timers[i].irq, rproc);
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
omap_rproc_release_timer(&timers[i]);
timers[i].odt = NULL;
timers[i].timer_ops = NULL;
timers[i].irq = -1;
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
}
}
return 0;
}
/**
* omap_rproc_mbox_callback() - inbound mailbox message handler
mailbox/omap: adapt to the new mailbox framework The OMAP mailbox driver and its existing clients (remoteproc for OMAP4+) are adapted to use the generic mailbox framework. The main changes for the adaptation are: - The tasklet used for Tx is replaced with the state machine from the generic mailbox framework. The workqueue used for processing the received messages stays intact for minimizing the effects on the OMAP mailbox clients. - The existing exported client API, omap_mbox_get, omap_mbox_put and omap_mbox_send_msg are deleted, as the framework provides equivalent functionality. A OMAP-specific omap_mbox_request_channel is added though to support non-DT way of requesting mailboxes. - The OMAP mailbox driver is integrated with the mailbox framework through the proper implementations of mbox_chan_ops, except for .last_tx_done and .peek_data. The OMAP mailbox driver does not need these ops, as it is completely interrupt driven. - The OMAP mailbox driver uses a custom of_xlate controller ops that allows phandles for the pargs specifier instead of indexing to avoid any channel registration order dependencies. - The new framework does not support multiple clients operating on a single channel, so the reference counting logic is simplified. - The remoteproc driver (current client) is adapted to use the new API. The notifier callbacks used within this client is replaced with the regular callbacks from the newer framework. - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, with the signature modified to take in the new mbox_chan handle instead of the OMAP specific omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Signed-off-by: Suman Anna <s-anna@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-04 02:05:50 +03:00
* @client: mailbox client pointer used for requesting the mailbox channel
* @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.
*/
mailbox/omap: adapt to the new mailbox framework The OMAP mailbox driver and its existing clients (remoteproc for OMAP4+) are adapted to use the generic mailbox framework. The main changes for the adaptation are: - The tasklet used for Tx is replaced with the state machine from the generic mailbox framework. The workqueue used for processing the received messages stays intact for minimizing the effects on the OMAP mailbox clients. - The existing exported client API, omap_mbox_get, omap_mbox_put and omap_mbox_send_msg are deleted, as the framework provides equivalent functionality. A OMAP-specific omap_mbox_request_channel is added though to support non-DT way of requesting mailboxes. - The OMAP mailbox driver is integrated with the mailbox framework through the proper implementations of mbox_chan_ops, except for .last_tx_done and .peek_data. The OMAP mailbox driver does not need these ops, as it is completely interrupt driven. - The OMAP mailbox driver uses a custom of_xlate controller ops that allows phandles for the pargs specifier instead of indexing to avoid any channel registration order dependencies. - The new framework does not support multiple clients operating on a single channel, so the reference counting logic is simplified. - The remoteproc driver (current client) is adapted to use the new API. The notifier callbacks used within this client is replaced with the regular callbacks from the newer framework. - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, with the signature modified to take in the new mbox_chan handle instead of the OMAP specific omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Signed-off-by: Suman Anna <s-anna@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-04 02:05:50 +03:00
static void omap_rproc_mbox_callback(struct mbox_client *client, void *data)
{
mailbox/omap: adapt to the new mailbox framework The OMAP mailbox driver and its existing clients (remoteproc for OMAP4+) are adapted to use the generic mailbox framework. The main changes for the adaptation are: - The tasklet used for Tx is replaced with the state machine from the generic mailbox framework. The workqueue used for processing the received messages stays intact for minimizing the effects on the OMAP mailbox clients. - The existing exported client API, omap_mbox_get, omap_mbox_put and omap_mbox_send_msg are deleted, as the framework provides equivalent functionality. A OMAP-specific omap_mbox_request_channel is added though to support non-DT way of requesting mailboxes. - The OMAP mailbox driver is integrated with the mailbox framework through the proper implementations of mbox_chan_ops, except for .last_tx_done and .peek_data. The OMAP mailbox driver does not need these ops, as it is completely interrupt driven. - The OMAP mailbox driver uses a custom of_xlate controller ops that allows phandles for the pargs specifier instead of indexing to avoid any channel registration order dependencies. - The new framework does not support multiple clients operating on a single channel, so the reference counting logic is simplified. - The remoteproc driver (current client) is adapted to use the new API. The notifier callbacks used within this client is replaced with the regular callbacks from the newer framework. - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, with the signature modified to take in the new mbox_chan handle instead of the OMAP specific omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Signed-off-by: Suman Anna <s-anna@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-04 02:05:50 +03: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-30 23:01:25 +04:00
struct device *dev = oproc->rproc->dev.parent;
const char *name = oproc->rproc->name;
mailbox/omap: adapt to the new mailbox framework The OMAP mailbox driver and its existing clients (remoteproc for OMAP4+) are adapted to use the generic mailbox framework. The main changes for the adaptation are: - The tasklet used for Tx is replaced with the state machine from the generic mailbox framework. The workqueue used for processing the received messages stays intact for minimizing the effects on the OMAP mailbox clients. - The existing exported client API, omap_mbox_get, omap_mbox_put and omap_mbox_send_msg are deleted, as the framework provides equivalent functionality. A OMAP-specific omap_mbox_request_channel is added though to support non-DT way of requesting mailboxes. - The OMAP mailbox driver is integrated with the mailbox framework through the proper implementations of mbox_chan_ops, except for .last_tx_done and .peek_data. The OMAP mailbox driver does not need these ops, as it is completely interrupt driven. - The OMAP mailbox driver uses a custom of_xlate controller ops that allows phandles for the pargs specifier instead of indexing to avoid any channel registration order dependencies. - The new framework does not support multiple clients operating on a single channel, so the reference counting logic is simplified. - The remoteproc driver (current client) is adapted to use the new API. The notifier callbacks used within this client is replaced with the regular callbacks from the newer framework. - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, with the signature modified to take in the new mbox_chan handle instead of the OMAP specific omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Signed-off-by: Suman Anna <s-anna@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-04 02:05:50 +03:00
u32 msg = (u32)data;
dev_dbg(dev, "mbox msg: 0x%x\n", msg);
switch (msg) {
case RP_MBOX_CRASH:
/*
* remoteproc detected an exception, notify the rproc core.
* The remoteproc core will handle the recovery.
*/
dev_err(dev, "omap rproc %s crashed\n", name);
rproc_report_crash(oproc->rproc, RPROC_FATAL_ERROR);
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 14:00:31 +03: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;
default:
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;
}
/* msg contains the index of the triggered vring */
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-30 23:01:25 +04:00
struct device *dev = rproc->dev.parent;
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 14:00:32 +03: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;
}
/* send the index of the triggered virtqueue in the mailbox payload */
mailbox/omap: adapt to the new mailbox framework The OMAP mailbox driver and its existing clients (remoteproc for OMAP4+) are adapted to use the generic mailbox framework. The main changes for the adaptation are: - The tasklet used for Tx is replaced with the state machine from the generic mailbox framework. The workqueue used for processing the received messages stays intact for minimizing the effects on the OMAP mailbox clients. - The existing exported client API, omap_mbox_get, omap_mbox_put and omap_mbox_send_msg are deleted, as the framework provides equivalent functionality. A OMAP-specific omap_mbox_request_channel is added though to support non-DT way of requesting mailboxes. - The OMAP mailbox driver is integrated with the mailbox framework through the proper implementations of mbox_chan_ops, except for .last_tx_done and .peek_data. The OMAP mailbox driver does not need these ops, as it is completely interrupt driven. - The OMAP mailbox driver uses a custom of_xlate controller ops that allows phandles for the pargs specifier instead of indexing to avoid any channel registration order dependencies. - The new framework does not support multiple clients operating on a single channel, so the reference counting logic is simplified. - The remoteproc driver (current client) is adapted to use the new API. The notifier callbacks used within this client is replaced with the regular callbacks from the newer framework. - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, with the signature modified to take in the new mbox_chan handle instead of the OMAP specific omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Signed-off-by: Suman Anna <s-anna@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-04 02:05:50 +03:00
ret = mbox_send_message(oproc->mbox, (void *)vqid);
if (ret < 0)
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 14:00:32 +03:00
pm_runtime_mark_last_busy(dev);
pm_runtime_put_autosuspend(dev);
}
/**
* 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.
*
* Return: 0 on success, or -EINVAL if boot address is not aligned properly
*/
static int omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
{
struct device *dev = rproc->dev.parent;
struct omap_rproc *oproc = rproc->priv;
struct omap_rproc_boot_data *bdata = oproc->boot_data;
u32 offset = bdata->boot_reg;
remoteproc/omap: Add support for DRA7xx remote processors DRA7xx/AM57xx SoCs have two IPU and up to two DSP processor subsystems for offloading different computation algorithms. The IPU processor subsystem contains dual-core ARM Cortex-M4 processors, and is very similar to those on OMAP5. The DSP processor subsystem is based on the TI's standard TMS320C66x DSP CorePac core. Support has been added to the OMAP remoteproc driver through new DRA7xx specific compatibles for properly probing and booting all the different processor subsystem instances on DRA7xx/AM57xx SoCs - IPU1, IPU2, DSP1 & DSP2. A build dependency with SOC_DRA7XX is added to enable the driver to be built in DRA7xx-only configuration. The DSP boot address programming needed enhancement for DRA7xx as the boot register fields are different on DRA7 compared to OMAP4 and OMAP5 SoCs. The register on DRA7xx contains additional fields within the register and the boot address bit-field is right-shifted by 10 bits. The internal memory parsing logic has also been updated to compute the device addresses for the L2 RAM for DSP devices using relative addressing logic, and to parse two additional RAMs at L1 level - L1P and L1D. This allows the remoteproc driver to support loading into these regions for a small subset of firmware images requiring as such. The most common usage would be to use the L1 programmable RAMs as L1 Caches. The firmware lookup logic also has to be adjusted for DRA7xx as there are (can be) more than one instance of both the IPU and DSP remote processors for the first time in OMAP4+ SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> [t-kristo@ti.com: moved address translation quirks to pdata] 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-8-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:27 +03:00
u32 value;
u32 mask;
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;
}
remoteproc/omap: Add support for DRA7xx remote processors DRA7xx/AM57xx SoCs have two IPU and up to two DSP processor subsystems for offloading different computation algorithms. The IPU processor subsystem contains dual-core ARM Cortex-M4 processors, and is very similar to those on OMAP5. The DSP processor subsystem is based on the TI's standard TMS320C66x DSP CorePac core. Support has been added to the OMAP remoteproc driver through new DRA7xx specific compatibles for properly probing and booting all the different processor subsystem instances on DRA7xx/AM57xx SoCs - IPU1, IPU2, DSP1 & DSP2. A build dependency with SOC_DRA7XX is added to enable the driver to be built in DRA7xx-only configuration. The DSP boot address programming needed enhancement for DRA7xx as the boot register fields are different on DRA7 compared to OMAP4 and OMAP5 SoCs. The register on DRA7xx contains additional fields within the register and the boot address bit-field is right-shifted by 10 bits. The internal memory parsing logic has also been updated to compute the device addresses for the L2 RAM for DSP devices using relative addressing logic, and to parse two additional RAMs at L1 level - L1P and L1D. This allows the remoteproc driver to support loading into these regions for a small subset of firmware images requiring as such. The most common usage would be to use the L1 programmable RAMs as L1 Caches. The firmware lookup logic also has to be adjusted for DRA7xx as there are (can be) more than one instance of both the IPU and DSP remote processors for the first time in OMAP4+ SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> [t-kristo@ti.com: moved address translation quirks to pdata] 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-8-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:27 +03: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);
}
/*
* 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-30 23:01:25 +04:00
struct device *dev = rproc->dev.parent;
int ret;
mailbox/omap: adapt to the new mailbox framework The OMAP mailbox driver and its existing clients (remoteproc for OMAP4+) are adapted to use the generic mailbox framework. The main changes for the adaptation are: - The tasklet used for Tx is replaced with the state machine from the generic mailbox framework. The workqueue used for processing the received messages stays intact for minimizing the effects on the OMAP mailbox clients. - The existing exported client API, omap_mbox_get, omap_mbox_put and omap_mbox_send_msg are deleted, as the framework provides equivalent functionality. A OMAP-specific omap_mbox_request_channel is added though to support non-DT way of requesting mailboxes. - The OMAP mailbox driver is integrated with the mailbox framework through the proper implementations of mbox_chan_ops, except for .last_tx_done and .peek_data. The OMAP mailbox driver does not need these ops, as it is completely interrupt driven. - The OMAP mailbox driver uses a custom of_xlate controller ops that allows phandles for the pargs specifier instead of indexing to avoid any channel registration order dependencies. - The new framework does not support multiple clients operating on a single channel, so the reference counting logic is simplified. - The remoteproc driver (current client) is adapted to use the new API. The notifier callbacks used within this client is replaced with the regular callbacks from the newer framework. - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, with the signature modified to take in the new mbox_chan handle instead of the OMAP specific omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Signed-off-by: Suman Anna <s-anna@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-04 02:05:50 +03:00
struct mbox_client *client = &oproc->client;
if (oproc->boot_data) {
ret = omap_rproc_write_dsp_boot_addr(rproc);
if (ret)
return ret;
}
mailbox/omap: adapt to the new mailbox framework The OMAP mailbox driver and its existing clients (remoteproc for OMAP4+) are adapted to use the generic mailbox framework. The main changes for the adaptation are: - The tasklet used for Tx is replaced with the state machine from the generic mailbox framework. The workqueue used for processing the received messages stays intact for minimizing the effects on the OMAP mailbox clients. - The existing exported client API, omap_mbox_get, omap_mbox_put and omap_mbox_send_msg are deleted, as the framework provides equivalent functionality. A OMAP-specific omap_mbox_request_channel is added though to support non-DT way of requesting mailboxes. - The OMAP mailbox driver is integrated with the mailbox framework through the proper implementations of mbox_chan_ops, except for .last_tx_done and .peek_data. The OMAP mailbox driver does not need these ops, as it is completely interrupt driven. - The OMAP mailbox driver uses a custom of_xlate controller ops that allows phandles for the pargs specifier instead of indexing to avoid any channel registration order dependencies. - The new framework does not support multiple clients operating on a single channel, so the reference counting logic is simplified. - The remoteproc driver (current client) is adapted to use the new API. The notifier callbacks used within this client is replaced with the regular callbacks from the newer framework. - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, with the signature modified to take in the new mbox_chan handle instead of the OMAP specific omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Signed-off-by: Suman Anna <s-anna@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-04 02:05:50 +03:00
client->dev = dev;
client->tx_done = NULL;
client->rx_callback = omap_rproc_mbox_callback;
client->tx_block = false;
client->knows_txdone = false;
oproc->mbox = mbox_request_channel(client, 0);
if (IS_ERR(oproc->mbox)) {
mailbox/omap: adapt to the new mailbox framework The OMAP mailbox driver and its existing clients (remoteproc for OMAP4+) are adapted to use the generic mailbox framework. The main changes for the adaptation are: - The tasklet used for Tx is replaced with the state machine from the generic mailbox framework. The workqueue used for processing the received messages stays intact for minimizing the effects on the OMAP mailbox clients. - The existing exported client API, omap_mbox_get, omap_mbox_put and omap_mbox_send_msg are deleted, as the framework provides equivalent functionality. A OMAP-specific omap_mbox_request_channel is added though to support non-DT way of requesting mailboxes. - The OMAP mailbox driver is integrated with the mailbox framework through the proper implementations of mbox_chan_ops, except for .last_tx_done and .peek_data. The OMAP mailbox driver does not need these ops, as it is completely interrupt driven. - The OMAP mailbox driver uses a custom of_xlate controller ops that allows phandles for the pargs specifier instead of indexing to avoid any channel registration order dependencies. - The new framework does not support multiple clients operating on a single channel, so the reference counting logic is simplified. - The remoteproc driver (current client) is adapted to use the new API. The notifier callbacks used within this client is replaced with the regular callbacks from the newer framework. - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, with the signature modified to take in the new mbox_chan handle instead of the OMAP specific omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Signed-off-by: Suman Anna <s-anna@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-04 02:05:50 +03:00
ret = -EBUSY;
dev_err(dev, "mbox_request_channel failed: %ld\n",
PTR_ERR(oproc->mbox));
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.
*/
mailbox/omap: adapt to the new mailbox framework The OMAP mailbox driver and its existing clients (remoteproc for OMAP4+) are adapted to use the generic mailbox framework. The main changes for the adaptation are: - The tasklet used for Tx is replaced with the state machine from the generic mailbox framework. The workqueue used for processing the received messages stays intact for minimizing the effects on the OMAP mailbox clients. - The existing exported client API, omap_mbox_get, omap_mbox_put and omap_mbox_send_msg are deleted, as the framework provides equivalent functionality. A OMAP-specific omap_mbox_request_channel is added though to support non-DT way of requesting mailboxes. - The OMAP mailbox driver is integrated with the mailbox framework through the proper implementations of mbox_chan_ops, except for .last_tx_done and .peek_data. The OMAP mailbox driver does not need these ops, as it is completely interrupt driven. - The OMAP mailbox driver uses a custom of_xlate controller ops that allows phandles for the pargs specifier instead of indexing to avoid any channel registration order dependencies. - The new framework does not support multiple clients operating on a single channel, so the reference counting logic is simplified. - The remoteproc driver (current client) is adapted to use the new API. The notifier callbacks used within this client is replaced with the regular callbacks from the newer framework. - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, with the signature modified to take in the new mbox_chan handle instead of the OMAP specific omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Signed-off-by: Suman Anna <s-anna@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-04 02:05:50 +03: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);
goto put_mbox;
}
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
ret = omap_rproc_enable_timers(rproc, true);
if (ret) {
dev_err(dev, "omap_rproc_enable_timers failed: %d\n", ret);
goto put_mbox;
}
ret = reset_control_deassert(oproc->reset);
if (ret) {
dev_err(dev, "reset control deassert failed: %d\n", ret);
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
goto disable_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 14:00:32 +03: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);
return 0;
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
disable_timers:
omap_rproc_disable_timers(rproc, true);
put_mbox:
mailbox/omap: adapt to the new mailbox framework The OMAP mailbox driver and its existing clients (remoteproc for OMAP4+) are adapted to use the generic mailbox framework. The main changes for the adaptation are: - The tasklet used for Tx is replaced with the state machine from the generic mailbox framework. The workqueue used for processing the received messages stays intact for minimizing the effects on the OMAP mailbox clients. - The existing exported client API, omap_mbox_get, omap_mbox_put and omap_mbox_send_msg are deleted, as the framework provides equivalent functionality. A OMAP-specific omap_mbox_request_channel is added though to support non-DT way of requesting mailboxes. - The OMAP mailbox driver is integrated with the mailbox framework through the proper implementations of mbox_chan_ops, except for .last_tx_done and .peek_data. The OMAP mailbox driver does not need these ops, as it is completely interrupt driven. - The OMAP mailbox driver uses a custom of_xlate controller ops that allows phandles for the pargs specifier instead of indexing to avoid any channel registration order dependencies. - The new framework does not support multiple clients operating on a single channel, so the reference counting logic is simplified. - The remoteproc driver (current client) is adapted to use the new API. The notifier callbacks used within this client is replaced with the regular callbacks from the newer framework. - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, with the signature modified to take in the new mbox_chan handle instead of the OMAP specific omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Signed-off-by: Suman Anna <s-anna@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-04 02:05:50 +03:00
mbox_free_channel(oproc->mbox);
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 14:00:32 +03: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 14:00:32 +03: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;
}
ret = reset_control_assert(oproc->reset);
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 14:00:32 +03:00
goto out;
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03: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 14:00:32 +03:00
goto enable_device;
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
mailbox/omap: adapt to the new mailbox framework The OMAP mailbox driver and its existing clients (remoteproc for OMAP4+) are adapted to use the generic mailbox framework. The main changes for the adaptation are: - The tasklet used for Tx is replaced with the state machine from the generic mailbox framework. The workqueue used for processing the received messages stays intact for minimizing the effects on the OMAP mailbox clients. - The existing exported client API, omap_mbox_get, omap_mbox_put and omap_mbox_send_msg are deleted, as the framework provides equivalent functionality. A OMAP-specific omap_mbox_request_channel is added though to support non-DT way of requesting mailboxes. - The OMAP mailbox driver is integrated with the mailbox framework through the proper implementations of mbox_chan_ops, except for .last_tx_done and .peek_data. The OMAP mailbox driver does not need these ops, as it is completely interrupt driven. - The OMAP mailbox driver uses a custom of_xlate controller ops that allows phandles for the pargs specifier instead of indexing to avoid any channel registration order dependencies. - The new framework does not support multiple clients operating on a single channel, so the reference counting logic is simplified. - The remoteproc driver (current client) is adapted to use the new API. The notifier callbacks used within this client is replaced with the regular callbacks from the newer framework. - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, with the signature modified to take in the new mbox_chan handle instead of the OMAP specific omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Signed-off-by: Suman Anna <s-anna@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-04 02:05:50 +03:00
mbox_free_channel(oproc->mbox);
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 14:00:32 +03: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);
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 14:00:32 +03: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;
}
/**
* 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;
}
static const struct rproc_ops omap_rproc_ops = {
.start = omap_rproc_start,
.stop = omap_rproc_stop,
.kick = omap_rproc_kick,
.da_to_va = omap_rproc_da_to_va,
};
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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03:00
rproc->state = RPROC_RUNNING;
out:
mutex_unlock(&rproc->lock);
return ret;
}
#endif /* CONFIG_PM */
static const struct omap_rproc_mem_data ipu_mems[] = {
{ .name = "l2ram", .dev_addr = 0x20000000 },
{ },
};
remoteproc/omap: Add support for DRA7xx remote processors DRA7xx/AM57xx SoCs have two IPU and up to two DSP processor subsystems for offloading different computation algorithms. The IPU processor subsystem contains dual-core ARM Cortex-M4 processors, and is very similar to those on OMAP5. The DSP processor subsystem is based on the TI's standard TMS320C66x DSP CorePac core. Support has been added to the OMAP remoteproc driver through new DRA7xx specific compatibles for properly probing and booting all the different processor subsystem instances on DRA7xx/AM57xx SoCs - IPU1, IPU2, DSP1 & DSP2. A build dependency with SOC_DRA7XX is added to enable the driver to be built in DRA7xx-only configuration. The DSP boot address programming needed enhancement for DRA7xx as the boot register fields are different on DRA7 compared to OMAP4 and OMAP5 SoCs. The register on DRA7xx contains additional fields within the register and the boot address bit-field is right-shifted by 10 bits. The internal memory parsing logic has also been updated to compute the device addresses for the L2 RAM for DSP devices using relative addressing logic, and to parse two additional RAMs at L1 level - L1P and L1D. This allows the remoteproc driver to support loading into these regions for a small subset of firmware images requiring as such. The most common usage would be to use the L1 programmable RAMs as L1 Caches. The firmware lookup logic also has to be adjusted for DRA7xx as there are (can be) more than one instance of both the IPU and DSP remote processors for the first time in OMAP4+ SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> [t-kristo@ti.com: moved address translation quirks to pdata] 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-8-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:27 +03: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 },
{ },
};
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",
.mems = ipu_mems,
};
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",
.mems = ipu_mems,
};
remoteproc/omap: Add support for DRA7xx remote processors DRA7xx/AM57xx SoCs have two IPU and up to two DSP processor subsystems for offloading different computation algorithms. The IPU processor subsystem contains dual-core ARM Cortex-M4 processors, and is very similar to those on OMAP5. The DSP processor subsystem is based on the TI's standard TMS320C66x DSP CorePac core. Support has been added to the OMAP remoteproc driver through new DRA7xx specific compatibles for properly probing and booting all the different processor subsystem instances on DRA7xx/AM57xx SoCs - IPU1, IPU2, DSP1 & DSP2. A build dependency with SOC_DRA7XX is added to enable the driver to be built in DRA7xx-only configuration. The DSP boot address programming needed enhancement for DRA7xx as the boot register fields are different on DRA7 compared to OMAP4 and OMAP5 SoCs. The register on DRA7xx contains additional fields within the register and the boot address bit-field is right-shifted by 10 bits. The internal memory parsing logic has also been updated to compute the device addresses for the L2 RAM for DSP devices using relative addressing logic, and to parse two additional RAMs at L1 level - L1P and L1D. This allows the remoteproc driver to support loading into these regions for a small subset of firmware images requiring as such. The most common usage would be to use the L1 programmable RAMs as L1 Caches. The firmware lookup logic also has to be adjusted for DRA7xx as there are (can be) more than one instance of both the IPU and DSP remote processors for the first time in OMAP4+ SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> [t-kristo@ti.com: moved address translation quirks to pdata] 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-8-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:27 +03: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,
};
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,
},
remoteproc/omap: Add support for DRA7xx remote processors DRA7xx/AM57xx SoCs have two IPU and up to two DSP processor subsystems for offloading different computation algorithms. The IPU processor subsystem contains dual-core ARM Cortex-M4 processors, and is very similar to those on OMAP5. The DSP processor subsystem is based on the TI's standard TMS320C66x DSP CorePac core. Support has been added to the OMAP remoteproc driver through new DRA7xx specific compatibles for properly probing and booting all the different processor subsystem instances on DRA7xx/AM57xx SoCs - IPU1, IPU2, DSP1 & DSP2. A build dependency with SOC_DRA7XX is added to enable the driver to be built in DRA7xx-only configuration. The DSP boot address programming needed enhancement for DRA7xx as the boot register fields are different on DRA7 compared to OMAP4 and OMAP5 SoCs. The register on DRA7xx contains additional fields within the register and the boot address bit-field is right-shifted by 10 bits. The internal memory parsing logic has also been updated to compute the device addresses for the L2 RAM for DSP devices using relative addressing logic, and to parse two additional RAMs at L1 level - L1P and L1D. This allows the remoteproc driver to support loading into these regions for a small subset of firmware images requiring as such. The most common usage would be to use the L1 programmable RAMs as L1 Caches. The firmware lookup logic also has to be adjusted for DRA7xx as there are (can be) more than one instance of both the IPU and DSP remote processors for the first time in OMAP4+ SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> [t-kristo@ti.com: moved address translation quirks to pdata] 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-8-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:27 +03:00
{
.compatible = "ti,dra7-dsp",
.data = &dra7_dsp_dev_data,
},
{
.compatible = "ti,dra7-ipu",
.data = &dra7_ipu_dev_data,
},
{
/* 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;
}
remoteproc/omap: Add support for DRA7xx remote processors DRA7xx/AM57xx SoCs have two IPU and up to two DSP processor subsystems for offloading different computation algorithms. The IPU processor subsystem contains dual-core ARM Cortex-M4 processors, and is very similar to those on OMAP5. The DSP processor subsystem is based on the TI's standard TMS320C66x DSP CorePac core. Support has been added to the OMAP remoteproc driver through new DRA7xx specific compatibles for properly probing and booting all the different processor subsystem instances on DRA7xx/AM57xx SoCs - IPU1, IPU2, DSP1 & DSP2. A build dependency with SOC_DRA7XX is added to enable the driver to be built in DRA7xx-only configuration. The DSP boot address programming needed enhancement for DRA7xx as the boot register fields are different on DRA7 compared to OMAP4 and OMAP5 SoCs. The register on DRA7xx contains additional fields within the register and the boot address bit-field is right-shifted by 10 bits. The internal memory parsing logic has also been updated to compute the device addresses for the L2 RAM for DSP devices using relative addressing logic, and to parse two additional RAMs at L1 level - L1P and L1D. This allows the remoteproc driver to support loading into these regions for a small subset of firmware images requiring as such. The most common usage would be to use the L1 programmable RAMs as L1 Caches. The firmware lookup logic also has to be adjusted for DRA7xx as there are (can be) more than one instance of both the IPU and DSP remote processors for the first time in OMAP4+ SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> [t-kristo@ti.com: moved address translation quirks to pdata] 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-8-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:27 +03:00
of_property_read_u32_index(np, "ti,bootreg", 2,
&oproc->boot_data->boot_reg_shift);
return 0;
}
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;
}
#ifdef CONFIG_OMAP_REMOTEPROC_WATCHDOG
static int omap_rproc_count_wdog_timers(struct device *dev)
{
struct device_node *np = dev->of_node;
int ret;
ret = of_count_phandle_with_args(np, "ti,watchdog-timers", NULL);
if (ret <= 0) {
dev_dbg(dev, "device does not have watchdog timers, status = %d\n",
ret);
ret = 0;
}
return ret;
}
#else
static int omap_rproc_count_wdog_timers(struct device *dev)
{
return 0;
}
#endif
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03: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;
int num_timers;
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
/*
* 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;
}
oproc->num_wd_timers = omap_rproc_count_wdog_timers(dev);
num_timers = oproc->num_timers + oproc->num_wd_timers;
if (num_timers) {
oproc->timers = devm_kcalloc(dev, num_timers,
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
sizeof(*oproc->timers),
GFP_KERNEL);
if (!oproc->timers)
return -ENOMEM;
dev_dbg(dev, "device has %d tick timers and %d watchdog timers\n",
oproc->num_timers, oproc->num_wd_timers);
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
}
return 0;
}
static int omap_rproc_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct omap_rproc *oproc;
struct rproc *rproc;
const char *firmware;
int ret;
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);
ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
if (ret) {
dev_err(&pdev->dev, "dma_set_coherent_mask: %d\n", ret);
return ret;
}
rproc = rproc_alloc(&pdev->dev, dev_name(&pdev->dev), &omap_rproc_ops,
firmware, sizeof(*oproc));
if (!rproc)
return -ENOMEM;
oproc = rproc->priv;
oproc->rproc = rproc;
oproc->reset = reset;
/* All existing OMAP IPU and DSP processors have an MMU */
rproc->has_iommu = true;
ret = omap_rproc_of_get_internal_memories(pdev, rproc);
if (ret)
goto free_rproc;
ret = omap_rproc_get_boot_data(pdev, rproc);
if (ret)
goto free_rproc;
remoteproc/omap: Request a timer(s) for remoteproc usage The remote processors in OMAP4+ SoCs are equipped with internal timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or the CTM timer within Unicache in IPU & DSP. However, these timers are gated when the processor subsystem clock is gated, making them rather difficult to use as OS tick sources. They will not be able to wakeup the processor from any processor-sleep induced clock-gating states. This can be avoided by using an external timer as the tick source, which can be controlled independently by the OMAP remoteproc driver code, but still allowing the processor subsystem clock to be auto-gated when the remoteproc cores are idle. This patch adds the support for OMAP remote processors to request timer(s) to be used by the remoteproc. The timers are enabled and disabled in line with the enabling/disabling of the remoteproc. The timer data is not mandatory if the advanced device management features are not required. The core timer functionality is provided by the OMAP DMTimer clocksource driver, which does not export any API. The logic is implemented through the timer device's platform data ops. The OMAP remoteproc driver mainly requires ops to request/free a dmtimer, and to start/stop a timer. The split ops helps in controlling the timer state without having to request and release a timer everytime it needs to use the timer. NOTE: If the gptimer is already in use by the time IPU and/or DSP are loaded, the processors will fail to boot. Signed-off-by: Suman Anna <s-anna@ti.com> 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-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 14:00:30 +03:00
ret = omap_rproc_of_get_timers(pdev, rproc);
if (ret)
goto free_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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03:00
oproc->fck = devm_clk_get(&pdev->dev, 0);
if (IS_ERR(oproc->fck)) {
ret = PTR_ERR(oproc->fck);
goto free_rproc;
}
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");
}
platform_set_drvdata(pdev, rproc);
ret = rproc_add(rproc);
if (ret)
goto release_mem;
return 0;
release_mem:
of_reserved_mem_device_release(&pdev->dev);
free_rproc:
rproc_free(rproc);
return ret;
}
static int omap_rproc_remove(struct platform_device *pdev)
{
struct rproc *rproc = platform_get_drvdata(pdev);
rproc_del(rproc);
rproc_free(rproc);
of_reserved_mem_device_release(&pdev->dev);
return 0;
}
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 14:00:31 +03: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 14:00:32 +03: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 14:00:31 +03:00
};
static struct platform_driver omap_rproc_driver = {
.probe = omap_rproc_probe,
.remove = omap_rproc_remove,
.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 14:00:31 +03:00
.pm = &omap_rproc_pm_ops,
.of_match_table = omap_rproc_of_match,
},
};
module_platform_driver(omap_rproc_driver);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("OMAP Remote Processor control driver");