summaryrefslogtreecommitdiff
path: root/drivers/remoteproc
AgeCommit message (Collapse)AuthorFilesLines
2025-04-10remoteproc: qcom_q6v5_mss: Handle platforms with one power domainLuca Weiss1-4/+17
[ Upstream commit 4641840341f37dc8231e0840ec1514b4061b4322 ] For example MSM8974 has mx voltage rail exposed as regulator and only cx voltage rail is exposed as power domain. This power domain (cx) is attached internally in power domain and cannot be attached in this driver. Fixes: 8750cf392394 ("remoteproc: qcom_q6v5_mss: Allow replacing regulators with power domains") Co-developed-by: Matti Lehtimäki <matti.lehtimaki@gmail.com> Signed-off-by: Matti Lehtimäki <matti.lehtimaki@gmail.com> Reviewed-by: Stephan Gerhold <stephan.gerhold@linaro.org> Signed-off-by: Luca Weiss <luca@lucaweiss.eu> Link: https://lore.kernel.org/r/20250217-msm8226-modem-v5-4-2bc74b80e0ae@lucaweiss.eu Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8226Luca Weiss1-1/+1
[ Upstream commit ba785ff4162a65f18ed501019637a998b752b5ad ] MSM8226 requires the CX power domain, so use the msm8996_adsp_resource which has cx under proxy_pd_names and is otherwise equivalent. Suggested-by: Stephan Gerhold <stephan.gerhold@linaro.org> Fixes: fb4f07cc9399 ("remoteproc: qcom: pas: Add MSM8226 ADSP support") Signed-off-by: Luca Weiss <luca@lucaweiss.eu> Reviewed-by: Stephan Gerhold <stephan.gerhold@linaro.org> Link: https://lore.kernel.org/r/20250128-pas-singlepd-v1-1-85d9ae4b0093@lucaweiss.eu Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10remoteproc: qcom: pas: add minidump_id to SC7280 WPSSLuca Weiss1-0/+1
[ Upstream commit d2909538bff0189d4d038f4e903c70be5f5c2bfc ] Add the minidump ID to the wpss resources, based on msm-5.4 devicetree. Fixes: 300ed425dfa9 ("remoteproc: qcom_q6v5_pas: Add SC7280 ADSP, CDSP & WPSS") Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://lore.kernel.org/r/20250314-sc7280-wpss-minidump-v1-1-d869d53fd432@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10remoteproc: qcom_q6v5_pas: Make single-PD handling more robustLuca Weiss1-5/+5
[ Upstream commit e917b73234b02aa4966325e7380d2559bf127ba9 ] Only go into the if condition for single-PD handling when there's actually just one power domain specified there. Otherwise it'll be an issue in the dts and we should fail in the regular code path. This also mirrors the latest changes in the qcom_q6v5_mss driver. Suggested-by: Stephan Gerhold <stephan.gerhold@linaro.org> Fixes: 17ee2fb4e856 ("remoteproc: qcom: pas: Vote for active/proxy power domains") Signed-off-by: Luca Weiss <luca@lucaweiss.eu> Reviewed-by: Stephan Gerhold <stephan.gerhold@linaro.org> Link: https://lore.kernel.org/r/20250128-pas-singlepd-v1-2-85d9ae4b0093@lucaweiss.eu Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10remoteproc: core: Clear table_sz when rproc_shutdownPeng Fan1-0/+1
[ Upstream commit efdde3d73ab25cef4ff2d06783b0aad8b093c0e4 ] There is case as below could trigger kernel dump: Use U-Boot to start remote processor(rproc) with resource table published to a fixed address by rproc. After Kernel boots up, stop the rproc, load a new firmware which doesn't have resource table ,and start rproc. When starting rproc with a firmware not have resource table, `memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` will trigger dump, because rproc->cache_table is set to NULL during the last stop operation, but rproc->table_sz is still valid. This issue is found on i.MX8MP and i.MX9. Dump as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __pi_memcpy_generic+0x110/0x22c lr : rproc_start+0x88/0x1e0 Call trace: __pi_memcpy_generic+0x110/0x22c (P) rproc_boot+0x198/0x57c state_store+0x40/0x104 dev_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/0x1cc vfs_write+0x240/0x378 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xcc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c Clear rproc->table_sz to address the issue. Fixes: 9dc9507f1880 ("remoteproc: Properly deal with the resource table when detaching") Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20250319100106.3622619-1-peng.fan@oss.nxp.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-17remoteproc: omap: Handle ARM dma_iommu_mappingRobin Murphy1-0/+17
commit 1dc7c8ed7cb378dd3974387692dfa833aee718d4 upstream. It's no longer practical for the OMAP IOMMU driver to trick arm_setup_iommu_dma_ops() into ignoring its presence, so let's use the same tactic as other IOMMU API users on 32-bit ARM and explicitly kick the arch code's dma_iommu_mapping out of the way to avoid problems. Fixes: 4720287c7bf7 ("iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()") Signed-off-by: Robin Murphy <robin.murphy@arm.com> Tested-by: Beleswar Padhi <b-padhi@ti.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/6186e311cb6f64a787f87fd41e49a73f409b789c.1730136799.git.robin.murphy@arm.com [Fixed changelog title] Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-08remoteproc: core: Fix ida_free call while not allocatedArnaud Pouliquen1-7/+7
commit 7378aeb664e5ebc396950b36a1f2dedf5aabec20 upstream. In the rproc_alloc() function, on error, put_device(&rproc->dev) is called, leading to the call of the rproc_type_release() function. An error can occurs before ida_alloc is called. In such case in rproc_type_release(), the condition (rproc->index >= 0) is true as rproc->index has been initialized to 0. ida_free() is called reporting a warning: [ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 ida_free+0x100/0x164 [ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0 [ 4.188854] ida_free called for id=0 which is not allocated. [ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000 [ 4.203556] Modules linked in: panel_orisetech_otm8009a dw_mipi_dsi_stm(+) gpu_sched dw_mipi_dsi stm32_rproc stm32_crc32 stm32_ipcc(+) optee(+) [ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442 [ 4.231481] Hardware name: STM32 (Device Tree Support) [ 4.236627] Workqueue: events_unbound deferred_probe_work_func [ 4.242504] Call trace: [ 4.242522] unwind_backtrace from show_stack+0x10/0x14 [ 4.250218] show_stack from dump_stack_lvl+0x50/0x64 [ 4.255274] dump_stack_lvl from __warn+0x80/0x12c [ 4.260134] __warn from warn_slowpath_fmt+0x114/0x188 [ 4.265199] warn_slowpath_fmt from ida_free+0x100/0x164 [ 4.270565] ida_free from rproc_type_release+0x38/0x60 [ 4.275832] rproc_type_release from device_release+0x30/0xa0 [ 4.281601] device_release from kobject_put+0xc4/0x294 [ 4.286762] kobject_put from rproc_alloc.part.0+0x208/0x28c [ 4.292430] rproc_alloc.part.0 from devm_rproc_alloc+0x80/0xc4 [ 4.298393] devm_rproc_alloc from stm32_rproc_probe+0xd0/0x844 [stm32_rproc] [ 4.305575] stm32_rproc_probe [stm32_rproc] from platform_probe+0x5c/0xbc Calling ida_alloc earlier in rproc_alloc ensures that the rproc->index is properly set. Fixes: 08333b911f01 ("remoteproc: Directly use ida_alloc()/free()") Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20241122175127.2188037-1-arnaud.pouliquen@foss.st.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-08remoteproc: mtk_scp: Only populate devices for SCP coresChen-Yu Tsai1-2/+10
[ Upstream commit dbb9c372555c0b2a5a9264418bfba6d017752808 ] When multi-core SCP support was added, the driver was made to populate platform devices for all the sub-nodes. This ended up adding platform devices for the rpmsg sub-nodes as well, which never actually get used, since rpmsg devices are registered through the rpmsg interface. Limit of_platform_populate() to just populating the SCP cores with a compatible string match list. Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP") Cc: Tinghan Shen <tinghan.shen@mediatek.com> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20241211072009.120511-1-wenst@chromium.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-15remoteproc: qcom: wcss: Remove double assignment in q6v5_wcss_probe()Yuesong Li1-1/+0
cocci report a double assignment warning.'wcss->version' was assigned twice in 'q6v5_wcss_probe()'. Signed-off-by: Yuesong Li <liyuesong@vivo.com> Link: https://lore.kernel.org/r/20240823065546.3371378-1-liyuesong@vivo.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-15remoteproc: qcom_q6v5_mss: Re-order writes to the IMEM regionSibi Sankar1-3/+3
Any write access to the IMEM region when the Q6 is setting up XPU protection on it will result in a XPU violation. Fix this by ensuring IMEM writes related to the MBA post-mortem logs happen before the Q6 is brought out of reset. Fixes: 318130cc9362 ("remoteproc: qcom_q6v5_mss: Add MBA log extraction support") Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20240819073020.3291287-1-quic_sibis@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-15remoteproc: qcom_wcnss_iris: Simplify with dev_err_probe()Krzysztof Kozlowski1-3/+2
Use dev_err_probe() to make error and defer code handling simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241011-remote-proc-dev-err-probe-v1-10-5abb4fc61eca@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-15remoteproc: qcom_q6v5_wcss: Simplify with dev_err_probe()Krzysztof Kozlowski1-62/+30
Use dev_err_probe() to make error and defer code handling simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241011-remote-proc-dev-err-probe-v1-9-5abb4fc61eca@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-15remoteproc: qcom_q6v5_pas: Simplify with dev_err_probe()Krzysztof Kozlowski1-15/+7
Use dev_err_probe() to make error and defer code handling simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241011-remote-proc-dev-err-probe-v1-8-5abb4fc61eca@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-15remoteproc: qcom_q6v5_mss: Drop redundant error printks in probeKrzysztof Kozlowski1-18/+6
Do not print errors of getting clocks and regulators in probe twice: once in q6v5_init_clocks() or q6v5_regulator_init() and then again in the probe function. This also avoids dmesg flood on deferred probe. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241011-remote-proc-dev-err-probe-v1-7-5abb4fc61eca@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-15remoteproc: qcom_q6v5_mss: Simplify with dev_err_probe()Krzysztof Kozlowski1-16/+8
Use dev_err_probe() to make error and defer code handling simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241011-remote-proc-dev-err-probe-v1-6-5abb4fc61eca@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-15remoteproc: qcom_q6v5_adsp: Simplify with dev_err_probe()Krzysztof Kozlowski1-11/+6
Use dev_err_probe() to make error and defer code handling simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241011-remote-proc-dev-err-probe-v1-5-5abb4fc61eca@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-15remoteproc: qcom_q6v5_pas: disable auto boot for wpssBalaji Pothunoori1-1/+1
Currently, the rproc "atomic_t power" variable is incremented during: a. WPSS rproc auto boot. b. AHB power on for ath11k. During AHB power off (rmmod ath11k_ahb.ko), rproc_shutdown fails to unload the WPSS firmware because the rproc->power value is '2', causing the atomic_dec_and_test(&rproc->power) condition to fail. Consequently, during AHB power on (insmod ath11k_ahb.ko), QMI_WLANFW_HOST_CAP_REQ_V01 fails due to the host and firmware QMI states being out of sync. Fixes: 300ed425dfa9 ("remoteproc: qcom_q6v5_pas: Add SC7280 ADSP, CDSP & WPSS") Cc: stable@vger.kernel.org Signed-off-by: Balaji Pothunoori <quic_bpothuno@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241018105911.165415-1-quic_bpothuno@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-15remoteproc: qcom: pas: Make remoteproc name human friendlyBjorn Andersson1-1/+1
The remoteproc "name" property is supposed to present the "human readable" name of the remoteproc, while using the device name is readable, it's not "friendly". Instead, use the "sysmon_name" as the identifier for the remoteproc instance. It matches the typical names used when we speak about each instance, while still being unique. Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Chris Lew <quic_clew@quicinc.com> Link: https://lore.kernel.org/r/20241022-rproc-friendly-name-v1-1-350c82b075cb@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-15remoteproc: qcom: pas: enable SAR2130P audio DSP supportDmitry Baryshkov1-0/+1
Enable support for the Audio DSP on the Qualcomm SAR2130P platform, reusing the SM8350 resources. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20241027-sar2130p-adsp-v1-3-bd204e39d24e@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-15remoteproc: qcom: pas: add minidump_id to SM8350 resourcesDmitry Baryshkov1-0/+2
Specify minidump_id for the SM8350 DSPs. It was omitted for in the original commit e8b4e9a21af7 ("remoteproc: qcom: pas: Add SM8350 PAS remoteprocs"). Fixes: e8b4e9a21af7 ("remoteproc: qcom: pas: Add SM8350 PAS remoteprocs") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20241027-sar2130p-adsp-v1-2-bd204e39d24e@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-15remoteproc: qcom: wcss: Remove subdevs on the error path of q6v5_wcss_probe()Joe Hattori1-2/+17
Current implementation of q6v5_wcss_probe() in qcom_q6v5_wcss.c and does not remove the subdevs on the error path. Fix this bug by calling qcom_remove_{ssr,sysmon,pdm,glink}_subdev(), and qcom_q6v5_deinit() appropriately. Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp> Link: https://lore.kernel.org/r/c4437393bfaeda69351157849b5e0a904586b1c2.1731038950.git.joe@pf.is.s.u-tokyo.ac.jp Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-15remoteproc: qcom: adsp: Remove subdevs on the error path of adsp_probe()Joe Hattori1-2/+9
Current implementation of adsp_probe() in qcom_q6v5_adsp.c and does not remove the subdevs of adsp on the error path. Fix this bug by calling qcom_remove_{ssr,sysmon,pdm,smd,glink}_subdev(), and qcom_q6v5_deinit() appropriately. Fixes: dc160e449122 ("remoteproc: qcom: Introduce Non-PAS ADSP PIL driver") Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp> Link: https://lore.kernel.org/r/fed3df4219543d46b88bacf87990d947f3fac8d7.1731038950.git.joe@pf.is.s.u-tokyo.ac.jp Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-15remoteproc: qcom: pas: Remove subdevs on the error path of adsp_probe()Joe Hattori1-5/+15
Current implementation of adsp_probe() in qcom_q6v5_pas.c does not remove the subdevs of adsp on the error path. Fix this bug by calling qcom_remove_{ssr,sysmon,pdm,smd,glink}_subdev(), qcom_q6v5_deinit(), and adsp_unassign_memory_region() appropriately. Fixes: 4b48921a8f74 ("remoteproc: qcom: Use common SMD edge handler") Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp> Link: https://lore.kernel.org/r/a1cabc64240022a7f1d5237aa2aa6f72d8fb7052.1731038950.git.joe@pf.is.s.u-tokyo.ac.jp Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-10-29remoteproc: Switch back to struct platform_driver::remove()Uwe Kleine-König18-18/+18
After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/remoteproc to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20241025131340.258233-2-u.kleine-koenig@baylibre.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-10-29remoteproc: k3-dsp: Force cast from iomem address spaceAndrew Davis1-1/+1
These memory regions are mapped as Normal Non-Cached which on does not have the normal IO address space limitations and so this cast is safe. Add '__force' to explicitly specify that the cast is intentional to remove a sparse check warning. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20241021204557.929823-3-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-10-29remoteproc: k3-r5: Force cast from iomem address spaceAndrew Davis1-1/+1
These memory regions are mapped as Normal Non-Cached which on does not have the normal IO address space limitations and so this cast is safe. Add '__force' to explicitly specify that the cast is intentional to remove a sparse check warning. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20241021204557.929823-2-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-10-29remoteproc: k3-r5: Use IO memset to clear TCMsAndrew Davis1-2/+2
While it should be safe to use normal memset() on these memories as they are mapped as Normal Non-Cached, using the memset_io() provides stronger guarantees on access alignment and fixes a sparse check warning. Switch to memset_io() here. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20241021204557.929823-1-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-10-18remoteproc: k3-r5: Add compile testing supportAndrew Davis1-1/+2
This driver can be compile tested on non-K3 architectures as long as TI_SCI_PROTOCOL is not compiled as a module. Enable this here to improve this driver's build coverage. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20241016164141.93401-3-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-10-18remoteproc: k3-dsp: Add compile testing supportAndrew Davis1-1/+2
This driver can be compile tested on non-K3 architectures as long as TI_SCI_PROTOCOL is not compiled as a module. Enable this here to improve this driver's build coverage. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20241016164141.93401-2-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-10-16mailbox, remoteproc: k3-m4+: fix compile testingArnd Bergmann1-3/+3
The k3-m4 remoteproc driver was merged with incorrect dependencies. Despite multiple people trying to fix this, the version 6.12-rc2 remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m when the driver is built-in. arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function `k3_m4_rproc_probe': ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to `devm_ti_sci_get_by_phandle' Fix the dependency again to make it work in all configurations. The 'select OMAP2PLUS_MBOX' no longer matches what the other drivers dependencies. The link failure can be avoided with a simple 'depends do, so turn that into the same 'depends' to ensure we get no circular on TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is what we use elsehwere. On the other hand, building for OMAP2PLUS makes no sense since the hardware only exists on K3. Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem") Fixes: ba0c0cb56f22 ("remoteproc: k3-m4: use the proper dependencies") Fixes: 54595f2807d2 ("mailbox, remoteproc: omap2+: fix compile testing") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20241007132441.2732215-1-arnd@kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-10-15remoteproc: ti_k3_r5: Simplify with scoped for each OF child loopKrzysztof Kozlowski1-4/+1
Use scoped for_each_available_child_of_node_scoped() when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241011-remote-proc-dev-err-probe-v1-4-5abb4fc61eca@linaro.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-10-15remoteproc: ti_k3_r5: Simplify with dev_err_probe()Krzysztof Kozlowski1-45/+24
Use dev_err_probe() to make error and defer code handling simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241011-remote-proc-dev-err-probe-v1-3-5abb4fc61eca@linaro.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-10-15remoteproc: da8xx: Simplify with dev_err_probe()Krzysztof Kozlowski1-16/+6
Use dev_err_probe() to make error and defer code handling simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241011-remote-proc-dev-err-probe-v1-2-5abb4fc61eca@linaro.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-10-15remoteproc: da8xx: Handle deferred probeKrzysztof Kozlowski1-5/+2
Don't pollute dmesg on deferred probe by using dev_err_probe(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241011-remote-proc-dev-err-probe-v1-1-5abb4fc61eca@linaro.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-09-30remoteproc: Use iommu_paging_domain_alloc()Lu Baolu1-3/+3
An iommu domain is allocated in rproc_enable_iommu() and is attached to rproc->dev.parent in the same function. Use iommu_paging_domain_alloc() to make it explicit. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20240812072811.9737-1-baolu.lu@linux.intel.com Acked-by: Beleswar Padhi <b-padhi@ti.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-09-30remoteproc: k3: Call of_node_put(rmem_np) only once in three functionsMarkus Elfring3-10/+5
An of_node_put(rmem_np) call was immediately used after a pointer check for a of_reserved_mem_lookup() call in three function implementations. Thus call such a function only once instead directly before the checks. This issue was transformed by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Link: https://lore.kernel.org/r/c46b06f9-72b1-420b-9dce-a392b982140e@web.de Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-09-29Merge tag 'mailbox-v6.12' of ↵Linus Torvalds1-4/+2
git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox Pull mailbox updates from Jassi Brar: - fix kconfig dependencies (mhu-v3, omap2+) - use devie name instead of genereic imx_mu_chan as interrupt name (imx) - enable sa8255p and qcs8300 ipc controllers (qcom) - Fix timeout during suspend mode (bcm2835) - convert to use use of_property_match_string (mailbox) - enable mt8188 (mediatek) - use devm_clk_get_enabled helpers (spreadtrum) - fix device-id typo (rockchip) * tag 'mailbox-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox: mailbox, remoteproc: omap2+: fix compile testing dt-bindings: mailbox: qcom-ipcc: Document QCS8300 IPCC dt-bindings: mailbox: qcom-ipcc: document the support for SA8255p dt-bindings: mailbox: mtk,adsp-mbox: Add compatible for MT8188 mailbox: Use of_property_match_string() instead of open-coding mailbox: bcm2835: Fix timeout during suspend mode mailbox: sprd: Use devm_clk_get_enabled() helpers mailbox: rockchip: fix a typo in module autoloading mailbox: imx: use device name in interrupt name mailbox: ARM_MHU_V3 should depend on ARM64
2024-09-27mailbox, remoteproc: omap2+: fix compile testingArnd Bergmann1-4/+2
Selecting CONFIG_OMAP2PLUS_MBOX while compile testing causes a build failure: WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX Depends on [n]: MAILBOX [=y] && (ARCH_OMAP2PLUS || ARCH_K3) Selected by [m]: - TI_K3_M4_REMOTEPROC [=m] && REMOTEPROC [=y] && (ARCH_K3 || COMPILE_TEST [=y]) Using 'select' to force-enable another subsystem is generally a mistake and causes problems such as this one, so change the three drivers that link against this driver to use 'depends on' instead, and ensure the driver itself can be compile tested regardless of the platform. When compile-testing without CONFIG_TI_SCI_PROTOCOL=m, there is a chance for a link failure, so add a careful dependency on that. arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function `k3_m4_rproc_probe': ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to `devm_ti_sci_get_by_phandle' Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Andrew Davis <afd@ti.com> Reviewed-by: Martyn Welch <martyn.welch@collabora.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-09-24remoteproc: k3-m4: use the proper dependenciesLinus Torvalds1-1/+1
The TI_K3_M4_REMOTEPROC Kconfig entry selects OMAP2PLUS_MBOX, but that driver in turn depends on other things, which the k4-m4 driver didn't. This causes a Kconfig time warning: WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX Depends on [n]: MAILBOX [=y] && (ARCH_OMAP2PLUS || ARCH_K3) Selected by [m]: - TI_K3_M4_REMOTEPROC [=m] && REMOTEPROC [=y] && (ARCH_K3 || COMPILE_TEST [=y]) because you can't select something that is unavailable. Make the dependencies for TI_K3_M4_REMOTEPROC match those of the OMAP2PLUS_MBOX driver that it needs. Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem") Cc: Bjorn Andersson <andersson@kernel.org> Cc: Martyn Welch <martyn.welch@collabora.com> Cc: Hari Nagalla <hnagalla@ti.com> Cc: Andrew Davis <afd@ti.com> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-09-09remoteporc: ingenic: Use devm_platform_ioremap_resource_byname()Zhang Zekun1-2/+1
platform_get_resource_byname() and devm_ioremap_resource() can be replaced by devm_platform_ioremap_resource_byname(), which can simplify the code logic a bit, No functional change here. Signed-off-by: Zhang Zekun <zhangzekun11@huawei.com> Link: https://lore.kernel.org/r/20240906113405.92782-4-zhangzekun11@huawei.com [Fixed patch title] Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-09-09remoteproc: da8xx: Use devm_platform_ioremap_resource_byname()Zhang Zekun1-8/+2
platform_get_resource_byname() and devm_ioremap_resource() can be replaced by devm_platform_ioremap_resource_byname(), which can simplify the code logic a bit, No functional change here. Signed-off-by: Zhang Zekun <zhangzekun11@huawei.com> Link: https://lore.kernel.org/r/20240906113405.92782-3-zhangzekun11@huawei.com [Fixed patch title] Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-09-09remoteproc: st_slim: Use devm_platform_ioremap_resource_byname()Zhang Zekun1-4/+2
platform_get_resource_byname() and devm_ioremap_resource() can be replaced by devm_platform_ioremap_resource_byname(), which can simplify the code logic a bit, No functional change here. Signed-off-by: Zhang Zekun <zhangzekun11@huawei.com> Link: https://lore.kernel.org/r/20240906113405.92782-2-zhangzekun11@huawei.com [Fixed patch title] Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-09-05remoteproc: xlnx: Add sram supportTanmay Shah1-0/+135
AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM). R5 cores can access OCM and access is faster than DDR memory but slower than TCM memories available. Sram region can have optional multiple power-domains. Platform management firmware is responsible to operate these power-domains. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Link: https://lore.kernel.org/r/20240830173735.279432-1-tanmay.shah@amd.com [Fixed dma_addr_t type cast when calling rproc_mem_entry_init()] Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-08-28remoteproc: k3-r5: Fix error handling when power-up failedJan Kiszka1-1/+2
By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance. Fixes: 61f6f68447ab ("remoteproc: k3-r5: Wait for core0 power-up before powering up core1") Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Acked-by: Beleswar Padhi <b-padhi@ti.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/9f481156-f220-4adf-b3d9-670871351e26@siemens.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-08-26remoteproc: imx_rproc: Add support for poweroff and rebootPeng Fan2-0/+46
On some NXP platforms (e.g i.MX7ULP) the poweroff and reboot operations are done via a separate remote core. Typically Linux needs to send a message to the remote core and requests for poweroff or reboot. By default the communication between Linux core and the remote core is is done via a blocking mailbox mechanism but Linux doesn't allow blocking operations in the system off (reboot, power off) handlers. So, we need to make sure the mailbox message send operations do not block for this specific operations. Fortunately, Linux allows us to register handlers that are called in preparation of the system off operations. Thus, before carrying the power off or reboot preparations, just destroy the existing mailboxes and create them as non-blocking. Note that power off and restart are totally different operations and are not complementary. We introduce a new flag in the imx remoteproc per device data which tells us when a device needs this special setup. For now, only imx7ulp needs it. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20240822-imx_rproc-v3-2-6d943723945d@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-08-26remoteproc: imx_rproc: Allow setting of the mailbox transmit modePeng Fan1-6/+6
Current mailbox is blocking by default, but there are cases where we don't need to wait for a response. Linux just needs to send data to the remote processor, so let's allow tx_block mode to be set (true/false) depending on usecase. No functional changes. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20240822-imx_rproc-v3-1-6d943723945d@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-08-21remoteproc: k3-r5: Delay notification of wakeup eventUdit Kumar1-2/+3
Few times, core1 was scheduled to boot first before core0, which leads to error: 'k3_r5_rproc_start: can not start core 1 before core 0'. This was happening due to some scheduling between prepare and start callback. The probe function waits for event, which is getting triggered by prepare callback. To avoid above condition move event trigger to start instead of prepare callback. Fixes: 61f6f68447ab ("remoteproc: k3-r5: Wait for core0 power-up before powering up core1") Signed-off-by: Udit Kumar <u-kumar1@ti.com> [ Applied wakeup event trigger only for Split-Mode booted rprocs ] Signed-off-by: Beleswar Padhi <b-padhi@ti.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240820105004.2788327-1-b-padhi@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-08-21remoteproc: k3-m4: Add a remoteproc driver for M4F subsystemMartyn Welch3-0/+681
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in the MCU domain. This core is typically used for safety applications in a stand alone mode. However, some application (non safety related) may want to use the M4F core as a generic remote processor with IPC to the host processor. The M4F core has internal IRAM and DRAM memories and are exposed to the system bus for code and data loading. A remote processor driver is added to support this subsystem, including being able to load and boot the M4F core. Loading includes to M4F internal memories and predefined external code/data memories. The carve outs for external contiguous memory is defined in the M4F device node and should match with the external memory declarations in the M4F image binary. The M4F subsystem has two resets. One reset is for the entire subsystem i.e including the internal memories and the other, a local reset is only for the M4F processing core. When loading the image, the driver first releases the subsystem reset, loads the firmware image and then releases the local reset to let the M4F processing core run. Signed-off-by: Martyn Welch <martyn.welch@collabora.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Andrew Davis <afd@ti.com> Tested-by: Wadim Egorov <w.egorov@phytec.de> Link: https://lore.kernel.org/r/20240802152109.137243-4-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-08-21remoteproc: k3: Factor out TI-SCI processor control OF get functionAndrew Davis3-54/+28
Building the TSP structure is common for users of the TI-SCI processor control interface. Factor out this function and put it with the rest of the TI-SCI processor control functions. Signed-off-by: Andrew Davis <afd@ti.com> Tested-by: Wadim Egorov <w.egorov@phytec.de> Link: https://lore.kernel.org/r/20240802152109.137243-3-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2024-08-16remoteproc: k3-dsp: Acquire mailbox handle during probe routineBeleswar Padhi1-50/+30
Acquire the mailbox handle during device probe and do not release handle in stop/detach routine or error paths. This removes the redundant requests for mbox handle later during rproc start/attach. This also allows to defer remoteproc driver's probe if mailbox is not probed yet. Signed-off-by: Beleswar Padhi <b-padhi@ti.com> Acked-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240808074127.2688131-4-b-padhi@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>