- 14 Feb, 2023 2 commits
-
-
Mukesh Ojha authored
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
-
Mukesh Ojha authored
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:
-
- 12 Feb, 2023 1 commit
-
-
Tinghan Shen authored
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.comSigned-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org>
-
- 19 Jan, 2023 6 commits
-
-
Sibi Sankar authored
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: 6c5a9dc2 ("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:
-
Christoph Hellwig authored
This reverts commit fc156629. 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:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Sibi Sankar authored
The dynamic memory region used for metadata authentication would still be a part of the kernel mapping and any access to this region by the application processor after assigning it to the remote Q6 will result in a XPU violation. This is fixed by using a no-map carveout instead. Update the bindings to reflect the addition of the new modem metadata carveout on SC7280 SoC. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Sibi Sankar authored
The dynamic memory region used for metadata authentication would still be a part of the kernel mapping and any access to this region by the application processor after assigning it to the remote Q6 will result in a XPU violation. This is fixed by using a no-map carveout instead. Update the bindings to reflect the addition of the new modem metadata carveout on SC7180 SoC. Reviewed-by:
-
Sibi Sankar authored
The dynamic memory region used for metadata authentication would still be a part of the kernel mapping and any access to this region by the application processor after assigning it to the remote Q6 will result in a XPU violation. This is fixed by using a no-map carveout instead. Update the bindings to reflect the addition of the new modem metadata carveout on MSM8996 (and similar) SoCs. Reviewed-by:
-
Sibi Sankar authored
Convert MSM8996 and similar (MSM8998/SDM845) MSS PIL bindings to schema. Reviewed-by:
-
- 18 Jan, 2023 5 commits
-
-
Neil Armstrong authored
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:
-
Neil Armstrong authored
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 authored
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 authored
This documents the compatible for the component used to boot the aDSP, cDSP and MPSS on the SM8550 SoC. The SM8550 boot process on SM8550 now requires a secondary "Devicetree" firmware to be passed along the main Firmware, and the cDSP a new power domain named "NSP". A third memory domain for the DSM memory zone is also needed for the MPSS PAS bindings. Reviewed-by:
-
Neil Armstrong authored
Move memory-region and firmware-name definitions out of qcom,pas-common.yaml since they will be redefined differently for SM8550 PAS bindings documentation. Reviewed-by:
-
- 13 Jan, 2023 2 commits
-
-
Jai Luthra authored
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.comSigned-off-by:
-
Hari Nagalla authored
The TI AM62A SoCs have a C7xv DSP and Analytics engine for deep learning purposes. The DSP part is similar to the C71x DSP found on K3 J7 SoCs, but additional hardware accelerators and IP are added to the subsystem for deep learning. Compatible info is updated to match AM62A SoCs. Signed-off-by:
-
- 06 Jan, 2023 6 commits
-
-
Tero Kristo authored
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.comSigned-off-by:
-
Roger Quadros authored
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:
Roger Quadros <rogerq@ti.com> Signed-off-by:
-
Suman Anna authored
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:
-
MD Danish Anwar authored
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:
-
MD Danish Anwar authored
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:
-
Suman Anna authored
Add DT schema binding for PRU consumers. The binding includes all the common properties that can be used by different PRU consumer or application nodes and supported by the PRU remoteproc driver. These are used to configure the PRU hardware for specific user applications. The application nodes themselves should define their own bindings. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230106121046.886863-2-danishanwar@ti.comSigned-off-by:
-
- 04 Jan, 2023 3 commits
-
-
AngeloGioacchino Del Regno authored
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 authored
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:
-
Chen-Yu Tsai authored
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: 63c13d61 ("remoteproc/mediatek: add SCP support for mt8183") Signed-off-by:
Chen-Yu Tsai <wenst@chromium.org> Reviewed-by:
-
- 28 Dec, 2022 14 commits
-
-
Mukesh Ojha authored
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:
-
Sireesh Kodali authored
Add support for booting the Audio DSP on the MSM8953 platform. This is used by SoCs like SDM450, SDM625, SDM626, APQ8053, etc. Since the configuration is the same on all SoCs, a single compatible string is used. Signed-off-by:
Sireesh Kodali <sireeshkodali1@gmail.com> Reviewed-by:
-
Sireesh Kodali authored
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:
-
Srinivasa Rao Mandadapu authored
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:
-
Srinivasa Rao Mandadapu authored
Add efuse evb selection control and enable it for starting ADSP. Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
-
Srinivasa Rao Mandadapu authored
Replace hard coded values of QDSP6 boot control reg params with appropriate macro names. Signed-off-by:
-
Srinivasa Rao Mandadapu authored
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 authored
Update adsp pil data and compatible name for loading ADSP binary on SC7280 based platforms. Signed-off-by:
-
Srinivasa Rao Mandadapu authored
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 authored
Add ADSP PIL loading support for SC7280 SoCs. Signed-off-by:
-
Gokul krishna Krishnakumar authored
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:
-
Gaosheng Cui authored
qcom_iris_driver has been removed since commit 1fcef985 ("remoteproc: qcom: wcnss: Fix race with iris probe"), so remove it. Signed-off-by:
Gaosheng Cui <cuigaosheng1@huawei.com> Reviewed-by:
-
Wolfram Sang authored
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:
-
Abel Vesa authored
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:
-
- 27 Dec, 2022 1 commit
-
-
Krzysztof Kozlowski authored
According to DTS and Linux driver, the MSM8996 SLPI PIL takes two clocks - xo and aggre2: qcom/msm8996-oneplus3t.dtb: remoteproc@1c00000: clocks: [[20], [3, 64]] is too long qcom/msm8996-oneplus3t.dtb: remoteproc@1c00000: clock-names: ['xo', 'aggre2'] is too long Signed-off-by:
-
