summaryrefslogtreecommitdiff
path: root/drivers/remoteproc
AgeCommit message (Collapse)Author
2023-01-18remoteproc: qcom_q6v5_pas: add sm8550 adsp, cdsp & mpss compatible & dataNeil Armstrong
This adds the compatible & data for the aDSP, cDSP and MPSS found in the SM8550 SoC. This platform requires the "Devicetree" firmware to be loaded along the main firmware. The MPSS DSM memory to be assigned to the MPSS subsystem is the third memory-region entry as defined in the bindings. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221114-narmstrong-sm8550-upstream-remoteproc-v4-5-54154c08c0b7@linaro.org
2023-01-18remoteproc: qcom_q6v5_pas: add support for assigning memory to firmwareNeil Armstrong
Starting with SM8550, the DSM memory must now be shared to the firmware by the APPS process instead of being defined in the carveout memory reserved for MPSS. In order to handle that, add a region_assign_idx in adsp_data to specify with index of memory-region must be assigned to the MPSS via the qcom_scm_assign_mem() call at probe time. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221114-narmstrong-sm8550-upstream-remoteproc-v4-4-54154c08c0b7@linaro.org
2023-01-18remoteproc: qcom_q6v5_pas: add support for dtb co-firmware loadingNeil Armstrong
Starting from the SM8550 SoC, starting the aDSP, cDSP and MPSS will require loading a separate "Devicetree" firmware. In order to satisfy the load & authentication order required by the SM8550 SoC, the following is implemented: - "Devicetree" firmware request & load in dedicated memory - Q6V5 prepare - Power Domain & Clocks enable - "Devicetree" firmware authentication - Main firmware load in dedicated memory - Main firmware authentication - Q6V5 startup - "Devicetree" firmware metadata release - Main metadata release When booting older platforms, the "Devicetree" steps would be bypassed and the load & authentication order would still be valid. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221114-narmstrong-sm8550-upstream-remoteproc-v4-3-54154c08c0b7@linaro.org
2023-01-13remoteproc: k3-c7x: Add support for C7xv DSP on AM62A SoCJai Luthra
Add support to the K3 DSP remoteproc driver to configure the C7xv subsystem core on AM62A SoCs. The C7xv susbsytem is based on C71 DSP with anlytics engine for deep learning purposes. The remoteproc handling for device management is similar to the C66/C71 DSPs on K3 J7 family SoCs, even though there are additional hardware accelerators and IP updates to C7xv subsystem. Signed-off-by: Jai Luthra <j-luthra@ti.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com> Link: https://lore.kernel.org/r/20221230132453.32022-3-hnagalla@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-01-06remoteproc: pru: Configure firmware based on client setupTero Kristo
Client device node property firmware-name is now used to configure firmware for the PRU instances. The default firmware is also restored once releasing the PRU resource. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20230106121046.886863-7-danishanwar@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-01-06remoteproc: pru: Add pru_rproc_set_ctable() functionRoger Quadros
Some firmwares expect the OS drivers to configure the CTABLE entries publishing dynamically allocated memory regions. For example, the PRU Ethernet firmwares use the C28 and C30 entries for retrieving the Shared RAM and System SRAM (OCMC) areas allocated by the PRU Ethernet client driver. Provide a way for users to do that through a new API, pru_rproc_set_ctable(). The API returns 0 on success and a negative value on error. NOTE: The programmable CTABLE entries are typically re-programmed by the PRU firmwares when dealing with a certain block of memory during block processing. This API provides an interface to the PRU client drivers to publish a dynamically allocated memory block with the PRU firmware using a CTABLE entry instead of a negotiated address in shared memory. Additional synchronization may be needed between the PRU client drivers and firmwares if different addresses needs to be published at run-time reusing the same CTABLE entry. CTABLE for stands for "constant table". Each CTable entry just holds the upper address bits so PRU can reference to external memory with larger address bits. For use case please see prueth_sw_emac_config() in "drivers/net/ethernet/ti/prueth_switch.c" /* Set in constant table C28 of PRUn to ICSS Shared memory */ pru_rproc_set_ctable(prueth->pru0, PRU_C28, sharedramaddr); pru_rproc_set_ctable(prueth->pru1, PRU_C28, sharedramaddr); /* Set in constant table C30 of PRUn to OCMC memory */ pru_rproc_set_ctable(prueth->pru0, PRU_C30, ocmcaddr); pru_rproc_set_ctable(prueth->pru1, PRU_C30, ocmcaddr); Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Link: https://lore.kernel.org/r/20230106121046.886863-6-danishanwar@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-01-06remoteproc: pru: Make sysfs entries read-only for PRU client driven bootsSuman Anna
The PRU remoteproc driver is not configured for 'auto-boot' by default, and allows to be booted either by in-kernel PRU client drivers or by userspace using the generic remoteproc sysfs interfaces. The sysfs interfaces should not be permitted to change the remoteproc firmwares or states when a PRU is being managed by an in-kernel client driver. Use the newly introduced remoteproc generic 'sysfs_read_only' flag to provide these restrictions by setting and clearing it appropriately during the PRU acquire and release steps. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20230106121046.886863-5-danishanwar@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-01-06remoteproc: pru: Add APIs to get and put the PRU coresMD Danish Anwar
Add two new APIs, pru_rproc_get() and pru_rproc_put(), to the PRU driver to allow client drivers to acquire and release the remoteproc device associated with a PRU core. The PRU cores are treated as resources with only one client owning it at a time. The pru_rproc_get() function returns the rproc handle corresponding to a PRU core identified by the device tree "ti,prus" property under the client node. The pru_rproc_put() is the complementary function to pru_rproc_get(). Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20230106121046.886863-4-danishanwar@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-01-06remoteproc: pru: Add enum for PRU Core Identifiers.MD Danish Anwar
Introducing enum pruss_pru_id for PRU Core Identifiers. PRUSS_PRU0 indicates PRU Core 0. PRUSS_PRU1 indicates PRU Core 1. PRUSS_NUM_PRUS indicates the total number of PRU Cores. Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20230106121046.886863-3-danishanwar@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-01-04remoteproc/mtk_scp: Remove timeout variable from scp_ipi_send()AngeloGioacchino Del Regno
That variable was used twice, but now it's just used once to store msecs_to_jiffies(wait), fed to wait_event_timeout(): we might as well remove it for the sake of cleaning up. This brings no functional changes. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230104115341.320951-3-angelogioacchino.delregno@collabora.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-01-04remoteproc/mtk_scp: Use readl_poll_timeout_atomic() for pollingAngeloGioacchino Del Regno
Convert the usage of an open-coded custom tight poll while loop with the provided readl_poll_timeout_atomic() macro. This cleanup brings no functional change. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230104115341.320951-2-angelogioacchino.delregno@collabora.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-01-04remoteproc/mtk_scp: Move clk ops outside send_lockChen-Yu Tsai
Clocks are properly reference counted and do not need to be inside the lock range. Right now this triggers a false-positive lockdep warning on MT8192 based Chromebooks, through a combination of mtk-scp that has a cros-ec-rpmsg sub-device, the (actual) cros-ec I2C adapter registration, I2C client (not on cros-ec) probe doing i2c transfers and enabling clocks. This is a false positive because the cros-ec-rpmsg under mtk-scp does not have an I2C adapter, and also each I2C adapter and cros-ec instance have their own mutex. Move the clk operations outside of the send_lock range. Fixes: 63c13d61eafe ("remoteproc/mediatek: add SCP support for mt8183") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230104083110.736377-1-wenst@chromium.org [Fixed "Fixes:" tag line] Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-12-28remoteproc: qcom: pas: Fix subdevice add orderMukesh Ojha
Currently, the notification like QCOM_SSR_BEFORE_SHUTDOWN is not exactly sent before starting shutdown activity on remote subsystem but it is getting sent after sysmon shutdown request to remote. On getting QCOM_SSR_BEFORE_SHUTDOWN, some client want remote subsystem to be alive to communicate but as sysmon shutdown request is getting sent to remote before QCOM_SSR_BEFORE_SHUTDOWN notification sent to kernel client due to which remote is not in a condition to communicate with kernel clients. Fixing the subdevice ordering will fix this as ssr subdevice will be first one to get triggered in shutdown/stop path. Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/1671024983-22634-1-git-send-email-quic_mojha@quicinc.com
2022-12-28remoteproc: qcom: pas: Add MSM8953 ADSP PIL supportSireesh Kodali
Add support for the Audio DSP PIL found on the Qualcomm MSM8953 platform. The same configuration is used on all SoCs based on the MSM8953 platform (SDM450, SDA450, SDM625, SDM632, APQ8053). Signed-off-by: Sireesh Kodali <sireeshkodali1@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221013042749.104668-2-sireeshkodali1@gmail.com
2022-12-28remoteproc: qcom: Add support for memory sandboxSrinivasa Rao Mandadapu
Update pil driver with SMMU mapping for allowing authorised memory access to ADSP firmware, by carveout reserved adsp memory region from device tree file. Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/1664368073-13659-8-git-send-email-quic_srivasam@quicinc.com
2022-12-28remoteproc: qcom: Add efuse evb selection controlSrinivasa Rao Mandadapu
Add efuse evb selection control and enable it for starting ADSP. Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/1664368073-13659-7-git-send-email-quic_srivasam@quicinc.com
2022-12-28remoteproc: qcom: Replace hard coded values with macrosSrinivasa Rao Mandadapu
Replace hard coded values of QDSP6 boot control reg params with appropriate macro names. Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/1664368073-13659-6-git-send-email-quic_srivasam@quicinc.com
2022-12-28remoteproc: qcom: Update rproc parse firmware callbackSrinivasa Rao Mandadapu
Change parse_fw callback in rproc ops from qcom_register_dump_segments to local function such that, it can perform coredump segments registration and it can parse section header in memory sandboxing required platforms. Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/1664368073-13659-5-git-send-email-quic_srivasam@quicinc.com
2022-12-28remoteproc: qcom: Add compatible name for SC7280 ADSPSrinivasa Rao Mandadapu
Update adsp pil data and compatible name for loading ADSP binary on SC7280 based platforms. Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/1664368073-13659-4-git-send-email-quic_srivasam@quicinc.com
2022-12-28remoteproc: qcom: Add flag in adsp private data structureSrinivasa Rao Mandadapu
Add flag in qcom_adsp private data structure and initialize it to distinguish ADSP modules, which has iommu requirement, for using iommu selectively. Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/1664368073-13659-3-git-send-email-quic_srivasam@quicinc.com
2022-12-28remoteproc: qcom: q6v5: Avoid setting smem bit in case of crash shutdownGokul krishna Krishnakumar
Avoid setting smem bit in case of crash shutdown, as remote processor is not able to send the ack back. Signed-off-by: Gokul krishna Krishnakumar <quic_gokukris@quicinc.com> [bjorn: Rewrote the comment] Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/9e549a54e2a6ede3e413de933fd1725c660993c3.1662995608.git.quic_gokukris@quicinc.com
2022-12-28remoteproc: qcom: wcnss: remove unused qcom_iris_driver declarationGaosheng Cui
qcom_iris_driver has been removed since commit 1fcef985c8bd ("remoteproc: qcom: wcnss: Fix race with iris probe"), so remove it. Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220911090637.3208939-1-cuigaosheng1@huawei.com
2022-12-28remoteproc: move from strlcpy with unused retval to strscpyWolfram Sang
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220818210059.7253-1-wsa+renesas@sang-engineering.com
2022-12-28remoteproc: qcom: q6v5: Use _clk_get_optional for aggre2_clkAbel Vesa
Only msm8996 and msm8998 SLPIs need the RPM_SMD_AGGR2_NOC_CLK (as aggre2 clock). None of the other platforms do. Back when the support for the mentioned platforms was added to the q6v5 pass driver, the devm_clk_get_optional was not available, so the has_aggre2_clk was necessary in order to differentiate between plaforms that need this clock and those which do not. Now that devm_clk_get_optional is available, we can drop the has_aggre2_clk. This makes the adsp_data more cleaner and removes the check within adsp_init_clocks. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220718121514.2451590-1-abel.vesa@linaro.org
2022-12-27remoteproc: qcom: qcom_wcnss: Add support for pronto-v3Vladimir Lypak
Pronto-v3 is similar to pronto-v2. It requires two power domains, one regulator, and it requires the xo clock. It is used on the MSM8953 platform. Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com> Signed-off-by: Sireesh Kodali <sireeshkodali1@gmail.com> Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221001031345.31293-2-sireeshkodali1@gmail.com
2022-12-27remoteproc: qcom: q6v5-mss: Add modem support on MSM8953Sireesh Kodali
The modem on the MSM8953 platform is similar to the modem on the MSM8996 platform in terms of set up. It differs primarily in that TZ needs to be informed of the modem start address and pas_id. Signed-off-by: Sireesh Kodali <sireeshkodali1@gmail.com> Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220908182433.466908-8-stephan.gerhold@kernkonzept.com
2022-12-27remoteproc: qcom: q6v5-mss: Add support for MSM8909Stephan Gerhold
Port the initialization sequence necessary for booting the modem remote processor on the MSM8909 SoC from Qualcomm's msm-3.10 release [1]. The sequence is actually similar to the existing one for MSM8996 and MSM8998 except that there is no separate QDSP6SS_MEM_PWR_CTL register and most of the "memories" are enabled at once instead of sequentially. To reuse the existing code just insert some if statements where needed and add a configuration similar to the one from MSM8916. [1]: https://git.codelinaro.org/clo/la/kernel/msm-3.10/-/commit/56dcedc8dac8abff6b007f76a29430b2d0a44704 Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220908182433.466908-6-stephan.gerhold@kernkonzept.com
2022-12-07remoteproc: core: Do pm_relax when in RPROC_OFFLINE stateMaria Yu
Make sure that pm_relax() happens even when the remoteproc is stopped before the crash handler work is scheduled. Signed-off-by: Maria Yu <quic_aiquny@quicinc.com> Cc: stable <stable@vger.kernel.org> Fixes: a781e5aa5911 ("remoteproc: core: Prevent system suspend during remoteproc recovery") Link: https://lore.kernel.org/r/20221206015957.2616-2-quic_aiquny@quicinc.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-12-06remoteproc: qcom: q6v5: Fix missing clk_disable_unprepare() in ↵Shang XiaoJing
q6v5_wcss_qcs404_power_on() q6v5_wcss_qcs404_power_on() have no fail path for readl_poll_timeout(). Add fail path for readl_poll_timeout(). Fixes: 0af65b9b915e ("remoteproc: qcom: wcss: Add non pas wcss Q6 support for QCS404") Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221204082757.18850-1-shangxiaojing@huawei.com
2022-12-06remoteproc: qcom_q6v5_pas: Fix missing of_node_put() in ↵Yuan Can
adsp_alloc_memory_region() The pointer node is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. Fixes: b9e718e950c3 ("remoteproc: Introduce Qualcomm ADSP PIL") Signed-off-by: Yuan Can <yuancan@huawei.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221203070639.15128-1-yuancan@huawei.com
2022-12-06remoteproc: qcom_q6v5_pas: detach power domains on removeLuca Weiss
We need to detach from the power domains also on remove, not just on probe fail so a subsequent probe works as expected. Otherwise the following error appears on re-probe: [ 29.452005] sysfs: cannot create duplicate filename '/devices/genpd:0:3000000.remoteproc' [ 29.477121] CPU: 1 PID: 483 Comm: sh Tainted: G W 6.1.0-rc4-00075-g71a113770bda #78 [ 29.510319] Hardware name: Fairphone 4 (DT) [ 29.538335] Call trace: [ 29.564470] dump_backtrace.part.0+0xe0/0xf0 [ 29.592602] show_stack+0x18/0x30 [ 29.619616] dump_stack_lvl+0x64/0x80 [ 29.646834] dump_stack+0x18/0x34 [ 29.673541] sysfs_warn_dup+0x60/0x7c [ 29.700592] sysfs_create_dir_ns+0xec/0x110 [ 29.728057] kobject_add_internal+0xb8/0x374 [ 29.755530] kobject_add+0x9c/0x104 [ 29.782072] device_add+0xbc/0x8a0 [ 29.808445] device_register+0x20/0x30 [ 29.835175] genpd_dev_pm_attach_by_id+0xa4/0x190 [ 29.862851] genpd_dev_pm_attach_by_name+0x3c/0xb0 [ 29.890472] dev_pm_domain_attach_by_name+0x20/0x30 [ 29.918212] adsp_probe+0x278/0x580 [ 29.944384] platform_probe+0x68/0xc0 [ 29.970603] really_probe+0xbc/0x2dc [ 29.996662] __driver_probe_device+0x78/0xe0 [ 30.023491] device_driver_attach+0x48/0xac [ 30.050215] bind_store+0xb8/0x114 [ 30.075957] drv_attr_store+0x24/0x3c [ 30.101874] sysfs_kf_write+0x44/0x54 [ 30.127751] kernfs_fop_write_iter+0x120/0x1f0 [ 30.154448] vfs_write+0x1ac/0x380 [ 30.179937] ksys_write+0x70/0x104 [ 30.205274] __arm64_sys_write+0x1c/0x2c [ 30.231060] invoke_syscall+0x48/0x114 [ 30.256594] el0_svc_common.constprop.0+0x44/0xec [ 30.283183] do_el0_svc+0x2c/0xd0 [ 30.308320] el0_svc+0x2c/0x84 [ 30.333059] el0t_64_sync_handler+0xf4/0x120 [ 30.359001] el0t_64_sync+0x18c/0x190 [ 30.384385] kobject_add_internal failed for genpd:0:3000000.remoteproc with -EEXIST, don't try to register things with the same name in the same directory. [ 30.406029] remoteproc remoteproc0: releasing 3000000.remoteproc [ 30.416064] qcom_q6v5_pas: probe of 3000000.remoteproc failed with error -17 Fixes: 17ee2fb4e856 ("remoteproc: qcom: pas: Vote for active/proxy power domains") Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221118090816.100012-2-luca.weiss@fairphone.com
2022-12-06remoteproc: qcom_q6v5_pas: disable wakeup on probe fail or removeLuca Weiss
Leaving wakeup enabled during probe fail (-EPROBE_DEFER) or remove makes the subsequent probe fail. [ 3.749454] remoteproc remoteproc0: releasing 3000000.remoteproc [ 3.752949] qcom_q6v5_pas: probe of 3000000.remoteproc failed with error -17 [ 3.878935] remoteproc remoteproc0: releasing 4080000.remoteproc [ 3.887602] qcom_q6v5_pas: probe of 4080000.remoteproc failed with error -17 [ 4.319552] remoteproc remoteproc0: releasing 8300000.remoteproc [ 4.332716] qcom_q6v5_pas: probe of 8300000.remoteproc failed with error -17 Fix this by disabling wakeup in both cases so the driver can properly probe on the next try. Fixes: a781e5aa5911 ("remoteproc: core: Prevent system suspend during remoteproc recovery") Fixes: dc86c129b4fb ("remoteproc: qcom: pas: Mark devices as wakeup capable") Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221118090816.100012-1-luca.weiss@fairphone.com
2022-12-06remoteproc: qcom: q6v5: Fix potential null-ptr-deref in q6v5_wcss_init_mmio()Shang XiaoJing
q6v5_wcss_init_mmio() will call platform_get_resource_byname() that may fail and return NULL. devm_ioremap() will use res->start as input, which may causes null-ptr-deref. Check the ret value of platform_get_resource_byname() to avoid the null-ptr-deref. Fixes: 0af65b9b915e ("remoteproc: qcom: wcss: Add non pas wcss Q6 support for QCS404") Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221125021641.29392-1-shangxiaojing@huawei.com
2022-12-06remoteproc: sysmon: fix memory leak in qcom_add_sysmon_subdev()Gaosheng Cui
The kfree() should be called when of_irq_get_byname() fails or devm_request_threaded_irq() fails in qcom_add_sysmon_subdev(), otherwise there will be a memory leak, so add kfree() to fix it. Fixes: 027045a6e2b7 ("remoteproc: qcom: Add shutdown-ack irq") Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221129105650.1539187-1-cuigaosheng1@huawei.com
2022-12-06remoteproc: sysmon: Make QMI message rules constJeff Johnson
Commit ff6d365898d4 ("soc: qcom: qmi: use const for struct qmi_elem_info") allows QMI message encoding/decoding rules to be const, so do that for sysmon. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Reviewed-by: Alex Elder <elder@linaro.org> Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220914234705.28405-3-quic_jjohnson@quicinc.com
2022-11-25drivers: remoteproc: Add Xilinx r5 remoteproc driverTanmay Shah
This driver enables r5f dual core Real time Processing Unit subsystem available on Xilinx Zynq Ultrascale MPSoC Platform. RPU subsystem (cluster) can be configured in different modes e.g. split mode in which two r5f cores work independent of each other and lock-step mode in which both r5f cores execute same code clock-for-clock and notify if the result is different. The Xilinx r5 Remoteproc Driver boots the RPU cores via calls to the Xilinx Platform Management Unit that handles the R5 configuration, memory access and R5 lifecycle management. The interface to this manager is done in this driver via zynqmp_pm_* function calls. Signed-off-by: Ben Levinsky <ben.levinsky@amd.com> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20221114233940.2096237-7-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-11-21remoteproc: core: Use device_match_of_node()ye xingchen
Replace the open-code with device_match_of_node(). Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn> Link: https://lore.kernel.org/r/202211171541061366938@zte.com.cn Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-11-15remoteproc: imx_rproc: Correct i.MX93 DRAM mappingPeng Fan
According to updated reference mannual, the M33 DRAM view of 0x[C,D]0000000 maps to A55 0xC0000000, so correct it. Fixes: 9222fabf0e39 ("remoteproc: imx_rproc: Support i.MX93") Signed-off-by: Peng Fan <peng.fan@nxp.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20221102111410.38737-1-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-10-24remoteproc: imx_rproc: Enable attach recovery for i.MX8QM/QXPPeng Fan
i.MX8QM/QXP M4 could recover without help from Linux, so to support it: - enable feature RPROC_FEAT_ATTACH_ON_RECOVERY - set recovery_disabled as false Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20221021041526.3696483-8-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-10-24remoteproc: imx_rproc: Request mbox channel laterPeng Fan
It is possible that when remote processor crash, the communication channel will be broken with garbage value in mailbox, such as when Linux is issuing a message through mailbox, remote processor crashes, we need free & rebuild the mailbox channels to make sure no garbage value in mailbox channels. So move the request/free to start/stop for managing remote procesosr in Linux, move to attach/detach for remote processor is out of control of Linux. Previous, we just request mbox when attach for CM4 boot early before Linux, but if mbox defer probe, remoteproc core will do resource cleanup and corrupt resource table for later probe. So move request mbox ealier and still keep mbox request when attach for self recovery case, but keep a check when request/free mbox. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20221021041526.3696483-7-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-10-24remoteproc: imx_rproc: Support i.MX8QMPeng Fan
Most logic are same as i.MX8QXP, but i.MX8QM has two general purpose M4 cores, the two cores runs independently and they have different resource id, different start address from SCFW view. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20221021041526.3696483-6-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-10-24remoteproc: imx_rproc: Support kicking Mcore from Linux for i.MX8QXPPeng Fan
When M4 is in the same hardware partition with Cortex-A, it could be start/stop by Linux. Added power domain to make sure M4 could run, it requires several power domains to work. Make clock always optional for i.MX8QXP, because SCFW handles it when power up M4 core. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20221021041526.3696483-5-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-10-24remoteproc: imx_rproc: Support attaching to i.MX8QXP M4Peng Fan
When M4 is kicked by SCFW, M4 runs in its own hardware partition, Linux could only do IPC with M4, it could not start, stop, update image. We disable recovery reboot when M4 is managed by SCFW, because remoteproc core still not support M4 auto-recovery without loading image. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20221021041526.3696483-4-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-10-24remoteproc: imx_dsp_rproc: Add mutex protection for workqueueShengjiu Wang
The workqueue may execute late even after remoteproc is stopped or stopping, some resources (rpmsg device and endpoint) have been released in rproc_stop_subdevices(), then rproc_vq_interrupt() accessing these resources will cause kennel dump. Call trace: virtqueue_add_split+0x1ac/0x560 virtqueue_add_inbuf+0x4c/0x60 rpmsg_recv_done+0x15c/0x294 vring_interrupt+0x6c/0xa4 rproc_vq_interrupt+0x30/0x50 imx_dsp_rproc_vq_work+0x24/0x40 [imx_dsp_rproc] process_one_work+0x1d0/0x354 worker_thread+0x13c/0x470 kthread+0x154/0x160 ret_from_fork+0x10/0x20 Add mutex protection in imx_dsp_rproc_vq_work(), if the state is not running, then just skip calling rproc_vq_interrupt(). Also the flush workqueue operation can't be added in rproc stop for the same reason. The call sequence is rproc_shutdown -> rproc_stop ->rproc_stop_subdevices ->rproc->ops->stop() ->imx_dsp_rproc_stop ->flush_work -> rproc_vq_interrupt The resource needed by rproc_vq_interrupt has been released in rproc_stop_subdevices, so flush_work is not safe to be called in imx_dsp_rproc_stop. Fixes: ec0e5549f358 ("remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MX") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1664524216-19949-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-10-24remoteproc: core: Auto select rproc-virtio device idShengjiu Wang
With multiple remoteproc device, there will below error: sysfs: cannot create duplicate filename '/bus/platform/devices/rproc-virtio.0' The rvdev_data.index is duplicate, that cause issue, so need to use the PLATFORM_DEVID_AUTO instead. After fixing device name it becomes something like: /bus/platform/devices/rproc-virtio.2.auto Fixes: 1d7b61c06dc3 ("remoteproc: virtio: Create platform device for the remoteproc_virtio") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Tested-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/1666100644-27010-1-git-send-email-shengjiu.wang@nxp.com [Fixed typographical error in comment block] Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-10-05remoteproc: virtio: Fix warning on bindings by removing the of_match_tableArnaud Pouliquen
The checkpatch tool complains that "virtio,rproc" is not documented. But it is not possible to probe the device "rproc-virtio" by declaring it in the device tree. So documenting it in the bindings does not make sense. This commit solves the checkpatch warning by suppressing the useless of_match_table. Suggested-by: Rob Herring <robh@kernel.org> Fixes: 1d7b61c06dc3 ("remoteproc: virtio: Create platform device for the remoteproc_virtio") Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20221005081317.3411684-1-arnaud.pouliquen@foss.st.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-09-28remoteproc: Support attach recovery after rproc crashPeng Fan
Current logic only support main processor to stop/start the remote processor after crash. However to SoC, such as i.MX8QM/QXP, the remote processor could do attach recovery after crash and trigger watchdog to reboot itself. It does not need main processor to load image, or stop/start remote processor. Introduce two functions: rproc_attach_recovery, rproc_boot_recovery for the two cases. Boot recovery is as before, let main processor to help recovery, while attach recovery is to recover itself without help. To attach recovery, we only do detach and attach. Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20220928064756.4059662-3-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-09-28remoteproc: Introduce rproc featuresPeng Fan
remote processor may support: - boot recovery with help from main processor - self recovery without help from main processor - iommu - etc Introduce rproc features could simplify code to avoid adding more bool flags Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20220928064756.4059662-2-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-09-21remoteproc: virtio: Create platform device for the remoteproc_virtioArnaud Pouliquen
Define a platform driver to manage the remoteproc virtio device as a platform devices. The platform device allows to pass rproc_vdev_data platform data to specify properties that are stored in the rproc_vdev structure. Such approach will allow to preserve legacy remoteproc virtio device creation but also to probe the device using device tree mechanism. remoteproc_virtio.c update: - Add rproc_virtio_driver platform driver. The probe ops replaces the rproc_rvdev_add_device function. - All reference to the rvdev->dev has been updated to rvdev-pdev->dev. - rproc_rvdev_release is removed as associated to the rvdev device. - The use of rvdev->kref counter is replaced by get/put_device on the remoteproc virtio platform device. - The vdev device no longer increments rproc device counter. increment/decrement is done in rproc_virtio_probe/rproc_virtio_remove function in charge of the vrings allocation/free. remoteproc_core.c update: Migrate from the rvdev device to the rvdev platform device. From this patch, when a vdev resource is found in the resource table the remoteproc core register a platform device. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20220921135044.917140-5-arnaud.pouliquen@foss.st.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-09-21remoteproc: Move rproc_vdev management to remoteproc_virtio.cArnaud Pouliquen
Move functions related to the management of the rproc_vdev structure in the remoteproc_virtio.c. The aim is to decorrelate as possible the virtio management from the core part. Due to the strong correlation between the vrings and the resource table the rproc_alloc/parse/free_vring functions are kept in the remoteproc core. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20220921135044.917140-4-arnaud.pouliquen@foss.st.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>