summaryrefslogtreecommitdiffstats
path: root/drivers/remoteproc (follow)
Commit message (Collapse)AuthorAgeFilesLines
* remoteproc: pull in slab.hMichael S. Tsirkin2020-04-171-0/+1
| | | | | | | | In preparation to virtio header changes, include slab.h directly as this module is using it. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
* remoteproc/omap: Fix set_load call in omap_rproc_request_timerNathan Chancellor2020-04-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <natechancellor@gmail.com> Acked-by: Suman Anna <s-anna@ti.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge tag 'rproc-v5.7' of ↵Linus Torvalds2020-04-0323-218/+1745
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc 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 identifiersSuman Anna2020-03-261-26/+1
| | | | | | | | | | | | | | | | | | | | | | | | Use the appropriate SPDX license identifiers in various OMAP remoteproc source files and drop the previous boilerplate license text. 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-16-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc/omap: Add watchdog functionality for remote processorsSuman Anna2020-03-262-11/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <mathieu.poirier@linaro.org> 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> Link: https://lore.kernel.org/r/20200324110035.29907-15-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc/omap: Report device exceptions and trigger recoverySuman Anna2020-03-261-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <subramaniam.ca@ti.com> Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Andrew F. Davis <afd@ti.com> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200324110035.29907-14-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc/omap: Add support for runtime auto-suspend/resumeSuman Anna2020-03-261-9/+203
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * remoteproc/omap: Add support for system suspend/resumeSuman Anna2020-03-262-2/+207
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * remoteproc/omap: Request a timer(s) for remoteproc usageSuman Anna2020-03-261-1/+290
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * remoteproc/omap: Check for undefined mailbox messagesSuman Anna2020-03-262-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <subramaniam.ca@ti.com> Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Andrew F. Davis <afd@ti.com> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200324110035.29907-10-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc/omap: Add support for DRA7xx remote processorsSuman Anna2020-03-262-2/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * remoteproc/omap: Initialize and assign reserved memory nodeSuman Anna2020-03-261-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The reserved memory nodes are not assigned to platform devices by default in the driver core to avoid the lookup for every platform device and incur a penalty as the real users are expected to be only a few devices. OMAP remoteproc devices fall into the above category and the OMAP remoteproc driver _requires_ specific CMA pools to be assigned for each device at the moment to align on the location of the vrings and vring buffers in the RTOS-side firmware images. So, use the of_reserved_mem_device_init/release() API appropriately to assign the corresponding reserved memory region to the OMAP remoteproc device. Note that only one region per device is allowed by the framework. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Andrew F. Davis <afd@ti.com> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200324110035.29907-7-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc/omap: Add the rproc ops .da_to_va() implementationSuman Anna2020-03-261-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An implementation for the rproc ops .da_to_va() has been added that provides the address translation between device addresses to kernel virtual addresses for internal RAMs present on that particular remote processor device. The implementation provides the translations based on the addresses parsed and stored during the probe. This ops gets invoked by the exported rproc_da_to_va() function and allows the remoteproc core's ELF loader to be able to load program data directly into the internal memories. 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-6-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc/omap: Add support to parse internal memories from DTSuman Anna2020-03-261-0/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OMAP remoteproc driver has been enhanced to parse and store the kernel mappings for different internal RAM memories that may be present within each remote processor IP subsystem. Different devices have varying memories present on current SoCs. The current support handles the L2RAM for all IPU devices on OMAP4+ SoCs. The DSPs on OMAP4/OMAP5 only have Unicaches and do not have any L1 or L2 RAM memories. IPUs are expected to have the L2RAM at a fixed device address of 0x20000000, based on the current limitations on Attribute MMU configurations. NOTE: The current logic doesn't handle the parsing of memories for DRA7 remoteproc devices, and will be added alongside the DRA7 support. Signed-off-by: Suman Anna <s-anna@ti.com> [t-kristo: converted to parse mem names / device addresses from 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-5-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc/omap: Add a sanity check for DSP boot address alignmentSuman Anna2020-03-261-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DSP remote processors on OMAP SoCs require a boot register to be programmed with a boot address, and this boot address needs to be on a 1KB boundary. The current code is simply masking the boot address appropriately without performing any sanity checks before releasing the resets. An unaligned boot address results in an undefined execution behavior and can result in various bus errors like MMU Faults or L3 NoC errors. Such errors are hard to debug and can be easily avoided by adding a sanity check for the alignment before booting a DSP remote processor. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Andrew F. Davis <afd@ti.com> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200324110035.29907-4-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc/omap: Add device tree supportSuman Anna2020-03-261-17/+160
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OMAP4+ SoCs support device tree boot only. The OMAP remoteproc driver is enhanced to support remoteproc devices created through Device Tree, support for legacy platform devices has been deprecated. The current DT support handles the IPU and DSP processor subsystems on OMAP4 and OMAP5 SoCs. The OMAP remoteproc driver relies on the ti-sysc, reset, and syscon layers for performing clock, reset and boot vector management (DSP remoteprocs only) of the devices, but some of these are limited only to the machine-specific layers in arch/arm. The dependency against control module API for boot vector management of the DSP remoteprocs has now been removed with added logic to parse the boot register from the DT node and program it appropriately directly within the driver. The OMAP remoteproc driver expects the firmware names to be provided via device tree entries (firmware-name.) These are used to load the proper firmware during boot of the remote processor. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Suman Anna <s-anna@ti.com> [t-kristo@ti.com: converted to use ti-sysc framework] 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-3-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: qcom: Introduce panic handler for PAS and ADSPBjorn Andersson2020-03-262-0/+16
| | | | | | | | | | | | | | | | | | | | Make the PAS and ADSP/CDSP remoteproc drivers implement the panic handler that will invoke a stop to prepare the remoteprocs for post mortem debugging. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200324052904.738594-5-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: qcom: q6v5: Add common panic handlerBjorn Andersson2020-03-262-0/+21
| | | | | | | | | | | | | | | | | | | | | | Add a common panic handler that invokes a stop request and sleep enough to let the remoteproc flush it's caches etc in order to aid post mortem debugging. For now a hard coded 200ms is returned to the remoteproc core, this value is taken from the downstream kernel. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200324052904.738594-4-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: Introduce "panic" callback in opsBjorn Andersson2020-03-261-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce generic support for handling kernel panics in remoteproc drivers, in order to allow operations needed for aiding in post mortem system debugging, such as flushing caches etc. The function can return a number of milliseconds needed by the remote to "settle" and the core will wait the longest returned duration before returning from the panic handler. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200324052904.738594-3-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: Traverse rproc_list under RCU read lockBjorn Andersson2020-03-261-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | In order to be able to traverse the mostly read-only rproc_list without locking during panic migrate traversal to be done under rcu_read_lock(). Mutual exclusion for modifications of the list continues to be handled by the rproc_list_mutex and a synchronization point is added before releasing objects that are popped from the list. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200324052904.738594-2-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: Fix NULL pointer dereference in rproc_virtio_notifyNikita Shubin2020-03-261-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Undefined rproc_ops .kick method in remoteproc driver will result in "Unable to handle kernel NULL pointer dereference" in rproc_virtio_notify, after firmware loading if: 1) .kick method wasn't defined in driver 2) resource_table exists in firmware and has "Virtio device entry" defined Let's refuse to register an rproc-induced virtio device if no kick method was defined for rproc. [ 13.180049][ T415] 8<--- cut here --- [ 13.190558][ T415] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 13.212544][ T415] pgd = (ptrval) [ 13.217052][ T415] [00000000] *pgd=00000000 [ 13.224692][ T415] Internal error: Oops: 80000005 [#1] PREEMPT SMP ARM [ 13.231318][ T415] Modules linked in: rpmsg_char imx_rproc virtio_rpmsg_bus rpmsg_core [last unloaded: imx_rproc] [ 13.241687][ T415] CPU: 0 PID: 415 Comm: unload-load.sh Not tainted 5.5.2-00002-g707df13bbbdd #6 [ 13.250561][ T415] Hardware name: Freescale i.MX7 Dual (Device Tree) [ 13.257009][ T415] PC is at 0x0 [ 13.260249][ T415] LR is at rproc_virtio_notify+0x2c/0x54 [ 13.265738][ T415] pc : [<00000000>] lr : [<8050f6b0>] psr: 60010113 [ 13.272702][ T415] sp : b8d47c48 ip : 00000001 fp : bc04de00 [ 13.278625][ T415] r10: bc04c000 r9 : 00000cc0 r8 : b8d46000 [ 13.284548][ T415] r7 : 00000000 r6 : b898f200 r5 : 00000000 r4 : b8a29800 [ 13.291773][ T415] r3 : 00000000 r2 : 990a3ad4 r1 : 00000000 r0 : b8a29800 [ 13.299000][ T415] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 13.306833][ T415] Control: 10c5387d Table: b8b4806a DAC: 00000051 [ 13.313278][ T415] Process unload-load.sh (pid: 415, stack limit = 0x(ptrval)) [ 13.320591][ T415] Stack: (0xb8d47c48 to 0xb8d48000) [ 13.325651][ T415] 7c40: b895b680 00000001 b898f200 803c6430 b895bc80 7f00ae18 [ 13.334531][ T415] 7c60: 00000035 00000000 00000000 b9393200 80b3ed80 00004000 b9393268 bbf5a9a2 [ 13.343410][ T415] 7c80: 00000e00 00000200 00000000 7f00aff0 7f00a014 b895b680 b895b800 990a3ad4 [ 13.352290][ T415] 7ca0: 00000001 b898f210 b898f200 00000000 00000000 7f00e000 00000001 00000000 [ 13.361170][ T415] 7cc0: 00000000 803c62e0 80b2169c 802a0924 b898f210 00000000 00000000 b898f210 [ 13.370049][ T415] 7ce0: 80b9ba44 00000000 80b9ba48 00000000 7f00e000 00000008 80b2169c 80400114 [ 13.378929][ T415] 7d00: 80b2169c 8061fd64 b898f210 7f00e000 80400744 b8d46000 80b21634 80b21634 [ 13.387809][ T415] 7d20: 80b2169c 80400614 80b21634 80400718 7f00e000 00000000 b8d47d7c 80400744 [ 13.396689][ T415] 7d40: b8d46000 80b21634 80b21634 803fe338 b898f254 b80fe76c b8d32e38 990a3ad4 [ 13.405569][ T415] 7d60: fffffff3 b898f210 b8d46000 00000001 b898f254 803ffe7c 80857a90 b898f210 [ 13.414449][ T415] 7d80: 00000001 990a3ad4 b8d46000 b898f210 b898f210 80b17aec b8a29c20 803ff0a4 [ 13.423328][ T415] 7da0: b898f210 00000000 b8d46000 803fb8e0 b898f200 00000000 80b17aec b898f210 [ 13.432209][ T415] 7dc0: b8a29c20 990a3ad4 b895b900 b898f200 8050fb7c 80b17aec b898f210 b8a29c20 [ 13.441088][ T415] 7de0: b8a29800 b895b900 b8a29a04 803c5ec0 b8a29c00 b898f200 b8a29a20 00000007 [ 13.449968][ T415] 7e00: b8a29c20 8050fd78 b8a29800 00000000 b8a29a20 b8a29c04 b8a29820 b8a299d0 [ 13.458848][ T415] 7e20: b895b900 8050e5a4 b8a29800 b8a299d8 b8d46000 b8a299e0 b8a29820 b8a299d0 [ 13.467728][ T415] 7e40: b895b900 8050e008 000041ed 00000000 b8b8c440 b8a299d8 b8a299e0 b8a299d8 [ 13.476608][ T415] 7e60: b8b8c440 990a3ad4 00000000 b8a29820 b8b8c400 00000006 b8a29800 b895b880 [ 13.485487][ T415] 7e80: b8d47f78 00000000 00000000 8050f4b4 00000006 b895b890 b8b8c400 008fbea0 [ 13.494367][ T415] 7ea0: b895b880 8029f530 00000000 00000000 b8d46000 00000006 b8d46000 008fbea0 [ 13.503246][ T415] 7ec0: 8029f434 00000000 b8d46000 00000000 00000000 8021e2e4 0000000a 8061fd0c [ 13.512125][ T415] 7ee0: 0000000a b8af0c00 0000000a b8af0c40 00000001 b8af0c40 00000000 8061f910 [ 13.521005][ T415] 7f00: 0000000a 80240af4 00000002 b8d46000 00000000 8061fd0c 00000002 80232d7c [ 13.529884][ T415] 7f20: 00000000 b8d46000 00000000 990a3ad4 00000000 00000006 b8a62d80 008fbea0 [ 13.538764][ T415] 7f40: b8d47f78 00000000 b8d46000 00000000 00000000 802210c0 b88f2900 00000000 [ 13.547644][ T415] 7f60: b8a62d80 b8a62d80 b8d46000 00000006 008fbea0 80221320 00000000 00000000 [ 13.556524][ T415] 7f80: b8af0c00 990a3ad4 0000006c 008fbea0 76f1cda0 00000004 80101204 00000004 [ 13.565403][ T415] 7fa0: 00000000 80101000 0000006c 008fbea0 00000001 008fbea0 00000006 00000000 [ 13.574283][ T415] 7fc0: 0000006c 008fbea0 76f1cda0 00000004 00000006 00000006 00000000 00000000 [ 13.583162][ T415] 7fe0: 00000004 7ebaf7d0 76eb4c0b 76e3f206 600d0030 00000001 00000000 00000000 [ 13.592056][ T415] [<8050f6b0>] (rproc_virtio_notify) from [<803c6430>] (virtqueue_notify+0x1c/0x34) [ 13.601298][ T415] [<803c6430>] (virtqueue_notify) from [<7f00ae18>] (rpmsg_probe+0x280/0x380 [virtio_rpmsg_bus]) [ 13.611663][ T415] [<7f00ae18>] (rpmsg_probe [virtio_rpmsg_bus]) from [<803c62e0>] (virtio_dev_probe+0x1f8/0x2c4) [ 13.622022][ T415] [<803c62e0>] (virtio_dev_probe) from [<80400114>] (really_probe+0x200/0x450) [ 13.630817][ T415] [<80400114>] (really_probe) from [<80400614>] (driver_probe_device+0x16c/0x1ac) [ 13.639873][ T415] [<80400614>] (driver_probe_device) from [<803fe338>] (bus_for_each_drv+0x84/0xc8) [ 13.649102][ T415] [<803fe338>] (bus_for_each_drv) from [<803ffe7c>] (__device_attach+0xd4/0x164) [ 13.658069][ T415] [<803ffe7c>] (__device_attach) from [<803ff0a4>] (bus_probe_device+0x84/0x8c) [ 13.666950][ T415] [<803ff0a4>] (bus_probe_device) from [<803fb8e0>] (device_add+0x444/0x768) [ 13.675572][ T415] [<803fb8e0>] (device_add) from [<803c5ec0>] (register_virtio_device+0xa4/0xfc) [ 13.684541][ T415] [<803c5ec0>] (register_virtio_device) from [<8050fd78>] (rproc_add_virtio_dev+0xcc/0x1b8) [ 13.694466][ T415] [<8050fd78>] (rproc_add_virtio_dev) from [<8050e5a4>] (rproc_start+0x148/0x200) [ 13.703521][ T415] [<8050e5a4>] (rproc_start) from [<8050e008>] (rproc_boot+0x384/0x5c0) [ 13.711708][ T415] [<8050e008>] (rproc_boot) from [<8050f4b4>] (state_store+0x3c/0xc8) [ 13.719723][ T415] [<8050f4b4>] (state_store) from [<8029f530>] (kernfs_fop_write+0xfc/0x214) [ 13.728348][ T415] [<8029f530>] (kernfs_fop_write) from [<8021e2e4>] (__vfs_write+0x30/0x1cc) [ 13.736971][ T415] [<8021e2e4>] (__vfs_write) from [<802210c0>] (vfs_write+0xac/0x17c) [ 13.744985][ T415] [<802210c0>] (vfs_write) from [<80221320>] (ksys_write+0x64/0xe4) [ 13.752825][ T415] [<80221320>] (ksys_write) from [<80101000>] (ret_fast_syscall+0x0/0x54) [ 13.761178][ T415] Exception stack(0xb8d47fa8 to 0xb8d47ff0) [ 13.766932][ T415] 7fa0: 0000006c 008fbea0 00000001 008fbea0 00000006 00000000 [ 13.775811][ T415] 7fc0: 0000006c 008fbea0 76f1cda0 00000004 00000006 00000006 00000000 00000000 [ 13.784687][ T415] 7fe0: 00000004 7ebaf7d0 76eb4c0b 76e3f206 [ 13.790442][ T415] Code: bad PC value [ 13.839214][ T415] ---[ end trace 1fe21ecfc9f28852 ]--- Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Nikita Shubin <NShubin@topcon.com> Fixes: 7a186941626d ("remoteproc: remove the single rpmsg vdev limitation") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200306072452.24743-1-NShubin@topcon.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: return error for bad "recovery" debugfs inputAlex Elder2020-03-261-0/+2
| | | | | | | | | | | | | | | | | | If the value written to the "recovery" debugfs file is not one of the recognized commands return an error to indicate it's invalid. Signed-off-by: Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20200228183359.16229-5-elder@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: remoteproc debugfs file fixesAlex Elder2020-03-261-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Don't bother checking the remoteproc state before calling rproc_trigger_recovery() because that function will verify the state, and the state can only be safely checked while holding the mutex anyway. Make the mode for "recovery" be writable. Signed-off-by: Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20200228183359.16229-3-elder@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: re-check state in rproc_trigger_recovery()Alex Elder2020-03-261-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two places call rproc_trigger_recovery(): - rproc_crash_handler_work() sets rproc->state to CRASHED under protection of the mutex, then calls it if recovery is not disabled. This function is called in workqueue context when scheduled in rproc_report_crash(). - rproc_recovery_write() calls it in two spots, both of which the only call it if the rproc->state is CRASHED. The mutex is taken right away in rproc_trigger_recovery(). However, by the time the mutex is acquired, something else might have changed rproc->state to something other than CRASHED. The work that follows that is only appropriate for a remoteproc in CRASHED state. So check the state after acquiring the mutex, and only proceed with the recovery work if the remoteproc is still in CRASHED state. Delay reporting that recovering has begun until after we hold the mutex and we know the remote processor is in CRASHED state. Signed-off-by: Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20200228183359.16229-2-elder@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: stm32: demote warning about optional property absenceAhmad Fatoum2020-03-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | The mainline device trees lack the "st,syscfg-pdds", so probing the driver always throws the warning. As the property is optional per binding and the driver can deal with its absence, demote the warning to info log level. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Link: https://lore.kernel.org/r/20200224172519.15315-1-a.fatoum@pengutronix.de Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc/mediatek: Use size_t type for len in scp_da_to_vaNathan Chancellor2020-03-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang errors: drivers/remoteproc/mtk_scp.c:364:14: error: incompatible function pointer types initializing 'void *(*)(struct rproc *, u64, size_t)' (aka 'void *(*)(struct rproc *, unsigned long long, unsigned int)') with an expression of type 'void *(struct rproc *, u64, int)' (aka 'void *(struct rproc *, unsigned long long, int)') [-Werror,-Wincompatible-function-pointer-types] .da_to_va = scp_da_to_va, ^~~~~~~~~~~~ 1 error generated. Make the same change as commit 0fcbb369f052 ("remoteproc: Use size_t type for len in da_to_va"), which was not updated for the acceptance of commit 63c13d61eafe ("remoteproc/mediatek: add SCP support for mt8183"). Fixes: 0fcbb369f052 ("remoteproc: Use size_t type for len in da_to_va") Link: https://github.com/ClangBuiltLinux/linux/issues/927 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Link: https://lore.kernel.org/r/20200310211514.32288-1-natechancellor@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: Adapt coredump to generate correct elf typeClement Leger2020-03-262-32/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that remoteproc can load an elf64, coredump elf class should be the same as the loaded elf class. In order to do that, add a elf_class field to rproc with default values. If an elf is loaded successfully, this field will be updated with the loaded elf class. Then, the coredump core code has been modified to use the generic elf macro in order to create an elf file with correct class. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Clement Leger <cleger@kalray.eu> Link: https://lore.kernel.org/r/20200302093902.27849-9-cleger@kalray.eu Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: Allow overriding only sanity_checkClement Leger2020-03-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | Now that rproc_elf_sanity_check can be used by external drivers, allow to only overwrite the sanity_check member of rproc_ops. This will allow drivers to handle elf32 and elf64 by overwriting sanity_check with rproc_elf_sanity_check function. Signed-off-by: Clement Leger <cleger@kalray.eu> Link: https://lore.kernel.org/r/20200302093902.27849-8-cleger@kalray.eu Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: Add elf64 support in elf loaderClement Leger2020-03-262-56/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to support elf64, use macros from remoteproc_elf_helpers.h to access elf headers depending on elf class. To allow new drivers to support elf64, add rproc_elf_sanity_check function which make more sense than adding a elf64 named one since it will support both elf versions. Driver which need to support both elf32/elf64 should use this new function for elf sanity check instead of the elf32 one. Signed-off-by: Clement Leger <cleger@kalray.eu> Tested-by: Arnaud POULIQUEN <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200302093902.27849-7-cleger@kalray.eu Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: Rename rproc_elf_sanity_check for elf32Clement Leger2020-03-266-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | Since this function will be modified to support both elf32 and elf64, rename the existing one to elf32 (which is the only supported format at the moment). This will allow not to introduce possible side effect when adding elf64 support (ie: all backends will still support only elf32 if not requested explicitely using rproc_elf_sanity_check). Signed-off-by: Clement Leger <cleger@kalray.eu> Link: https://lore.kernel.org/r/20200302093902.27849-6-cleger@kalray.eu Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: Add elf helpers to access elf64 and elf32 fieldsClement Leger2020-03-261-0/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | elf32 and elf64 mainly differ by their types. In order to avoid copy/pasting the whole loader code, generate static inline functions which will access values according to the elf class. It allows to keep a common loader basis. In order to accommodate both elf types sizes, the maximum size for a elf header member is chosen using the maximum value of the field for both elf class. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Clement Leger <cleger@kalray.eu> Link: https://lore.kernel.org/r/20200302093902.27849-5-cleger@kalray.eu Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: Use u64 type for boot_addrClement Leger2020-03-263-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | elf64 entry is defined as a u64. Since boot_addr is used to store the elf entry point, change boot_addr type to u64 to support both elf32 and elf64. In the same time, fix users that were using this variable. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Clement Leger <cleger@kalray.eu> Link: https://lore.kernel.org/r/20200302093902.27849-4-cleger@kalray.eu [bjorn: Fixes up return type of rproc_get_boot_addr()] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: Use size_t instead of int for rproc_mem_entry lenClement Leger2020-03-262-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | Now that rproc_da_to_va uses a size_t for length, use a size_t for len field of rproc_mem_entry. Function used to create such structures now takes a size_t instead of int to allow full size range to be handled. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Clement Leger <cleger@kalray.eu> Link: https://lore.kernel.org/r/20200302093902.27849-3-cleger@kalray.eu Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: Use size_t type for len in da_to_vaClement Leger2020-03-2611-18/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | With upcoming changes in elf loader for elf64 support, section size will be a u64. When used with da_to_va, this will potentially lead to overflow if using the current "int" type for len argument. Change da_to_va prototype to use a size_t for len and fix all users of this function. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Clement Leger <cleger@kalray.eu> Link: https://lore.kernel.org/r/20200302093902.27849-2-cleger@kalray.eu Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: fix kernel-doc warningsArnaud Pouliquen2020-03-262-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following warnings when documentation is built: drivers/remoteproc/remoteproc_virtio.c:330: warning: Function parameter or member 'id' not described in 'rproc_add_virtio_dev' drivers/remoteproc/remoteproc_core.c:243: warning: Function parameter or member 'name' not described in 'rproc_find_carveout_by_name' drivers/remoteproc/remoteproc_core.c:473: warning: Function parameter or member 'offset' not described in 'rproc_handle_vdev' drivers/remoteproc/remoteproc_core.c:604: warning: Function parameter or member 'offset' not described in 'rproc_handle_trace' drivers/remoteproc/remoteproc_core.c:678: warning: Function parameter or member 'offset' not described in 'rproc_handle_devmem' drivers/remoteproc/remoteproc_core.c:873: warning: Function parameter or member 'offset' not described in 'rproc_handle_carveout' drivers/remoteproc/remoteproc_core.c:1029: warning: cannot understand function prototype: 'rproc_handle_resource_t rproc_loading_handlers[RSC_LAST] = ' drivers/remoteproc/remoteproc_core.c:1693: warning: Function parameter or member 'work' not described in 'rproc_crash_handler_work' Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200212161956.10358-1-arnaud.pouliquen@st.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: qcom_q6v5_mss: Reload the mba region on coredumpSibi Sankar2020-03-261-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On secure devices after a wdog/fatal interrupt, the mba region has to be refreshed in order to prevent the following errors during mba load. Err Logs: remoteproc remoteproc2: stopped remote processor 4080000.remoteproc qcom-q6v5-mss 4080000.remoteproc: PBL returned unexpected status -284031232 qcom-q6v5-mss 4080000.remoteproc: PBL returned unexpected status -284031232 .... qcom-q6v5-mss 4080000.remoteproc: PBL returned unexpected status -284031232 qcom-q6v5-mss 4080000.remoteproc: MBA booted, loading mpss Fixes: 7dd8ade24dc2a ("remoteproc: qcom: q6v5-mss: Add custom dump function for modem") Cc: stable@vger.kernel.org Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200304194729.27979-4-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: qcom_q6v5_mss: Validate each segment during loadingBjorn Andersson2020-03-261-25/+58
| | | | | | | | | | | | | | | | | | | | | | | | The code used to sync with the MBA after each segment loaded and this is still what's done downstream. So reduce the delta towards downstream by switching to a model where the content is iteratively validated. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200304194729.27979-3-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
| * remoteproc: qcom_q6v5_mss: Don't reassign mpss region on shutdownBjorn Andersson2020-03-261-11/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Trying to reclaim mpss memory while the mba is not running causes the system to crash on devices with security fuses blown, so leave it assigned to the remote on shutdown and recover it on a subsequent boot. Fixes: 6c5a9dc2481b ("remoteproc: qcom: Make secure world call for mem ownership switch") Cc: stable@vger.kernel.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200304194729.27979-2-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
* | remoteproc: clean up notification configAlex Elder2020-03-171-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rearrange the config files for remoteproc and IPA to fix their interdependencies. First, have CONFIG_QCOM_Q6V5_MSS select QCOM_Q6V5_IPA_NOTIFY so the notification code is built regardless of whether IPA needs it. Next, represent QCOM_IPA as being dependent on QCOM_Q6V5_MSS rather than setting its value to match QCOM_Q6V5_COMMON (which is selected by QCOM_Q6V5_MSS). Drop all dependencies from QCOM_Q6V5_IPA_NOTIFY. The notification code will be built whenever QCOM_Q6V5_MSS is set, and it has no other dependencies. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | remoteproc: add IPA notification to q6v5 driverAlex Elder2020-03-094-0/+130
|/ | | | | | | | | | | | | | | | | | | | | | | | Set up a subdev in the q6v5 modem remoteproc driver that generates event notifications for the IPA driver to use for initialization and recovery following a modem shutdown or crash. A pair of new functions provides a way for the IPA driver to register and deregister a notification callback function that will be called whenever modem events (about to boot, running, about to shut down, etc.) occur. A void pointer value (provided by the IPA driver at registration time) and an event type are supplied to the callback function. One event, MODEM_REMOVING, is signaled whenever the q6v5 driver is about to remove the notification subdevice. It requires the IPA driver de-register its callback. This sub-device is only used by the modem subsystem (MSS) driver, so the code that adds the new subdev and allows registration and deregistration of the notifier is found in "qcom_q6v6_mss.c". Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* remoteproc: qcom: q6v5-mss: Improve readability of reset_assertSibi Sankar2020-01-241-3/+12
| | | | | | | | | | Define AXI_GATING_VALID_OVERRIDE and fixup comments to improve readability of Q6 modem reset sequence on SC7180 SoCs. Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200123131236.1078-3-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
* remoteproc: qcom: q6v5-mss: Use regmap_read_poll_timeoutSibi Sankar2020-01-241-20/+7
| | | | | | | | | Replace the loop for HALT_ACK detection with regmap_read_poll_timeout. Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200123131236.1078-2-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
* remoteproc: qcom: q6v5-mss: Rename boot status timeoutSibi Sankar2020-01-221-2/+2
| | | | | | | | | Rename the FSM timeout on SC7180 to BOOT_STATUS_TIMEOUT_US. Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200117135130.3605-4-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
* remoteproc: qcom: q6v5-mss: Improve readability across clk handlingSibi Sankar2020-01-221-14/+18
| | | | | | | | | | Define CLKEN and CLKOFF for improving readability of Q6SS clock handling. Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200117135130.3605-3-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
* remoteproc: use struct_size() helperGustavo A. R. Silva2020-01-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct fw_rsc_vdev { ... struct fw_rsc_vdev_vring vring[0]; } __packed; Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. So, replace the following form: sizeof(*rsc) + rsc->num_of_vrings * sizeof(struct fw_rsc_vdev_vring) with: struct_size(rsc, vring, rsc->num_of_vrings) This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20190830151406.GA23274@embeddedor Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
* remoteproc: Initialize rproc_class before useBrandon Maier2020-01-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The remoteproc_core and remoteproc drivers all initialize with module_init(). However remoteproc drivers need the rproc_class during their probe. If one of the remoteproc drivers runs init and gets through probe before remoteproc_init() runs, a NULL pointer access of rproc_class's `glue_dirs` spinlock occurs. > Unable to handle kernel NULL pointer dereference at virtual address 000000dc > pgd = c0004000 > [000000dc] *pgd=00000000 > Internal error: Oops: 5 [#1] PREEMPT ARM > Modules linked in: > CPU: 0 PID: 1 Comm: swapper Tainted: G W 4.14.106-rt56 #1 > Hardware name: Generic OMAP36xx (Flattened Device Tree) > task: c6050000 task.stack: c604a000 > PC is at rt_spin_lock+0x40/0x6c > LR is at rt_spin_lock+0x28/0x6c > pc : [<c0523c90>] lr : [<c0523c78>] psr: 60000013 > sp : c604bdc0 ip : 00000000 fp : 00000000 > r10: 00000000 r9 : c61c7c10 r8 : c6269c20 > r7 : c0905888 r6 : c6269c20 r5 : 00000000 r4 : 000000d4 > r3 : 000000dc r2 : c6050000 r1 : 00000002 r0 : 000000d4 > Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none ... > [<c0523c90>] (rt_spin_lock) from [<c03b65a4>] (get_device_parent+0x54/0x17c) > [<c03b65a4>] (get_device_parent) from [<c03b6bec>] (device_add+0xe0/0x5b4) > [<c03b6bec>] (device_add) from [<c042adf4>] (rproc_add+0x18/0xd8) > [<c042adf4>] (rproc_add) from [<c01110e4>] (my_rproc_probe+0x158/0x204) > [<c01110e4>] (my_rproc_probe) from [<c03bb6b8>] (platform_drv_probe+0x34/0x70) > [<c03bb6b8>] (platform_drv_probe) from [<c03b9dd4>] (driver_probe_device+0x2c8/0x420) > [<c03b9dd4>] (driver_probe_device) from [<c03ba02c>] (__driver_attach+0x100/0x11c) > [<c03ba02c>] (__driver_attach) from [<c03b7d08>] (bus_for_each_dev+0x7c/0xc0) > [<c03b7d08>] (bus_for_each_dev) from [<c03b910c>] (bus_add_driver+0x1cc/0x264) > [<c03b910c>] (bus_add_driver) from [<c03ba714>] (driver_register+0x78/0xf8) > [<c03ba714>] (driver_register) from [<c010181c>] (do_one_initcall+0x100/0x190) > [<c010181c>] (do_one_initcall) from [<c0800de8>] (kernel_init_freeable+0x130/0x1d0) > [<c0800de8>] (kernel_init_freeable) from [<c051eee8>] (kernel_init+0x8/0x114) > [<c051eee8>] (kernel_init) from [<c01175b0>] (ret_from_fork+0x14/0x24) > Code: e2843008 e3c2203f f5d3f000 e5922010 (e193cf9f) > ---[ end trace 0000000000000002 ]--- Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com> Link: https://lore.kernel.org/r/20190530225223.136420-1-brandon.maier@rockwellcollins.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
* rpmsg: add rpmsg support for mt8183 SCP.Pi-Hsun Shih2020-01-204-4/+61
| | | | | | | | Add a simple rpmsg support for mt8183 SCP, that use IPI / IPC directly. Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Link: https://lore.kernel.org/r/20191112110330.179649-4-pihsun@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
* remoteproc/mediatek: add SCP support for mt8183Erin Lo2020-01-205-0/+930
| | | | | | | | | | Provide a basic driver to control Cortex M4 co-processor Signed-off-by: Erin Lo <erin.lo@mediatek.com> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Link: https://lore.kernel.org/r/20191112110330.179649-3-pihsun@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
* remoteproc: mss: q6v5-mss: Add modem support on SC7180Sibi Sankar2019-12-201-1/+198
| | | | | | | | | | Add the out of reset sequence support for modem sub-system on SC7180 SoCs. It requires access to an additional halt nav register to put the modem back into reset. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20191219054506.20565-3-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
* remoteproc: qcom: pas: Add MSM8998 ADSP and SLPI supportSibi Sankar2019-12-201-0/+32
| | | | | | | | | Add support for booting the Audio and Sensor DSPs found in Qualcomm's MSM8998 SoCs. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20191218132217.28141-4-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-19 01:52:01 +0100