Pull remoteproc updates from Bjorn Andersson: - Make the Xilinx remoteproc driver support running on only a single core, disable still unsupported remoteproc features, and stop the remoteproc on shutdown to facilitate kexec. - Conclude the renaming of the Qualcomm ADSP driver to "PAS" that was started many years ago. * tag 'rproc-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: remoteproc: xlnx: Fix kernel-doc warnings remoteproc: xlnx: Disable unsupported features remoteproc: xlnx: Add shutdown callback remoteproc: xlnx: Allow single core use in split mode dt-bindings: remoteproc: qcom,sa8775p-pas: Correct the interrupt number remoteproc: Don't use %pK through printk dt-bindings: remoteproc: qcom,sm8150-pas: Document QCS615 remoteproc remoteproc: qcom: pas: Conclude the rename from adsp
Fix kernel-doc warnings generated by following command: `scripts/kernel-doc -Werror -Wshort-desc -Wall \ drivers/remoteproc/xlnx_r5_remoteproc.c > /dev/null` warning: missing initial short description on line: * struct mbox_info ... Total 8 warnings fixed Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Link: https://lore.kernel.org/r/20250716213048.2316424-3-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
AMD-Xilinx platform driver does not support iommu or recovery mechanism
yet. Disable both features in platform driver.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20250716213048.2316424-2-tanmay.shah@amd.com
Fixes: 6b291e8020a8 ("drivers: remoteproc: Add Xilinx r5 remoteproc driver")
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
When the Cortex-M remote core is started and already running before Linux boots (typically by the Cortex-A bootloader using a command like bootaux), the current driver is unable to attach to it. This is because the driver only checks for remote cores running in different SCU partitions. However in this case, the M-core is in the same partition as Linux and is already powered up and running by the bootloader. This patch adds a check using dev_pm_genpd_is_on() to verify whether the M-core's power domains are already on. If all power domain devices are on, the driver assumes the M-core is running and proceed to attach to it. To accomplish this, we need to avoid passing any attach_data or flags to dev_pm_domain_attach_list(), allowing the platform device become a consumer of the power domain provider without changing its current state. During probe, also enable and sync the device runtime PM to make sure the power domains are correctly managed when the core is controlled by the kernel. Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Hiago De Franco <hiago.franco@toradex.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20250716194638.113115-1-hiagofranco@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
For the i.MX8X and i.MX8 family SoCs, when the Cortex-M core is powered up and started by the Cortex-A core using the bootloader (e.g., via the U-Boot bootaux command), both M-core and Linux run within the same SCFW (System Controller Firmware) partition. With that, Linux has permission to control the M-core. But once the M-core is started by the bootloader, the SCFW automatically enables its clock and sets the clock rate. If Linux later attempts to enable the same clock via clk_prepare_enable(), the SCFW returns a 'LOCKED' error, as the clock is already configured by the SCFW. This causes the probe function in imx_rproc.c to fail, leading to the M-core power domain being shut down while the core is still running. This results in a fault from the SCU (System Controller Unit) and triggers a system reset. To address this issue, ignore handling the clk for i.MX8X and i.MX8 M-core, as SCFW already takes care of enabling and configuring the clock. Suggested-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Hiago De Franco <hiago.franco@toradex.com> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20250629172512.14857-3-hiagofranco@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In case of kexec call, each driver's shutdown callback is called. Handle this call for rproc driver and shutdown/detach each core that was powered on before. This is needed for proper Life Cycle Management of remote processor. Otherwise on next linux boot, remote processor can't be started due to bad refcount of power-domain managed by platform management controller. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Link: https://lore.kernel.org/r/20250620195728.3216935-1-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
When operating in split mode, it is a valid usecase to have only one core enabled in the cluster. Remove exact core count expecatation from the driver. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Link: https://lore.kernel.org/r/20250618181933.1253033-1-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
In the past %pK was preferable to %p as it would not leak raw pointer
values into the kernel log.
Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
the regular %p has been improved to avoid this issue.
Furthermore, restricted pointers ("%pK") were never meant to be used
through printk(). They can still unintentionally leak raw pointers or
acquire sleeping locks in atomic contexts.
Switch to the regular pointer formatting which is safer and
easier to reason about.
There are still a few users of %pK left, but these use it through seq_file,
for which its usage is safe.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://lore.kernel.org/r/20250611-restricted-pointers-remoteproc-v1-1-f059097ba663@linutronix.de
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The change that renamed the driver from "adsp" to "pas" didn't change
any of the implementation. The result is an aesthetic eyesore, and
confusing to many.
Conclude the rename of the driver, by updating function, structures and
variable names to match what the driver actually is. The "Hexagon v5" is
also dropped from the name and Kconfig, as this isn't correct either.
No functional change.
Fixes: 9e004f97161d ("remoteproc: qcom: Rename Hexagon v5 PAS driver")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Reviewed-by: Wasim Nazir <quic_wasimn@quicinc.com>
Link: https://lore.kernel.org/r/20250605-pas-rename-v2-1-f1c89e49e691@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Pull remoteproc updates from Bjorn Andersson: - Fix resource cleanup in the remoteproc attach error handling code paths - Refactor the various TI K3 drivers to extract and reuse common code between them - Add support in the i.MX remoteproc driver for determining from the firmware if Linux should wait on a "firmware ready" signal at startup - Improve the Xilinx R5F power down mechanism to handle use cases where this is shared with other entities in the system * tag 'rproc-v6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: (46 commits) remoteproc: k3: Refactor release_tsp() functions into common driver remoteproc: k3: Refactor reserved_mem_init() functions into common driver remoteproc: k3: Refactor mem_release() functions into common driver remoteproc: k3: Refactor of_get_memories() functions into common driver remoteproc: k3: Refactor .da_to_va rproc ops into common driver remoteproc: k3: Refactor .get_loaded_rsc_table ops into common driver remoteproc: k3: Refactor .detach rproc ops into common driver remoteproc: k3: Refactor .attach rproc ops into common driver remoteproc: k3: Refactor .stop rproc ops into common driver remoteproc: k3: Refactor .start rproc ops into common driver remoteproc: k3: Refactor .unprepare rproc ops into common driver remoteproc: k3: Refactor .prepare rproc ops into common driver remoteproc: k3-dsp: Assert local reset during .prepare callback remoteproc: k3-dsp: Don't override rproc ops in IPC-only mode remoteproc: k3: Refactor rproc_request_mbox() implementations into common driver remoteproc: k3-m4: Ping the mbox while acquiring the channel remoteproc: k3: Refactor rproc_release() implementation into common driver remoteproc: k3-m4: Introduce central function to release rproc from reset remoteproc: k3-dsp: Correct Reset deassert logic for devices w/o lresets remoteproc: k3: Refactor rproc_reset() implementation into common driver ...