lwn.git/drivers/remoteproc, branch docs-5.8-2

remoteproc/omap: Fix set_load call in omap_rproc_request_timer

2020-04-03T17:47:21+00:00

When building arm allyesconfig: drivers/remoteproc/omap_remoteproc.c:174:44: error: too many arguments to function call, expected 2, have 3 timer->timer_ops->set_load(timer->odt, 0, 0); ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ 1 error generated. This is due to commit 02e6d546e3bd ("clocksource/drivers/timer-ti-dm: Enable autoreload in set_pwm") in the clockevents tree interacting with commit e28edc571925 ("remoteproc/omap: Request a timer(s) for remoteproc usage") from the rpmsg tree. This should have been fixed during the merge of the remoteproc tree since it happened after the clockevents tree merge; however, it does not look like my email was noticed by either maintainer and I did not pay attention when the pull was sent since I was on CC. Fixes: c6570114316f ("Merge tag 'rproc-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc") Link: https://lore.kernel.org/lkml/20200327185055.GA22438@ubuntu-m2-xlarge-x86/ Signed-off-by: Nathan Chancellor Acked-by: Suman Anna Signed-off-by: Linus Torvalds

Merge tag 'rproc-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc

2020-04-02T22:42:13+00:00

Pull remoteproc updates from Bjorn Andersson: - a range of improvements to the OMAP remoeteproc driver; among other things adding devicetree, suspend/resume and watchdog support, and adds support the remoteprocs in the DRA7xx SoC - support for 64-bit firmware, extends the ELF loader to support this and fixes for a number of race conditions in the recovery handling - a generic mechanism to allow remoteproc drivers to sync state with remote processors during a panic, and uses this to prepare Qualcomm remote processors for post mortem analysis - fixes to cleanly recover from crashes in the modem firmware on production Qualcomm devices * tag 'rproc-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc: (37 commits) remoteproc/omap: Switch to SPDX license identifiers remoteproc/omap: Add watchdog functionality for remote processors remoteproc/omap: Report device exceptions and trigger recovery remoteproc/omap: Add support for runtime auto-suspend/resume remoteproc/omap: Add support for system suspend/resume remoteproc/omap: Request a timer(s) for remoteproc usage remoteproc/omap: Check for undefined mailbox messages remoteproc/omap: Remove the platform_data header remoteproc/omap: Add support for DRA7xx remote processors remoteproc/omap: Initialize and assign reserved memory node remoteproc/omap: Add the rproc ops .da_to_va() implementation remoteproc/omap: Add support to parse internal memories from DT remoteproc/omap: Add a sanity check for DSP boot address alignment remoteproc/omap: Add device tree support dt-bindings: remoteproc: Add OMAP remoteproc bindings remoteproc: qcom: Introduce panic handler for PAS and ADSP remoteproc: qcom: q6v5: Add common panic handler remoteproc: Introduce "panic" callback in ops remoteproc: Traverse rproc_list under RCU read lock remoteproc: Fix NULL pointer dereference in rproc_virtio_notify ...

remoteproc/omap: Switch to SPDX license identifiers

2020-03-26T05:29:51+00:00

Use the appropriate SPDX license identifiers in various OMAP remoteproc source files and drop the previous boilerplate license text. Signed-off-by: Suman Anna Signed-off-by: Tero Kristo Reviewed-by: Andrew F. Davis Acked-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200324110035.29907-16-t-kristo@ti.com Signed-off-by: Bjorn Andersson

remoteproc/omap: Add watchdog functionality for remote processors

2020-03-26T05:29:51+00:00

Remote processors can be stuck in a loop, and may not be recoverable if they do not have a built-in watchdog. The watchdog implementation for OMAP remote processors uses external gptimers that can be used to interrupt both the Linux host as well as the remote processor. Each remote processor is responsible for refreshing the timer during normal behavior - during OS task scheduling or entering the idle loop properly. During a watchdog condition (executing a tight loop causing no scheduling), the host processor gets interrupts and schedules a recovery for the corresponding remote processor. The remote processor may also get interrupted to be able to print a back trace. A menuconfig option has also been added to enable/disable the Watchdog functionality, with the default as disabled. Acked-by: Mathieu Poirier Signed-off-by: Suman Anna Signed-off-by: Tero Kristo Reviewed-by: Andrew F. Davis Link: https://lore.kernel.org/r/20200324110035.29907-15-t-kristo@ti.com Signed-off-by: Bjorn Andersson

remoteproc/omap: Report device exceptions and trigger recovery

2020-03-26T05:29:50+00:00

The OMAP remote processors send a special mailbox message (RP_MBOX_CRASH) when they crash and detect an internal device exception. Add support to the mailbox handling function upon detection of this special message to report this crash to the remoteproc core. The remoteproc core can trigger a recovery using the prevailing recovery mechanism, already in use for MMU Fault recovery. Co-developed-by: Subramaniam Chanderashekarapuram Signed-off-by: Subramaniam Chanderashekarapuram Signed-off-by: Suman Anna Signed-off-by: Tero Kristo Reviewed-by: Bjorn Andersson Reviewed-by: Andrew F. Davis Acked-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200324110035.29907-14-t-kristo@ti.com Signed-off-by: Bjorn Andersson

remoteproc/omap: Add support for runtime auto-suspend/resume

2020-03-26T05:29:50+00:00

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 [t-kristo@ti.com: converted to use ti-sysc instead of hwmod] Signed-off-by: Tero Kristo Reviewed-by: Andrew F. Davis Acked-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com Signed-off-by: Bjorn Andersson

remoteproc/omap: Add support for system suspend/resume

2020-03-26T05:29:50+00:00

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 [t-kristo@ti.com: converted to use ti-sysc instead of hwmod] Signed-off-by: Tero Kristo Reviewed-by: Andrew F. Davis Acked-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com Signed-off-by: Bjorn Andersson

remoteproc/omap: Request a timer(s) for remoteproc usage

2020-03-26T05:29:49+00:00

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 Signed-off-by: Tero Kristo Reviewed-by: Andrew F. Davis Acked-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200324110035.29907-11-t-kristo@ti.com Signed-off-by: Bjorn Andersson

remoteproc/omap: Check for undefined mailbox messages

2020-03-26T05:29:49+00:00

Add some checks in the mailbox callback function to limit any processing in the mailbox callback function to only certain currently valid messages, and drop all the remaining messages. A debug message is added to print any such invalid messages when the appropriate trace control is enabled. Co-developed-by: Subramaniam Chanderashekarapuram Signed-off-by: Subramaniam Chanderashekarapuram Signed-off-by: Suman Anna Signed-off-by: Tero Kristo Reviewed-by: Bjorn Andersson Reviewed-by: Andrew F. Davis Acked-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200324110035.29907-10-t-kristo@ti.com Signed-off-by: Bjorn Andersson

remoteproc/omap: Add support for DRA7xx remote processors

2020-03-26T05:29:48+00:00

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 [t-kristo@ti.com: moved address translation quirks to pdata] Signed-off-by: Tero Kristo Reviewed-by: Andrew F. Davis Acked-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200324110035.29907-8-t-kristo@ti.com Signed-off-by: Bjorn Andersson