- 18 Jan, 2023 2 commits
-
-
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:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> 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-2-54154c08c0b7@linaro.org
-
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:
Mathieu Poirier <mathieu.poirier@linaro.org>
-
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 <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230104115341.320951-3-angelogioacchino.delregno@collabora.comSigned-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:
Mukesh Ojha <quic_mojha@quicinc.com> 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:
Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by:
-
Srinivasa Rao Mandadapu authored
Replace hard coded values of QDSP6 boot control reg params with appropriate macro names. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-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 13 commits
-
-
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:
-
Krzysztof Kozlowski authored
Split SC7180 and SC7280remote processor Peripheral Authentication Service bindings into their own file to reduce complexity and make maintenance easier. Signed-off-by:
-
Krzysztof Kozlowski authored
Split QCS404 remote processor Peripheral Authentication Service bindings into their own file to reduce complexity and make maintenance easier. Signed-off-by:
-
Krzysztof Kozlowski authored
Split SDX55 remote processor Peripheral Authentication Service bindings into their own file to reduce complexity and make maintenance easier. Signed-off-by:
-
Krzysztof Kozlowski authored
Split SC8180x remote processor Peripheral Authentication Service bindings into their own file to reduce complexity and make maintenance easier. The binding is incomplete due to lack of upstreamed DTS - no example and not all power domains defined. Signed-off-by:
-
Krzysztof Kozlowski authored
Split SC8280XP remote processor Peripheral Authentication Service bindings into their own file to reduce complexity and make maintenance easier. While moving correctly constrain the number of interrupts per specific device. Signed-off-by:
-
Krzysztof Kozlowski authored
Split SM6350 remote processor Peripheral Authentication Service bindings into their own file to reduce complexity and make maintenance easier. Signed-off-by:
-
Krzysztof Kozlowski authored
Split SM8150 and SM8250 remote processor Peripheral Authentication Service bindings into their own file to reduce complexity and make maintenance easier. Signed-off-by:
-
Krzysztof Kozlowski authored
Split SM8350 and SM8450 remote processor Peripheral Authentication Service bindings into their own file to reduce complexity and make maintenance easier. Signed-off-by:
-
Krzysztof Kozlowski authored
Split common part of Qualcomm SoC Peripheral Authentication Service bindings into a re-usable schema file. Signed-off-by:
-
Krzysztof Kozlowski authored
Some remote processors (e.g. QCS404 CDSP, SC7180 MPSS/MSS) can be brought to life using two different bindings: 1. PIL (Peripheral Image Loader) 2. PAS (Peripheral Authentication Service) They still describe the same hardware - firmware load for remote processor - but use different methods to communicate with that processor. For these SoCs, the qcom,adsp.yaml bindings were describing the PAS method, however for easier customization of board DTS, the bindings combined additional properties from PIL: reset lines, qcom,halt-regs and additional clocks. The devices and Linux kernel drivers, when instantiated as PAS, do not use these properties, so drop them from the bindings. Signed-off-by:
-
Sireesh Kodali authored
On MSM8974, power domains are not yet supported. The platform uses regulators. This patch marks either the power-domains or *-supply as required (instead of always requiring the power domains). Signed-off-by:
-
Sireesh Kodali authored
The pronto v3 remoteproc is similar to pronto v2. It is found on the MSM8953 platform, which is used by SDM450, SDM625, SDM626, APQ8053 and other SoCs. Since the configuration is same on all SoCs, a single compatible is used. Signed-off-by:
-
