When remoteproc goes down unexpectedly this results in a state where any
acquired hwspinlocks will remain locked possibly resulting in deadlock.
In order to ensure all locks are freed we include a call to
qcom_smem_bust_hwspin_lock_by_host() during remoteproc shutdown.
For qcom_q6v5_pas remoteprocs, each remoteproc has an assigned smem
host_id. Remoteproc can pass this id to smem to try and bust the lock on
remoteproc stop.
This edge case only occurs with q6v5_pas watchdog crashes. The error
fatal case has handling to clear the hwspinlock before the error fatal
interrupt is triggered.
Signed-off-by: Richard Maina <quic_rmaina@quicinc.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Chris Lew <quic_clew@quicinc.com>
Link: https://lore.kernel.org/r/20240529-hwspinlock-bust-v3-4-c8b924ffa5a2@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
In scp_ipi_handler(), instead of zeroing out the entire shared
buffer, which may be as large as 600 bytes, overwrite it with the
received data, then zero out only the remaining bytes.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20240520112724.139945-1-angelogioacchino.delregno@collabora.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
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: 3c8a9066d5 ("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>
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: c08a824945 ("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>
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: 6dedbd1d54 ("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>
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: 6dedbd1d54 ("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>
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>
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>
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>
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>
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>
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>
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: 3efa0ea743 ("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>
Since commit 43a7206b09 ("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>
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.
It 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.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmX3oxcVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FargP/1kVpsEZbzaqc3v0OJBShG45gpQR
O9wIfP0T9KrZGDSayAGX7/c80cvLl3y/ukkwY6ehGLrV2iOQ2+7fhV9vLDe09a95
mMkcE3d3WFrlDPGPjquTRlCFjkBcK/WloQWBQZZ+ZtCxjfUjwKxtPutB7XPCQC4r
Ky3qUUhkxhXSD2R8Vr8PSDtdMxwj991A7Ejo+wRYEzv40atiJ0M3v9/hjNeIinVz
zui6EOB0p9s4geDfD7uAbbDfwi7CxvlprC3AcAYz4KWV1q5Dh8NhYI0KqcF03G8q
pCpJHuHYBBiarAvflKe99KLSiVz7+GOtcz2a4d4YBSbePliW+HafPXugUqBG/RtC
TzH1H4NuS+07JyYlklz/lC3Do284LimSrGlGMR+uypY8sLWRVSHBazTJypGHOUZd
ei/E3Nf7hbEkBh31o4lTMVrVT/zTXKe2gdzAM7dgom6euav8OiUEgpVdc2ye3oHf
0Xmeb8UXAVTCZEfHqgKr3QO3v3wAbarbJ/UZiPHeN/5kFUxbTxpRAmpTeI4ViKk3
KDbqibnx6YI8UHkAPgQalf1x37z2f1b/DEfi3nulzwLsZ0UgvoZy5Zim7RSS/R5K
JFqMNKPj0m2J6LF+2YTjZL6Af989mWmLOLPTM6szpWvEil/ndRTqWaAKOilWeGJu
wqVp6JrREfPhHsWY
=na/C
-----END PGP SIGNATURE-----
Merge tag 'rproc-v6.9' of 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
...
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>
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>
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>
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>
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>
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>
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>
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>
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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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: 8a471396d2 ("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>
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: 13140de09c ("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>
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: 1d7b61c06d ("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>
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>
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>
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>
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>
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>
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: 5c77ebcd05 ("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>
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>
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>
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: 1fdbf0cdde ("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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmT2AqkVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FvWMQALC4zy9ZNMLDNmfD4uO8u5R65eWv
MzZqqsIVjmdcNcrJykKdIw33gBo50zw6AHcZjSdhOHdGvi/g8vQERhVO1k4dMzII
JepoWG5HHY2nffr8LNQzG2HD0n4l6CQV3Ftg0/JlAhO1ADJz70HME3tUOiizLQUP
TfIfF0pkmcjHERFNe+ESdWqkw+DUGGHXSs+b4f8jjqBvKSYayPo02wSAw/koV44a
DJlw4U2omP76NWu30prqGqGvdB1ADwLcVLAFJg7+1c5ttqsZcz/SOZRlHbss200F
5JuM5IF6HJgq2E9Cst+iWlH1ZtiMFFf+ZRmHv48BImpaBdeTcZuEz9k42ay3eVwJ
FghK77c63MbICBOQiQv+QeGr5c49pU1UbioxtIKa3MmNE6gE/qHaLerHXyxd5XTq
dhxuqFNgq4xClq9H8CUTkugSvHLvXiaZim240N2715GYL2VR4ZfAkM1xywBEKu32
WZ61ueb0oZWYFUui2KrPgjvlQzf5ZtTs+1y000WJypaoCXU2kcq/zAvjMJlReYDu
d97sntyy2Deae7ko/sMz4XrICQCug0WTE5PFXOCttWsYOJ8DvSvhND5fVmxc/uA3
Gd+HdnLOc+RfKXiL5BoVf+BUIeuKTNaMutkIabcGTvgPPbJlic7iw6kR8NqCQ+mr
U8E4hulg1I9aXwu4
=BV3w
-----END PGP SIGNATURE-----
Merge tag 'rproc-v6.6' of 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
...
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>
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: 03bd158e15 ("remoteproc: stm32: use correct format strings on 64-bit")
Fixes: 410119ee29 ("remoteproc: stm32: wakeup the system by wdg irq")
Fixes: 13140de09c ("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>
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>
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>
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>
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>
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] 7dd6dd9b93
[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>
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>
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>
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>
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>
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>
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>
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>
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>
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().
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmSjLeMVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FrC0P/jRxXCckwudaZFEQW3LTr8QDI/zV
+ZkVBV9VUfjV64mY0Z6dAihXcONVYCNhKXX+6h+I/nxUfAqAJY7wbQBDmB/C7EL0
qm185BBHNr8XmxezwmttKpeiCibcRoLbSCOeJXjXbOU3op/h7zTu6zLE2gLPWvWM
s+x784cbiK5W/IY8DWoSHKW5XXMjgTta8pk8VhovnB/EokHjdbEHXQgpn/HVogvk
ErczPWli8+bmzlAwd5RUNUW6q/Lnx3ffjC5dsVhlqK0iGNIu6fa0YUk35Uc7ig09
0D2iZBqZLff/2WTW+PMHfdNl6dfzcLBLgoDpnFwOX2QO17qjKHTQfAwDshJkhKw6
9BiJifXaVX2vrBCd7REUrAeHmzIbgO+yCnKFr1UyLmbj0x/DXQLCQHrkPXycKgKi
Z9ujdJC7XsFyn1DSgxNSSWSpDhJOuMX77Umi/ASRWPha15H3YlOjqXV/Vaoy0iPg
E7iCL2dd11X9s/LXp16ahcAgb7c6vEXclWm1CsTQzhMDLMmVBysMa/AWg8Gtq4hW
pxCwsGWG7CTTAE2/E7N6AX/caNRs2Z++b6MLRVrIvvokgnk2Ofhqlyn71r7FstlV
uBWUM9BszeIzG6NYAKWjRo036tVgTWnMWsy+i5uSOEUD6JsaMm7TnjVEOAtz1cQE
VWbln8J7plG5ly6g
=9t2a
-----END PGP SIGNATURE-----
Merge tag 'rproc-v6.5' of 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
...
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmSdmbIACgkQYKtH/8kJ
UicewQ/6Aq8j5pBFYBimZoyQ0bi9z+prGrHoDDYLew2vKjtOXJl5z7ZnM3J1oyPt
Zvis3IaGkHJCuuqotPdsquZrzHq8slzXzwkHPfHORJBC4gV0V/vMS8w32tO5FfTq
ULrMyWnbsU7Udeywc2xuEpAoC9+bXX9brnCpa3H41peIGZKM+0g7EE6FASt3YaOk
O+ZMSGqF8QbCqSQrUH3GudFlFMy/VxIvwuUsbLt8aNkRACunQZXVgUdArvLV49nX
SElFN7hOVRoVDv0rgYMxlwElymrta/kMyjLba8GU1GIhzyDGozVqIJQAnsQ3f6CC
yyzaJm27zzJH0mx9jx4W+JLBdjqDL4ctE2WyllRVIpTGYMHiMQtutHNwtNupIuD5
j9j/fIVQWZqOdWXnA6V/CHYN1MZBRTH3KQcnLlYPC01dWKThPDnrHGfwOkfsrwtN
zuERJJ+gd5b8KW4dmy1ueDOSB8162LxbS7iHxpOBGySmqVOYj3XUqACZhKRfXfIQ
BVj9punCE/gO2fMb9IZByjeOzgtV+PBRmPxoglyaGkT4fVfL06kEbpKFYbXXq9b/
aAS/U84gGr8ebWsOXszwDnBzTZRzjMVv/T9KDTTJuWbBEPNyCR7fUG0cZ50rSKnJ
2cTPe3a0sS6LaBt71qfExCIfxG+cJ2c3N1U5/jb2C49Aob45obs=
=zvLr
-----END PGP SIGNATURE-----
Merge tag 'soc-drivers-6.5' of 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
...
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>
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
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: de598695a2 ("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>
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>
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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
- updates to scripts/gdb from Glenn Washburn
- kexec cleanups from Bjorn Helgaas
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQTTMBEPP41GrTpTJgfdBJ7gKXxAjgUCZEr+6wAKCRDdBJ7gKXxA
jn4NAP4u/hj/kR2dxYehcVLuQqJspCRZZBZlAReFJyHNQO6voAEAk0NN9rtG2+/E
r0G29CJhK+YL0W6mOs8O1yo9J1rZnAM=
=2CUV
-----END PGP SIGNATURE-----
Merge tag 'mm-nonmm-stable-2023-04-27-16-01' of 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
...
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
on this pull request.
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
8b41fc4454 ("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.
[0] https://lore.kernel.org/all/Y/kXDqW+7d71C4wz@bombadil.infradead.org/
[1] https://lkml.kernel.org/r/025f2151-ce7c-5630-9b90-98742c97ac65@redhat.com
[2] https://lwn.net/Articles/927569/
[3] https://lkml.kernel.org/r/20230414052840.1994456-3-mcgrof@kernel.org
-----BEGIN PGP SIGNATURE-----
iQJGBAABCgAwFiEENnNq2KuOejlQLZofziMdCjCSiKcFAmRG4m0SHG1jZ3JvZkBr
ZXJuZWwub3JnAAoJEM4jHQowkoinQ2oP/0xlvKwJg6Ey8fHZF0qv8VOskE80zoLF
hMazU3xfqLA+1TQvouW1YBxt3jwS3t1Ehs+NrV+nY9Yzcm0MzRX/n3fASJVe7nRr
oqWWQU+voYl5Pw1xsfdp6C8IXpBQorpYby3Vp0MAMoZyl2W2YrNo36NV488wM9KC
jD4HF5Z6xpnPSZTRR7AgW9mo7FdAtxPeKJ76Bch7lH8U6omT7n36WqTw+5B1eAYU
YTOvrjRs294oqmWE+LeebyiOOXhH/yEYx4JNQgCwPdxwnRiGJWKsk5va0hRApqF/
WW8dIqdEnjsa84lCuxnmWgbcPK8cgmlO0rT0DyneACCldNlldCW1LJ0HOwLk9pea
p3JFAsBL7TKue4Tos6I7/4rx1ufyBGGIigqw9/VX5g0Iif+3BhWnqKRfz+p9wiMa
Fl7cU6u7yC68CHu1HBSisK16cYMCPeOnTSd89upHj8JU/t74O6k/ARvjrQ9qmNUt
c5U+OY+WpNJ1nXQydhY/yIDhFdYg8SSpNuIO90r4L8/8jRQYXNG80FDd1UtvVDuy
eq0r2yZ8C0XHSlOT9QHaua/tWV/aaKtyC/c0hDRrigfUrq8UOlGujMXbUnrmrWJI
tLJLAc7ePWAAoZXGSHrt0U27l029GzLwRdKqJ6kkDANVnTeOdV+mmBg9zGh3/Mp6
agiwdHUMVN7X
=56WK
-----END PGP SIGNATURE-----
Merge tag 'modules-6.4-rc1' of 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
8b41fc4454 ("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
...
Unnecessary type casts from the void * rproc->priv pointer is dropped
throughout te 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.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmRGncUVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3Fv4QQAOI09pf3QgA/OIUyCdfI83+/WHtp
n+WczvqNFhecyYwjmiv2h3QyNb+yZolGFEmFXgG6sboICm5Xji+eU5CG67AQq/q7
QkB4jqp+fu7DYXxr55kmWb4iusgptMxtnKRLUZsSThF2kNrPRny1m+RHd6thPgUK
Jt1P0bc599g0RF57fv7VTt5aUKfKrGPQq0i/2h1WOTKGVURXmaNrbcbfZkuK4Jmd
IeE13AyrdSZjEdbrLEEfZaYWXS66ubVm2nQRhFJ8z2tEaSawVelsjNDc0QmalQ6c
Av1VPPk9nDt1smSDmp6/+91AyCautXKYaCG6E/FKwwrI5xDTGvkiaJL0pk1XVcO3
1VxGH2TVROR4r/J93mRinvDiyOHE8RRaXHv52XPMqyC8DCpfbhqSoL5vjNGiBVef
Ox8qlBZBlMFgfsYPCeorfiuv5jOEQxbyghiAdIEHtIv89nrWYwsX8PFVx25C28xr
9ZTGwyWxu8HhTdCLmn4MFuQ9WfzpeTCkVLYS0Cu/elNU44w8qYNNQlPP1jBqDWdD
HRby1A2+SeIpfTlrbHHJdQ0ujSrUyLtnYn9AMKqjxyM831dcOOnn0zI1e/xwBpeV
kxUziu/zm7Ijr9LLViwJqeZI46eSmJjUhOxsNi1zZFlFw4UknWengbwR9fKf9Mkd
LFKFjgAPbnyPJEls
=HEds
-----END PGP SIGNATURE-----
Merge tag 'rproc-v6.4' of 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
...
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
Since commit 8b41fc4454 ("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>
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>
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>
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>
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>
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>
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: ec0e5549f3 ("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>
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: b29b4249f8 ("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>
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: 285892a74f ("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>
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: 3df52ed7f2 ("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>
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: 13140de09c ("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>
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>
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>
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>
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
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>
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: 6b291e8020 ("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>
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>
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>
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmPtSN8ACgkQmmx57+YA
GNkOSw/+JS5tElm/ZP7c3uWYp6uwvcb0jUlKW/U3aCtPiPEcYDLEqIEXwcNdaDMh
m4rW3GYlW0IRL3FsyuYkSLx+EIIUIfs40wldYXJOqRDj0XasndiloIwltOQJGfd9
C/UVM0FpJdxMJrcBMFgwLLQCIbAVnhHP34i6ppDRgxW/MfTeiCaaG6fnS70iv6mC
oh2N7FoZSKDtTrFtlR5TqFiK5v/W1CgNJVuglkFB0ceFpjyBpp/8AT0FGS887xCz
IYSTqm4Q/79vaZXI1Y2oog257cgdwsVqgPrnK5CuSFhTnAcJMCekiFelHq8Yhyuk
Rw7j/B3KO3AOaxmR75c6SZdeZ+VHgUMRC/RKe3fay0sm3Zea2kAIPXA6Zn+r/cxb
8M94V59qBz+f8XmpXRTK1UR3s3EbwFIuNyuDIkeorMtpSKtvqJXmZxGDwNIfXr2F
/voo++MKjzdtdxdW/D/5Tc9DC0Pyb4HLi0EYj2QCzA03njmfLDF1w73NfzMec+GD
R1zAd3FEbiJQx8Hin0PSPjYXpfMnkjkGAEcE9N9Ralg4ewNWAxfOFsAhHKTZNssL
pitTAvHR/+dXtvkX7FUi2l/6fqn8nJUrg/xRazPPp3scRbpuk8m6P4MNr3/lsaHk
HTQ/hYwDdecWLvKXjw5y9yIr3yhLmPPcloTVIIFFjsM0t8b+d9E=
=p6Xp
-----END PGP SIGNATURE-----
Merge tag 'soc-drivers-6.3' of 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
...
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()
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmP7kusVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3Fe1gP/3uTJ/2f5rLgaW4qrN+b93PNONF3
TWqGcEltAOfc2bLhS9aUk57FT8gRLJ+y5im4JXxJO9Vbnj0/pBrsBKitbVvqWbTB
qztROqQN7KtooD+qc9Ndf2caL9Oca2R8SH3C0bO5JbdM+7BSv3rO8xu7K0X6SLsI
kpf4C3cq+IP2vk7TErmYYYnEkr46Y3xT8HdUC7eCgiZQl+UnV2Cv4QNsbANkuvDp
aLnmKpeTqgBb8plJ3XSU6mOEK+Cf2nwFg3oYj4JJEMLVxXwepGpDC5mDppqUyaA8
XO8j7XP+2kstlq/8ERbZmPJjKnDBIjRXDq0I7ixg9fUee/CMGmxQQnMkaD1OBR95
jUGn7VtwEMwMzAycRWsi6SqRFyhsKI6rYHRTVSeePcbn/T6er4XHcOYhKdndKEK/
/2Uqw45gOFRZS7l0BqRTXJ1WYzl85Va07DQGQ0MaesxRHmiJcdbmhocr9vU7d5pw
L1brGoQ5vPJdCZGY1jRN0UclapqE9CVVwFgR4gi/Kh+4DwmI58q2cp5PHCHs592Y
MBViWL6//XHhf9GiqrfQZZEoV4PhyuqjSye6At9mwLif2n4RynLMI0iipzP0ydBf
2R+0YLrdXg757r/+IUl+T8IINCd3JgirOkzUBs8vN9zwRJYi6veHieDjYqUS9nXs
3Wjm5kbmxukSfaps
=clXY
-----END PGP SIGNATURE-----
Merge tag 'rproc-v6.3' of 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
...
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.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmP7jLkVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FKy4P/RBK8WFS9FJHgP3KZrN8XawruWco
W/23uiW5tKmtzXO4RB6ZMnHR6iURgqzN6cQnguH9neq4ze1rBbLUkSeKtYK8FwJg
XApzFMDCxtnjZwCAMdtT14C6R0mDt21DyeGCwRRaQg4eqiaPpuQBNX9ijgh3bons
GKK0UJuZ1o/E+/pf18+vls1PRKXDqmFr8OUpIPEdM0EA8Mr+bFGbA9TbBkHWr7uq
5xo7GSZU8u+mA53HGNctIVWAFEM0v9xHLgbjSXcHSiuS0xAC99CHw6TlA26SY6WS
gh/ovF31m7tC7lz4nFSZfeLHbKb02dRmjIDxsCMFp5pLq/jbMgbkoJ97qtQlSQhW
VjQemUzGvaENgwZr5ZcHEJ75SoGNtudHnfnwZeybRGjfiMLocVDcTZ81qIvxr8y7
jZkrQw2uUpGu8qrV9URuIHb5xfo5ixdZ8llgKWq6/PT8pcYWcwBybby55jJ/vhG0
7Fbv37VeEyq9xxpNfwuMELA2RztT5zrbPZVSfN348PIgMW3nbGzryw//r6HxmUUr
+FoSvuSBwrnEHlsdgg3ydzIhzgY1+k3jQcS7xW+nZ3PG7eHBhIVBPyNZ9xydtfaL
TBtjsCRigoLMxp8Fpdz0xANF5PICXcGfqX4591yZ9Q7fAYYQr/WKtiWS+cNd5t6A
nXDMGwVYjEA46n/1
=0w8J
-----END PGP SIGNATURE-----
Merge tag 'rpmsg-v6.3' of 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
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
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
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
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
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>
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
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>
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: 6c5a9dc248 ("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
This reverts commit fc156629b2.
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
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
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
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
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>
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>
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>
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>
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>
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>
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>
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: 63c13d61ea ("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>
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
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
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
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
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
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
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
qcom_iris_driver has been removed since
commit 1fcef985c8 ("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
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
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
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
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]: 56dcedc8da
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
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: a781e5aa59 ("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>
q6v5_wcss_qcs404_power_on() have no fail path for readl_poll_timeout().
Add fail path for readl_poll_timeout().
Fixes: 0af65b9b91 ("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
The pointer node is returned by of_parse_phandle() with refcount
incremented. We should use of_node_put() on it when done.
Fixes: b9e718e950 ("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
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: a781e5aa59 ("remoteproc: core: Prevent system suspend during remoteproc recovery")
Fixes: dc86c129b4 ("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
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: 0af65b9b91 ("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
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: 027045a6e2 ("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
Commit ff6d365898 ("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
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>
According to updated reference mannual, the M33 DRAM view of
0x[C,D]0000000 maps to A55 0xC0000000, so correct it.
Fixes: 9222fabf0e ("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>
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>
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>
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>
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>
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>
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: ec0e5549f3 ("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>
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: 1d7b61c06d ("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>
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: 1d7b61c06d ("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>
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>
