summaryrefslogtreecommitdiffstats
path: root/drivers/remoteproc
AgeCommit message (Collapse)AuthorLines
12 daysremoteproc: imx_rproc: Fix unreachable platform prepare_opsPeng Fan-1/+1
Smatch reports unreachable code in imx_rproc_prepare(), where an early return inside the reserved-memory parsing loop prevents platform prepare_ops from being executed. When of_reserved_mem_region_to_resource() fails, imx_rproc_prepare() returns immediately, so the platform-specific prepare callback is never called. As a result, prepare_ops such as imx_rproc_sm_lmm_prepare() on i.MX95 have no chance to run. This is problematic when Linux controls the M7 Logical Machine and is responsible for preparing resources such as TCM. Without running the platform prepare callback, loading the M7 ELF into TCM may fail if the bootloader did not power up and initialize TCM. Fix this by breaking out of the reserved-memory loop instead of returning, allowing the platform prepare_ops to be executed as intended. Fixes: edd2a9956055 ("remoteproc: imx_rproc: Introduce prepare ops for imx_rproc_dcfg") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-remoteproc/aYYXAa2Fj36XG4yQ@p14s/T/#t Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20260208-imx-rproc-fix-v1-1-ad74555eb9a4@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
12 daysremoteproc: mediatek: Unprepare SCP clock during system suspendTzung-Bi Shih-0/+39
Prior to commit d935187cfb27 ("remoteproc: mediatek: Break lock dependency to prepare_lock"), `scp->clk` was prepared and enabled only when it needs to communicate with the SCP. The commit d935187cfb27 moved the prepare operation to remoteproc's prepare(), keeping the clock prepared as long as the SCP is running. The power consumption due to the prolonged clock preparation can be negligible when the system is running, as SCP is designed to be a very power efficient processor. However, the clock remains prepared even when the system enters system suspend. This prevents the underlying clock controller (and potentially the parent PLLs) from shutting down, which increases power consumption and may block the system from entering deep sleep states. Add suspend and resume callbacks. Unprepare the clock in suspend() if it was active and re-prepare it in resume() to ensure the clock is properly disabled during system suspend, while maintaining the "always prepared" semantics while the system is active. The driver doesn't implement .attach() callback, hence it only checks for RPROC_RUNNING. Fixes: d935187cfb27 ("remoteproc: mediatek: Break lock dependency to prepare_lock") Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20260206033034.3031781-1-tzungbi@kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
13 daysremoteproc: sysmon: Correct subsys_name_len type in QMI requestBjorn Andersson-1/+1
The QMI message encoder has up until recently read a single byte (as elem_size == 1), but with the introduction of big endian support it's become apparent that this field is expected to be a full u32 - regardless of the size of the length in the encoded message (which is what elem_size specifies). The result is that the encoder now reads past the length byte and rejects the unreasonably large length formed when including the following 3 bytes from the subsys_name array. Fix this by changing to the expected type. Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon") Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Reviewed-by: Chris Lew <christopher.lew@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260220-qmi-encode-invalid-length-v2-1-5674be35ab29@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-02-23remoteproc: qcom_wcnss: Fix reserved region mapping failureRob Herring (Arm)-1/+1
Commit c70b9d5fdcd7 ("remoteproc: qcom: Use of_reserved_mem_region_* functions for "memory-region"") switched from devm_ioremap_wc() to devm_ioremap_resource_wc(). The difference is devm_ioremap_resource_wc() also requests the resource which fails. Testing of both fixed and dynamic reserved regions indicates that requesting the resource should work, so I'm not sure why it doesn't work in this case. Fix the issue by reverting back to devm_ioremap_wc(). Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Reported-by: André Apitzsch <git@apitzsch.eu> Fixes: c70b9d5fdcd7 ("remoteproc: qcom: Use of_reserved_mem_region_* functions for "memory-region"") Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: André Apitzsch <git@apitzsch.eu> # on BQ Aquaris M5 Link: https://lore.kernel.org/r/20260128220243.3018526-1-robh@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-02-21Convert 'alloc_obj' family to use the new default GFP_KERNEL argumentLinus Torvalds-17/+17
This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21treewide: Replace kmalloc with kmalloc_obj for non-scalar typesKees Cook-18/+17
This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-03remoteproc: imx_rproc: Fix invalid loaded resource table detectionPeng Fan-0/+4
imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded resource table even when the current firmware does not provide one. When the device tree contains a "rsc-table" entry, priv->rsc_table is non-NULL and denotes where a resource table would be located if one is present in memory. However, when the current firmware has no resource table, rproc->table_ptr is NULL. The function still returns priv->rsc_table, and the remoteproc core interprets this as a valid loaded resource table. Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when there is no resource table for the current firmware (i.e. when rproc->table_ptr is NULL). This aligns the function's semantics with the remoteproc core: a loaded resource table is only reported when a valid table_ptr exists. With this change, starting firmware without a resource table no longer triggers a crash. Fixes: e954a1bd1610 ("remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table") Cc: stable@vger.kernel.org Signed-off-by: Peng Fan <peng.fan@nxp.com> Acked-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20260129-imx-rproc-fix-v3-1-fc4e41e6e750@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-26remoteproc: mediatek: Break lock dependency to `prepare_lock`Tzung-Bi Shih-13/+30
A potential circular locking dependency (ABBA deadlock) exists between `ec_dev->lock` and the clock framework's `prepare_lock`. The first order (A -> B) occurs when scp_ipi_send() is called while `ec_dev->lock` is held (e.g., within cros_ec_cmd_xfer()): 1. cros_ec_cmd_xfer() acquires `ec_dev->lock` and calls scp_ipi_send(). 2. scp_ipi_send() calls clk_prepare_enable(), which acquires `prepare_lock`. See #0 in the following example calling trace. (Lock Order: `ec_dev->lock` -> `prepare_lock`) The reverse order (B -> A) is more complex and has been observed (learned) by lockdep. It involves the clock prepare operation triggering power domain changes, which then propagates through sysfs and power supply uevents, eventually calling back into the ChromeOS EC driver and attempting to acquire `ec_dev->lock`: 1. Something calls clk_prepare(), which acquires `prepare_lock`. It then triggers genpd operations like genpd_runtime_resume(), which takes `&genpd->mlock`. 2. Power domain changes can trigger regulator changes; regulator changes can then trigger device link changes; device link changes can then trigger sysfs changes. Eventually, power_supply_uevent() is called. 3. This leads to calls like cros_usbpd_charger_get_prop(), which calls cros_ec_cmd_xfer_status(), which then attempts to acquire `ec_dev->lock`. See #1 ~ #6 in the following example calling trace. (Lock Order: `prepare_lock` -> `&genpd->mlock` -> ... -> `&ec_dev->lock`) Move the clk_prepare()/clk_unprepare() operations for `scp->clk` to the remoteproc prepare()/unprepare() callbacks. This ensures `prepare_lock` is only acquired in prepare()/unprepare() callbacks. Since `ec_dev->lock` is not involved in the callbacks, the dependency loop is broken. This means the clock is always "prepared" when the SCP is running. The prolonged "prepared time" for the clock should be acceptable as SCP is designed to be a very power efficient processor. The power consumption impact can be negligible. A simplified calling trace reported by lockdep: > -> #6 (&ec_dev->lock) > cros_ec_cmd_xfer > cros_ec_cmd_xfer_status > cros_usbpd_charger_get_port_status > cros_usbpd_charger_get_prop > power_supply_get_property > power_supply_show_property > power_supply_uevent > dev_uevent > uevent_show > dev_attr_show > sysfs_kf_seq_show > kernfs_seq_show > -> #5 (kn->active#2) > kernfs_drain > __kernfs_remove > kernfs_remove_by_name_ns > sysfs_remove_file_ns > device_del > __device_link_del > device_links_driver_bound > -> #4 (device_links_lock) > device_link_remove > _regulator_put > regulator_put > -> #3 (regulator_list_mutex) > regulator_lock_dependent > regulator_disable > scpsys_power_off > _genpd_power_off > genpd_power_off > -> #2 (&genpd->mlock/1) > genpd_add_subdomain > pm_genpd_add_subdomain > scpsys_add_subdomain > scpsys_probe > -> #1 (&genpd->mlock) > genpd_runtime_resume > __rpm_callback > rpm_callback > rpm_resume > __pm_runtime_resume > clk_core_prepare > clk_prepare > -> #0 (prepare_lock) > clk_prepare > scp_ipi_send > scp_send_ipi > mtk_rpmsg_send > rpmsg_send > cros_ec_pkt_xfer_rpmsg Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20260112110755.2435899-1-tzungbi@kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-13Merge branch '20260105-kvmrprocv10-v10-0-022e96815380@oss.qualcomm.com' of ↵Bjorn Andersson-35/+130
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into rproc-next Merge the support for loading and managing TustZone-based remote processors found in the Qualcomm Glymur platform from a shared topic branch, as it's a mix of qcom-soc and remoteproc patches.
2026-01-13remoteproc: qcom: pas: Enable Secure PAS support with IOMMU managed by LinuxMukesh Ojha-5/+43
Most Qualcomm platforms feature Gunyah hypervisor, which typically handles IOMMU configuration. This includes mapping memory regions and device memory resources for remote processors by intercepting qcom_scm_pas_auth_and_reset() calls. These mappings are later removed during teardown. Additionally, SHM bridge setup is required to enable memory protection for both remoteproc metadata and its memory regions. When the aforementioned hypervisor is absent, the operating system must perform these configurations instead. When Linux runs as the hypervisor (@ EL2) on a SoC, it will have its own device tree overlay file that specifies the firmware stream ID now managed by Linux for a particular remote processor. If the iommus property is specified in the remoteproc device tree node, it indicates that IOMMU configuration must be handled by Linux. In this case, the has_iommu flag is set for the remote processor, which ensures that the resource table, carveouts, and SHM bridge are properly configured before memory is passed to TrustZone for authentication. Otherwise, the has_iommu flag remains unset, which indicates default behavior. Enables Secure PAS support for remote processors when IOMMU configuration is managed by Linux. Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-13-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-13remoteproc: pas: Extend parse_fw callback to fetch resources via SMC callMukesh Ojha-2/+57
Qualcomm remote processor may rely on static and dynamic resources for it to be functional. For most of the Qualcomm SoCs, when run with Gunyah or older QHEE hypervisor, all the resources whether it is static or dynamic, is managed by the hypervisor. Dynamic resources if it is present for a remote processor will always be coming from secure world via SMC call while static resources may be present in remote processor firmware binary or it may be coming from SMC call along with dynamic resources. Remoteproc already has method like rproc_elf_load_rsc_table() to check firmware binary has resources or not and if it is not having then we pass NULL and zero as input resource table and its size argument respectively to qcom_scm_pas_get_rsc_table() and while it has resource present then it should pass the present resources to Trustzone(TZ) so that it could authenticate the present resources and append dynamic resource to return in output_rt argument along with authenticated resources. Extend parse_fw callback to include SMC call to get resources from Trustzone and to leverage resource table parsing and mapping and unmapping code from the remoteproc framework. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-12-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-13soc: qcom: mdtloader: Add PAS context aware qcom_mdt_pas_load() functionMukesh Ojha-19/+5
Introduce a new PAS context-aware function, qcom_mdt_pas_load(), for remote processor drivers. This function utilizes the PAS context pointer returned from qcom_scm_pas_ctx_init() to perform firmware metadata verification and memory setup via SMC calls. The qcom_mdt_pas_load() and qcom_mdt_load() functions are largely similar, but the former is designed for clients using the PAS context-based data structure. Over time, all users of qcom_mdt_load() can be migrated to use qcom_mdt_pas_load() for consistency and improved abstraction. As the remoteproc PAS driver (qcom_q6v5_pas) has already adopted the PAS context-based approach, update it to use qcom_mdt_pas_load(). Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-6-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-13remoteproc: pas: Replace metadata context with PAS context structureMukesh Ojha-11/+27
As a superset of the existing metadata context, the PAS context structure enables both remoteproc and non-remoteproc subsystems to better support scenarios where the SoC runs with or without the Gunyah hypervisor. To reflect this, relevant SCM and metadata functions are updated to incorporate PAS context awareness and remove metadata context data structure completely. Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-5-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-13remoteproc: imx_rproc: Add support for i.MX95Peng Fan-0/+22
Add imx_rproc_cfg_imx95_m7 and address(TCM and DDR) mapping. Add i.MX95 of_device_id entry. Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20260109-imx95-rproc-2026-1-8-v6-6-d2fefb36263d@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-13remoteproc: imx_rproc: Add support for System Manager CPU APIPeng Fan-2/+33
When the System Manager configuration places the M7 core in the same Logical Machine(LM) as the A55 cores (M7 LM ID equals A55 LM ID), Linux can control M7 using the CPU protocol API. For more details, see the previous patch that adds LMM API support. Changes include: - Introduce imx_rproc_ops_sm_cpu for CPU API operations. - Reuse imx_rproc_sm_detect_mode to detect shared LM and set priv->ops to imx_rproc_ops_sm_cpu. - Implement imx_rproc_sm_cpu_{start,stop} to handle M7 start and stop. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20260109-imx95-rproc-2026-1-8-v6-5-d2fefb36263d@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-13remoteproc: imx_rproc: Add support for System Manager LMM APIPeng Fan-0/+171
i.MX95 features a Cortex-M33 core, six Cortex-A55 cores, and one Cortex-M7 core. The System Control Management Interface(SCMI) firmware runs on the M33 core. The i.MX95 SCMI firmware named System Manager(SM) includes vendor extension protocols, Logical Machine Management(LMM) protocol and CPU protocol and etc. Depending on SM configuration, M7 can be used as follows: (1) M7 in a separate Logical Machine (LM) from A55 cores, that Linux can't control (2) M7 in a separate LM from A55 cores that Linux can control using LMM protocol. (3) M7 runs in same Logical Machine as A55 cores, so Linux can control it using CPU protocol So extend the driver to using LMM and CPU protocol to manage the M7 core. - Compare linux LM ID(got using scmi_imx_lmm_info) and M7 LM ID(the ID is fixed as 1 in SM firmware if M7 is in a separate LM), if Linux LM ID is not same as M7 LM ID(linux and M7 in same LM), use LMM protocol to start/stop. CPU protocol support will be added in the following patch. Whether using CPU or LMM protocol to start/stop, the M7 status detection could use CPU protocol to detect started or not. So in imx_rproc_detect_mode, use scmi_imx_cpu_started to check the status of M7. - For above case (1) and (2), Use SCMI_IMX_LMM_POWER_ON to detect whether the M7 LM is under control of A55 LM. - For above case , after using SCMI_IMX_LMM_POWER_ON to check permission, SCMI_IMX_LMM_SHUTDOWN API should be called to shutdown the M7 LM to save power only when M7 LM is going to be started by remoteproc framework. Otherwise bypass SCMI_IMX_LMM_SHUTDOWN API if M7 LM is started before booting Linux. Current setup relies on pre-Linux software(U-Boot) to do M7 TCM ECC initialization. In future, we could add the support in Linux to decouple U-Boot and Linux. Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20260109-imx95-rproc-2026-1-8-v6-4-d2fefb36263d@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-13remoteproc: imx_rproc: Introduce prepare ops for imx_rproc_dcfgPeng Fan-0/+6
Allow each platform to provide its own prepare operations, preparing for i.MX95 LMM and CPU ops support. No functional changes. Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20260109-imx95-rproc-2026-1-8-v6-3-d2fefb36263d@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-13remoteproc: imx_rproc: Add runtime ops copy to support dynamic behaviorPeng Fan-14/+13
Structure imx_rproc_dcfg contains a const pointer to imx_rproc_plat_ops, which defines the start/stop/detect_mode operations for a remote processor. To preserve the const correctness of the static configuration while allowing runtime modification of ops behavior, introduce a new imx_rproc_plat_ops member in struct imx_rproc named `ops`. During initialization, dcfg->ops is assigned to priv->ops. Enable the driver to safely override ops at runtime without affecting the original const configuration. Improve flexibility for platforms that require dynamic operation switching (e.g. i.MX95 Logical Machine ops and CPU ops). Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20260109-imx95-rproc-2026-1-8-v6-2-d2fefb36263d@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-05remoteproc: xlnx_r5: Simplify with scoped for each OF child loopKrzysztof Kozlowski-7/+2
Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260102124827.64355-4-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-05remoteproc: mtk_scp: Simplify with scoped for each OF child loopKrzysztof Kozlowski-6/+1
Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260102124827.64355-3-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-05remoteproc: imx_dsp_rproc: Only reset carveout memory at RPROC_OFFLINE stateShengjiu Wang-3/+5
Do not reset memory at suspend and resume stage, because some memory is used to save the software state for resume, if it is cleared, the resume operation can fail. Fixes: c4c432dfb00f ("remoteproc: imx_dsp_rproc: Add support of recovery and coredump process") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Link: https://lore.kernel.org/r/20251218071750.2692132-1-shengjiu.wang@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-12-17remoteproc: imx_dsp_rproc: Fix multiple start/stop operationsDaniel Baluta-17/+33
After commit 67a7bc7f0358 ("remoteproc: Use of reserved_mem_region_* functions for "memory-region"") following commands with imx-dsp-rproc started to fail: $ echo zephyr.elf > /sys/class/remoteproc/remoteproc0/firmware $ echo start > /sys/class/remoteproc/remoteproc0/state $ echo stop > /sys/class/remoteproc/remoteproc0/state $ echo start > /sys/class/remoteproc/remoteproc0/state #! This fails -sh: echo: write error: Device or resource busy This happens because aforementioned commit replaced devm_ioremap_wc with devm_ioremap_resource_wc which will "reserve" the memory region with the first start and then will fail at the second start if the memory region is already reserved. Even partially reverting the faulty commit won't fix the underlying issue because we map the address in prepare() but we never unmap it at unprepare(), so we will keep leaking memory regions. So, lets use alloc() and release() callbacks for memory carveout handling. This will nicely map() the memory region at prepare() time and unmap() it at unprepare(). Fixes: 67a7bc7f0358 ("remoteproc: Use of_reserved_mem_region_* functions for "memory-region"") Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20251210154906.99210-1-daniel.baluta@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-12-16remoteproc: imx_rproc: Use strstarts for "rsc-table" checkShenwei Wang-1/+1
The resource name may include an address suffix, for example: rsc-table@1fff8000. To handle such cases, use strstarts() instead of strcmp() when checking for "rsc-table". Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Fixes: 67a7bc7f0358 ("remoteproc: Use of_reserved_mem_region_* functions for "memory-region"") Link: https://lore.kernel.org/r/20251208233302.684139-1-shenwei.wang@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-12-14remoteproc: imx_dsp_rproc: Wait for suspend ACK only if WAIT_FW_CONFIRMATION ↵Iuliana Prodan-0/+6
is set The DSP suspend path currently waits unconditionally for a suspend ack from the firmware. This breaks firmwares that do not implement the mailbox-based CONFIRMATION handshake, as the DSP never responds and system suspend fails with -EBUSY. The driver already uses the WAIT_FW_CONFIRMATION flag to indicate that the firmware supports the CONFIRMATION handshake at boot. Apply the same logic during suspend: only send the suspend message and wait for the suspend ack when the firmware is expected to support it. Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20251204122825.756106-3-iuliana.prodan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-12-14remoteproc: imx_dsp_rproc: Rename macro to reflect multiple contextsIuliana Prodan-11/+11
Rename WAIT_FW_READY to WAIT_FW_CONFIRMATION and FEATURE_DONT_WAIT_FW_READY to FEATURE_SKIP_FW_CONFIRMATION. This way, the term CONFIRMATION covers: - waiting for firmware to confirm it is ready to start; - waiting for any other confirmation from firmware. Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20251204122825.756106-2-iuliana.prodan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-12-14remoteproc: imx_dsp_rproc: Skip RP_MBOX_SUSPEND_SYSTEM when mailbox TX ↵Iuliana Prodan-0/+9
channel is uninitialized Firmwares that do not use mailbox communication (e.g., the hello_world sample) leave priv->tx_ch as NULL. The current suspend logic unconditionally sends RP_MBOX_SUSPEND_SYSTEM, which is invalid without an initialized TX channel. Detect the no_mailboxes case early and skip sending the suspend message. Instead, proceed directly to the runtime PM suspend path, which is the correct behavior for firmwares that cannot respond to mailbox requests. Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> Link: https://lore.kernel.org/r/20251204122825.756106-1-iuliana.prodan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-11-29remoteproc: qcom_q6v5_wcss: use optional reset for wcss_q6_bcr_resetAlexandru Gagniuc-1/+2
The "wcss_q6_bcr_reset" is not used on IPQ8074, and IPQ6018. Use devm_reset_control_get_optional_exclusive() for this reset so that probe() does not fail on platforms where it is not used. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Link: https://lore.kernel.org/r/20251129013207.3981517-2-mr.nuke.me@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-29remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regsAlexandru Gagniuc-4/+4
The "qcom,halt-regs" consists of a phandle reference followed by the three offsets within syscon for halt registers. Thus, we need to request 4 integers from of_property_read_variable_u32_array(), with the halt_reg ofsets at indexes 1, 2, and 3. Offset 0 is the phandle. With MAX_HALT_REG at 3, of_property_read_variable_u32_array() returns -EOVERFLOW, causing .probe() to fail. Increase MAX_HALT_REG to 4, and update the indexes accordingly. Fixes: 0af65b9b915e ("remoteproc: qcom: wcss: Add non pas wcss Q6 support for QCS404") Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Link: https://lore.kernel.org/r/20251129013207.3981517-1-mr.nuke.me@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-29remoteproc: qcom_wcnss: Fix NULL vs IS_ERR() bug in wcnss_alloc_memory_region()Dan Carpenter-2/+2
The devm_ioremap_resource_wc() function never returns NULL, it returns error pointers. Update the checking to match. Fixes: c70b9d5fdcd7 ("remoteproc: qcom: Use of_reserved_mem_region_* functions for "memory-region"") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/09a43da41ee277a80a3265348831e747f7b62620.1764427595.git.dan.carpenter@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-29remoteproc: qcom: q6v5: Fix NULL vs IS_ERR() bug in q6v5_alloc_memory_region()Dan Carpenter-2/+2
The devm_ioremap_resource_wc() function never returns NULL, it returns error pointers. Update the checking to match. Fixes: c70b9d5fdcd7 ("remoteproc: qcom: Use of_reserved_mem_region_* functions for "memory-region"") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/674b32a78563282adeaf3cdf941314a0b8181026.1764427595.git.dan.carpenter@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-29remoteproc: qcom: pas: Fix a couple NULL vs IS_ERR() bugsDan Carpenter-4/+4
The devm_ioremap_resource_wc() function never returns NULL, it returns error pointers. Update the checking to match. Fixes: c70b9d5fdcd7 ("remoteproc: qcom: Use of_reserved_mem_region_* functions for "memory-region"") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/0599691acc394d9390da8fa0b5de3399b132b187.1764427595.git.dan.carpenter@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-29remoteproc: qcom_q6v5_adsp: Fix a NULL vs IS_ERR() check in ↵Dan Carpenter-2/+3
adsp_alloc_memory_region() The devm_ioremap_resource_wc() function never returns NULL, it returns error pointers. Update the check to match. Fixes: c70b9d5fdcd7 ("remoteproc: qcom: Use of_reserved_mem_region_* functions for "memory-region"") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/6d6b1b0fb6a61b5155a640507217fd7e658858cf.1764427595.git.dan.carpenter@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-27remoteproc: imx_dsp_rproc: Fix NULL vs IS_ERR() bug in ↵Dan Carpenter-2/+2
imx_dsp_rproc_add_carveout() The devm_ioremap_resource_wc() function never returns NULL, it returns error pointers. Update the error checking to match. Fixes: 67a7bc7f0358 ("remoteproc: Use of_reserved_mem_region_* functions for "memory-region"") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Link: https://lore.kernel.org/r/aSf6OerBbPcxBUVt@stanley.mountain Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-11-27remoteproc: st: Fix indexing of memory-regionsBjorn Andersson-1/+0
The recent transition to use of_reserved_mem_region_to_resource() changes the while loop to a for loop, but the increment of the "index" variable was left behind at the end of the loop, as highlighted by the following error/warning: error: variable 'index' is incremented both in the loop header and in the loop body [-Werror,-Wfor-loop-analysis] Drop the extra increment to avoid skipping over every other memory-region in the loop. Fixes: 67a7bc7f0358 ("remoteproc: Use of_reserved_mem_region_* functions for "memory-region"") Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251126-st-remoteproc-double-index-v1-1-3b0a8b21ac18@oss.qualcomm.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-11-26remoteproc: qcom: pas: Add support for SDM660 CDSPNickolay Goppen-0/+1
Compute DSP in SDM660 is compatible with generic cdsp_resource_init descriptor. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # ifc6560 Signed-off-by: Nickolay Goppen <setotau@mainlining.org> Link: https://lore.kernel.org/r/20251110-qcom-sdm660-cdsp-v3-3-cc3c37287e72@mainlining.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-26remoteproc: omap: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus-3/+0
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20250704075445.3221481-1-sakari.ailus@linux.intel.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-26remoteproc: qcom: Use of_reserved_mem_region_* functions for "memory-region"Rob Herring (Arm)-129/+72
Use the newly added of_reserved_mem_region_to_resource() and of_reserved_mem_region_count() functions to handle "memory-region" properties. The error handling is a bit different in some cases. Often "memory-region" is optional, so failed lookup is not an error. But then an error in of_reserved_mem_lookup() is treated as an error. However, that distinction is not really important. Either the region is available and usable or it is not. So now, it is just of_reserved_mem_region_to_resource() which is checked for an error. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20251124182751.507624-2-robh@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-26remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8974Luca Weiss-1/+1
MSM8974 requires the CX power domain, so use the msm8996_adsp_resource which has cx under proxy_pd_names and is otherwise equivalent. Signed-off-by: Luca Weiss <luca@lucaweiss.eu> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250621-msm8974-rpmpd-switch-v1-2-0a2cb303c446@lucaweiss.eu Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-25remoteproc: Use of_reserved_mem_region_* functions for "memory-region"Rob Herring (Arm)-196/+129
Use the newly added of_reserved_mem_region_to_resource() and of_reserved_mem_region_count() functions to handle "memory-region" properties. The error handling is a bit different in some cases. Often "memory-region" is optional, so failed lookup is not an error. But then an error in of_reserved_mem_lookup() is treated as an error. However, that distinction is not really important. Either the region is available and usable or it is not. So now, it is just of_reserved_mem_region_to_resource() which is checked for an error. Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Tested-by: Peng Fan <peng.fan@nxp.com> # i.MX93-11x11-EVK for imx_rproc.c Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> # rcar Tested-by: Beleswar Padhi <b-padhi@ti.com> # TI Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20251124182751.507624-1-robh@kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-11-19remoteproc: imx_dsp_rproc: Simplify start/stop error handlingPeng Fan-21/+18
Replace goto-based error handling with early return pattern in imx_dsp_rproc_{start,stop}() functions, and simplify if-else logic. No functional changes, only code structure improvements for better maintainability. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20251119-imx-dsp-2025-11-19-v4-12-adafd342d07b@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-11-19remoteproc: imx_rproc: Remove enum imx_rproc_methodPeng Fan-8/+0
There is no user of enum imx_rproc_method after moved to ops based method. Remove it. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20251119-imx-dsp-2025-11-19-v4-11-adafd342d07b@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-11-19remoteproc: imx_dsp_rproc: Simplify IMX_RPROC_RESET_CONTROLLER switch casePeng Fan-33/+38
Introduce imx_dsp_rproc_reset_ctr_{start, stop, detect_mode}() helper functions for i.MX variants using IMX_RPROC_RESET_CONTROLLER to manage remote processors. Allows the removal of the IMX_RPROC_RESET_CONTROLLER switch-case blocks from imx_dsp_rproc_[start,stop,detect_mode](), resulting in cleaner and more maintainable code. No functional changes. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20251119-imx-dsp-2025-11-19-v4-10-adafd342d07b@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-11-19remoteproc: imx_dsp_rproc: Simplify IMX_RPROC_SCU_API switch casePeng Fan-21/+29
Introduce imx_dsp_rproc_scu_api_{start, stop, detect_mode}() helper functions for i.MX variants using IMX_RPROC_SCU_API to manage remote processors. Allows the removal of the IMX_RPROC_SCU_API switch-case blocks from imx_dsp_rproc_[start,stop,detect_mode](), resulting in cleaner and more maintainable code. No functional changes. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20251119-imx-dsp-2025-11-19-v4-9-adafd342d07b@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-11-19remoteproc: imx_dsp_rproc: Simplify IMX_RPROC_MMIO switch casePeng Fan-23/+40
Introduce imx_dsp_rproc_mmio_{start, stop, detect_mode}() helper functions for i.MX variants using IMX_RPROC_MMIO to manage remote processors. Allows the removal of the IMX_RPROC_MMIO switch-case blocks from imx_dsp_rproc_[start,stop,detect_mode](), resulting in cleaner and more maintainable code. No functional changes. Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20251119-imx-dsp-2025-11-19-v4-8-adafd342d07b@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-11-19remoteproc: imx_dsp_rproc: Move imx_dsp_rproc_dcfg closer to ↵Peng Fan-50/+50
imx_dsp_rproc_of_match Move the imx_dsp_rproc_dcfg structure definitions closer to imx_dsp_rproc_of_match to prepare for adding start/stop/detect_mode ops for each i.MX variant. Avoids the need to declare function prototypes such as 'static int imx_dsp_rproc_mbox_init(struct imx_dsp_rproc *priv)' at the beginning of the file, improving code organization and readability. No functional changes. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20251119-imx-dsp-2025-11-19-v4-7-adafd342d07b@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-11-19remoteproc: imx_dsp_rproc: Use start/stop/detect_mode ops from imx_rproc_dcfgPeng Fan-0/+16
Allow each platform to provide its own implementation of start/stop/ detect_mode operations, and prepare to eliminate the need for multiple switch-case statements. Improve code readability and maintainability by encapsulating platform-specific behavior. No functional changes. Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20251119-imx-dsp-2025-11-19-v4-6-adafd342d07b@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-11-19remoteproc: imx_dsp_rproc: Drop extra spacePeng Fan-2/+2
Drop extra space between return and zero. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20251119-imx-dsp-2025-11-19-v4-5-adafd342d07b@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-11-19remoteproc: imx_dsp_rproc: Use dev_err_probe() for firmware and mode errorsPeng Fan-9/+4
Use dev_err_probe() to simplify the code. No functional change. Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20251119-imx-dsp-2025-11-19-v4-4-adafd342d07b@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-11-19remoteproc: imx_dsp_rproc: Use devm_pm_runtime_enable() helperPeng Fan-9/+1
Current code on the cleanup path just disables runtime PM for a device. Using resource managed version devm_pm_runtime_enable() registers a cleanup callback that sets autosuspend to false and then disables runtime PM for a device. So, basically the same functionality as we don't use autosuspend anyway. As a result, the .remove callback is no longer needed, reducing boilerplate code. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20251119-imx-dsp-2025-11-19-v4-3-adafd342d07b@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-11-19remoteproc: imx_dsp_rproc: Use devm_rproc_add() helperPeng Fan-4/+1
Replace manual rproc_add() and cleanup logic with devm_rproc_add(), which ties the remoteproc lifecycle to the device's lifecycle. This simplifies error handling and ensures proper cleanup. No functional changes. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20251119-imx-dsp-2025-11-19-v4-2-adafd342d07b@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>