aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/remoteproc
AgeCommit message (Collapse)AuthorFilesLines
2024-05-06remoteproc: k3-r5: Jump to error handling labels in start/stop errorsBeleswar Padhi1-2/+4
In case of errors during core start operation from sysfs, the driver directly returns with the -EPERM error code. Fix this to ensure that mailbox channels are freed on error before returning by jumping to the 'put_mbox' error handling label. Similarly, jump to the 'out' error handling label to return with required -EPERM error code during the core stop operation from sysfs. Fixes: 3c8a9066d584 ("remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs") Signed-off-by: Beleswar Padhi <b-padhi@ti.com> Link: https://lore.kernel.org/r/20240506141849.1735679-1-b-padhi@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-05-06remoteproc: mediatek: Fix error code in scp_rproc_init()Dan Carpenter1-0/+1
Set the error code to ERR_PTR(-ENOMEM). Otherwise if there is an allocation failure it leads to a NULL dereference in the caller. Fixes: c08a82494500 ("remoteproc: mediatek: Support setting DRAM and IPI shared buffer sizes") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/b2114e3c-fa64-4edb-a1ff-d2009e544c3f@moroto.mountain Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-04-30remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfsBeleswar Padhi1-2/+21
PSC controller has a limitation that it can only power-up the second core when the first core is in ON state. Power-state for core0 should be equal to or higher than core1. Therefore, prevent core1 from powering up before core0 during the start process from sysfs. Similarly, prevent core0 from shutting down before core1 has been shut down from sysfs. Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem") Signed-off-by: Beleswar Padhi <b-padhi@ti.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240430105307.1190615-3-b-padhi@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-04-30remoteproc: k3-r5: Wait for core0 power-up before powering up core1Apurva Nandan1-0/+33
PSC controller has a limitation that it can only power-up the second core when the first core is in ON state. Power-state for core0 should be equal to or higher than core1, else the kernel is seen hanging during rproc loading. Make the powering up of cores sequential, by waiting for the current core to power-up before proceeding to the next core, with a timeout of 2sec. Add a wait queue event in k3_r5_cluster_rproc_init call, that will wait for the current core to be released from reset before proceeding with the next core. Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem") Signed-off-by: Apurva Nandan <a-nandan@ti.com> Signed-off-by: Beleswar Padhi <b-padhi@ti.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240430105307.1190615-2-b-padhi@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-04-30remoteproc: mediatek: Support setting DRAM and IPI shared buffer sizesOlivia Wen3-23/+79
The SCP on different chips will require different DRAM sizes and IPI shared buffer sizes based on varying requirements. Signed-off-by: Olivia Wen <olivia.wen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240430011534.9587-4-olivia.wen@mediatek.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-04-30remoteproc: mediatek: Support MT8188 SCP core 1Olivia Wen1-3/+143
MT8188 SCP has two RISC-V cores which is similar to MT8195 but without L1TCM. We've added MT8188-specific functions to configure L1TCM in multicore setups. Signed-off-by: Olivia Wen <olivia.wen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240430011534.9587-3-olivia.wen@mediatek.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-04-24drivers: remoteproc: xlnx: Fix uninitialized tcm modeTanmay Shah1-0/+2
Add "else" case for default tcm mode to silent following static check: zynqmp_r5_cluster_init() error: uninitialized symbol 'tcm_mode'. Fixes: a6b974b40f94 ("drivers: remoteproc: xlnx: Add Versal and Versal-NET support") Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/20240424163344.1344304-1-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-04-23drivers: remoteproc: xlnx: Fix uninitialized variable useTanmay Shah1-1/+1
Fix following warning for clang compiler with W=1 option: initialize the variable 'ret' to silence this warning 907 | int ret, i; | ^ | = 0 Fixes: a6b974b40f94 ("drivers: remoteproc: xlnx: Add Versal and Versal-NET support") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404231839.oHiY9Lw8-lkp@intel.com/ Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Link: https://lore.kernel.org/r/20240423170210.1035957-1-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-04-22drivers: remoteproc: xlnx: Add Versal and Versal-NET supportTanmay Shah1-36/+17
AMD-Xilinx Versal platform is successor of ZynqMP platform. Real-time Processing Unit R5 cluster IP on Versal is same as of ZynqMP Platform. Power-domains ids for Versal platform is different than ZynqMP. AMD-Xilinx Versal-NET platform is successor of Versal platform. Versal-NET Real-Time Processing Unit has two clusters and each cluster contains dual core ARM Cortex-R52 processors. Each R52 core is assigned 128KB of TCM memory. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Link: https://lore.kernel.org/r/20240418220125.744322-1-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-04-16remoteproc: zynqmp: parse TCM from device treeTanmay Shah1-7/+120
ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information is available in device-tree. Parse TCM information in driver as per new bindings. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Link: https://lore.kernel.org/r/20240412183708.4036007-5-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-04-16remoteproc: zynqmp: fix lockstep mode memory regionTanmay Shah1-134/+12
In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep mode memory region as per hardware reference manual. | *TCM* | *R5 View* | *Linux view* | | R5_0 ATCM (128 KB) | 0x0000_0000 | 0xFFE0_0000 | | R5_0 BTCM (128 KB) | 0x0002_0000 | 0xFFE2_0000 | However, driver shouldn't model it as above because R5 core0 TCM and core1 TCM has different power-domains mapped to it. Hence, TCM address space in lockstep mode should be modeled as 64KB regions only where each region has its own power-domain as following: | *TCM* | *R5 View* | *Linux view* | | R5_0 ATCM0 (64 KB) | 0x0000_0000 | 0xFFE0_0000 | | R5_0 BTCM0 (64 KB) | 0x0002_0000 | 0xFFE2_0000 | | R5_0 ATCM1 (64 KB) | 0x0001_0000 | 0xFFE1_0000 | | R5_0 BTCM1 (64 KB) | 0x0003_0000 | 0xFFE3_0000 | This makes driver maintanance easy and makes design robust for future platorms as well. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Link: https://lore.kernel.org/r/20240412183708.4036007-2-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-04-08remoteproc: zynqmp: Add coredump supportLeonard Crestez1-0/+5
Supporting remoteproc coredump requires the platform-specific driver to register coredump segments to be dumped. Do this by calling rproc_coredump_add_segment for every carveout. Also call rproc_coredump_set_elf_info when then rproc is created. If the ELFCLASS parameter is not provided then coredump fails with an error. Other drivers seem to pass EM_NONE for the machine argument but for me this shows a warning in gdb. Pass EM_ARM because this is an ARM R5. Signed-off-by: Leonard Crestez <cdleonard@gmail.com> Link: https://lore.kernel.org/r/d4556268-8274-4089-949f-3b97d67793c7@gmail.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-03-26remoteproc: mediatek: Make sure IPI buffer fits in L2TCMAngeloGioacchino Del Regno1-1/+9
The IPI buffer location is read from the firmware that we load to the System Companion Processor, and it's not granted that both the SRAM (L2TCM) size that is defined in the devicetree node is large enough for that, and while this is especially true for multi-core SCP, it's still useful to check on single-core variants as well. Failing to perform this check may make this driver perform R/W operations out of the L2TCM boundary, resulting (at best) in a kernel panic. To fix that, check that the IPI buffer fits, otherwise return a failure and refuse to boot the relevant SCP core (or the SCP at all, if this is single core). Fixes: 3efa0ea743b7 ("remoteproc/mediatek: read IPI buffer offset from FW") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240321084614.45253-2-angelogioacchino.delregno@collabora.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-03-26remoteproc: Make rproc_class constantRicardo B. Marliere2-2/+2
Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the rproc_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Link: https://lore.kernel.org/r/20240305-class_cleanup-remoteproc2-v1-1-1b139e9828c9@marliere.net Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-03-21Merge tag 'rproc-v6.9' of ↵Linus Torvalds12-295/+357
git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux Pull remoteproc updates from Bjorn Andersson: "Qualcomm SM8650 audio, compute and modem remoteproc are added. Qualcomm X1 Elite audio and compute remoteprocs are added, after support for shutting down the bootloader-loaded firmware loaded into the audio DSP.. A dozen drivers in the subsystem are transitioned to use devres helpers for remoteproc and memory allocations - this makes it possible to acquire in-kernel handle to individual remoteproc instances in a cluster. The release of DMA memory for remoteproc virtio is corrected to ensure that restarting due to a watchdog bite doesn't attempt to allocate the memory again without first freeing it. Last, but not least, a couple of DeviceTree binding cleanups" * tag 'rproc-v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: (30 commits) remoteproc: qcom_q6v5_pas: Unload lite firmware on ADSP remoteproc: qcom_q6v5_pas: Add support for X1E80100 ADSP/CDSP dt-bindings: remoteproc: qcom,sm8550-pas: document the X1E80100 aDSP & cDSP remoteproc: qcom_wcnss: Use devm_rproc_alloc() helper remoteproc: qcom_q6v5_wcss: Use devm_rproc_alloc() helper remoteproc: qcom_q6v5_pas: Use devm_rproc_alloc() helper remoteproc: qcom_q6v5_mss: Use devm_rproc_alloc() helper remoteproc: qcom_q6v5_adsp: Use devm_rproc_alloc() helper dt-bindings: remoteproc: do not override firmware-name $ref dt-bindings: remoteproc: qcom,glink-rpm-edge: drop redundant type from label remoteproc: qcom: pas: correct data indentation remoteproc: Make rproc_get_by_phandle() work for clusters remoteproc: qcom: pas: Add SM8650 remoteproc support remoteproc: qcom: pas: make region assign more generic dt-bindings: remoteproc: qcom,sm8550-pas: document the SM8650 PAS remoteproc: k3-dsp: Use devm_rproc_add() helper remoteproc: k3-dsp: Use devm_ioremap_wc() helper remoteproc: k3-dsp: Add devm action to release tsp remoteproc: k3-dsp: Use devm_kzalloc() helper remoteproc: k3-dsp: Use devm_ti_sci_get_by_phandle() helper ...
2024-03-05remoteproc: qcom_q6v5_pas: Unload lite firmware on ADSPSibi Sankar1-0/+7
The UEFI loads a lite variant of the ADSP firmware to support charging use cases. The kernel needs to unload and reload it with the firmware that has full feature support for audio. This patch arbitarily shutsdown the lite firmware before loading the full firmware. Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20240212-x1e80100-remoteproc-v2-3-604614367f38@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-03-05remoteproc: qcom_q6v5_pas: Add support for X1E80100 ADSP/CDSPSibi Sankar1-0/+41
Add support for PIL loading on ADSP and CDSP on X1E80100 SoCs. Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20240212-x1e80100-remoteproc-v2-2-604614367f38@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-03-05remoteproc: qcom_wcnss: Use devm_rproc_alloc() helperAndrew Davis1-11/+6
Use the device lifecycle managed allocation function. This helps prevent mistakes like freeing out of order in cleanup functions and forgetting to free on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123184632.725054-7-afd@ti.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-03-05remoteproc: qcom_q6v5_wcss: Use devm_rproc_alloc() helperAndrew Davis1-15/+9
Use the device lifecycle managed allocation function. This helps prevent mistakes like freeing out of order in cleanup functions and forgetting to free on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123184632.725054-6-afd@ti.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-03-05remoteproc: qcom_q6v5_pas: Use devm_rproc_alloc() helperAndrew Davis1-3/+1
Use the device lifecycle managed allocation function. This helps prevent mistakes like freeing out of order in cleanup functions and forgetting to free on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123184632.725054-5-afd@ti.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-03-05remoteproc: qcom_q6v5_mss: Use devm_rproc_alloc() helperAndrew Davis1-16/+12
Use the device lifecycle managed allocation function. This helps prevent mistakes like freeing out of order in cleanup functions and forgetting to free on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123184632.725054-4-afd@ti.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-03-05remoteproc: qcom_q6v5_adsp: Use devm_rproc_alloc() helperAndrew Davis1-9/+5
Use the device lifecycle managed allocation function. This helps prevent mistakes like freeing out of order in cleanup functions and forgetting to free on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123184632.725054-3-afd@ti.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-03-05remoteproc: qcom: pas: correct data indentationDmitry Baryshkov1-62/+62
Correct indentation of several struct adsp_data instances to always use a single TAB character instead of two. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240304-qcom-pd-mapper-v3-4-6858fa1ac1c8@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-02-14remoteproc: qcom_q6v5_adsp: Convert to dev_pm_domain_attach|detach_list()Ulf Hansson1-87/+73
Let's avoid some of the boilerplate code to manage the various PM domain cases, by converting into using dev_pm_domain_attach|detach_list(). As a part of the conversion, we are moving over to use device_links, which simplifies the runtime PM support too. Moreover, while attaching let's trust that an already attached single PM domain is the correct one. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Bjorn Andersson <andersson@kernel.org> Cc: Konrad Dybcio <konrad.dybcio@linaro.org> Cc: <linux-remoteproc@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20240130123951.236243-5-ulf.hansson@linaro.org
2024-02-14remoteproc: imx_rproc: Convert to dev_pm_domain_attach|detach_list()Ulf Hansson1-64/+9
Let's avoid the boilerplate code to manage the multiple PM domain case, by converting into using dev_pm_domain_attach|detach_list(). Cc: Bjorn Andersson <andersson@kernel.org> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Daniel Baluta <daniel.baluta@nxp.com> Cc: <linux-remoteproc@vger.kernel.org> Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20240130123951.236243-4-ulf.hansson@linaro.org
2024-02-14remoteproc: imx_dsp_rproc: Convert to dev_pm_domain_attach|detach_list()Ulf Hansson1-73/+9
Let's avoid the boilerplate code to manage the multiple PM domain case, by converting into using dev_pm_domain_attach|detach_list(). Cc: Bjorn Andersson <andersson@kernel.org> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Daniel Baluta <daniel.baluta@nxp.com> Cc: <linux-remoteproc@vger.kernel.org> Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20240130123951.236243-3-ulf.hansson@linaro.org
2024-02-06remoteproc: Make rproc_get_by_phandle() work for clustersMathieu Poirier1-2/+27
Multi-cluster remoteproc designs typically have the following DT declaration: remoteproc-cluster { compatible = "soc,remoteproc-cluster"; core0: core0 { compatible = "soc,remoteproc-core" memory-region; sram; }; core1: core1 { compatible = "soc,remoteproc-core" memory-region; sram; } }; A driver exists for the cluster rather than the individual cores themselves so that operation mode and HW specific configurations applicable to the cluster can be made. Because the driver exists at the cluster level and not the individual core level, function rproc_get_by_phandle() fails to return the remoteproc associated with the phandled it is called for. This patch enhances rproc_get_by_phandle() by looking for the cluster's driver when the driver for the immediate remoteproc's parent is not found. Reported-by: Ben Levinsky <ben.levinsky@xilinx.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Co-developed-by: Tarak Reddy <tarak.reddy@amd.com> Signed-off-by: Tarak Reddy <tarak.reddy@amd.com> Co-developed-by: Tanmay Shah <tanmay.shah@amd.com> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Link: https://lore.kernel.org/r/20240130154849.1018666-1-tanmay.shah@amd.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-02-06remoteproc: qcom: pas: Add SM8650 remoteproc supportNeil Armstrong1-0/+50
Add DSP Peripheral Authentication Service support for the SM8650 platform. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20240123-topic-sm8650-upstream-remoteproc-v7-3-61283f50162f@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-02-06remoteproc: qcom: pas: make region assign more genericNeil Armstrong1-34/+66
The current memory region assign only supports a single memory region. But new platforms introduces more regions to make the memory requirements more flexible for various use cases. Those new platforms also shares the memory region between the DSP and HLOS. To handle this, make the region assign more generic in order to support more than a single memory region and also permit setting the regions permissions as shared. Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240123-topic-sm8650-upstream-remoteproc-v7-2-61283f50162f@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-02-05remoteproc: k3-dsp: Use devm_rproc_add() helperAndrew Davis1-7/+2
Use device lifecycle managed devm_rproc_add() helper function. This helps prevent mistakes like deleting out of order in cleanup functions and forgetting to delete on all error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240205182753.36978-6-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-02-05remoteproc: k3-dsp: Use devm_ioremap_wc() helperAndrew Davis1-38/+10
Use a device lifecycle managed ioremap helper function. This helps prevent mistakes like unmapping out of order in cleanup functions and forgetting to unmap on all error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240205182753.36978-5-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-02-05remoteproc: k3-dsp: Add devm action to release tspAndrew Davis1-14/+13
Use a device lifecycle managed action to release tps ti_sci_proc handle. This helps prevent mistakes like releasing out of order in cleanup functions and forgetting to release on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240205182753.36978-4-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-02-05remoteproc: k3-dsp: Use devm_kzalloc() helperAndrew Davis1-6/+2
Use device lifecycle managed devm_kzalloc() helper function. This helps prevent mistakes like freeing out of order in cleanup functions and forgetting to free on all error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240205182753.36978-3-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-02-05remoteproc: k3-dsp: Use devm_ti_sci_get_by_phandle() helperAndrew Davis1-23/+9
Use the device lifecycle managed TI-SCI get() function. This helps prevent mistakes like not put()'ing in the wrong order in cleanup functions and forgetting to put() on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240205182753.36978-2-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-02-02remoteproc: stm32: Use devm_rproc_alloc() helperAndrew Davis1-3/+1
Use the device lifecycle managed allocation function. This helps prevent mistakes like freeing out of order in cleanup functions and forgetting to free on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123184632.725054-9-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-02-02remoteproc: st: Use devm_rproc_alloc() helperAndrew Davis1-10/+5
Use the device lifecycle managed allocation function. This helps prevent mistakes like freeing out of order in cleanup functions and forgetting to free on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123184632.725054-8-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-02-02remoteproc: imx_rproc: Use devm_rproc_alloc() helperAndrew Davis1-11/+5
Use the device lifecycle managed allocation function. This helps prevent mistakes like freeing out of order in cleanup functions and forgetting to free on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123184632.725054-2-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-02-02remoteproc: imx_dsp_rproc: Use devm_rproc_alloc() helperAndrew Davis1-7/+4
Use the device lifecycle managed allocation function. This helps prevent mistakes like freeing out of order in cleanup functions and forgetting to free on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123184632.725054-1-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-02-02remoteproc: k3-dsp: Use devm_kcalloc() helperAndrew Davis1-3/+1
Use a device lifecycle managed action to free memory. This helps prevent mistakes like freeing out of order in cleanup functions and forgetting to free on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123184913.725435-3-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-02-02remoteproc: k3-dsp: Add devm action to release reserved memoryAndrew Davis1-8/+12
Use a device lifecycle managed action to release reserved memory. This helps prevent mistakes like releasing out of order in cleanup functions and forgetting to release on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123184913.725435-2-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-02-02remoteproc: k3-dsp: Use devm_rproc_alloc() helperAndrew Davis1-11/+5
Use the device lifecycle managed allocation function. This helps prevent mistakes like freeing out of order in cleanup functions and forgetting to free on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123184913.725435-1-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-01-23remoteproc: stm32: Fix incorrect type assignment returned by ↵Arnaud Pouliquen1-1/+1
stm32_rproc_get_loaded_rsc_tablef The sparse tool complains about the remove of the _iomem attribute. stm32_rproc.c:660:17: warning: cast removes address space '__iomem' of expression Add '__force' to explicitly specify that the cast is intentional. This conversion is necessary to cast to addresses pointer, which are then managed by the remoteproc core as a pointer to a resource_table structure. Fixes: 8a471396d21c ("remoteproc: stm32: Move resource table setup to rproc_ops") Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20240117135312.3381936-3-arnaud.pouliquen@foss.st.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-01-23remoteproc: stm32: Fix incorrect type in assignment for vaArnaud Pouliquen1-2/+2
The sparse tool complains about the attribute conversion between a _iomem void * and a void *: stm32_rproc.c:122:12: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *va @@ got void [noderef] __iomem * @@ stm32_rproc.c:122:12: sparse: expected void *va stm32_rproc.c:122:12: sparse: got void [noderef] __iomem * Add '__force' to explicitly specify that the cast is intentional. This conversion is necessary to cast to virtual addresses pointer,used, by the remoteproc core. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312150052.HCiNKlqB-lkp@intel.com/ Fixes: 13140de09cc2 ("remoteproc: stm32: add an ST stm32_rproc driver") Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20240117135312.3381936-2-arnaud.pouliquen@foss.st.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-01-22remoteproc: virtio: Fix wdg cannot recovery remote processorJoakim Zhang1-3/+3
Recovery remote processor failed when wdg irq received: [ 0.842574] remoteproc remoteproc0: crash detected in cix-dsp-rproc: type watchdog [ 0.842750] remoteproc remoteproc0: handling crash #1 in cix-dsp-rproc [ 0.842824] remoteproc remoteproc0: recovering cix-dsp-rproc [ 0.843342] remoteproc remoteproc0: stopped remote processor cix-dsp-rproc [ 0.847901] rproc-virtio rproc-virtio.0.auto: Failed to associate buffer [ 0.847979] remoteproc remoteproc0: failed to probe subdevices for cix-dsp-rproc: -16 The reason is that dma coherent mem would not be released when recovering the remote processor, due to rproc_virtio_remove() would not be called, where the mem released. It will fail when it try to allocate and associate buffer again. Releasing reserved memory from rproc_virtio_dev_release(), instead of rproc_virtio_remove(). Fixes: 1d7b61c06dc3 ("remoteproc: virtio: Create platform device for the remoteproc_virtio") Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com> Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231217053659.3245745-1-joakim.zhang@cixtech.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-12-17remoteproc: qcom_q6v5_pas: Add SC7280 ADSP, CDSP & WPSSLuca Weiss1-0/+19
Add support for the ADSP, CDSP and WPSS remoteprocs found on the SC7280 SoC using the q6v5-pas driver. This driver can be used on regular LA ("Linux Android") based releases, however the SC7280 ChromeOS devices need different driver support due to firmware differences. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://lore.kernel.org/r/20231208-sc7280-remoteprocs-v3-6-6aa394d33edf@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-11-30remoteproc: k3-dsp: Convert to platform remove callback returning voidUwe Kleine-König1-5/+3
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). There is no change in behaviour as .remove() already returned zero unconditionally. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231123211657.518181-8-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-11-30remoteproc: k3-dsp: Use symbolic error codes in error messagesUwe Kleine-König1-44/+34
The error message failed to send mailbox message (-EINVAL) is (for a human) more useful than failed to send mailbox message, status = -22 Adapt all error messages to use the symbolic names instead of the numeric constants. The error paths in .probe() make use of dev_err_probe() which automatically handles EPROBE_DEFER. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231123211657.518181-7-u.kleine-koenig@pengutronix.de> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-11-30remoteproc: k3-dsp: Suppress duplicate error message in .remove()Uwe Kleine-König1-1/+2
When the remove callback returns non-zero, the driver core emits an error message about the error value being ignored. As the driver already emits an error message already, return zero. This has no effect apart from suppressing the core's message. The platform device gets unbound irrespective of the return value. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231123211657.518181-6-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-11-20remoteproc: imx_dsp_rproc: Add mandatory find_loaded_rsc_table opIuliana Prodan1-0/+1
Add the .find_loaded_rsc_table operation for i.MX DSP. We need it for inter-process communication between DSP and main core. This callback is used to find the resource table (defined in remote processor linker script) where the address of the vrings along with the other allocated resources (carveouts etc) are stored. If this is not found, the vrings are not allocated and the IPC between cores will not work. Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20231013152731.23471-2-iuliana.prodan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-10-16remoteproc: st: Fix sometimes uninitialized ret in st_rproc_probe()Nathan Chancellor1-1/+3
Clang warns (or errors with CONFIG_WERROR=y): drivers/remoteproc/st_remoteproc.c:357:6: error: variable 'ret' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] 357 | if (!ddata->config) | ^~~~~~~~~~~~~~ drivers/remoteproc/st_remoteproc.c:442:9: note: uninitialized use occurs here 442 | return ret; | ^~~ drivers/remoteproc/st_remoteproc.c:357:2: note: remove the 'if' if its condition is always false 357 | if (!ddata->config) | ^~~~~~~~~~~~~~~~~~~ 358 | goto free_rproc; | ~~~~~~~~~~~~~~~ drivers/remoteproc/st_remoteproc.c:348:9: note: initialize the variable 'ret' to silence this warning 348 | int ret, i; | ^ | = 0 1 error generated. Set ret to -ENODEV, which seems to be a standard return code when device_get_match_data() returns NULL. Closes: https://github.com/ClangBuiltLinux/linux/issues/1944 Fixes: 5c77ebcd05ac ("remoteproc: st: Use device_get_match_data()") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20231012-st_remoteproc-fix-sometimes-uninit-v1-1-f64d0f2d5b37@kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-10-11remoteproc: st: Use device_get_match_data()Rob Herring1-10/+4
Use preferred device_get_match_data() instead of of_match_device() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Link: https://lore.kernel.org/r/20231009211356.3242037-10-robh@kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-09-29remoteproc: zynqmp: Change tcm address translation methodTanmay Shah1-38/+20
Introduce device address in hardcode TCM table. Device address is used for address translation. Also, previous method(hack) to mask few bits from address to achieve address translation is removed Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Link: https://lore.kernel.org/r/20230925172648.2339048-1-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-09-21remoteproc: mediatek: Refactor single core check and fix retrocompatibilityAngeloGioacchino Del Regno1-11/+7
In older devicetrees we had the ChromeOS EC in a node called "cros-ec" instead of the newer "cros-ec-rpmsg", but this driver is now checking only for the latter, breaking compatibility with those. Besides, we can check if the SCP is single or dual core by simply walking through the children of the main SCP node and checking if if there's more than one "mediatek,scp-core" compatible node. Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP") Reported-by: "kernelci.org bot" <bot@kernelci.org> Tested-by: Laura Nao <laura.nao@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230919092336.51007-1-angelogioacchino.delregno@collabora.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-09-20remoteproc: qcom: q6v5-mss: Remove PNoC clock from 8996 MSSKonrad Dybcio1-1/+0
The PNoC clock is a clock for the entire PNoC bus, managed from within the interconnect driver. Attaching it to MSS was a total hack. Get rid of it. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230721-topic-rpm_clk_cleanup-v2-10-1e506593b1bd@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20remoteproc: qcom: pas: Add SM6375 MPSSKonrad Dybcio1-0/+16
Add a config for the MPSS present on SM6375. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230725-topic-6375_rproc-v5-3-a8e9cde56a20@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20remoteproc: qcom: pas: Add SM6375 ADSP & CDSPKonrad Dybcio1-0/+2
Add a config for the ADSP&CDSP present on SM6375. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230725-topic-6375_rproc-v5-2-a8e9cde56a20@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20remoteproc: qcom: pas: Add sc7180 adspNikita Travkin1-0/+1
sc7180 has a dedicated ADSP similar to the one found in sm8250. Add it's compatible to the driver reusing the existing config so the devices that use the adsp can probe it. Signed-off-by: Nikita Travkin <nikita@trvn.ru> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20230907-sc7180-adsp-rproc-v3-2-6515c3fbe0a3@trvn.ru Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-14remoteproc: zynqmp: fix TCM carveouts in lockstep modeTanmay Shah1-23/+43
In lockstep mode following is TCM address map: | *TCM* | *R5 View* | *Linux view* | | R5_0 ATCM (128 KB) | 0x0000_0000 | 0xFFE0_0000 | | R5_0 BTCM (128 KB) | 0x0002_0000 | 0xFFE2_0000 | Current driver keeps single TCM carveout in lockstep mode as ATCM and BTCM addresses form contiguous memory region. Although the addresses are contiguous, it is not same type of memory. ATCM typically holds interrupt or exception code that must be accessed at high speed. BTCM typically holds a block of data for intensive processing, such as audio or video processing. As both are different types of memory, they should be allocated as different carveout. This patch is fixing TCM carveout allocation in lockstep mode. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Link: https://lore.kernel.org/r/20230913024323.2768114-1-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-09-13remoteproc: mediatek: Refine ipi handler error messageTinghan Shen1-1/+1
The error message doesn't accurately reflect the cause of the error. The error is due to a handler not being found, not an invalid IPI ID. Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230901080935.14571-14-tinghan.shen@mediatek.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-09-13remoteproc: mediatek: Report watchdog crash to all coresTinghan Shen1-1/+7
To ensure consistent behavior, the watchdog timeout handling of the multi-core SCP should reset the whole SCP sub-system when watchdog timeout. Triggering the rproc recovery flow on all instances will ensure proper recovery of the SCP sub-system. Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230901080935.14571-13-tinghan.shen@mediatek.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-09-13remoteproc: mediatek: Handle MT8195 SCP core 1 watchdog timeoutTinghan Shen2-1/+29
The MT8195 SCP core 1 watchdog timeout needs to be handled in the SCP core 0 IRQ handler because the MT8195 SCP core 1 watchdog timeout IRQ is wired on the same IRQ entry for core 0 watchdog timeout. MT8195 SCP has a watchdog status register to identify the watchdog timeout source when IRQ triggered. Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230901080935.14571-12-tinghan.shen@mediatek.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-09-13remoteproc: mediatek: Setup MT8195 SCP core 1 SRAM offsetTinghan Shen2-0/+35
Because MT8195 SCP core 0 and core 1 both boot from head of SRAM and have the same viewpoint of SRAM, SCP has a "core 1 SRAM offset" configuration to control the access destination of SCP core 1 to boot core 1 from different SRAM location. The "core 1 SRAM offset" configuration is composed by a range and an offset. It works like a simple memory mapped mechanism. When SCP core 1 accesses a SRAM address located in the range, the SCP bus adds the configured offset to the address to shift the physical destination address on SCP SRAM. This shifting is transparent to the software running on SCP core 1. Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230901080935.14571-11-tinghan.shen@mediatek.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-09-13remoteproc: mediatek: Remove dependency of MT8195 SCP L2TCM power control on ↵Tinghan Shen2-15/+59
dual-core SCP Previously, SCP core 0 controlled the power of L2TCM and dictated that SCP core 1 could only boot after SCP core 0. To address this constraint, extracted the power control flow of L2TCM and made it shared between both cores, enabling support for arbitrary boot order. The flow for controlling L2TCM power has been incorporated into the mt8195_scp_before_load() and mt8195_scp_stop() APIs, which are respectively invoked during the rproc->ops->start() and rproc->ops->stop() operations. These APIs effectively serve the same purpose as the rproc prepare()/unprepare() APIs." Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230901080935.14571-10-tinghan.shen@mediatek.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-09-13remoteproc: mediatek: Probe SCP cluster on multi-core SCPTinghan Shen1-5/+119
The difference of single-core SCP and multi-core SCP device tree is the presence of child device nodes described SCP cores. The SCP driver populates the platform device and checks the child nodes to identify whether it's a single-core SCP or a multi-core SCP. Add the remoteproc instances of multi-core SCP to the SCP cluster list. When the SCP driver is removed, it cleanup resources by walking through the cluster list. Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230901080935.14571-9-tinghan.shen@mediatek.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-09-13remoteproc: mediatek: Probe SCP cluster on single-core SCPTinghan Shen2-25/+63
This is the 3rd preliminary step for probing multi-core SCP. Rewrite the probing flow of single-core SCP to adapt with the 'cluster' concept needed by the multi-core SCP. The SCP core object(s) is maintained at the cluster list. Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230901080935.14571-8-tinghan.shen@mediatek.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-09-13remoteproc: mediatek: Revise SCP rproc initialization flow for multi-core SCPTinghan Shen1-24/+39
This is the 2nd preliminary step for probing multi-core SCP. Initialization of configuration and L1TCM registers is extracted to only performed once on multi-core SCP. The rest of remoteproc initialization procedure is similar for both single and multi-core SCP and is applied to each core. Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230901080935.14571-7-tinghan.shen@mediatek.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-09-13remoteproc: mediatek: Extract SCP common registersTinghan Shen3-85/+96
This is the 1st preliminary steps for probing multi-core SCP. The registers of config and l1tcm are common on single-core SCP and multi-core SCP. Extract these registers out to reduce duplicated fields in mtk_scp when multiple SCP instances are created. Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230901080935.14571-6-tinghan.shen@mediatek.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-09-13remoteproc: mediatek: Add MT8195 SCP core 1 operationsTinghan Shen2-0/+64
The SCP rproc driver has a set of chip dependent callbacks for boot sequence and IRQ handling. Implement these callbacks for MT8195 SCP core 1. Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230901080935.14571-5-tinghan.shen@mediatek.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-09-13remoteproc: stm32: Clean up redundant dev_err_probe()Chen Jiahao1-2/+2
Referring to platform_get_irq()'s definition, the return value has already been checked if ret < 0, and printed via dev_err_probe(). Calling dev_err_probe() one more time outside platform_get_irq() is obviously redundant. Removing outside dev_err_probe() to clean it up. Besides, switch to use platform_get_irq_optional() since the irq is optional here. Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com> Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20230817083336.404635-1-chenjiahao16@huawei.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-09-04Merge tag 'rproc-v6.6' of ↵Linus Torvalds21-146/+264
git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux Pull remoteproc updates from Bjorn Andersson: "Support for booting the iMX remoteprocs using MMIO, instead of SMCCC is added. The iMX driver is also extended to support delivering interrupts from an arbitrary number of vdev. Support is added to the TI PRU driver, to allow GPMUX to be controlled from DeviceTree. The Qualcomm coredump collector is extended to fall back to generating a full coredump, in the case that the loaded firmware doesn't support generating minidump. The overly terse MD abbreviation of "MINIDUMP" is expanded, to make the code easier on the eye. The list of Qualcomm Sensor Low Power Island (SLPI) instances supported is cleaned up, and SDM845 is added. SDM630/636/660 support for the modem subsystem (mss) is added. All the Qualcomm drivers are transitioned to of_reserved_mem_lookup() instead of open coding the resolution of reserved-memory regions, to gain handling of error cases. A couple of drivers are transitioned to use devm_platform_ioremap_resource_byname(). The stm32 remoteproc driver's PM operations are updated to modern macros, to avoid the "unused variable"-warning in some configurations. Drivers are transitioned away from directly including of_device.h" * tag 'rproc-v6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: (23 commits) remoteproc: pru: add support for configuring GPMUX based on client setup remoteproc: stm32: fix incorrect optional pointers remoteproc: imx_rproc: Switch iMX8MN/MP from SMCCC to MMIO dt-bindings: remoteproc: imx_rproc: Support i.MX8MN/P MMIO dt-bindings: remoteproc: qcom,msm8996-mss-pil: Fix 8996 clocks remoteproc: qcom: pas: add SDM845 SLPI compatible remoteproc: qcom: q6v5-mss: Add support for SDM630/636/660 dt-bindings: remoteproc: qcom,msm8996-mss-pil: Add SDM660 compatible remoteproc: qcom: Expand MD_* as MINIDUMP_* remoteproc: qcom: pas: refactor SLPI remoteproc init dt-bindings: remoteproc: qcom: adsp: add qcom,sdm845-slpi-pas compatible remoteproc: qcom: wcnss: use devm_platform_ioremap_resource_byname() remoteproc: qcom: q6v5: use devm_platform_ioremap_resource_byname() dt-bindings: remoteproc: qcom: sm6115-pas: Add QCM2290 remoteproc: qcom: Add full coredump fallback mechanism remoteproc: core: Export the rproc coredump APIs remoteproc: qcom: Use of_reserved_mem_lookup() remoteproc: imx_rproc: iterate all notifiyids in rx callback dt-bindings: remoteproc: qcom,adsp: bring back firmware-name dt-bindings: remoteproc: qcom,sm8550-pas: require memory-region ...
2023-08-21remoteproc: pru: add support for configuring GPMUX based on client setupTero Kristo1-0/+22
The GPMUX config value for a PRU device can now be configured by client by specifying it in the device node ti,pruss-gp-mux-sel. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Link: https://lore.kernel.org/r/20230802064925.1895750-1-danishanwar@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-08-21remoteproc: stm32: fix incorrect optional pointersArnd Bergmann1-6/+6
Compile-testing without CONFIG_OF shows that the of_match_ptr() macro was used incorrectly here: drivers/remoteproc/stm32_rproc.c:662:34: warning: unused variable 'stm32_rproc_match' [-Wunused-const-variable] As in almost every driver, the solution is simply to remove the use of this macro. The same thing happened with the deprecated SIMPLE_DEV_PM_OPS(), but the corresponding warning was already shut up with __maybe_unused annotations, so fix those as well by using the correct DEFINE_SIMPLE_DEV_PM_OPS() macros and removing the extraneous __maybe_unused modifiers. For completeness, also add a pm_ptr() to let the PM ops be eliminated completely when CONFIG_PM is turned off. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202307242300.ia82qBTp-lkp@intel.com Fixes: 03bd158e1535 ("remoteproc: stm32: use correct format strings on 64-bit") Fixes: 410119ee29b6 ("remoteproc: stm32: wakeup the system by wdg irq") Fixes: 13140de09cc2 ("remoteproc: stm32: add an ST stm32_rproc driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20230724195704.2432382-1-arnd@kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-08-13soc: qcom: aoss: Tidy up qmp_send() callersBjorn Andersson1-7/+1
With qmp_send() handling variable length messages and string formatting he callers of qmp_send() can be cleaned up to not care about these things. Drop the QMP_MSG_LEN sized buffers and use the message formatting, as appropriate. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Link: https://lore.kernel.org/r/20230811205839.727373-5-quic_bjorande@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-08-13soc: qcom: aoss: Move length requirements from callerBjorn Andersson1-1/+1
The existing implementation of qmp_send() requires the caller to provide a buffer which is of word-aligned. The underlying reason for this is that message ram only supports word accesses, but pushing this requirement onto the clients results in the same boiler plate code sprinkled in every call site. By using a temporary buffer in qmp_send() we can hide the underlying hardware limitations from the clients and allow them to pass their NUL-terminates C string directly. Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230811205839.727373-2-quic_bjorande@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-27remoteproc: imx_rproc: Switch iMX8MN/MP from SMCCC to MMIOMarek Vasut2-2/+58
The MX8M CM7 boot via SMC call is problematic, since not all versions of ATF support this interface. Extend the MMIO support so it can boot the CM7 on MX8MN/MP instead and discern the two alternatives using DT compatible strings. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20230724222418.163220-2-marex@denx.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-07-15remoteproc: qcom: pas: add SDM845 SLPI compatibleDylan Van Assche1-0/+1
Add a compatible for the SDM845 SLPI to the Qualcomm remoteproc q6v5_pas driver. The SLPI is the same as in SM8150, SM8250, SM8350, and SM8450, so use the same resource in the driver. Signed-off-by: Dylan Van Assche <me@dylanvanassche.be> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230330164633.117335-4-me@dylanvanassche.be Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15remoteproc: qcom: q6v5-mss: Add support for SDM630/636/660Alexey Minnekhanov1-2/+49
Snapdragon 630/660 modem subsystem is similar to one in MSM8998 and can almost reuse it's reset sequence. Downstream sources call this q6v5 version "qdsp6v62-1-5" and its code path has additional checks for QDSP6v55_BHS_EN_REST_ACK status [2]. Inspiration is taken from Konrad Dybcio's work in [1], but reworked to use common code path with MSM8996/8998, instead of completely separate "if" block for SDM660. [1] https://github.com/SoMainline/linux/commit/7dd6dd9b936dc8d6c1f1abe299e5b065c33741e8 [2] https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/lavender-q-oss/drivers/soc/qcom/pil-q6v5.c#L393 Co-developed-by: Konrad Dybcio <konradybcio@gmail.com> Signed-off-by: Konrad Dybcio <konradybcio@gmail.com> Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230621175046.61521-2-alexeymin@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15remoteproc: qcom: Expand MD_* as MINIDUMP_*Mukesh Ojha1-6/+6
Expand MD_* as MINIDUMP_* which makes more sense than the abbreviation. Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/1683133352-10046-2-git-send-email-quic_mojha@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15remoteproc: qcom: pas: refactor SLPI remoteproc initDylan Van Assche1-40/+8
SLPI remoteproc initialization is the same for SDM845, SM8150, SM8250, SM8350 but is duplicated for each compatible. Refactor initialization structs for these 4 compatibles as a single struct. Signed-off-by: Dylan Van Assche <me@dylanvanassche.be> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230330164633.117335-3-me@dylanvanassche.be Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15remoteproc: qcom: wcnss: use devm_platform_ioremap_resource_byname()Ye Xingchen1-3/+1
Convert platform_get_resource_byname(),devm_ioremap_resource() to a single call to devm_platform_ioremap_resource_byname(), as this is exactly what this function does. Signed-off-by: Ye Xingchen <ye.xingchen@zte.com.cn> Link: https://lore.kernel.org/r/202303221116427329010@zte.com.cn Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15remoteproc: qcom: q6v5: use devm_platform_ioremap_resource_byname()Ye Xingchen1-2/+1
Convert platform_get_resource_byname(),devm_ioremap_resource() to a single call to devm_platform_ioremap_resource_byname(), as this is exactly what this function does. Signed-off-by: Ye Xingchen <ye.xingchen@zte.com.cn> Link: https://lore.kernel.org/r/202303221115145068959@zte.com.cn Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15remoteproc: qcom: Add full coredump fallback mechanismSiddharth Gupta2-2/+12
If a remoteproc's firmware does not support minidump but the driver adds an ID, the minidump driver does not collect any coredumps when the remoteproc crashes. This hinders the purpose of coredump collection. This change adds a fallback mechanism in the event of a crash. Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org> Signed-off-by: Gokul krishna Krishnakumar <quic_gokukris@quicinc.com> Link: https://lore.kernel.org/r/20230224211707.30916-3-quic_gokukris@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15remoteproc: core: Export the rproc coredump APIsSiddharth Gupta2-4/+2
The remoteproc coredump APIs are currently only part of the internal remoteproc header. This prevents the remoteproc platform drivers from using these APIs when needed. This change moves the rproc_coredump() and rproc_coredump_cleanup() APIs to the linux header and marks them as exported symbols. Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org> Signed-off-by: Gokul krishna Krishnakumar <quic_gokukris@quicinc.com> Link: https://lore.kernel.org/r/20230224211707.30916-2-quic_gokukris@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15remoteproc: qcom: Use of_reserved_mem_lookup()Stephan Gerhold4-62/+69
Reserved memory can be either looked up using the generic function of_address_to_resource() or using the special of_reserved_mem_lookup(). The latter has the advantage that it ensures that the referenced memory region was really reserved and is not e.g. status = "disabled". of_reserved_mem also supports allocating reserved memory dynamically at boot time. This works only when using of_reserved_mem_lookup() since there won't be a fixed address in the device tree. Switch the code to use of_reserved_mem_lookup(), similar to qcom_q6v5_wcss.c which is using it already. There is no functional difference for static reserved memory allocations. While at it this also adds two missing of_node_put() calls in qcom_q6v5_pas.c. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Tested-by: Caleb Connolly <caleb.connolly@linaro.org> # SDM845 Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Link: https://lore.kernel.org/r/20230710-rproc-of-rmem-v3-1-eea7f0a33590@gerhold.net Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15remoteproc: imx_rproc: iterate all notifiyids in rx callbackPeng Fan1-2/+11
The current code only supports one vdev and a single callback, but there are cases need more vdevs. So iterate all notifyids to support more vdevs with the single callback. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20230629093327.3376308-1-peng.fan@oss.nxp.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15remoteproc: Explicitly include correct DT includesRob Herring16-17/+20
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230714174935.4063513-1-robh@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-03Merge tag 'rproc-v6.5' of ↵Linus Torvalds18-100/+97
git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux Pull remoteproc updates from Bjorn Andersson: "The bulk of these patches relates to the moving to a void-returning remove callback. The i.MX HiFi remoteproc driver gets its pm_ops helpers updated to resolve build warnings about 'defined but not used' variables in certain configurations. The ST STM32 remoteproc driver is extended to allow using a SCMI reset controller to hold boot, and has an error message corrected. The Qualcomm Q6V5 PAS driver gains a missing 'static' qualifier on adsp_segment_dump()" * tag 'rproc-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: (23 commits) remoteproc: qcom_q6v5_pas: staticize adsp_segment_dump() remoteproc: stm32: Fix error code in stm32_rproc_parse_dt() remoteproc: stm32: Allow hold boot management by the SCMI reset controller dt-bindings: remoteproc: st,stm32-rproc: Rework reset declarations remoteproc: imx_dsp_rproc: use modern pm_ops remoteproc: wkup_m3: Convert to platform remove callback returning void remoteproc: stm32: Convert to platform remove callback returning void remoteproc: st: Convert to platform remove callback returning void remoteproc: virtio: Convert to platform remove callback returning void remoteproc: rcar: Convert to platform remove callback returning void remoteproc: qcom_wcnss: Convert to platform remove callback returning void remoteproc: qcom_q6v5_wcss: Convert to platform remove callback returning void remoteproc: qcom_q6v5_pas: Convert to platform remove callback returning void remoteproc: qcom_q6v5_mss: Convert to platform remove callback returning void remoteproc: qcom_q6v5_adsp: Convert to platform remove callback returning void remoteproc: pru: Convert to platform remove callback returning void remoteproc: omap: Convert to platform remove callback returning void remoteproc: mtk_scp: Convert to platform remove callback returning void remoteproc: meson_mx_ao_arc: Convert to platform remove callback returning void remoteproc: keystone: Convert to platform remove callback returning void ...
2023-06-29Merge tag 'soc-drivers-6.5' of ↵Linus Torvalds1-15/+0
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC driver updates from Arnd Bergmann: "Nothing surprising in the SoC specific drivers, with the usual updates: - Added or improved SoC driver support for Tegra234, Exynos4121, RK3588, as well as multiple Mediatek and Qualcomm chips - SCMI firmware gains support for multiple SMC/HVC transport and version 3.2 of the protocol - Cleanups amd minor changes for the reset controller, memory controller, firmware and sram drivers - Minor changes to amd/xilinx, samsung, tegra, nxp, ti, qualcomm, amlogic and renesas SoC specific drivers" * tag 'soc-drivers-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (118 commits) dt-bindings: interrupt-controller: Convert Amlogic Meson GPIO interrupt controller binding MAINTAINERS: add PHY-related files to Amlogic SoC file list drivers: meson: secure-pwrc: always enable DMA domain tee: optee: Use kmemdup() to replace kmalloc + memcpy soc: qcom: geni-se: Do not bother about enable/disable of interrupts in secondary sequencer dt-bindings: sram: qcom,imem: document qdu1000 soc: qcom: icc-bwmon: Fix MSM8998 count unit dt-bindings: soc: qcom,rpmh-rsc: Require power-domains soc: qcom: socinfo: Add Soc ID for IPQ5300 dt-bindings: arm: qcom,ids: add SoC ID for IPQ5300 soc: qcom: Fix a IS_ERR() vs NULL bug in probe soc: qcom: socinfo: Add support for new fields in revision 19 soc: qcom: socinfo: Add support for new fields in revision 18 dt-bindings: firmware: scm: Add compatible for SDX75 soc: qcom: mdt_loader: Fix split image detection dt-bindings: memory-controllers: drop unneeded quotes soc: rockchip: dtpm: use C99 array init syntax firmware: tegra: bpmp: Add support for DRAM MRQ GSCs soc/tegra: pmc: Use devm_clk_notifier_register() soc/tegra: pmc: Simplify debugfs initialization ...
2023-06-22remoteproc: stm32: use correct format strings on 64-bitArnd Bergmann2-4/+4
With CONFIG_ARCH_STM32 making it into arch/arm64, a couple of format strings no longer work, since they rely on size_t being compatible with %x, or they print an 'int' using %z: drivers/remoteproc/stm32_rproc.c: In function 'stm32_rproc_mem_alloc': drivers/remoteproc/stm32_rproc.c:122:22: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'size_t' {aka 'long unsigned int'} [-Werror=format=] drivers/remoteproc/stm32_rproc.c:122:40: note: format string is defined here 122 | dev_dbg(dev, "map memory: %pa+%x\n", &mem->dma, mem->len); | ~^ | | | unsigned int | %lx drivers/remoteproc/stm32_rproc.c:125:30: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'size_t' {aka 'long unsigned int'} [-Werror=format=] drivers/remoteproc/stm32_rproc.c:125:65: note: format string is defined here 125 | dev_err(dev, "Unable to map memory region: %pa+%x\n", | ~^ | | | unsigned int | %lx drivers/remoteproc/stm32_rproc.c: In function 'stm32_rproc_get_loaded_rsc_table': drivers/remoteproc/stm32_rproc.c:646:30: error: format '%zx' expects argument of type 'size_t', but argument 4 has type 'int' [-Werror=format=] drivers/remoteproc/stm32_rproc.c:646:66: note: format string is defined here 646 | dev_err(dev, "Unable to map memory region: %pa+%zx\n", | ~~^ | | | long unsigned int | %x Fix up all three instances to work across architectures, and enable compile testing for this driver to ensure it builds everywhere. Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-06-14remoteproc: qcom_q6v5_pas: staticize adsp_segment_dump()Krzysztof Kozlowski1-1/+1
adsp_segment_dump() is not used outside of this unit, so add missing static to fix: drivers/remoteproc/qcom_q6v5_pas.c:108:6: warning: no previous prototype for ‘adsp_segment_dump’ [-Wmissing-prototypes] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230507144826.193067-1-krzysztof.kozlowski@linaro.org
2023-05-23remoteproc: stm32: Fix error code in stm32_rproc_parse_dt()Dan Carpenter1-1/+1
There is a cut and paste bug so this code was returning the wrong variable. It should have been "ddata->hold_boot_rst" instead of "ddata->rst". Fixes: de598695a2ad ("remoteproc: stm32: Allow hold boot management by the SCMI reset controller") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/6f457246-6446-42cb-81ae-d37221d726b1@kili.mountain Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-17soc: ti: pruss: Add helper functions to set GPI mode, MII_RT_event and XFRSuman Anna1-15/+0
The PRUSS CFG module is represented as a syscon node and is currently managed by the PRUSS platform driver. Add easy accessor functions to set GPI mode, MII_RT event enable/disable and XFR (XIN XOUT) enable/disable to enable the PRUSS Ethernet usecase. These functions reuse the generic pruss_cfg_update() API function. 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> Signed-off-by: Puranjay Mohan <p-mohan@ti.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Reviewed-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Link: https://lore.kernel.org/r/20230414045542.3249939-5-danishanwar@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2023-05-15remoteproc: stm32: Allow hold boot management by the SCMI reset controllerArnaud Pouliquen1-21/+55
The hold boot can be managed by the SCMI controller as a reset. If the "hold_boot" reset is defined in the device tree, use it. Else use the syscon controller directly to access to the register. The support of the SMC call is deprecated but kept for legacy support. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20230512093926.661509-3-arnaud.pouliquen@foss.st.com
2023-05-09remoteproc: imx_dsp_rproc: use modern pm_opsArnd Bergmann1-6/+5
Without CONFIG_PM, the driver warns about unused functions: drivers/remoteproc/imx_dsp_rproc.c:1210:12: error: 'imx_dsp_runtime_suspend' defined but not used [-Werror=unused-function] 1210 | static int imx_dsp_runtime_suspend(struct device *dev) | ^~~~~~~~~~~~~~~~~~~~~~~ drivers/remoteproc/imx_dsp_rproc.c:1178:12: error: 'imx_dsp_runtime_resume' defined but not used [-Werror=unused-function] 1178 | static int imx_dsp_runtime_resume(struct device *dev) | ^~~~~~~~~~~~~~~~~~~~~~ Change the old SET_SYSTEM_SLEEP_PM_OPS()/SET_RUNTIME_PM_OPS() helpers to their modern replacements that avoid the warning, and remove the now unnecessary __maybe_unused annotations on the other PM helper functions. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Link: https://lore.kernel.org/r/20230420213610.2219080-1-arnd@kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: wkup_m3: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230504194453.1150368-19-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: stm32: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20230504194453.1150368-18-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: st: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Link: https://lore.kernel.org/r/20230504194453.1150368-17-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: virtio: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230504194453.1150368-16-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: rcar: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230504194453.1150368-15-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: qcom_wcnss: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Link: https://lore.kernel.org/r/20230504194453.1150368-14-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: qcom_q6v5_wcss: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Link: https://lore.kernel.org/r/20230504194453.1150368-13-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: qcom_q6v5_pas: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Link: https://lore.kernel.org/r/20230504194453.1150368-12-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: qcom_q6v5_mss: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Link: https://lore.kernel.org/r/20230504194453.1150368-11-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: qcom_q6v5_adsp: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Link: https://lore.kernel.org/r/20230504194453.1150368-10-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: pru: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230504194453.1150368-9-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: omap: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230504194453.1150368-8-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: mtk_scp: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20230504194453.1150368-7-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: meson_mx_ao_arc: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20230504194453.1150368-6-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: keystone: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230504194453.1150368-5-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: imx: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Link: https://lore.kernel.org/r/20230504194453.1150368-4-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: imx_dsp: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Link: https://lore.kernel.org/r/20230504194453.1150368-3-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-05-09remoteproc: da8xx: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230504194453.1150368-2-u.kleine-koenig@pengutronix.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-04-27Merge tag 'mm-nonmm-stable-2023-04-27-16-01' of ↵Linus Torvalds2-4/+4
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull non-MM updates from Andrew Morton: "Mainly singleton patches all over the place. Series of note are: - updates to scripts/gdb from Glenn Washburn - kexec cleanups from Bjorn Helgaas" * tag 'mm-nonmm-stable-2023-04-27-16-01' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (50 commits) mailmap: add entries for Paul Mackerras libgcc: add forward declarations for generic library routines mailmap: add entry for Oleksandr ocfs2: reduce ioctl stack usage fs/proc: add Kthread flag to /proc/$pid/status ia64: fix an addr to taddr in huge_pte_offset() checkpatch: introduce proper bindings license check epoll: rename global epmutex scripts/gdb: add GDB convenience functions $lx_dentry_name() and $lx_i_dentry() scripts/gdb: create linux/vfs.py for VFS related GDB helpers uapi/linux/const.h: prefer ISO-friendly __typeof__ delayacct: track delays from IRQ/SOFTIRQ scripts/gdb: timerlist: convert int chunks to str scripts/gdb: print interrupts scripts/gdb: raise error with reduced debugging information scripts/gdb: add a Radix Tree Parser lib/rbtree: use '+' instead of '|' for setting color. proc/stat: remove arch_idle_time() checkpatch: check for misuse of the link tags checkpatch: allow Closes tags with links ...
2023-04-27Merge tag 'modules-6.4-rc1' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux Pull module updates from Luis Chamberlain: "The summary of the changes for this pull requests is: - Song Liu's new struct module_memory replacement - Nick Alcock's MODULE_LICENSE() removal for non-modules - My cleanups and enhancements to reduce the areas where we vmalloc module memory for duplicates, and the respective debug code which proves the remaining vmalloc pressure comes from userspace. Most of the changes have been in linux-next for quite some time except the minor fixes I made to check if a module was already loaded prior to allocating the final module memory with vmalloc and the respective debug code it introduces to help clarify the issue. Although the functional change is small it is rather safe as it can only *help* reduce vmalloc space for duplicates and is confirmed to fix a bootup issue with over 400 CPUs with KASAN enabled. I don't expect stable kernels to pick up that fix as the cleanups would have also had to have been picked up. Folks on larger CPU systems with modules will want to just upgrade if vmalloc space has been an issue on bootup. Given the size of this request, here's some more elaborate details: The functional change change in this pull request is the very first patch from Song Liu which replaces the 'struct module_layout' with a new 'struct module_memory'. The old data structure tried to put together all types of supported module memory types in one data structure, the new one abstracts the differences in memory types in a module to allow each one to provide their own set of details. This paves the way in the future so we can deal with them in a cleaner way. If you look at changes they also provide a nice cleanup of how we handle these different memory areas in a module. This change has been in linux-next since before the merge window opened for v6.3 so to provide more than a full kernel cycle of testing. It's a good thing as quite a bit of fixes have been found for it. Jason Baron then made dynamic debug a first class citizen module user by using module notifier callbacks to allocate / remove module specific dynamic debug information. Nick Alcock has done quite a bit of work cross-tree to remove module license tags from things which cannot possibly be module at my request so to: a) help him with his longer term tooling goals which require a deterministic evaluation if a piece a symbol code could ever be part of a module or not. But quite recently it is has been made clear that tooling is not the only one that would benefit. Disambiguating symbols also helps efforts such as live patching, kprobes and BPF, but for other reasons and R&D on this area is active with no clear solution in sight. b) help us inch closer to the now generally accepted long term goal of automating all the MODULE_LICENSE() tags from SPDX license tags In so far as a) is concerned, although module license tags are a no-op for non-modules, tools which would want create a mapping of possible modules can only rely on the module license tag after the commit 8b41fc4454e ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"). Nick has been working on this *for years* and AFAICT I was the only one to suggest two alternatives to this approach for tooling. The complexity in one of my suggested approaches lies in that we'd need a possible-obj-m and a could-be-module which would check if the object being built is part of any kconfig build which could ever lead to it being part of a module, and if so define a new define -DPOSSIBLE_MODULE [0]. A more obvious yet theoretical approach I've suggested would be to have a tristate in kconfig imply the same new -DPOSSIBLE_MODULE as well but that means getting kconfig symbol names mapping to modules always, and I don't think that's the case today. I am not aware of Nick or anyone exploring either of these options. Quite recently Josh Poimboeuf has pointed out that live patching, kprobes and BPF would benefit from resolving some part of the disambiguation as well but for other reasons. The function granularity KASLR (fgkaslr) patches were mentioned but Joe Lawrence has clarified this effort has been dropped with no clear solution in sight [1]. In the meantime removing module license tags from code which could never be modules is welcomed for both objectives mentioned above. Some developers have also welcomed these changes as it has helped clarify when a module was never possible and they forgot to clean this up, and so you'll see quite a bit of Nick's patches in other pull requests for this merge window. I just picked up the stragglers after rc3. LWN has good coverage on the motivation behind this work [2] and the typical cross-tree issues he ran into along the way. The only concrete blocker issue he ran into was that we should not remove the MODULE_LICENSE() tags from files which have no SPDX tags yet, even if they can never be modules. Nick ended up giving up on his efforts due to having to do this vetting and backlash he ran into from folks who really did *not understand* the core of the issue nor were providing any alternative / guidance. I've gone through his changes and dropped the patches which dropped the module license tags where an SPDX license tag was missing, it only consisted of 11 drivers. To see if a pull request deals with a file which lacks SPDX tags you can just use: ./scripts/spdxcheck.py -f \ $(git diff --name-only commid-id | xargs echo) You'll see a core module file in this pull request for the above, but that's not related to his changes. WE just need to add the SPDX license tag for the kernel/module/kmod.c file in the future but it demonstrates the effectiveness of the script. Most of Nick's changes were spread out through different trees, and I just picked up the slack after rc3 for the last kernel was out. Those changes have been in linux-next for over two weeks. The cleanups, debug code I added and final fix I added for modules were motivated by David Hildenbrand's report of boot failing on a systems with over 400 CPUs when KASAN was enabled due to running out of virtual memory space. Although the functional change only consists of 3 lines in the patch "module: avoid allocation if module is already present and ready", proving that this was the best we can do on the modules side took quite a bit of effort and new debug code. The initial cleanups I did on the modules side of things has been in linux-next since around rc3 of the last kernel, the actual final fix for and debug code however have only been in linux-next for about a week or so but I think it is worth getting that code in for this merge window as it does help fix / prove / evaluate the issues reported with larger number of CPUs. Userspace is not yet fixed as it is taking a bit of time for folks to understand the crux of the issue and find a proper resolution. Worst come to worst, I have a kludge-of-concept [3] of how to make kernel_read*() calls for modules unique / converge them, but I'm currently inclined to just see if userspace can fix this instead" Link: https://lore.kernel.org/all/Y/kXDqW+7d71C4wz@bombadil.infradead.org/ [0] Link: https://lkml.kernel.org/r/025f2151-ce7c-5630-9b90-98742c97ac65@redhat.com [1] Link: https://lwn.net/Articles/927569/ [2] Link: https://lkml.kernel.org/r/20230414052840.1994456-3-mcgrof@kernel.org [3] * tag 'modules-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux: (121 commits) module: add debugging auto-load duplicate module support module: stats: fix invalid_mod_bytes typo module: remove use of uninitialized variable len module: fix building stats for 32-bit targets module: stats: include uapi/linux/module.h module: avoid allocation if module is already present and ready module: add debug stats to help identify memory pressure module: extract patient module check into helper modules/kmod: replace implementation with a semaphore Change DEFINE_SEMAPHORE() to take a number argument module: fix kmemleak annotations for non init ELF sections module: Ignore L0 and rename is_arm_mapping_symbol() module: Move is_arm_mapping_symbol() to module_symbol.h module: Sync code of is_arm_mapping_symbol() scripts/gdb: use mem instead of core_layout to get the module address interconnect: remove module-related code interconnect: remove MODULE_LICENSE in non-modules zswap: remove MODULE_LICENSE in non-modules zpool: remove MODULE_LICENSE in non-modules x86/mm/dump_pagetables: remove MODULE_LICENSE in non-modules ...
2023-04-25Merge tag 'rproc-v6.4' of ↵Linus Torvalds15-184/+626
git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux Pull remoteproc updates from Bjorn Andersson: - Unnecessary type casts from the 'void *' rproc->priv pointer are dropped throughout the subsystem. - A kernel-doc error is corrected in the Mediatek SCPI IPI implementation - The firmware loading onto the IMX DSP remote processors is reworked to avoid non-32bit memory operations. A module parameter is introduced to assist development of firmware without communication abilities in place. Error paths in imx_dsp_rproc_mbox_alloc() is cleaned up - The cluster configuration handling in the TI K3 R5 driver is corrected and support for the single-R5 core found in the TI AM62x SoC family is introduced - The TI PRU driver device- to virtual-address translation is updated to avoid compiler warning about the unsigned device-address always being larger than 0 - The ST remoteproc driver is transitioned to use of_property_present() - Issues with kicks arriving after the STM32 remote processor has been shut down are mitigated by checking the processor's state before handling them. - Support for mailbox channels for communication with the remote processors are added to the Xilinx R5 remoteproc driver. The naming of carveouts are corrected and their parsing is reworked. For this a couple of fixes targeting the mailbox subsystem are picked up here as well. - Reference counting of of_nodes are corrected in the ST, STM32, RCAR and IMX remoteproc drivers * tag 'rproc-v6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: (24 commits) remoteproc: st: Use of_property_present() for testing DT property presence dt-bindings: remoteproc: Drop unneeded quotes remoteproc: imx_dsp_rproc: Fix kernel test robot sparse warning remoteproc: imx_dsp_rproc: Improve exception handling in imx_dsp_rproc_mbox_alloc() remoteproc: pru: Remove always true check positive unsigned value dt-bindings: remoteproc: stm32-rproc: Typo fix remoteproc: stm32_rproc: Add mutex protection for workqueue remoteproc: Remove unnecessary (void*) conversions remoteproc: imx_dsp_rproc: Call of_node_put() on iteration error remoteproc: imx_rproc: Call of_node_put() on iteration error remoteproc: rcar_rproc: Call of_node_put() on iteration error remoteproc: st: Call of_node_put() on iteration error remoteproc: stm32: Call of_node_put() on iteration error remoteproc: k3-r5: Use separate compatible string for TI AM62x SoC family dt-bindings: remoteproc: ti: Add new compatible for AM62 SoC family remoteproc: k3-r5: Simplify cluster mode setting usage remoteproc/mtk_scpi_ipi: Fix one kernel-doc comment remoteproc: xilinx: Add mailbox channels for rpmsg drivers: remoteproc: xilinx: Fix carveout names mailbox: zynqmp: Fix typo in IPI documentation ...
2023-04-18remoteproc: st: Use of_property_present() for testing DT property presenceRob Herring1-1/+1
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230310144736.1546972-1-robh@kernel.org
2023-04-13remoteproc: remove MODULE_LICENSE in non-modulesNick Alcock1-1/+0
Since commit 8b41fc4454e ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations are used to identify modules. As a consequence, uses of the macro in non-modules will cause modprobe to misidentify their containing object file as a module when it is not (false positives), and modprobe might succeed rather than failing with a suitable error message. So remove it in the files in this commit, none of which can be built as modules. Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Suggested-by: Luis Chamberlain <mcgrof@kernel.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Acked-by: Mukesh Ojha <quic_mojha@quicinc.com> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: linux-modules@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> Cc: Bjorn Andersson <andersson@kernel.org> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: linux-remoteproc@vger.kernel.org Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2023-04-11remoteproc: imx_dsp_rproc: Fix kernel test robot sparse warningMathieu Poirier1-4/+4
This patch fixes the kernel test robot warning reported here: https://lore.kernel.org/bpf/642f916b.pPIKZ%2Fl%2F%2Fbw8tvIH%25lkp@intel.com/T/ Fixes: 408ec1ff0caa ("remoteproc: imx_dsp_rproc: Add custom memory copy implementation for i.MX DSP Cores") Link: https://lore.kernel.org/r/20230407161429.3973177-1-mathieu.poirier@linaro.org Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-04-10remoteproc: imx_dsp_rproc: Improve exception handling in ↵Markus Elfring1-11/+7
imx_dsp_rproc_mbox_alloc() The label “err_out” was used to jump to another pointer check despite of the detail in the implementation of the function “imx_dsp_rproc_mbox_alloc” that it was determined already that the corresponding variable contained an error pointer because of a failed call of the function “mbox_request_channel_byname”. Thus perform the following adjustments: 1. Return directly after a call of the function “mbox_request_channel_byname” failed for the input parameter “tx”. 2. Use more appropriate labels instead. 3. Reorder jump targets at the end. 4. Omit a function call and three extra checks. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Link: https://lore.kernel.org/r/d0e18bb1-afc4-8b6f-bb1c-b74b3bad908e@web.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-04-08ELF: fix all "Elf" typosAlexey Dobriyan2-4/+4
ELF is acronym and therefore should be spelled in all caps. I left one exception at Documentation/arm/nwfpe/nwfpe.rst which looks like being written in the first person. Link: https://lkml.kernel.org/r/Y/3wGWQviIOkyLJW@p183 Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-04-05remoteproc: pru: Remove always true check positive unsigned valueSimon Horman1-3/+2
In both cases the type of da is u32. And PRU_PDRAM_DA is 0. So the check da >= PRU_PDRAM_DA is always true and can be removed. Flagged by Smatch: drivers/remoteproc/pru_rproc.c:660 pru_d_da_to_va() warn: always true condition '(da >= 0) => (0-u32max >= 0)' drivers/remoteproc/pru_rproc.c:709 pru_i_da_to_va() warn: always true condition '(da >= 0) => (0-u32max >= 0)' No functional changes intended. Compile tested only. Reported-by: kernel test robot <lkp@intel.com> Link: https://www.spinics.net/lists/kernel/msg4025983.html Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20230404-pru-always-true-v1-1-b1b55eeff188@kernel.org [Fixed typo in changelog] Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-04-03remoteproc: stm32_rproc: Add mutex protection for workqueueArnaud Pouliquen1-0/+8
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 kernel dump. Call trace: virtqueue_add_inbuf virtqueue_add_inbuf rpmsg_recv_single rpmsg_recv_done vring_interrupt stm32_rproc_mb_vq_work process_one_work worker_thread kthread Suggested-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20230331160634.3113031-1-arnaud.pouliquen@foss.st.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-04-03remoteproc: Remove unnecessary (void*) conversionsYu Zhe7-41/+41
Pointer variables of void * type do not require type cast. Signed-off-by: Yu Zhe <yuzhe@nfschina.com> Link: https://lore.kernel.org/r/20230328024907.29791-1-yuzhe@nfschina.com [Fixed merge conflict in xlnx_r5_remoteproc.c] Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-04-03remoteproc: imx_dsp_rproc: Call of_node_put() on iteration errorMathieu Poirier1-3/+9
Function of_phandle_iterator_next() calls of_node_put() on the last device_node it iterated over, but when the loop exits prematurely it has to be called explicitly. Fixes: ec0e5549f358 ("remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MX") Cc: stable@vger.kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com> Link: https://lore.kernel.org/r/20230320221826.2728078-6-mathieu.poirier@linaro.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-04-03remoteproc: imx_rproc: Call of_node_put() on iteration errorMathieu Poirier1-2/+5
Function of_phandle_iterator_next() calls of_node_put() on the last device_node it iterated over, but when the loop exits prematurely it has to be called explicitly. Fixes: b29b4249f8f0 ("remoteproc: imx_rproc: add i.MX specific parse fw hook") Cc: stable@vger.kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20230320221826.2728078-5-mathieu.poirier@linaro.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-04-03remoteproc: rcar_rproc: Call of_node_put() on iteration errorMathieu Poirier1-2/+7
Function of_phandle_iterator_next() calls of_node_put() on the last device_node it iterated over, but when the loop exits prematurely it has to be called explicitly. Fixes: 285892a74f13 ("remoteproc: Add Renesas rcar driver") Cc: stable@vger.kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20230320221826.2728078-4-mathieu.poirier@linaro.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-04-03remoteproc: st: Call of_node_put() on iteration errorMathieu Poirier1-1/+4
Function of_phandle_iterator_next() calls of_node_put() on the last device_node it iterated over, but when the loop exits prematurely it has to be called explicitly. Fixes: 3df52ed7f269 ("remoteproc: st: add reserved memory support") Cc: stable@vger.kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20230320221826.2728078-3-mathieu.poirier@linaro.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-04-03remoteproc: stm32: Call of_node_put() on iteration errorMathieu Poirier1-1/+5
Function of_phandle_iterator_next() calls of_node_put() on the last device_node it iterated over, but when the loop exits prematurely it has to be called explicitly. Fixes: 13140de09cc2 ("remoteproc: stm32: add an ST stm32_rproc driver") Cc: stable@vger.kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20230320221826.2728078-2-mathieu.poirier@linaro.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-03-29remoteproc: k3-r5: Use separate compatible string for TI AM62x SoC familyDevarsh Thakkar1-12/+47
AM62 and AM62A SoCs use single core R5F which is a new scenario different than the one being used with CLUSTER_MODE_SINGLECPU which is for utilizing a single core from a set of cores available in R5F cluster present in the SoC. To support this single core scenario map it with newly defined CLUSTER_MODE_SINGLECORE and use it when compatible is set to ti,am62-r5fss. Also set PROC_BOOT_CFG_FLAG_R5_SINGLE_CORE config for CLUSTER_MODE_SINGLECORE too as it is required by R5 core when it is being as general purpose core instead of device manager. For IPC-only mode when config flag PROC_BOOT_CFG_FLAG_R5_SINGLE_CORE is set, skip overriding to CLUSTER_MODE_SINGLECPU when CLUSTER_MODE_SINGLECORE is set as same flag is applicable for single core configuration too. Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20230327152832.923480-4-devarsht@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-03-29remoteproc: k3-r5: Simplify cluster mode setting usageDevarsh Thakkar1-36/+40
Check the validity of mode against SoC supported modes right at the probe to minimize the usage of same check further in the code. Set default value of cluster-mode only if cluster-mode device tree property is empty. In case devicetree provided cluster-mode property is invalid For e.g. using CLUSTER_MODE_SINGLECPU on any SoC other than am64x then return error. If firmware has set the PROC_BOOT_STATUS_FLAG_R5_SINGLECORE_ONLY flag then what it means is that only CLUSTER_MODE_SINGLECPU is possible to use [1] and hence there is no need to check for soc_data->single_cpu_mode first and then checking cluster mode. PROC_BOOT_CFG_FLAG_R5_SINGLE_CORE flag can be set directly for CLUSTER_MODE_SINGLECPU without checking for soc_data->single_cpu_mode since that check has already been done during probe. For IPC-only mode, directly override cluster mode as per config flag set by bootloader without checking for soc specific data. This because config flag would already have been validated by firmware when bootloader was setting it. Link: [1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/PROC_BOOT.html?highlight=singlecore_only#arm-r5 Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20230327152832.923480-2-devarsht@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-03-16remoteproc/mtk_scpi_ipi: Fix one kernel-doc commentYang Li1-1/+1
Fix the function name in kernel-doc comments to clear the below warning: drivers/remoteproc/mtk_scp_ipi.c:136: warning: expecting prototype for scp_ipi_lock(). Prototype was for scp_ipi_unlock() instead Reported-by: Abaci Robot <abaci@linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4544 Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230316084011.99613-1-yang.lee@linux.alibaba.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-03-15firmware: qcom_scm: Use fixed width src vm bitmapElliot Berman2-5/+5
The maximum VMID for assign_mem is 63. Use a u64 to represent this bitmap instead of architecture-dependent "unsigned int" which varies in size on 32-bit and 64-bit platforms. Acked-by: Kalle Valo <kvalo@kernel.org> (ath10k) Tested-by: Gokul krishna Krishnakumar <quic_gokukris@quicinc.com> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230213181832.3489174-1-quic_eberman@quicinc.com
2023-03-14remoteproc: xilinx: Add mailbox channels for rpmsgTanmay Shah1-1/+217
This patch makes each r5 core mailbox client and uses tx and rx channels to send and receive data to/from remote processor respectively. This is needed for rpmsg communication to remote processor. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Link: https://lore.kernel.org/r/20230311012407.1292118-6-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-03-14drivers: remoteproc: xilinx: Fix carveout namesTanmay Shah1-70/+20
If the unit address is appended to node name of memory-region, then adding rproc carveouts fails as node name and unit-address both are passed as carveout name (i.e. vdev0vring0@xxxxxxxx). However, only node name is expected by remoteproc framework. This patch moves memory-region node parsing from driver probe to prepare and only passes node-name and not unit-address Fixes: 6b291e8020a8 ("drivers: remoteproc: Add Xilinx r5 remoteproc driver") Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230311012407.1292118-5-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-03-13remoteproc: imx_dsp_rproc: Add custom memory copy implementation for i.MX ↵Iuliana Prodan1-1/+186
DSP Cores The IRAM is part of the HiFi DSP. According to hardware specification only 32-bits write are allowed otherwise we get a Kernel panic. Therefore add a custom memory copy and memset functions to deal with the above restriction. Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> Link: https://lore.kernel.org/r/20230221170356.27923-1-iuliana.prodan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-03-13remoteproc: imx_dsp_rproc: Add module parameter to ignore ready flag from ↵Iuliana Prodan1-2/+30
remote processor There are cases when we want to test a simple "hello world" application on the DSP and we don't have IPC between the cores. Therefore, do not wait for a confirmation from the remote processor at start. Added "no_mailboxes" flag while inserting the module to not initialize any mailboxes, and so ignore remote processor reply after start. By default, this is off - do not ignore reply from rproc. Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20230217094124.9440-1-iuliana.prodan@oss.nxp.com [Fixed checkpatch warning] Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-02-27Merge tag 'soc-drivers-6.3' of ↵Linus Torvalds3-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC driver updates from Arnd Bergmann: "As usual, there are lots of minor driver changes across SoC platforms from NXP, Amlogic, AMD Zynq, Mediatek, Qualcomm, Apple and Samsung. These usually add support for additional chip variations in existing drivers, but also add features or bugfixes. The SCMI firmware subsystem gains a unified raw userspace interface through debugfs, which can be used for validation purposes. Newly added drivers include: - New power management drivers for StarFive JH7110, Allwinner D1 and Renesas RZ/V2M - A driver for Qualcomm battery and power supply status - A SoC device driver for identifying Nuvoton WPCM450 chips - A regulator coupler driver for Mediatek MT81xxv" * tag 'soc-drivers-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (165 commits) power: supply: Introduce Qualcomm PMIC GLINK power supply soc: apple: rtkit: Do not copy the reg state structure to the stack soc: sunxi: SUN20I_PPU should depend on PM memory: renesas-rpc-if: Remove redundant division of dummy soc: qcom: socinfo: Add IDs for IPQ5332 and its variant dt-bindings: arm: qcom,ids: Add IDs for IPQ5332 and its variant dt-bindings: power: qcom,rpmpd: add RPMH_REGULATOR_LEVEL_LOW_SVS_L1 firmware: qcom_scm: Move qcom_scm.h to include/linux/firmware/qcom/ MAINTAINERS: Update qcom CPR maintainer entry dt-bindings: firmware: document Qualcomm SM8550 SCM dt-bindings: firmware: qcom,scm: add qcom,scm-sa8775p compatible soc: qcom: socinfo: Add Soc IDs for IPQ8064 and variants dt-bindings: arm: qcom,ids: Add Soc IDs for IPQ8064 and variants soc: qcom: socinfo: Add support for new field in revision 17 soc: qcom: smd-rpm: Add IPQ9574 compatible soc: qcom: pmic_glink: remove redundant calculation of svid soc: qcom: stats: Populate all subsystem debugfs files dt-bindings: soc: qcom,rpmh-rsc: Update to allow for generic nodes soc: qcom: pmic_glink: add CONFIG_NET/CONFIG_OF dependencies soc: qcom: pmic_glink: Introduce altmode support ...
2023-02-26Merge tag 'rproc-v6.3' of ↵Linus Torvalds13-154/+887
git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux Pull remoteproc updates from Bjorn Andersson: - Support for PRU clients to acquire a control reference to the PRU instances is introduced, and the PRU now allows specifying firmware-name in Devicetree. sysfs is requested to be read-only when the remoteproc instance is consumed by another kernel driver - Support for the C7xv DSP on AM62A SoC is introduced - The Devicetree binding for the Qualcomm PAS devices are split up in multiple files, to better account for the differences in resources between them. A number of missing Devicetree bindings are added, and the Qualcomm WCNSS binding is converted to YAML - A few cleanups are introduced for the Mediatek SCP driver. And a sanity check of the firmware image is introduced in the Mediatek driver - For Qualcomm SC7280 ADSP support is added, MSM8953 gains ADSP and modem support, SM6115 and SM8550 gains ADSP, CDSP and modem support, and support for pronto v3 support (used on e.g. MSM8953) is added - The Qualcomm modem remoteproc driver is modified to use a no-map reserved-memory region for it's authentication metadata, in order to avoid fatal security violations caused by accesses from Linux during the authentication process - Support for separate loading of a Devicetree blob is added to the PAS driver, and support for the PAS driver to carve out DSM memory for the modem is added as well - The Qualcomm ADSP remoteproc driver gains support for mapping memory into specific range using the IOMMU. The sysmon driver is transitioned to strlcpy() * tag 'rproc-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: (69 commits) dt-bindings: mailbox: qcom,apcs-kpss-global: drop mbox-names from example dt-bindings: remoteproc: qcom,glink-edge: correct label description dt-bindings: remoteproc: qcom,glink-rpm-edge: convert to DT schema dt-bindings: remoteproc: qcom,sm8550-pas: correct power domains remoteproc: qcom_q6v5_pas: enable sm8550 adsp & cdsp autoboot dt-bindings: remoteproc: qcom: Add sm6115 pas yaml file remoteproc: qcom: pas: Add sm6115 remoteprocs remoteproc: qcom: pas: Adjust the phys addr wrt the mem region remoteproc: qcom: fix sparse warnings remoteproc: qcom: replace kstrdup with kstrndup remoteproc: mediatek: Check the SCP image format remoteproc: qcom_q6v5_mss: Use a carveout to authenticate modem headers Revert "remoteproc: qcom_q6v5_mss: map/unmap metadata region before/after use" dt-bindings: remoteproc: qcom,sc7280-mss-pil: Update memory-region dt-bindings: remoteproc: qcom,sc7180-mss-pil: Update memory-region dt-bindings: remoteproc: qcom,msm8996-mss-pil: Update memory region dt-bindings: remoteproc: qcom,q6v5: Move MSM8996 to schema remoteproc: qcom_q6v5_pas: add sm8550 adsp, cdsp & mpss compatible & data remoteproc: qcom_q6v5_pas: add support for assigning memory to firmware remoteproc: qcom_q6v5_pas: add support for dtb co-firmware loading ...
2023-02-26Merge tag 'rpmsg-v6.3' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux Pull rpmsg updates from Bjorn Andersson: - rpmsg ctrl and char driver locking is ensure ordering in cases where the communication link is being torn down in parallel with calls to open(2) or poll(2) - The glink driver is refactored, to move rpm/smem-specifics out of the common logic and better suite further improvements, such as transports without a mailbox controller. The handling of remoteproc shutdown is improved, to fail clients immediately instead of having them to wait for timeouts. A driver_override memory leak is corrected and a few spelling improvements are introduced - glink_ssr is transitioned off strlcpy() and "gpr" is added as a valid child node of the glink-edge DT binding * tag 'rpmsg-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: rpmsg: glink: Release driver_override rpmsg: glink: Avoid infinite loop on intent for missing channel rpmsg: glink: Fix GLINK command prefix rpmsg: glink: Fix spelling of peek rpmsg: glink: Cancel pending intent requests at removal rpmsg: glink: Fail qcom_glink_tx() once remove has been initiated rpmsg: glink: Move irq and mbox handling to transports rpmsg: glink: rpm: Wrap driver context rpmsg: glink: smem: Wrap driver context rpmsg: glink: Extract tx kick operation rpmsg: glink: Include types in qcom_glink_native.h rpmsg: ctrl: Add lock to rpmsg_ctrldev_remove rpmsg: char: Add lock to avoid race when rpmsg device is released rpmsg: move from strlcpy with unused retval to strscpy dt-bindings: remoteproc: qcom,glink-edge: add GPR node
2023-02-14remoteproc: qcom_q6v5_pas: enable sm8550 adsp & cdsp autobootNeil Armstrong1-2/+2
Set the SM8550 adsp & cdsp auto_boot to true to match the behavior of the previous platforms. Fixes: 7eddedc97563 ("remoteproc: qcom_q6v5_pas: add sm8550 adsp, cdsp & mpss compatible & data") Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230206-topic-sm8550-upstream-fix-remoteproc-autoboot-v1-1-11445a0c27c6@linaro.org
2023-02-14remoteproc: qcom: pas: Add sm6115 remoteprocsBhupesh Sharma1-0/+3
Among the subsystems in the Qualcomm sm6115 platform we find audio, compute and modem DSPs. Add support for controlling these using the peripheral authentication service (PAS) remoteproc driver. Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230128053504.2099620-1-bhupesh.sharma@linaro.org
2023-02-14remoteproc: qcom: pas: Adjust the phys addr wrt the mem regionYogesh Lal3-6/+32
The minidump table in the toc contains physical addresses that may lie before the physical address of the first elf segment in relocatable images. This change adds a custom dump function for minidumps which calculates the offset into the carveout region using the start of the physical address instead of the start of the first elf segment. Signed-off-by: Yogesh Lal <quic_ylal@quicinc.com> Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/1667409129-6254-1-git-send-email-quic_ylal@quicinc.com
2023-02-14remoteproc: qcom: fix sparse warningsMukesh Ojha1-2/+2
This patch try to address below sparse warnings. drivers/remoteproc/qcom_common.c:126:27: warning: restricted __le32 degrades to integer drivers/remoteproc/qcom_common.c:133:32: warning: cast to restricted __le32 drivers/remoteproc/qcom_common.c:133:32: warning: cast from restricted __le64 Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/1675180866-16695-1-git-send-email-quic_mojha@quicinc.com
2023-02-14remoteproc: qcom: replace kstrdup with kstrndupMukesh Ojha1-1/+1
Since, there is no guarantee that region.name will be 0-terminated from the firmware side, replace kstrdup with kstrndup. Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/1676383691-29738-1-git-send-email-quic_mojha@quicinc.com
2023-02-14rpmsg: glink: smem: Wrap driver contextBjorn Andersson1-1/+2
The Glink SMEM driver allocates a struct device and hangs two devres-allocated pipe objects thereon. To facilitate the move of interrupt and mailbox handling to the driver, introduce a wrapper object capturing the device, glink reference and remote processor id. The type of the remoteproc reference is updated, as these are specifically targeting the SMEM implementation. Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Chris Lew <quic_clew@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230213155215.1237059-3-quic_bjorande@quicinc.com
2023-02-12remoteproc: mediatek: Check the SCP image formatTinghan Shen1-0/+1
Do a sanity check on the SCP image before loading it to avoid driver crashes. Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230210031354.1335-1-tinghan.shen@mediatek.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2023-02-08firmware: qcom_scm: Move qcom_scm.h to include/linux/firmware/qcom/Elliot Berman3-3/+3
Move include/linux/qcom_scm.h to include/linux/firmware/qcom/qcom_scm.h. This removes 1 of a few remaining Qualcomm-specific headers into a more approciate subdirectory under include/. Suggested-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Acked-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230203210956.3580811-1-quic_eberman@quicinc.com
2023-01-25iommu: Add a gfp parameter to iommu_map()Jason Gunthorpe1-2/+3
The internal mechanisms support this, but instead of exposting the gfp to the caller it wrappers it into iommu_map() and iommu_map_atomic() Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/1-v3-76b587fe28df+6e3-iommu_map_gfp_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-01-18remoteproc: qcom_q6v5_mss: Use a carveout to authenticate modem headersSibi Sankar1-6/+53
Any access to the dynamically allocated metadata region by the application processor after assigning it to the remote Q6 will result in a XPU violation. Fix this by replacing the dynamically allocated memory region with a no-map carveout and unmap the modem metadata memory region before passing control to the remote Q6. Reported-and-tested-by: Amit Pundir <amit.pundir@linaro.org> Fixes: 6c5a9dc2481b ("remoteproc: qcom: Make secure world call for mem ownership switch") Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230117085840.32356-7-quic_sibis@quicinc.com
2023-01-18Revert "remoteproc: qcom_q6v5_mss: map/unmap metadata region before/after use"Christoph Hellwig1-32/+6
This reverts commit fc156629b23a21181e473e60341e3a78af25a1d4. This commit manages to do three API violations at once: - dereference the return value of dma_alloc_attrs with the DMA_ATTR_NO_KERNEL_MAPPING mapping, which is clearly forbidden and will do the wrong thing on various dma mapping implementations. The fact that dma-direct uses a struct page as a cookie is an undocumented implementation detail - include dma-map-ops.h and use pgprot_dmacoherent despite a clear comment documenting that this is not acceptable - use of the VM_DMA_COHERENT for something that is not the dma-mapping code - use of VM_FLUSH_RESET_PERMS for vmap, while it is only supported for vmalloc Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230117085840.32356-6-quic_sibis@quicinc.com
2023-01-18remoteproc: qcom_q6v5_pas: add sm8550 adsp, cdsp & mpss compatible & dataNeil Armstrong1-0/+63
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 Armstrong1-0/+71
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 Armstrong1-13/+121
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 Luthra1-0/+12
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 Kristo1-0/+34
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 Quadros1-0/+59
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 Anna1-0/+2
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 Anwar1-2/+126
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 Anwar1-3/+4
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 Regno1-3/+1
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 Regno1-8/+11
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 Tsai1-6/+5
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 Ojha1-1/+1
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 Kodali1-0/+1
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 Mandadapu1-1/+55
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 Mandadapu1-0/+17
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 Mandadapu1-2/+5
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 Mandadapu1-1/+22
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 Mandadapu1-0/+16
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 Mandadapu1-0/+5
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 Krishnakumar1-2/+2
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 Cui1-2/+0
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 Sang1-1/+1
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 Vesa1-35/+7
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 Lypak1-0/+12
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 Kodali1-2/+53
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 Gerhold1-33/+90
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 Yu1-1/+8
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 XiaoJing1-1/+2
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 Can1-0/+1
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 Weiss1-0/+1
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 Weiss1-0/+2
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 XiaoJing1-0/+3
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 Cui1-1/+4
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 Johnson1-4/+4
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 Shah3-0/+1081
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 xingchen1-1/+1
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 Fan1-2/+2
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 Fan1-1/+2
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 Fan1-2/+46
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 Fan1-3/+44
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 Fan1-3/+93
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 Fan1-1/+107
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 Wang1-3/+9
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 Wang1-1/+7
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 Pouliquen1-7/+1
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 Fan1-19/+43
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 Fan1-0/+15
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 Pouliquen3-77/+80
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 Pouliquen3-160/+161
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>