aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/remoteproc (follow)
AgeCommit message (Collapse)AuthorFilesLines
2020-12-16Merge tag 'arm-soc-drivers-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds1-13/+28
Pull ARM SoC driver updates from Arnd Bergmann: "There are a couple of subsystems maintained by other people that merge their drivers through the SoC tree, those changes include: - The SCMI firmware framework gains support for sensor notifications and for controlling voltage domains. - A large update for the Tegra memory controller driver, integrating it better with the interconnect framework - The memory controller subsystem gains support for Mediatek MT8192 - The reset controller framework gains support for sharing pulsed resets For Soc specific drivers in drivers/soc, the main changes are - The Allwinner/sunxi MBUS gets a rework for the way it handles dma_map_ops and offsets between physical and dma address spaces. - An errata fix plus some cleanups for Freescale Layerscape SoCs - A cleanup for renesas drivers regarding MMIO accesses. - New SoC specific drivers for Mediatek MT8192 and MT8183 power domains - New SoC specific drivers for Aspeed AST2600 LPC bus control and SoC identification. - Core Power Domain support for Qualcomm MSM8916, MSM8939, SDM660 and SDX55. - A rework of the TI AM33xx 'genpd' power domain support to use information from DT instead of platform data - Support for TI AM64x SoCs - Allow building some Amlogic drivers as modules instead of built-in Finally, there are numerous cleanups and smaller bug fixes for Mediatek, Tegra, Samsung, Qualcomm, TI OMAP, Amlogic, Rockchips, Renesas, and Xilinx SoCs" * tag 'arm-soc-drivers-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (222 commits) soc: mediatek: mmsys: Specify HAS_IOMEM dependency for MTK_MMSYS firmware: xilinx: Properly align function parameter firmware: xilinx: Add a blank line after function declaration firmware: xilinx: Remove additional newline firmware: xilinx: Fix kernel-doc warnings firmware: xlnx-zynqmp: fix compilation warning soc: xilinx: vcu: add missing register NUM_CORE soc: xilinx: vcu: use vcu-settings syscon registers dt-bindings: soc: xlnx: extract xlnx, vcu-settings to separate binding soc: xilinx: vcu: drop useless success message clk: samsung: mark PM functions as __maybe_unused soc: samsung: exynos-chipid: initialize later - with arch_initcall soc: samsung: exynos-chipid: order list of SoCs by name memory: jz4780_nemc: Fix potential NULL dereference in jz4780_nemc_probe() memory: ti-emif-sram: only build for ARMv7 memory: tegra30: Support interconnect framework memory: tegra20: Support hardware versioning and clean up OPP table initialization dt-bindings: memory: tegra20-emc: Document opp-supported-hw property soc: rockchip: io-domain: Fix error return code in rockchip_iodomain_probe() reset-controller: ti: force the write operation when assert or deassert ...
2020-12-10remoteproc/mediatek: read IPI buffer offset from FWTzung-Bi Shih2-22/+69
Reads the IPI buffer offset from the FW binary. The information resides in addr of .ipi_buffer section. Moves scp_ipi_init() to rproc_ops::parse_fw() phase. The IPI buffer can be initialized only if the offset is clear. To backward compatible to MT8183 SCP, specify the offset in the board specific mtk_scp_of_data. Reads the default offset if the firmware doesn't have it. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20201202044609.2501913-1-tzungbi@google.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc/mediatek: unprepare clk if scp_before_load failsTzung-Bi Shih1-1/+2
Fixes the error handling to unprepare clk if scp_before_load fails. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Fixes: fd0b6c1ff85a ("remoteproc/mediatek: Add support for mt8192 SCP") Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20201203155914.3844426-1-tzungbi@google.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: qcom: Fix potential NULL dereference in adsp_init_mmio()Zhang Changzhong1-6/+3
platform_get_resource() may fail and in this case a NULL dereference will occur. Fix it to use devm_platform_ioremap_resource() instead of calling platform_get_resource() and devm_ioremap(). This is detected by Coccinelle semantic patch. @@ expression pdev, res, n, t, e, e1, e2; @@ res = \(platform_get_resource\|platform_get_resource_byname\)(pdev, t, n); + if (!res) + return -EINVAL; ... when != res == NULL e = devm_ioremap(e1, res->start, e2); Fixes: dc160e449122 ("remoteproc: qcom: Introduce Non-PAS ADSP PIL driver") Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1607392460-20516-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc/mediatek: Fix kernel test robot warningSouptick Joarder1-3/+1
Kernel test robot throws below warning -> >> drivers/remoteproc/mtk_scp.c:755:37: warning: unused variable >> 'mt8183_of_data' [-Wunused-const-variable] static const struct mtk_scp_of_data mt8183_of_data = { ^ >> drivers/remoteproc/mtk_scp.c:765:37: warning: unused variable >> 'mt8192_of_data' [-Wunused-const-variable] static const struct mtk_scp_of_data mt8192_of_data = { ^ As suggested by Bjorn, there's no harm in just dropping the of_match_ptr() wrapping of mtk_scp_of_match in the definition of mtk_scp_driver and we avoid this whole problem. Reported-by: kernel test robot <lkp@intel.com> Suggested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Link: https://lore.kernel.org/r/1606513855-21130-1-git-send-email-jrdr.linux@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: k3-dsp: Fix return value check in k3_dsp_rproc_of_get_memories()YueHaibing1-2/+2
In case of error, the function devm_ioremap_wc() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Fixes: 6edbe024ba17 ("remoteproc: k3-dsp: Add a remoteproc driver of K3 C66x DSPs") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20200905122503.17352-1-yuehaibing@huawei.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: qcom: pas: fix error handling in adsp_pds_enableZhang Qilong1-1/+4
If the pm_runtime_get_sync failed in adsp_pds_enable when loop (i), The unroll_pd_votes will start from (i - 1), and it will resulted in following problems: 1) pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to pm_runtime_put_noidle will result in reference leak. 2) Have not reset pds[i] performance state. Then we fix it. Fixes: 17ee2fb4e8567 ("remoteproc: qcom: pas: Vote for active/proxy power domains") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201102143554.144707-1-zhangqilong3@huawei.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: qcom: fix reference leak in adsp_startZhang Qilong1-1/+3
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to pm_runtime_put_noidle will result in reference leak in adsp_start, so we should fix it. Fixes: dc160e4491222 ("remoteproc: qcom: Introduce Non-PAS ADSP PIL driver") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201102143534.144484-1-zhangqilong3@huawei.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: q6v5-mss: fix error handling in q6v5_pds_enableZhang Qilong1-1/+4
If the pm_runtime_get_sync failed in q6v5_pds_enable when loop (i), The unroll_pd_votes will start from (i - 1), and it will resulted in following problems: 1) pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to pm_runtime_put_noidle will result in reference leak. 2) Have not reset pds[i] performance state. Then we fix it. Fixes: 4760a896be88e ("remoteproc: q6v5-mss: Vote for rpmh power domains") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201102143433.143996-1-zhangqilong3@huawei.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc/mtk_scp: surround DT device IDs with CONFIG_OFAlexandre Courbot1-0/+2
Now that this driver can be compiled with COMPILE_TEST, we have no guarantee that CONFIG_OF will also be defined. When that happens, a warning about mtk_scp_of_match being defined but unused will be reported so make sure this variable is only defined if of_match_ptr() actually uses it. Fixes: cbd2dca74926c0e4610c40923cc786b732c9e8ef remoteproc: scp: add COMPILE_TEST dependency Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Alexandre Courbot <acourbot@chromium.org> Link: https://lore.kernel.org/r/20201102074007.299222-1-acourbot@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: qcom: Add minidump id for sm8150 modemSiddharth Gupta1-0/+1
Add minidump id for modem in sm8150 chipset so that the regions to be included in the coredump generated upon a crash is based on the minidump tables in SMEM instead of those in the ELF header. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by, Reviewed-by or Tested-by that you received previously.: Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org> Link: https://lore.kernel.org/r/1605819935-10726-5-git-send-email-sidgup@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: qcom: Add capability to collect minidumpsSiddharth Gupta3-2/+173
This patch adds support for collecting minidump in the event of remoteproc crash. Parse the minidump table based on remoteproc's unique minidump-id, read all memory regions from the remoteproc's minidump table entry and expose the memory to userspace. The remoteproc platform driver can choose to collect a full/mini dump by specifying the coredump op. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Co-developed-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Co-developed-by: Gurbir Arora <gurbaror@codeaurora.org> Signed-off-by: Gurbir Arora <gurbaror@codeaurora.org> Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org> Link: https://lore.kernel.org/r/1605819935-10726-4-git-send-email-sidgup@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: coredump: Add minidump functionalitySiddharth Gupta2-0/+166
This change adds a new kind of core dump mechanism which instead of dumping entire program segments of the firmware, dumps sections of the remoteproc memory which are sufficient to allow debugging the firmware. This function thus uses section headers instead of program headers during creation of the core dump elf. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Co-developed-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org> Link: https://lore.kernel.org/r/1605819935-10726-3-git-send-email-sidgup@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: core: Add ops to enable custom coredump functionalitySiddharth Gupta1-1/+5
Each remoteproc might have different requirements for coredumps and might want to choose the type of dumps it wants to collect. This change allows remoteproc drivers to specify their own custom dump function to be executed in place of rproc_coredump. If the coredump op is not specified by the remoteproc driver it will be set to rproc_coredump by default. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org> Link: https://lore.kernel.org/r/1605819935-10726-2-git-send-email-sidgup@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc/mediatek: change MT8192 CFG register baseTzung-Bi Shih1-13/+13
The correct MT8192 CFG register base is 0x20000 off. Changes the registers accordingly. Fixes: fd0b6c1ff85a ("remoteproc/mediatek: Add support for mt8192 SCP") Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20201210054109.587795-1-tzungbi@google.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: pru: Add support for various PRU cores on K3 J721E SoCsSuman Anna1-0/+3
The K3 J721E family of SoCs have a revised version of the AM65x ICSSG IP and contains two instances of this newer ICSSG IP. Each ICSSG processor subsystem contains 2 primary PRU cores, 2 auxiliary PRU cores called RTUs, and 2 new auxiliary cores called Transmit PRUs (Tx_PRUs). Enhance the existing PRU remoteproc driver to support these new PRU and RTU cores by using specific compatibles. The cores have the same memory copying limitations as on AM65x, so reuses the custom memcpy function within the driver's ELF loader implementation. The initial names for the firmware images for each PRU core are retrieved from DT nodes, and can be adjusted through sysfs if required. Signed-off-by: Suman Anna <s-anna@ti.com> Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201208141002.17777-7-grzegorz.jaszczyk@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: pru: Add support for various PRU cores on K3 AM65x SoCsSuman Anna1-9/+131
The K3 AM65x family of SoCs have the next generation of the PRU-ICSS processor subsystem, commonly referred to as ICSSG. Each ICSSG processor subsystem on AM65x SR1.0 contains two primary PRU cores and two new auxiliary PRU cores called RTUs. The AM65x SR2.0 SoCs have a revised ICSSG IP that is based off the subsequent IP revision used on J721E SoCs. This IP instance has two new custom auxiliary PRU cores called Transmit PRUs (Tx_PRUs) in addition to the existing PRUs and RTUs. Each RTU and Tx_PRU cores have their own dedicated IRAM (smaller than a PRU), Control and debug feature sets, but is different in terms of sub-modules integrated around it and does not have the full capabilities associated with a PRU core. The RTU core is typically used to aid a PRU core in accelerating data transfers, while the Tx_PRU cores is normally used to control the TX L2 FIFO if enabled in Ethernet applications. Both can also be used to run independent applications. The RTU and Tx_PRU cores though share the same Data RAMs as the PRU cores, so the memories have to be partitioned carefully between different applications. The new cores also support a new sub-module called Task Manager to support two different context thread executions. Enhance the existing PRU remoteproc driver to support these new PRU, RTU and Tx PRU cores by using specific compatibles. The initial names for the firmware images for each PRU core are retrieved from DT nodes, and can be adjusted through sysfs if required. The PRU remoteproc driver has to be specifically modified to use a custom memcpy function within its ELF loader implementation for these new cores in order to overcome a limitation with copying data into each of the core's IRAM memories. These memory ports support only 4-byte writes, and any sub-word order byte writes clear out the remaining bytes other than the bytes being written within the containing word. The default ARM64 memcpy also cannot be used as it throws an exception when the preferred 8-byte copy operation is attempted. This choice is made by using a state flag that is set only on K3 SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201208141002.17777-6-grzegorz.jaszczyk@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: pru: Add pru-specific debugfs supportSuman Anna1-0/+136
The remoteproc core creates certain standard debugfs entries, that does not give a whole lot of useful information for the PRUs. The PRU remoteproc driver is enhanced to add additional debugfs entries for PRU. These will be auto-cleaned up when the parent rproc debug directory is removed. The enhanced debugfs support adds two new entries: 'regs' and 'single_step'. The 'regs' dumps out the useful CTRL sub-module registers as well as each of the 32 GPREGs and CT_REGs registers. The GPREGs and CT_REGs though are printed only when the PRU is halted and accessible as per the IP design. The 'single_step' utilizes the single-step execution of the PRU cores. Writing a non-zero value performs a single step, and a zero value restores the PRU to execute in the same mode as the mode before the first single step. (note: if the PRU is halted because of a halt instruction, then no change occurs). Logic for setting the PC and jumping over a halt instruction shall be added in the future. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201208141002.17777-5-grzegorz.jaszczyk@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: pru: Add support for PRU specific interrupt configurationGrzegorz Jaszczyk2-0/+227
The firmware blob can contain optional ELF sections: .resource_table section and .pru_irq_map one. The second one contains the PRUSS interrupt mapping description, which needs to be setup before powering on the PRU core. To avoid RAM wastage this ELF section is not mapped to any ELF segment (by the firmware linker) and therefore is not loaded to PRU memory. The PRU interrupt configuration is handled within the PRUSS INTC irqchip driver and leverages the system events to interrupt channels and host interrupts mapping configuration. Relevant irq routing information is passed through a special .pru_irq_map ELF section (for interrupts routed to and used by PRU cores) or via the PRU application's device tree node (for interrupts routed to and used by the main CPU). The mappings are currently programmed during the booting/shutdown of the PRU. The interrupt configuration passed through .pru_irq_map ELF section is optional. It varies on specific firmware functionality and therefore have to be unwinded during PRU stop and performed again during PRU start. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Co-developed-by: Suman Anna <s-anna@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Link: https://lore.kernel.org/r/20201208141002.17777-4-grzegorz.jaszczyk@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: pru: Add a PRU remoteproc driverSuman Anna3-0/+446
The Programmable Real-Time Unit Subsystem (PRUSS) consists of dual 32-bit RISC cores (Programmable Real-Time Units, or PRUs) for program execution. This patch adds a remoteproc platform driver for managing the individual PRU RISC cores life cycle. The PRUs do not have a unified address space (have an Instruction RAM and a primary Data RAM at both 0x0). The PRU remoteproc driver therefore uses a custom remoteproc core ELF loader ops. The added .da_to_va ops is only used to provide translations for the PRU Data RAMs. This remoteproc driver does not have support for error recovery and system suspend/resume features. Different compatibles are used to allow providing scalability for instance-specific device data if needed. The driver uses a default firmware-name retrieved from device-tree for each PRU core, and the firmwares are expected to be present in the standard Linux firmware search paths. They can also be adjusted by userspace if required through the sysfs interface provided by the remoteproc core. The PRU remoteproc driver uses a client-driven boot methodology: it does _not_ support auto-boot so that the PRU load and boot is dictated by the corresponding client drivers for achieving various usecases. This allows flexibility for the client drivers or applications to set a firmware name (if needed) based on their desired functionality and boot the PRU. The sysfs bind and unbind attributes have also been suppressed so that the PRU devices cannot be unbound and thereby shutdown a PRU from underneath a PRU client driver. The driver currently supports the AM335x, AM437x, AM57xx and 66AK2G SoCs, and support for other TI SoCs will be added in subsequent patches. Co-developed-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201208141002.17777-3-grzegorz.jaszczyk@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-04remoteproc: fix spelling mistake "Peripherial" -> "Peripherial" in KconfigColin Ian King1-1/+1
There is a spelling mistake in the Kconfig help text. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20201204193411.1152006-1-colin.king@canonical.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-04remoteproc: sysmon: fix shutdown_acked stateArnd Bergmann1-5/+2
The latest version of sysmon_stop() starts by initializing the sysmon->shutdown_acked variable, but then overwrites it with an uninitialized variable later: drivers/remoteproc/qcom_sysmon.c:551:11: error: variable 'acked' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] else if (sysmon->ept) ^~~~~~~~~~~ drivers/remoteproc/qcom_sysmon.c:554:27: note: uninitialized use occurs here sysmon->shutdown_acked = acked; ^~~~~ Remove the local 'acked' variable again and set the state directly. Fixes: 5c212aaf5457 ("remoteproc: sysmon: Expose the shutdown result") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20201204193740.3162065-1-arnd@kernel.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-25remoteproc: k3-r5: Adjust TCM sizes in Split-mode on J7200 SoCsSuman Anna1-0/+43
The J7200 SoCs have a revised R5FSS IP that adds a unique feature w.r.t TCM sizing. Each R5F core in a cluster typically has 32 KB each of ATCM and BTCM, with only the Core0 TCMs usable in LockStep mode. This revised IP however doubles the total available TCM in LockStep mode by making the Core1 TCM visible immediately after the corresponding Core0 TCM. The R5F DT nodes on the J7200 SoCs define double (64 KB) the normal TCM size (32 KB) for R5F Core0 for each of ATCM and BTCM to represent the above. This increased TCM memory is only usable in LockStep-mode, and has to be adjusted to the normal 32 KB size in Split mode. Enhance the TI K3 R5F remoteproc for this logic through a new function. The adjustment is a no-op on prior SoCs and relies on the correct DTS node sizes in LockStep-mode on applicable SoCs. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20201119010531.21083-4-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-25remoteproc: k3-r5: Extend support to R5F clusters on J7200 SoCsSuman Anna1-2/+50
The K3 J7200 SoC family has a revised R5F sub-system and contains a subset of the R5F clusters present on J721E SoCs. The K3 J7200 SoCs only have two dual-core Arm R5F clusters/subsystems with 2 R5F cores each. One cluster is present within the MCU voltage domain (MCU_R5FSS0), while the other is present in the MAIN voltage domain (MAIN_R5FSS0). The revised IP has the following two new features: 1. TCMs are auto-initialized during module power-up, and the behavior is programmable through a MMR bit. 2. The LockStep-mode allows the Core1 TCMs to be combined with the Core0 TCMs effectively doubling the amount of TCMs available. The LockStep-mode on previous SoCs could only use the Core0 TCMs. This combined TCMs appear contiguous at the respective Core0 TCM addresses. Extend the support to these clusters in the K3 R5F remoteproc driver using J7200 specific compatibles. Logic for the second feature is added in the next patch. The integration of these clusters is very much similar to J721E SoCs otherwise. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20201119010531.21083-3-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-25remoteproc: Add a rproc_set_firmware() APISuman Anna2-31/+65
A new API, rproc_set_firmware() is added to allow the remoteproc platform drivers and remoteproc client drivers to be able to configure a custom firmware name that is different from the default name used during remoteproc registration. This function is being introduced to provide a kernel-level equivalent of the current sysfs interface to remoteproc client drivers, and can only change firmwares when the remoteproc is offline. This allows some remoteproc drivers to choose different firmwares at runtime based on the functionality the remote processor is providing. The TI PRU Ethernet driver will be an example of such usage as it requires to use different firmwares for different supported protocols. Also, update the firmware_store() function used by the sysfs interface to reuse this function to avoid code duplication. Reviewed-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Signed-off-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20201121032042.6195-1-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-25remoteproc: sysmon: Improve error messagesBjorn Andersson1-6/+6
Improve the style of a few of the error messages printed by the sysmon implementation and fix the copy-pasted shutdown error in the send-event function. Tested-by: Steev Klimaszewski <steev@kali.org> Reviewed-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Link: https://lore.kernel.org/r/20201122054135.802935-5-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-25remoteproc: qcom: q6v5: Query sysmon before graceful shutdownBjorn Andersson6-6/+13
Requesting a graceful shutdown through the shared memory state signals will not be acked in the event that sysmon has already successfully shut down the remote firmware. So extend the stop request API to optionally take the remoteproc's sysmon instance and query if there's already been a successful shutdown attempt, before doing the signal dance. Tested-by: Steev Klimaszewski <steev@kali.org> Reviewed-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Link: https://lore.kernel.org/r/20201122054135.802935-4-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-25remoteproc: sysmon: Expose the shutdown resultBjorn Andersson2-19/+69
A graceful shutdown of the Qualcomm remote processors where traditionally performed by invoking a shared memory state signal and waiting for the associated ack. This was later superseded by the "sysmon" mechanism, where some form of shared memory bus is used to send a "graceful shutdown request" message and one of more signals comes back to indicate its success. But when this newer mechanism is in effect the firmware is shut down by the time the older mechanism, implemented in the remoteproc drivers, attempts to perform a graceful shutdown - and as such it will never receive an ack back. This patch therefor track the success of the latest shutdown attempt in sysmon and exposes a new function in the API that the remoteproc driver can use to query the success and the necessity of invoking the older mechanism. Tested-by: Steev Klimaszewski <steev@kali.org> Reviewed-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Link: https://lore.kernel.org/r/20201122054135.802935-3-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-25remoteproc: sysmon: Ensure remote notification orderingBjorn Andersson1-4/+21
The reliance on the remoteproc's state for determining when to send sysmon notifications to a remote processor is racy with regard to concurrent remoteproc operations. Further more the advertisement of the state of other remote processor to a newly started remote processor might not only send the wrong state, but might result in a stream of state changes that are out of order. Address this by introducing state tracking within the sysmon instances themselves and extend the locking to ensure that the notifications are consistent with this state. Fixes: 1f36ab3f6e3b ("remoteproc: sysmon: Inform current rproc about all active rprocs") Fixes: 1877f54f75ad ("remoteproc: sysmon: Add notifications for events") Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon") Cc: stable@vger.kernel.org Reviewed-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Link: https://lore.kernel.org/r/20201122054135.802935-2-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-24remoteproc: qcom_q6v5_mss: map/unmap MBA region before/after useSibi Sankar1-15/+22
The application processor accessing the MBA region after assigning it to the remote Q6 would lead to an XPU violation. Fix this by un-mapping the MBA region post firmware copy and MBA text log dumps. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/1604473422-29639-2-git-send-email-sibis@codeaurora.org [bjorn: Renamed "ptr" to "mba_region"] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-24remoteproc: qcom_q6v5_mss: Replace ioremap with memremapSibi Sankar1-6/+6
Fix the sparse warnings reported by the kernel test bot by replacing ioremap calls with memremap. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/1604473422-29639-1-git-send-email-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-23remoteproc: qcom_sysmon: Constify qmi_indication_handlerRikard Falkeborn1-1/+1
The only usage of qmi_indication_handler[] is to pass its address to qmi_handle_init() which accepts a const pointer. Make it const to allow the compiler to put it in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20201122234540.34623-1-rikard.falkeborn@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-20remoteproc/mediatek: skip if filesz is 0Tzung-Bi Shih1-6/+6
The main purpose of the loop is to load the memory to the SCP SRAM. If filesz is 0, can go to next program header directly. We don't need to try to validate the FW binary for those filesz==0 segments. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20201116084413.3312631-3-tzungbi@google.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-20remoteproc/mediatek: fix boundary checkTzung-Bi Shih1-2/+2
It is valid if offset+length == sram_size. For example, sram_size=100, offset=99, length=1. Accessing offset 99 with length 1 is valid. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20201116084413.3312631-2-tzungbi@google.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-20remoteproc/mediatek: fix sparse errors on dma_alloc and dma_freeTzung-Bi Shih2-2/+2
Fixes the following sparse errors on dma_alloc_coherent() and dma_free_coherent(). On drivers/remoteproc/mtk_scp.c:559:23: warning: incorrect type in assignment (different address spaces) expected void [noderef] __iomem *cpu_addr got void * On drivers/remoteproc/mtk_scp.c:572:56: warning: incorrect type in argument 3 (different address spaces) expected void *cpu_addr got void [noderef] __iomem *cpu_addr The cpu_addr is not a __iomem address. Removes the marker. Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20201116082537.3287009-3-tzungbi@google.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-20remoteproc/mediatek: fix sparse errors on sram power on and offTzung-Bi Shih1-2/+2
Fixes the following sparse errors on sram power on and off: On drivers/remoteproc/mtk_scp.c:306:17: warning: incorrect type in argument 2 (different address spaces) expected void volatile [noderef] __iomem *addr got void *addr On drivers/remoteproc/mtk_scp.c:307:9: warning: incorrect type in argument 2 (different address spaces) expected void volatile [noderef] __iomem *addr got void *addr On drivers/remoteproc/mtk_scp.c:314:9: warning: incorrect type in argument 2 (different address spaces) expected void volatile [noderef] __iomem *addr got void *addr On drivers/remoteproc/mtk_scp.c:316:17: warning: incorrect type in argument 2 (different address spaces) expected void volatile [noderef] __iomem *addr got void *addr Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20201116082537.3287009-2-tzungbi@google.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-17remoteproc: stm32: Constify st_rproc_opsRikard Falkeborn1-1/+1
The only usage of st_rproc_ops is to pass its address to rproc_alloc() which accepts a const pointer. Make it const to allow the compiler to put it in read-only memory. Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20201107233630.9728-3-rikard.falkeborn@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-17remoteproc: ingenic: Constify ingenic_rproc_opsRikard Falkeborn1-1/+1
The only usage of ingenic_rproc_ops is to pass its address to devm_rproc_alloc(), which accepts a const pointer. Make it const to allow the compiler to put it in read-only memory. Acked-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20201107233630.9728-2-rikard.falkeborn@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-16remoteproc/wkup_m3: Use reset control driver if availableTony Lindgren1-13/+28
In order to move wkup_m3 to probe without platform data, let's add support for using optional reset control driver if configured in the dts. With this change and the related dts change, we can start dropping the platform data for am335x. And once wkup_m3 no longer needs platform data, we can simply drop the related legacy reset platform data callbacks from wkup_m3 driver later on after also am437x no longer depends on it. Cc: linux-remoteproc@vger.kernel.org Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-10-26remoteproc: ti_k3: fix -Wcast-function-type warningArnd Bergmann1-12/+6
The function cast causes a warning with "make W=1" drivers/remoteproc/ti_k3_r5_remoteproc.c: In function 'k3_r5_probe': drivers/remoteproc/ti_k3_r5_remoteproc.c:1368:12: warning: cast between incompatible function types from 'int (*)(struct platform_device *)' to 'void (*)(void *)' [-Wcast-function-type] Rewrite the code to avoid the cast, and fix the incorrect return type of the callback. Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20201026160533.3705998-1-arnd@kernel.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-10-26remoteproc: qcom_wcnss: Allow replacing regulators with power domainsStephan Gerhold1-16/+93
So far we have been doing all proxy votes by voting for raw voltages/load through the regulator interface. But actually VDDCX and VDDMX represent power domains that should be preferably managed using corner votes through the power domain interface. Looking closer the code was actually never doing the proxy votes correctly: The vddcx regulator is specified as: { "vddcx", .super_turbo = true }, which is supposed to say that we should vote for the maximum corner of the VDDCX power domain. But actually "super_turbo" is unused so all we did so far is to enable the power domain. We did not vote for it to scale to the maximum performance state. Using them through the power domain interface allows voting for the maximum performance state. However, we still need to support using them through the regulator interface for old device trees. The way this is implemented here is that we check if attaching the two power domain succeeds. If yes, we skip the first "num_pd_vregs" regulators in the "vregs" list and only request the remaining ones. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200916104135.25085-9-stephan@gerhold.net Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-10-26remoteproc: qcom_q6v5_mss: Allow replacing regulators with power domainsStephan Gerhold1-12/+56
Newer platforms vote for necessary power domains through the power domain subsystem. For historical reasons older platforms like MSM8916 or MSM8974 still control these as regulators. Managing them as power domains is preferred since that allows us to vote for corners instead of raw voltages. Make it possible for MSM8916 and MSM8974 to manage these as power domains. For compatibility with old device trees we still need to support falling back to the regulators when necessary. The way this is implemented here is that the deprecated regulators are defined as "fallback_proxy_supply". Only if attaching the power domains fails because they are not specified (-ENODATA) we request and manage the fallback regulators instead. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200916104135.25085-7-stephan@gerhold.net Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-10-22Merge tag 'rproc-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteprocLinus Torvalds11-58/+1757
Pull remoteproc updates from Bjorn Andersson: "This introduces support for the Mediatek MT9182 SCP and controlling the Cortex R5F processors found in TI K3 platforms. It clones the longstanding debugfs interface for controlling crash handling to sysfs. Lastly it solves a bug where after a warm reset of Qualcomm platforms the modem would crash upon first boot" * tag 'rproc-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc: remoteproc/mediatek: Remove non-standard dsb() remoteproc: Add recovery configuration to the sysfs interface remoteproc: Add coredump as part of sysfs interface remoteproc: Change default dump configuration to "disabled" remoteproc: k3-r5: Add loading support for on-chip SRAM regions remoteproc: k3-r5: Initialize TCM memories for ECC remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs remoteproc/mediatek: Add support for mt8192 SCP remoteproc: Fixup coredump debugfs disable request remoteproc: qcom_q6v5: Assign mpss region to Q6 before MBA boot remoteproc/mediatek: fix null pointer dereference on null scp pointer remoteproc: stm32: Fix pointer assignement remoteproc: scp: add COMPILE_TEST dependency
2020-10-15remoteproc/mediatek: Remove non-standard dsb()Bjorn Andersson1-4/+0
As reported by Stephen, dsb() is not declared on e.g. x86_64, preventing the mtp_scp from building. Simply remove the barrier (and the readback), suggested by Pi-Hsun to resolve this. Fixes: fd0b6c1ff85a ("remoteproc/mediatek: Add support for mt8192 SCP") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Suggested-by: Pi-Hsun Shih <pihsun@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-10-15Merge tag 'dma-mapping-5.10' of git://git.infradead.org/users/hch/dma-mappingLinus Torvalds2-2/+25
Pull dma-mapping updates from Christoph Hellwig: - rework the non-coherent DMA allocator - move private definitions out of <linux/dma-mapping.h> - lower CMA_ALIGNMENT (Paul Cercueil) - remove the omap1 dma address translation in favor of the common code - make dma-direct aware of multiple dma offset ranges (Jim Quinlan) - support per-node DMA CMA areas (Barry Song) - increase the default seg boundary limit (Nicolin Chen) - misc fixes (Robin Murphy, Thomas Tai, Xu Wang) - various cleanups * tag 'dma-mapping-5.10' of git://git.infradead.org/users/hch/dma-mapping: (63 commits) ARM/ixp4xx: add a missing include of dma-map-ops.h dma-direct: simplify the DMA_ATTR_NO_KERNEL_MAPPING handling dma-direct: factor out a dma_direct_alloc_from_pool helper dma-direct check for highmem pages in dma_direct_alloc_pages dma-mapping: merge <linux/dma-noncoherent.h> into <linux/dma-map-ops.h> dma-mapping: move large parts of <linux/dma-direct.h> to kernel/dma dma-mapping: move dma-debug.h to kernel/dma/ dma-mapping: remove <asm/dma-contiguous.h> dma-mapping: merge <linux/dma-contiguous.h> into <linux/dma-map-ops.h> dma-contiguous: remove dma_contiguous_set_default dma-contiguous: remove dev_set_cma_area dma-contiguous: remove dma_declare_contiguous dma-mapping: split <linux/dma-mapping.h> cma: decrease CMA_ALIGNMENT lower limit to 2 firewire-ohci: use dma_alloc_pages dma-iommu: implement ->alloc_noncoherent dma-mapping: add new {alloc,free}_noncoherent dma_map_ops methods dma-mapping: add a new dma_alloc_pages API dma-mapping: remove dma_cache_sync 53c700: convert to dma_alloc_noncoherent ...
2020-10-13remoteproc: Add recovery configuration to the sysfs interfaceRishabh Bhatnagar1-0/+56
Add recovery configuration to the sysfs interface. This will allow usage of this configuration feature in production devices where access to debugfs might be limited. Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Link: https://lore.kernel.org/r/1601662144-5964-4-git-send-email-rishabhb@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-10-13remoteproc: Add coredump as part of sysfs interfaceRishabh Bhatnagar1-0/+63
Add coredump as part of the sysfs interface. This will allow usage of this configuration feature in production devices where access to debugfs might be limited. Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Link: https://lore.kernel.org/r/1601662144-5964-3-git-send-email-rishabhb@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-10-13remoteproc: Change default dump configuration to "disabled"Rishabh Bhatnagar2-14/+13
Currently "default" configuration option means coredumps are enabled. To avoid confusion rename the "default" configuration option to "enabled" and disable collection of dumps by default as doing so makes sense for production devices. Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Link: https://lore.kernel.org/r/1601662144-5964-2-git-send-email-rishabhb@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-10-13remoteproc: k3-r5: Add loading support for on-chip SRAM regionsSuman Anna1-0/+79
The K3 SoCs has various internal on-chip SRAM memories like the SRAM within the MCU domain or the shared MSMC RAM within NavSS that can be used for multiple purposes. One such purpose is to have the R5F cores use a portion of such on-chip SRAM for fast-access data or to directly execute code. Add support to the K3 R5 remoteproc driver to parse and support loading into such memories. The SRAM regions need to be mapped as normal non-cacheable memory to avoid kernel crashes when the remoteproc loader code uses the Arm64 memset library function (the "DC ZVA" instruction throws a alignment fault on device type memory). These SRAM regions are completely optional as not all firmware images require these memories, and any such memory has to be reserved as such in the DTS files. 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-5-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-10-13remoteproc: k3-r5: Initialize TCM memories for ECCSuman Anna1-2/+15
The R5F processors on K3 SoCs all have two TCMs (ATCM and BTCM) that support 32-bit ECC. The TCMs are typically loaded with some boot-up code to initialize the R5 MPUs to further execute code out of DDR. The ECC for the TCMs is enabled by default on K3 SoCs due to internal default tie-off values, but the TCM memories are not initialized on device power up. Any read access without the corresponding TCM memory location initialized will generate an ECC error, and any such access from a A72 or A53 core will trigger a SError. So, zero initialize both the TCM memories before loading any firmware onto a R5F in remoteproc mode. Any R5F booted from U-Boot/SPL would require a similar initialization in the bootloader. Note that both the TCMs are initialized unconditionally as the TCM enable config bits only manage the access and visibility from R5. 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-4-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>