summaryrefslogtreecommitdiff
path: root/drivers/remoteproc
AgeCommit message (Collapse)AuthorFilesLines
2020-10-13remoteproc: k3-r5: Add a remoteproc driver for R5F subsystemSuman Anna3-0/+1317
The TI K3 family of SoCs typically have one or more dual-core Arm Cortex R5F processor clusters/subsystems (R5FSS). This R5F subsystem/cluster can be configured at boot time to be either run in a LockStep mode or in an Asymmetric Multi Processing (AMP) fashion in Split-mode. This subsystem has 64 KB each Tightly-Coupled Memory (TCM) internal memories for each core split between two banks - TCMA and TCMB (further interleaved into two banks). The subsystem does not have an MMU, but has a Region Address Translater (RAT) module that is accessible only from the R5Fs for providing translations between 32-bit CPU addresses into larger system bus addresses. Add a remoteproc driver to support this subsystem to be able to load and boot the R5F cores primarily in LockStep mode. The code also includes the base support for Split mode. Error Recovery and Power Management features are not currently supported. Loading support includes the internal TCMs and DDR. RAT support is left for a future patch, and as such the reserved memory carveout regions are all expected to be using memory regions within the first 2 GB. The R5F remote processors do not have an MMU, and so require fixed memory carveout regions matching the firmware image addresses. Support for this is provided by mandating multiple memory regions to be attached to the remoteproc device. The first memory region will be used to serve as the DMA pool for all dynamic allocations like the vrings and vring buffers. The remaining memory regions are mapped into the kernel at device probe time, and are used to provide address translations for firmware image segments without the need for any RSC_CARVEOUT entries. Any firmware image using memory outside of the supplied reserved memory carveout regions will be errored out. The R5F processors on TI K3 SoCs require a specific sequence for booting and shutting down the processors. This sequence is also dependent on the mode (LockStep or Split) the R5F cluster is configured for. The R5F cores have a Memory Protection Unit (MPU) that has a default configuration that does not allow the cores to run out of DDR out of reset. This is resolved by using the TCMs for boot-strapping code that applies the appropriate executable permissions on desired DDR memory. The loading into the TCMs requires that the resets be released first with the cores in halted state. The Power Sleep Controller (PSC) module on K3 SoCs requires that the cores be in WFI/WFE states with no active bus transactions before the cores can be put back into reset. Support for this is provided by using the newly introduced .prepare() and .unprepare() ops in the remoteproc core. The .prepare() ops is invoked before any loading, and the .unprepare() ops is invoked after the remoteproc resource cleanup. The R5F core resets are deasserted in .prepare() and asserted in .unprepare(), and the cores themselves are started and halted in .start() and .stop() ops. This ensures symmetric usage and allows the R5F cores state machine to be maintained properly between using the sysfs 'state' variable, bind/unbind and regular module load/unload flows. The subsystem is represented as a single remoteproc in LockStep mode, and as two remoteprocs in Split mode. The driver uses various TI-SCI interfaces to talk to the System Controller (DMSC) for managing configuration, power and reset management of these cores. IPC between the A53 cores and the R5 cores is supported through the virtio rpmsg stack using shared memory and OMAP Mailboxes. The AM65x SoCs typically have a single R5FSS in the MCU voltage domain. The J721E SoCs uses a slightly revised IP and typically have three R5FSSs, with one cluster present within the MCU voltage domain (MCU_R5FSS0), and the remaining two clusters present in the MAIN voltage domain (MAIN_R5FSS0 and MAIN_R5FSS1). The integration of these clusters on J721E SoC is also slightly different in that these IPs do support an actual local reset line, while they are a no-op on AM65x SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201002234234.20704-3-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-10-06dma-mapping: split <linux/dma-mapping.h>Christoph Hellwig2-1/+2
Split out all the bits that are purely for dma_map_ops implementations and related code into a new <linux/dma-map-ops.h> header so that they don't get pulled into all the drivers. That also means the architecture specific <asm/dma-mapping.h> is not pulled in by <linux/dma-mapping.h> any more, which leads to a missing includes that were pulled in by the x86 or arm versions in a few not overly portable drivers. Signed-off-by: Christoph Hellwig <hch@lst.de>
2020-09-26remoteproc: scp: add COMPILE_TEST dependencyAlexandre Courbot1-1/+1
This will improve this driver's build coverage. Reported-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Alexandre Courbot <acourbot@chromium.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-25remoteproc/mediatek: Add support for mt8192 SCPPi-Hsun Shih3-36/+204
Add support for mt8192 SCP. Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Reviewed-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20200921094847.2112399-1-pihsun@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-25remoteproc: Fixup coredump debugfs disable requestSibi Sankar1-1/+1
Fix the discrepancy observed between accepted input and read back value while disabling remoteproc coredump through the coredump debugfs entry. Fixes: 3afdc59e4390 ("remoteproc: Add coredump debugfs entry") Cc: stable@vger.kernel.org Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200916145100.15872-1-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-25remoteproc: qcom_q6v5: Assign mpss region to Q6 before MBA bootSibi Sankar1-3/+13
On secure devices which support warm reset, the MBA firmware requires access to the modem region to clear them out. Hence provide Q6 access to this region before MBA boot. This will be a nop during a modem SSR. Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200917175840.18708-1-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-25remoteproc/mediatek: fix null pointer dereference on null scp pointerColin Ian King1-3/+1
Currently when pointer scp is null a dev_err is being called that references the pointer which is the very thing we are trying to avoid doing. Remove the extraneous error message to avoid this issue. Addresses-Coverity: ("Dereference after null check") Fixes: 63c13d61eafe ("remoteproc/mediatek: add SCP support for mt8183") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20200918152428.27258-1-colin.king@canonical.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-17dma-mapping: introduce DMA range map, supplanting dma_pfn_offsetJim Quinlan1-1/+23
The new field 'dma_range_map' in struct device is used to facilitate the use of single or multiple offsets between mapping regions of cpu addrs and dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only capable of holding a single uniform offset and had no region bounds checking. The function of_dma_get_range() has been modified so that it takes a single argument -- the device node -- and returns a map, NULL, or an error code. The map is an array that holds the information regarding the DMA regions. Each range entry contains the address offset, the cpu_start address, the dma_start address, and the size of the region. of_dma_configure() is the typical manner to set range offsets but there are a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel driver code. These cases now invoke the function dma_direct_set_offset(dev, cpu_addr, dma_addr, size). Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> [hch: various interface cleanups] Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org> Tested-by: Nathan Chancellor <natechancellor@gmail.com>
2020-09-15remoteproc: stm32: Fix pointer assignementMathieu Poirier1-1/+1
Fix the assignment of the @state pointer - it is obviously wrong. Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Fixes: 376ffdc04456 ("remoteproc: stm32: Properly set co-processor state when attaching") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200831213758.206690-1-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-15remoteproc: scp: add COMPILE_TEST dependencyAlexandre Courbot1-1/+1
This will improve this driver's build coverage. Reported-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Alexandre Courbot <acourbot@chromium.org> Link: https://lore.kernel.org/r/20200915012911.489820-1-acourbot@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-08-23treewide: Use fallthrough pseudo-keywordGustavo A. R. Silva1-1/+0
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-08-11Merge tag 'rproc-v5.9' of ↵Linus Torvalds24-487/+2379
git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc Pull remoteproc updates from Bjorn Andersson: "This introduces a new "detached" state for remote processors that are deemed to be running at the time Linux boots and the infrastructure for "attaching" to these. It then introduces the support for performing this operation for the STM32 platform. The coredump functionality is moved out from the core file and gains support for an optional mode where the recovery phase awaits the notification from devcoredump that the dump should be released. This allows userspace to grab the coredump in scenarios where vmalloc space is too low for creating a complete copy of the coredump before handing this to devcoredump. A new character device based interface is introduced to allow tying the stoppage of a remote processor to the termination of a user space process. This is useful in situations when such process provides crucial resources/operations for the firmware running on the remote processor. The Texas Instrument K3 driver gains support for the C66x and C71x DSPs. Qualcomm remoteprocs gains support for stashing relocation information in IMEM, to aid post mortem debugging and the crash notification mechanism is generalized to be reusable in cases where loosely coupled drivers needs to know about the status of a remote processor. One such example is the IPA hardware block, which is jointly owned with the modem and migrated to this improved interface. It also introduces a number of bug fixes and debug improvements for the Qualcomm modem remoteproc driver. And it cleans up the inconsistent interface for remoteproc drivers to implement power management" * tag 'rproc-v5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc: (56 commits) remoteproc: core: Register the character device interface remoteproc: Add remoteproc character device interface remoteproc: kill IPA notify code net: ipa: new notification infrastructure remoteproc: k3-dsp: Add support for C71x DSPs dt-bindings: remoteproc: k3-dsp: Update bindings for C71x DSPs remoteproc: k3-dsp: Add support for L2RAM loading on C66x DSPs remoteproc: k3-dsp: Add a remoteproc driver of K3 C66x DSPs dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs remoteproc: k3: Add TI-SCI processor control helper functions remoteproc: Introduce rproc_of_parse_firmware() helper dt-bindings: arm: keystone: Add common TI SCI bindings remoteproc: qcom_q6v5_mss: Remove redundant running state remoteproc: qcom: q6v5: Update running state before requesting stop remoteproc: qcom_q6v5_mss: Add modem debug policy support remoteproc: qcom_q6v5_mss: Validate modem blob firmware size before load remoteproc: qcom_q6v5_mss: Validate MBA firmware size before load rpmsg: update documentation remoteproc: qcom_q6v5_mss: Add MBA log extraction support remoteproc: Add coredump debugfs entry ...
2020-08-04remoteproc: core: Register the character device interfaceSiddharth Gupta1-0/+7
Add the character device during rproc_add. This would create a character device node at /dev/remoteproc<index>. Userspace applications can interact with the remote processor using this interface. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org> Link: https://lore.kernel.org/r/1596044401-22083-3-git-send-email-sidgup@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-08-04remoteproc: Add remoteproc character device interfaceSiddharth Gupta4-0/+162
Add the character device interface into remoteproc framework. This interface can be used in order to boot/shutdown remote subsystems and provides a basic ioctl based interface to implement supplementary functionality. An ioctl call is implemented to enable the shutdown on release feature which will allow remote processors to be shutdown when the controlling userspace application crashes or hangs. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org> Link: https://lore.kernel.org/r/1596044401-22083-2-git-send-email-sidgup@codeaurora.org [bjorn: s/int32_t/s32/ per checkpatch] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-28remoteproc: kill IPA notify codeAlex Elder4-128/+0
The IPA code now uses the generic remoteproc SSR notification mechanism. This makes the original IPA notification code unused and unnecessary, so get rid of it. This is effectively a revert of commit d7f5f3c89c1a ("remoteproc: add IPA notification to q6v5 driver"). Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20200724181142.13581-3-elder@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-28remoteproc: k3-dsp: Add support for C71x DSPsSuman Anna1-2/+18
The Texas Instrument's K3 J721E SoCs have a newer next-generation C71x DSP Subsystem in the MAIN voltage domain in addition to the previous generation C66x DSP subsystems. The C71x DSP subsystem is based on the TMS320C71x DSP CorePac module. The C71x CPU is a true 64-bit machine including 64-bit memory addressing and single-cycle 64-bit base arithmetic operations and supports vector signal processing providing a significant lift in DSP processing power over C66x DSPs. J721E SoCs use a C711 (a one-core 512-bit vector width CPU core) DSP that is cache coherent with the A72 Arm cores. Each subsystem has one or more Fixed/Floating-Point DSP CPUs, with 32 KB of L1P Cache, 48 KB of L1D SRAM that can be configured and partitioned as either RAM and/or Cache, and 512 KB of L2 SRAM configurable as either RAM and/or Cache. The CorePac also includes a Matrix Multiplication Accelerator (MMA), a Stream Engine (SE) and a C71x Memory Management Unit (CMMU), an Interrupt Controller (INTC) and a Powerdown Management Unit (PMU) modules. Update the existing K3 DSP remoteproc driver to add support for this C71x DSP subsystem. The firmware loading support is provided by using the newly added 64-bit ELF loader support, and is limited to images using only external DDR memory at the moment. The L1D and L2 SRAMs are used as scratch memory when using as RAMs, and cannot be used for loadable segments. The CMMU is also not supported to begin with, and the driver is designed to treat the MMU as if it is in bypass mode. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200612225357.8251-3-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-28remoteproc: k3-dsp: Add support for L2RAM loading on C66x DSPsSuman Anna1-0/+72
The resets for the DSP processors on K3 SoCs are managed through the Power and Sleep Controller (PSC) module. Each DSP typically has two resets - a global module reset for powering on the device, and a local reset that affects only the CPU while allowing access to the other sub-modules within the DSP processor sub-systems. The C66x DSPs have two levels of internal RAMs that can be used to boot from, and the firmware loading into these RAMs require the local reset to be asserted with the device powered on/enabled using the module reset. Enhance the K3 DSP remoteproc driver to add support for loading into the internal RAMs. The local reset is deasserted on SoC power-on-reset, so logic has to be added in probe in remoteproc mode to balance the remoteproc state-machine. Note that the local resets are a no-op on C71x cores, and the hardware does not supporting loading into its internal RAMs. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200721223617.20312-7-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-28remoteproc: k3-dsp: Add a remoteproc driver of K3 C66x DSPsSuman Anna3-0/+713
The Texas Instrument's K3 J721E SoCs have two C66x DSP Subsystems in MAIN voltage domain that are based on the TI's standard TMS320C66x DSP CorePac module. Each subsystem has a Fixed/Floating-Point DSP CPU, with 32 KB each of L1P & L1D SRAMs that can be configured and partitioned as either RAM and/or Cache, and 288 KB of L2 SRAM with 256 KB of memory configurable as either RAM and/or Cache. The CorePac also includes an Internal DMA (IDMA), External Memory Controller (EMC), Extended Memory Controller (XMC) with a Region Address Translator (RAT) unit for 32-bit to 48-bit address extension/translations, an Interrupt Controller (INTC) and a Powerdown Controller (PDC). A new remoteproc module is added to perform the device management of these DSP devices. The support is limited to images using only external DDR memory at the moment, the loading support to internal memories and any on-chip RAM memories will be added in a subsequent patch. RAT support is also left for a future patch, and as such the reserved memory carveout regions are all expected to be using memory regions within the first 2 GB. Error Recovery and Power Management features are not currently supported. The C66x remote processors do not have an MMU, and so require fixed memory carveout regions matching the firmware image addresses. Support for this is provided by mandating multiple memory regions to be attached to the remoteproc device. The first memory region will be used to serve as the DMA pool for all dynamic allocations like the vrings and vring buffers. The remaining memory regions are mapped into the kernel at device probe time, and are used to provide address translations for firmware image segments without the need for any RSC_CARVEOUT entries. Any firmware image using memory outside of the supplied reserved memory carveout regions will be errored out. The driver uses various TI-SCI interfaces to talk to the System Controller (DMSC) for managing configuration, power and reset management of these cores. IPC between the A72 cores and the DSP cores is supported through the virtio rpmsg stack using shared memory and OMAP Mailboxes. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200721223617.20312-6-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-28remoteproc: k3: Add TI-SCI processor control helper functionsSuman Anna1-0/+104
Texas Instruments' K3 generation SoCs have specific modules/register spaces used for configuring the various aspects of a remote processor. These include power, reset, boot vector and other configuration features specific to each compute processor present on the SoC. These registers are managed by the System Controller such as DMSC on K3 AM65x SoCs. The Texas Instrument's System Control Interface (TI-SCI) Message Protocol is used to communicate to the System Controller from various compute processors to invoke specific services provided by the firmware running on the System Controller. Add a common processor control interface header file that can be used by multiple remoteproc drivers. The helper functions within this header file abstract the various TI SCI protocol ops for the remoteproc drivers, and allow them to request the System Controller to be able to program and manage various remote processors on the SoC. The remoteproc drivers are expected to manage the life-cycle of their ti_sci_proc_dev local structures. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200721223617.20312-4-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-28remoteproc: Introduce rproc_of_parse_firmware() helperSuman Anna2-0/+25
Add a new helper function rproc_of_parse_firmware() to the remoteproc core that can be used by various remoteproc drivers to look up the the "firmware-name" property from a rproc device node. This property is already being used by multiple drivers, so this helper can avoid repeating equivalent code in remoteproc drivers. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200721223617.20312-3-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-27remoteproc: qcom_q6v5_mss: Remove redundant running stateSibi Sankar1-5/+0
Remove the redundant running state, as an equivalent is maintained in the common q6v5 resource handling helpers. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200602163257.26978-2-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-27remoteproc: qcom: q6v5: Update running state before requesting stopSibi Sankar1-0/+2
Sometimes the stop triggers a watchdog rather than a stop-ack. Update the running state to false on requesting stop to skip the watchdog instead. Error Logs: $ echo stop > /sys/class/remoteproc/remoteproc0/state ipa 1e40000.ipa: received modem stopping event remoteproc-modem: watchdog received: sys_m_smsm_mpss.c:291:APPS force stop qcom-q6v5-mss 4080000.remoteproc-modem: port failed halt ipa 1e40000.ipa: received modem offline event remoteproc0: stopped remote processor 4080000.remoteproc-modem Reviewed-by: Evan Green <evgreen@chromium.org> Fixes: 3b415c8fb263 ("remoteproc: q6v5: Extract common resource handling") Cc: stable@vger.kernel.org Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200602163257.26978-1-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-27remoteproc: qcom_q6v5_mss: Add modem debug policy supportSibi Sankar1-1/+24
Add modem debug policy support which will enable coredumps and live debug support when the msadp firmware is present on secure devices. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200722201047.12975-4-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-27remoteproc: qcom_q6v5_mss: Validate modem blob firmware size before loadSibi Sankar1-3/+2
The following mem abort is observed when one of the modem blob firmware size exceeds the allocated mpss region. Fix this by restricting the copy size to segment size using request_firmware_into_buf before load. Err Logs: Unable to handle kernel paging request at virtual address Mem abort info: ... Call trace: __memcpy+0x110/0x180 rproc_start+0xd0/0x190 rproc_boot+0x404/0x550 state_store+0x54/0xf8 dev_attr_store+0x44/0x60 sysfs_kf_write+0x58/0x80 kernfs_fop_write+0x140/0x230 vfs_write+0xc4/0x208 ksys_write+0x74/0xf8 ... Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Fixes: 051fb70fd4ea4 ("remoteproc: qcom: Driver for the self-authenticating Hexagon v5") Cc: stable@vger.kernel.org Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200722201047.12975-3-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-27remoteproc: qcom_q6v5_mss: Validate MBA firmware size before loadSibi Sankar1-0/+6
The following mem abort is observed when the mba firmware size exceeds the allocated mba region. MBA firmware size is restricted to a maximum size of 1M and remaining memory region is used by modem debug policy firmware when available. Hence verify whether the MBA firmware size lies within the allocated memory region and is not greater than 1M before loading. Err Logs: Unable to handle kernel paging request at virtual address Mem abort info: ... Call trace: __memcpy+0x110/0x180 rproc_start+0x40/0x218 rproc_boot+0x5b4/0x608 state_store+0x54/0xf8 dev_attr_store+0x44/0x60 sysfs_kf_write+0x58/0x80 kernfs_fop_write+0x140/0x230 vfs_write+0xc4/0x208 ksys_write+0x74/0xf8 __arm64_sys_write+0x24/0x30 ... Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Fixes: 051fb70fd4ea4 ("remoteproc: qcom: Driver for the self-authenticating Hexagon v5") Cc: stable@vger.kernel.org Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200722201047.12975-2-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-21remoteproc: qcom_q6v5_mss: Add MBA log extraction supportSibi Sankar1-1/+37
On SC7180 the MBA firmware stores the bootup text logs in a 4K segment at the beginning of the MBA region. Add support to extract the logs which will be useful to debug mba boot/authentication issues. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200721112935.25716-3-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-21remoteproc: Add coredump debugfs entryRishabh Bhatnagar1-0/+90
Add coredump debugfs entry to configure the type of dump that will be collected during recovery. User can select between default or inline coredump functionality. Also coredump collection can be disabled through this interface. This functionality can be configured differently for different remote processors. Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Tested-by: Sibi Sankar <sibis@codeaurora.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/1594938035-7327-6-git-send-email-rishabhb@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-21remoteproc: Add inline coredump functionalityRishabh Bhatnagar1-18/+138
The current coredump implementation uses vmalloc area to copy all the segments. But this might put strain on low memory targets as the firmware size sometimes is in tens of MBs. The situation becomes worse if there are multiple remote processors undergoing recovery at the same time. This patch adds inline coredump functionality that avoids extra memory usage. This requires recovery to be halted until data is read by userspace and free function is called. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Tested-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/1594938035-7327-5-git-send-email-rishabhb@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-21remoteproc: Pass size and offset as arguments to segment dump functionRishabh Bhatnagar2-7/+8
Change the segment dump API signature to include size and offset arguments. Refactor the qcom_q6v5_mss driver to use these arguments while copying the segment. Doing this lays the ground work for "inline" coredump functionality being added in the next patch. Tested-by: Sibi Sankar <sibis@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Link: https://lore.kernel.org/r/1594938035-7327-4-git-send-email-rishabhb@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-21remoteproc: qcom_q6v5_mss: Replace mask based tracking with sizeSibi Sankar1-9/+8
In order to land inline coredump support for mss, the dump_segment function would need to support granularities less than the segment size. This is achieved by replacing mask based tracking with size. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Link: https://lore.kernel.org/r/1594938035-7327-3-git-send-email-rishabhb@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-21remoteproc: Move coredump functionality to a new fileRishabh Bhatnagar4-191/+209
Move all coredump functionality to an individual file. This is being done so that the current functionality can be extended in future patchsets. Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> Tested-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/1594938035-7327-2-git-send-email-rishabhb@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-17remoteproc: stm32: Update M4 state in stm32_rproc_stop()Mathieu Poirier1-0/+12
Update the co-processor state in function stm32_rproc_stop() so that it can be used in scenarios where the remoteproc core is attaching to the M4. Mainly based on the work published by Arnaud Pouliquen [1]. [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877 Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200714200445.1427257-12-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-17remoteproc: stm32: Introduce new attach() operationMathieu Poirier1-0/+8
Introduce new attach function to be used when attaching to a remote processor. Mainly based on the work published by Arnaud Pouliquen [1]. [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877 Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200714200445.1427257-11-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-17remoteproc: stm32: Properly handle the resource table when attachingMathieu Poirier1-0/+76
Properly set the remote processor's resource table based on where it was loaded by the external entity when attaching to a remote processor. Mainly based on the work published by Arnaud Pouliquen [1]. [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877 Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200714200445.1427257-10-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-17remoteproc: stm32: Parse memory regions when attaching to M4Mathieu Poirier1-3/+20
Split function stm32_rproc_parse_fw() in two parts, the first one to parse the memory regions and the second one to load the resource table. That way parsing of the memory regions can be done without having do deal with the resource table when attaching to a remote processor. Mainly based on the work published by Arnaud Pouliquen [1]. [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877 Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200714200445.1427257-9-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-17remoteproc: Make function rproc_resource_cleanup() publicMathieu Poirier1-1/+2
Make function rproc_resource_cleanup() public so that it can be used by platform drivers when allocating resources to be used by a detached remote processor. Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200714200445.1427257-8-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-17remoteproc: stm32: Properly set co-processor state when attachingMathieu Poirier1-0/+31
Introduce the required mechanic to set the state of the M4 in order to properly deal with scenarios where the co-processor has been started by another entity. Mainly based on the work published by Arnaud Pouliquen [1]. [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877 Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200714200445.1427257-7-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-17remoteproc: stm32: Parse syscon that will manage M4 synchronisationMathieu Poirier1-0/+26
Get from the DT the syncon to probe the state of the remote processor and the location of the resource table. Mainly based on the work published by Arnaud Pouliquen [1]. [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877 Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Loic Pallardy <loic.pallardy@st.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200714200445.1427257-6-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-17remoteproc: stm32: Remove memory translation from DT parsingMathieu Poirier1-1/+5
Other than one has to be done after the other, there is no correlation between memory translation and DT parsing. As such move function stm32_rproc_of_memory_translations() to stm32_rproc_probe() so that stm32_rproc_parse_dt() can be extended to look for attach bindings in a clean way. Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Loic Pallardy <loic.pallardy@st.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200714200445.1427257-5-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-17remoteproc: stm32: Decouple rproc from DT parsingMathieu Poirier1-11/+12
Remove the remote processor from the process of parsing the device tree since (1) there is no correlation between them and (2) to use the information that was gathered to make a decision on whether to synchronise with the M4 or not. Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200714200445.1427257-4-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-17remoteproc: stm32: Request IRQ with platform deviceMathieu Poirier1-2/+3
Request IRQ with platform device rather than remote proc in order to call stm32_rproc_parse_dt() before rproc_alloc(). That way we can know whether we need to synchronise with the MCU or not. Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Loic Pallardy <loic.pallardy@st.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200714200445.1427257-3-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-17remoteproc: stm32: Decouple rproc from memory translationMathieu Poirier1-4/+4
Remove the remote processor from the process of parsing the memory ranges since there is no correlation between them. Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Loic Pallardy <loic.pallardy@st.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200714200445.1427257-2-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-16remoteproc: Properly handle firmware name when attachingMathieu Poirier2-2/+32
This patch prevents the firmware image name from being displayed when the remoteproc core is attaching to a remote processor. This is needed needed since there is no guarantee about the nature of the firmware image that is loaded by the external entity. Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200714195035.1426873-10-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-16remoteproc: Refactor function rproc_free_vring()Mathieu Poirier1-4/+16
When function rproc_free_vring() clears the virtio device section it does so on the cached resource table rather than the one installed in the remote processor memory. When a remote processor has been booted by another entity there is no need to use a cached table and as such, no need to clear the virtio device section in it. Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200714195035.1426873-9-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-16remoteproc: Refactor function rproc_trigger_auto_boot()Mathieu Poirier1-0/+9
Refactor function rproc_trigger_auto_boot() to properly deal with scenarios where the remoteproc core needs to attach with a remote processor that has already been booted by an external entity. Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200714195035.1426873-8-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-16remoteproc: Refactor function rproc_boot()Mathieu Poirier1-11/+17
Refactor function rproc_boot() to properly deal with scenarios where the remoteproc core needs to attach with a remote processor that has already been booted by an external entity. Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200714195035.1426873-7-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-16remoteproc: Introducing function rproc_validate()Mathieu Poirier1-0/+41
Add a new function to assert the general health of the remote processor before handing it to the remoteproc core. Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Tested-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200714195035.1426873-6-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-16remoteproc: Introducing function rproc_actuate()Mathieu Poirier1-1/+58
Introduce function rproc_actuate() that provides the same functionatlity as rproc_fw_boot(), but without the steps that involve interaction with the firmware image. That way we can deal with scenarios where the remoteproc core is attaching to a remote processor that has already been started by another entity. Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Tested-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200714195035.1426873-5-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-16remoteproc: Introducing function rproc_attach()Mathieu Poirier1-0/+42
Introducing function rproc_attach() to enact the same actions as rproc_start(), but without the steps related to the handling of a firmware image. That way we can properly deal with scenarios where the remoteproc core needs to attach with a remote processsor that has been booted by another entity. Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200714195035.1426873-4-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-16remoteproc: Add new attach() remoteproc operationMathieu Poirier1-0/+8
Add an new attach() operation in order to properly deal with scenarios where the remoteproc core needs to attach to a remote processor that has been booted by another entity. Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200714195035.1426873-3-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>