summaryrefslogtreecommitdiff
path: root/drivers/interconnect
AgeCommit message (Collapse)AuthorFilesLines
2023-09-23interconnect: Teach lockdep about icc_bw_lock orderRob Clark1-1/+9
commit 13619170303878e1dae86d9a58b039475c957fcf upstream. Teach lockdep that icc_bw_lock is needed in code paths that could deadlock if they trigger reclaim. Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20230807171148.210181-8-robdclark@gmail.com Signed-off-by: Georgi Djakov <djakov@kernel.org> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-23interconnect: Fix locking for runpm vs reclaimRob Clark1-2/+6
[ Upstream commit af42269c3523492d71ebbe11fefae2653e9cdc78 ] For cases where icc_bw_set() can be called in callbaths that could deadlock against shrinker/reclaim, such as runpm resume, we need to decouple the icc locking. Introduce a new icc_bw_lock for cases where we need to serialize bw aggregation and update to decouple that from paths that require memory allocation such as node/link creation/ destruction. Fixes this lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 6.2.0-rc8-debug+ #554 Not tainted ------------------------------------------------------ ring0/132 is trying to acquire lock: ffffff80871916d0 (&gmu->lock){+.+.}-{3:3}, at: a6xx_pm_resume+0xf0/0x234 but task is already holding lock: ffffffdb5aee57e8 (dma_fence_map){++++}-{0:0}, at: msm_job_run+0x68/0x150 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (dma_fence_map){++++}-{0:0}: __dma_fence_might_wait+0x74/0xc0 dma_resv_lockdep+0x1f4/0x2f4 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x80/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 topology_parse_cpu_capacity+0x8c/0x178 get_cpu_for_node+0x88/0xc4 parse_cluster+0x1b0/0x28c parse_cluster+0x8c/0x28c init_cpu_topology+0x168/0x188 smp_prepare_cpus+0x24/0xf8 kernel_init_freeable+0x18c/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #2 (fs_reclaim){+.+.}-{0:0}: __fs_reclaim_acquire+0x3c/0x48 fs_reclaim_acquire+0x54/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 kzalloc.constprop.0+0x14/0x20 icc_node_create_nolock+0x4c/0xc4 icc_node_create+0x38/0x58 qcom_icc_rpmh_probe+0x1b8/0x248 platform_probe+0x70/0xc4 really_probe+0x158/0x290 __driver_probe_device+0xc8/0xe0 driver_probe_device+0x44/0x100 __driver_attach+0xf8/0x108 bus_for_each_dev+0x78/0xc4 driver_attach+0x2c/0x38 bus_add_driver+0xd0/0x1d8 driver_register+0xbc/0xf8 __platform_driver_register+0x30/0x3c qnoc_driver_init+0x24/0x30 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #1 (icc_lock){+.+.}-{3:3}: __mutex_lock+0xcc/0x3c8 mutex_lock_nested+0x30/0x44 icc_set_bw+0x88/0x2b4 _set_opp_bw+0x8c/0xd8 _set_opp+0x19c/0x300 dev_pm_opp_set_opp+0x84/0x94 a6xx_gmu_resume+0x18c/0x804 a6xx_pm_resume+0xf8/0x234 adreno_runtime_resume+0x2c/0x38 pm_generic_runtime_resume+0x30/0x44 __rpm_callback+0x15c/0x174 rpm_callback+0x78/0x7c rpm_resume+0x318/0x524 __pm_runtime_resume+0x78/0xbc adreno_load_gpu+0xc4/0x17c msm_open+0x50/0x120 drm_file_alloc+0x17c/0x228 drm_open_helper+0x74/0x118 drm_open+0xa0/0x144 drm_stub_open+0xd4/0xe4 chrdev_open+0x1b8/0x1e4 do_dentry_open+0x2f8/0x38c vfs_open+0x34/0x40 path_openat+0x64c/0x7b4 do_filp_open+0x54/0xc4 do_sys_openat2+0x9c/0x100 do_sys_open+0x50/0x7c __arm64_sys_openat+0x28/0x34 invoke_syscall+0x8c/0x128 el0_svc_common.constprop.0+0xa0/0x11c do_el0_svc+0xac/0xbc el0_svc+0x48/0xa0 el0t_64_sync_handler+0xac/0x13c el0t_64_sync+0x190/0x194 -> #0 (&gmu->lock){+.+.}-{3:3}: __lock_acquire+0xe00/0x1060 lock_acquire+0x1e0/0x2f8 __mutex_lock+0xcc/0x3c8 mutex_lock_nested+0x30/0x44 a6xx_pm_resume+0xf0/0x234 adreno_runtime_resume+0x2c/0x38 pm_generic_runtime_resume+0x30/0x44 __rpm_callback+0x15c/0x174 rpm_callback+0x78/0x7c rpm_resume+0x318/0x524 __pm_runtime_resume+0x78/0xbc pm_runtime_get_sync.isra.0+0x14/0x20 msm_gpu_submit+0x58/0x178 msm_job_run+0x78/0x150 drm_sched_main+0x290/0x370 kthread+0xf0/0x100 ret_from_fork+0x10/0x20 other info that might help us debug this: Chain exists of: &gmu->lock --> mmu_notifier_invalidate_range_start --> dma_fence_map Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(dma_fence_map); lock(mmu_notifier_invalidate_range_start); lock(dma_fence_map); lock(&gmu->lock); *** DEADLOCK *** 2 locks held by ring0/132: #0: ffffff8087191170 (&gpu->lock){+.+.}-{3:3}, at: msm_job_run+0x64/0x150 #1: ffffffdb5aee57e8 (dma_fence_map){++++}-{0:0}, at: msm_job_run+0x68/0x150 stack backtrace: CPU: 7 PID: 132 Comm: ring0 Not tainted 6.2.0-rc8-debug+ #554 Hardware name: Google Lazor (rev1 - 2) with LTE (DT) Call trace: dump_backtrace.part.0+0xb4/0xf8 show_stack+0x20/0x38 dump_stack_lvl+0x9c/0xd0 dump_stack+0x18/0x34 print_circular_bug+0x1b4/0x1f0 check_noncircular+0x78/0xac __lock_acquire+0xe00/0x1060 lock_acquire+0x1e0/0x2f8 __mutex_lock+0xcc/0x3c8 mutex_lock_nested+0x30/0x44 a6xx_pm_resume+0xf0/0x234 adreno_runtime_resume+0x2c/0x38 pm_generic_runtime_resume+0x30/0x44 __rpm_callback+0x15c/0x174 rpm_callback+0x78/0x7c rpm_resume+0x318/0x524 __pm_runtime_resume+0x78/0xbc pm_runtime_get_sync.isra.0+0x14/0x20 msm_gpu_submit+0x58/0x178 msm_job_run+0x78/0x150 drm_sched_main+0x290/0x370 kthread+0xf0/0x100 ret_from_fork+0x10/0x20 Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20230807171148.210181-7-robdclark@gmail.com Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13interconnect: qcom: bcm-voter: Use enable_maks for keepalive votingKonrad Dybcio1-4/+4
[ Upstream commit 1a70ca71547be051769f0628aa09717694f508f0 ] BCMs with an enable_mask expect to only have that specific value written to them. The current implementation only works by miracle for BCMs with enable mask == BIT(0), as the minimal vote we've been using so far just so happens to be equal to that. Use the correct value with keepalive voting. Fixes: d8630f050d3f ("interconnect: qcom: Add support for mask-based BCMs") Reported-by: Bjorn Andersson <quic_bjorande@quicinc.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230811-topic-icc_fix_1he-v2-2-0620af8ac133@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13interconnect: qcom: bcm-voter: Improve enable_mask handlingKonrad Dybcio1-7/+36
[ Upstream commit a1f4170dec440f023601d57e49227b784074d218 ] We don't need all the complex arithmetic for BCMs utilizing enable_mask, as all we need to do is to determine whether there's any user (or keepalive) asking for it to be on. Separate the logic for such BCMs for a small speed boost. Suggested-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230811-topic-icc_fix_1he-v2-1-0620af8ac133@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Stable-dep-of: 1a70ca71547b ("interconnect: qcom: bcm-voter: Use enable_maks for keepalive voting") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13interconnect: qcom: sm8450: Enable sync_stateKonrad Dybcio1-0/+1
[ Upstream commit 16862f1b2110eca6330e5be6d804e1a08e06a202 ] Enable sync_state on sm8450 so that the interconnect votes actually mean anything and aren't just pinned to INT_MAX. Fixes: fafc114a468e ("interconnect: qcom: Add SM8450 interconnect provider driver") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20230811-topic-8450_syncstate-v1-1-69ae5552a18b@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13interconnect: qcom: qcm2290: Enable sync stateKonrad Dybcio1-0/+1
[ Upstream commit 4e048e9b7a160f7112069c0ec2947be15f3e8154 ] Enable the generic .sync_state callback to ensure there are no outstanding votes that would waste power. Generally one would need a bunch of interface clocks to access the QoS registers when trying to go over all possible nodes during sync_state, but QCM2290 surprisingly does not seem to require any such handling. Fixes: 1a14b1ac3935 ("interconnect: qcom: Add QCM2290 driver support") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230720-topic-qcm2290_icc-v2-2-a2ceb9d3e713@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-08-16interconnect: qcom: sm8450: add enable_mask for bcm nodesNeil Armstrong1-0/+9
commit be02db24cf840bc0fdfbecc78ad803619dd143e6 upstream. Set the proper enable_mask to nodes requiring such value to be used instead of a bandwidth when voting. The masks were copied from the downstream implementation at [1]. [1] https://git.codelinaro.org/clo/la/kernel/msm-5.10/-/blob/KERNEL.PLATFORM.1.0.r2-05600-WAIPIOLE.0/drivers/interconnect/qcom/waipio.c Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230619-topic-sm8550-upstream-interconnect-mask-vote-v2-2-709474b151cc@linaro.org Fixes: fafc114a468e ("interconnect: qcom: Add SM8450 interconnect provider driver") Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-16interconnect: qcom: Add support for mask-based BCMsMike Tipton2-0/+7
commit d8630f050d3fd2079f8617dd6c00c6509109c755 upstream. Some BCMs aren't directly associated with the data path (i.e. ACV) and therefore don't communicate using BW. Instead, they are simply enabled/disabled with a simple bit mask. Add support for these. Origin commit retrieved from: https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/commit/2d1573e0206998151b342e6b52a4c0f7234d7e36 Signed-off-by: Mike Tipton <mdtipton@codeaurora.org> [narmstrong: removed copyright change from original commit] Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230619-topic-sm8550-upstream-interconnect-mask-vote-v2-1-709474b151cc@linaro.org Fixes: fafc114a468e ("interconnect: qcom: Add SM8450 interconnect provider driver") Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-11interconnect: qcom: rpm: drop bogus pm domain attachJohan Hovold3-9/+0
[ Upstream commit 72b2720c18ecde92e6a36c4ac897dd5848e3f379 ] Any power domain would already have been attached by the platform bus code so drop the bogus power domain attach which always succeeds from probe. This effectively reverts commit 7de109c0abe9 ("interconnect: icc-rpm: Add support for bus power domain"). Fixes: 7de109c0abe9 ("interconnect: icc-rpm: Add support for bus power domain") Cc: Yassine Oudjana <y.oudjana@protonmail.com> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org> # MSM8996 Sony Kagura Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230313084953.24088-3-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30interconnect: qcom: qcm2290: Fix MASTER_SNOC_BIMC_NRTKonrad Dybcio1-2/+2
[ Upstream commit 633a12fda6536a1a17bcea29502e777e86a4547e ] Due to what seems to be a copy-paste error, the _NRT master was identical to the _RT master, which should not be the case.. Fix it using the values available from the downstream kernel [1]. [1] https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/scuba-bus.dtsi#127 Fixes: 1a14b1ac3935 ("interconnect: qcom: Add QCM2290 driver support") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Shawn Guo <shawn.guo@linaro.org> Link: https://lore.kernel.org/r/20230103142120.15605-1-konrad.dybcio@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30interconnect: qcom: sm8450: switch to qcom_icc_rpmh_* functionDmitry Baryshkov1-96/+2
[ Upstream commit 87e8fab1917a2b3f6e3dedfd1cdf22a1416e6676 ] Change sm8450 interconnect driver to use generic qcom_icc_rpmh_* functions rather than embedding a copy of thema. This also fixes an overallocation of memory for icc_onecell_data structure. Fixes: fafc114a468e ("interconnect: qcom: Add SM8450 interconnect provider driver") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230105002221.1416479-3-dmitry.baryshkov@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30interconnect: qcom: osm-l3: fix icc_onecell_data allocationDmitry Baryshkov1-1/+1
[ Upstream commit f77ebdda0ee652124061c2ac42399bb6c367e729 ] This is a struct with a trailing zero-length array of icc_node pointers but it's allocated as if it were a single array of icc_nodes instead. Fortunately this overallocates memory rather then allocating less memory than required. Fix by replacing devm_kcalloc() with devm_kzalloc() and struct_size() macro. Fixes: 5bc9900addaf ("interconnect: qcom: Add OSM L3 interconnect provider support") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230105002221.1416479-2-dmitry.baryshkov@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-22interconnect: exynos: fix registration raceJohan Hovold1-10/+10
commit c9e46ca612cfbb0cf890f7ae7389b742e90efe64 upstream. The current interconnect provider registration interface is inherently racy as nodes are not added until the after adding the provider. This can specifically cause racing DT lookups to trigger a NULL-pointer deference when either a NULL pointer or not fully initialised node is returned from exynos_generic_icc_xlate(). Switch to using the new API where the provider is not registered until after it has been fully initialised. Fixes: 2f95b9d5cf0b ("interconnect: Add generic interconnect driver for Exynos SoCs") Cc: stable@vger.kernel.org # 5.11 Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306075651.2449-16-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22interconnect: exynos: fix node leak in probe PM QoS error pathJohan Hovold1-3/+3
commit 3aab264875bf3c915ea2517fae1eec213e0b4987 upstream. Make sure to add the newly allocated interconnect node to the provider before adding the PM QoS request so that the node is freed on errors. Fixes: 2f95b9d5cf0b ("interconnect: Add generic interconnect driver for Exynos SoCs") Cc: stable@vger.kernel.org # 5.11 Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306075651.2449-15-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22interconnect: qcom: msm8974: fix registration raceJohan Hovold1-12/+8
commit bfe7bcd2b9f5215de2144f097f39971180e7ea54 upstream. The current interconnect provider registration interface is inherently racy as nodes are not added until the after adding the provider. This can specifically cause racing DT lookups to fail. Switch to using the new API where the provider is not registered until after it has been fully initialised. Fixes: 4e60a9568dc6 ("interconnect: qcom: add msm8974 driver") Cc: stable@vger.kernel.org # 5.5 Reviewed-by: Brian Masney <bmasney@redhat.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306075651.2449-12-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22interconnect: qcom: rpmh: fix registration raceJohan Hovold1-10/+15
commit 74240a5bebd48d8b843c6d0f1acfaa722a5abeb7 upstream. The current interconnect provider registration interface is inherently racy as nodes are not added until the after adding the provider. This can specifically cause racing DT lookups to fail. Switch to using the new API where the provider is not registered until after it has been fully initialised. Fixes: 976daac4a1c5 ("interconnect: qcom: Consolidate interconnect RPMh support") Cc: stable@vger.kernel.org # 5.7 Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306075651.2449-11-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22interconnect: qcom: rpmh: fix probe child-node error handlingJohan Hovold1-2/+5
commit 6570d1d46eeade82965ccc4a3ab7d778898ef4bf upstream. Make sure to clean up and release resources properly also in case probe fails when populating child devices. Fixes: 57eb14779dfd ("interconnect: qcom: icc-rpmh: Support child NoC device probe") Cc: stable@vger.kernel.org # 6.0 Cc: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306075651.2449-10-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22interconnect: qcom: rpm: fix registration raceJohan Hovold1-12/+12
commit 90ae93d8affc1061cd87ca8ddd9a838c7d31a158 upstream. The current interconnect provider registration interface is inherently racy as nodes are not added until the after adding the provider. This can specifically cause racing DT lookups to fail. Switch to using the new API where the provider is not registered until after it has been fully initialised. Fixes: 62feb14ee8a3 ("interconnect: qcom: Consolidate interconnect RPM support") Fixes: 30c8fa3ec61a ("interconnect: qcom: Add MSM8916 interconnect provider driver") Cc: stable@vger.kernel.org # 5.7 Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Jun Nie <jun.nie@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306075651.2449-9-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22interconnect: qcom: rpm: fix probe child-node error handlingJohan Hovold1-2/+5
commit bc463201f60803fa6bf2741d59441031cd0910e4 upstream. Make sure to clean up and release resources properly also in case probe fails when populating child devices. Fixes: e39bf2972c6e ("interconnect: icc-rpm: Support child NoC device probe") Cc: stable@vger.kernel.org # 5.17 Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306075651.2449-7-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22interconnect: qcom: osm-l3: fix registration raceJohan Hovold1-8/+6
commit 174941ed28a3573db075da46d95b4dcf9d4c49c2 upstream. The current interconnect provider registration interface is inherently racy as nodes are not added until the after adding the provider. This can specifically cause racing DT lookups to fail: of_icc_xlate_onecell: invalid index 0 cpu cpu0: error -EINVAL: error finding src node cpu cpu0: dev_pm_opp_of_find_icc_paths: Unable to get path0: -22 qcom-cpufreq-hw: probe of 18591000.cpufreq failed with error -22 Switch to using the new API where the provider is not registered until after it has been fully initialised. Fixes: 5bc9900addaf ("interconnect: qcom: Add OSM L3 interconnect provider support") Cc: stable@vger.kernel.org # 5.7 Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306075651.2449-6-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22interconnect: fix mem leak when freeing nodesJohan Hovold1-0/+4
commit a5904f415e1af72fa8fe6665aa4f554dc2099a95 upstream. The node link array is allocated when adding links to a node but is not deallocated when nodes are destroyed. Fixes: 11f1ceca7031 ("interconnect: Add generic on-chip interconnect API") Cc: stable@vger.kernel.org # 5.1 Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # i.MX8MP MSC SM2-MB-EP1 Board Link: https://lore.kernel.org/r/20230306075651.2449-2-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22interconnect: imx: fix registration raceJohan Hovold1-10/+10
commit 9fbd35520f1f7f3cbe1873939a27ad9b009f21f9 upstream. The current interconnect provider registration interface is inherently racy as nodes are not added until the after adding the provider. This can specifically cause racing DT lookups to fail. Switch to using the new API where the provider is not registered until after it has been fully initialised. Fixes: f0d8048525d7 ("interconnect: Add imx core driver") Cc: stable@vger.kernel.org # 5.8 Cc: Alexandre Bailon <abailon@baylibre.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # i.MX8MP MSC SM2-MB-EP1 Board Link: https://lore.kernel.org/r/20230306075651.2449-5-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22interconnect: fix provider registration APIJohan Hovold1-14/+38
commit eb59eca0d8ac15f8c1b7f1cd35999455a90292c0 upstream. The current interconnect provider interface is inherently racy as providers are expected to be added before being fully initialised. Specifically, nodes are currently not added and the provider data is not initialised until after registering the provider which can cause racing DT lookups to fail. Add a new provider API which will be used to fix up the interconnect drivers. The old API is reimplemented using the new interface and will be removed once all drivers have been fixed. Fixes: 11f1ceca7031 ("interconnect: Add generic on-chip interconnect API") Fixes: 87e3031b6fbd ("interconnect: Allow endpoints translation via DT") Cc: stable@vger.kernel.org # 5.1 Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # i.MX8MP MSC SM2-MB-EP1 Board Link: https://lore.kernel.org/r/20230306075651.2449-4-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22interconnect: fix icc_provider_del() error handlingJohan Hovold1-12/+2
commit e0e7089bf9a87bc5e3997422e4e24563424f9018 upstream. The interconnect framework currently expects that providers are only removed when there are no users and after all nodes have been removed. There is currently nothing that guarantees this to be the case and the framework does not do any reference counting, but refusing to remove the provider is never correct as that would leave a dangling pointer to a resource that is about to be released in the global provider list (e.g. accessible through debugfs). Replace the current sanity checks with WARN_ON() so that the provider is always removed. Fixes: 11f1ceca7031 ("interconnect: Add generic on-chip interconnect API") Cc: stable@vger.kernel.org # 5.1: 680f8666baf6: interconnect: Make icc_provider_del() return void Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # i.MX8MP MSC SM2-MB-EP1 Board Link: https://lore.kernel.org/r/20230306075651.2449-3-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-01interconnect: qcom: msm8996: Fix regmap max_register valuesKonrad Dybcio1-5/+5
[ Upstream commit 4be39d5d86c690c60e2afe55787fc5ec4409d0f0 ] The device tree reg starts at BUS_BASE + QoS_OFFSET, but the regmap configs in the ICC driver had values suggesting the reg started at BUS_BASE. Shrink them down (where they haven't been already, so for providers where QoS_OFFSET = 0) to make sure they stay within their window. Fixes: 7add937f5222 ("interconnect: qcom: Add MSM8996 interconnect provider driver") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> #db820c Link: https://lore.kernel.org/r/20221210200353.418391-4-konrad.dybcio@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-01interconnect: qcom: msm8996: Provide UFS clocks to A2NoCKonrad Dybcio1-0/+9
[ Upstream commit 60426ff08af6a21275d9c879c0dfb09406469868 ] On eMMC devices the bootloader has no business enabling UFS clocks. That results in a platform hang and hard reboot when trying to vote on paths including MASTER_UFS and since sync_state guarantees that it's done at boot time, this effectively prevents such devices from booting. Fix that. Fixes: 7add937f5222 ("interconnect: qcom: Add MSM8996 interconnect provider driver") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> #db820c Link: https://lore.kernel.org/r/20221210200353.418391-3-konrad.dybcio@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31interconnect: qcom: sc7180: fix dropped const of qcom_icc_bcmKrzysztof Kozlowski1-1/+1
[ Upstream commit f24227a640344f894522045f74bb2decbdc4f55e ] Pointers to struct qcom_icc_bcm are const, but the change was dropped during merge. Fixes: 016fca59f95f ("Merge branch 'icc-const' into icc-next") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20221027154848.293523-1-krzysztof.kozlowski@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-20Merge branch 'icc-ignore-return-val' into icc-nextGeorgi Djakov12-19/+33
Today remove callbacks of platform devices return an int. This is unfortunate because the device core ignores the return value and so the platform code only emits a warning (and still removes the device). The longterm quest is to make these remove callbacks return void instead. This series is a preparation for that, with the goal to make the remove callbacks obviously always return 0. This way when the prototype of these functions is changed to return void, the change is straight forward and easy to review. Link: https://lore.kernel.org/r/20220718121409.171773-1-u.kleine-koenig@pengutronix.de Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-09-20interconnect: qcom: Kconfig: Make INTERCONNECT_QCOM tristateHuang Yiwei2-1/+4
Make INTERCONNECT_QCOM tristate so that icc-common.c can be compiled as a module. Signed-off-by: Huang Yiwei <quic_hyiwei@quicinc.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220914064122.16222-1-quic_hyiwei@quicinc.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-08-18interconnect: imx: Make imx_icc_unregister() return voidUwe Kleine-König6-8/+14
The function imx_icc_unregister() returns zero unconditionally. Make it return void. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220718121409.171773-9-u.kleine-koenig@pengutronix.de Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-08-16interconnect: Make icc_provider_del() return voidUwe Kleine-König1-7/+3
All users ignore the return value of icc_provider_del(). Consequently make it not return an error code. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220718121409.171773-8-u.kleine-koenig@pengutronix.de Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-08-16interconnect: sm8450: Ignore return value of icc_provider_del() in .remove()Uwe Kleine-König1-1/+3
icc_provider_del() already emits an error message on failure. In this case letting .remove() return the corresponding error code results in another error message and the device is removed anyhow. (See platform_remove().) So ignore the return value of icc_provider_del() and return 0 unconditionally. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220718121409.171773-7-u.kleine-koenig@pengutronix.de Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-08-16interconnect: osm-l3: Ignore return value of icc_provider_del() in .remove()Uwe Kleine-König1-1/+3
icc_provider_del() already emits an error message on failure. In this case letting .remove() return the corresponding error code results in another error message and the device is removed anyhow. (See platform_remove().) So ignore the return value of icc_provider_del() and return 0 unconditionally. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220718121409.171773-6-u.kleine-koenig@pengutronix.de Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-08-16interconnect: msm8974: Ignore return value of icc_provider_del() in .remove()Uwe Kleine-König1-1/+3
icc_provider_del() already emits an error message on failure. In this case letting .remove() return the corresponding error code results in another error message and the device is removed anyhow. (See platform_remove().) So ignore the return value of icc_provider_del() and return 0 unconditionally. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220718121409.171773-5-u.kleine-koenig@pengutronix.de Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-08-16interconnect: icc-rpmh: Ignore return value of icc_provider_del() in .remove()Uwe Kleine-König1-1/+3
icc_provider_del() already emits an error message on failure. In this case letting .remove() return the corresponding error code results in another error message and the device is removed anyhow. (See platform_remove().) So ignore the return value of icc_provider_del() and return 0 unconditionally. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220718121409.171773-4-u.kleine-koenig@pengutronix.de Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-08-16interconnect: icc-rpm: Ignore return value of icc_provider_del() in .remove()Uwe Kleine-König1-1/+3
icc_provider_del() already emits an error message on failure. In this case letting .remove() return the corresponding error code results in another error message and the device is removed anyhow. (See platform_remove().) So ignore the return value of icc_provider_del() and return 0 unconditionally. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220718121409.171773-3-u.kleine-koenig@pengutronix.de Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-08-16interconnect: imx: Ignore return value of icc_provider_del() in .remove()Uwe Kleine-König1-1/+3
icc_provider_del() already emits an error message on failure. In this case letting .remove() return the corresponding error code results in another error message and the device is removed anyhow. (See platform_remove().) So ignore the return value of icc_provider_del() and return 0 unconditionally. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220718121409.171773-2-u.kleine-koenig@pengutronix.de Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-07-15Merge branch 'icc-rpm' into icc-nextGeorgi Djakov8-52/+200
This patch set is to support bucket in icc-rpm driver, so it implements the similar mechanism in the icc-rpmh driver. It uses interconnect path tag to indicate the bandwidth voting is for which buckets, and there have three kinds of buckets: AWC, WAKE and SLEEP, finally the wake and sleep bucket values are used to set the corresponding clock (active and sleep clocks). So far, we keep the AWC bucket but doesn't really use it. Link: https://lore.kernel.org/r/20220712015929.2789881-1-leo.yan@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-07-15Merge branch 'icc-imx8mp' into icc-nextGeorgi Djakov9-21/+425
This patchset is to support i.MX8MP NoC settings, i.MX8MP NoC initial value after power up is invalid, need set a valid value after related power domain up. This patchset also includes two patch[1,2] during my development to enable the ICC feature for i.MX8MP. I not include ddrc DVFS in this patchset, ths patchset is only to support NoC value mode/priority/ext_control being set to a valid value that suggested by i.MX Chip Design Team. The value is same as NXP downstream one inside Arm Trusted Firmware: https://source.codeaurora.org/external/imx/imx-atf/tree/plat/imx/imx8m/i/gpc.c?h=lf_v2.4#n97 Link: https://lore.kernel.org/r/20220703091132.1412063-1-peng.fan@oss.nxp.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-07-15interconnect: imx: Add platform driver for imx8mpPeng Fan3-0/+265
Add a platform driver for the i.MX8MP SoC describing bus topology, based on internal documentation. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20220703091132.1412063-9-peng.fan@oss.nxp.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-07-15interconnect: imx: configure NoC mode/prioriry/ext_controlPeng Fan5-9/+90
Introduce imx_icc_noc_setting structure to describe a master port setting Pass imx_icc_noc_setting as a parameter from specific driver Set priority level, mode, ext control in imx_icc_node_set Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20220703091132.1412063-8-peng.fan@oss.nxp.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-07-15interconnect: imx: introduce imx_icc_providerPeng Fan2-10/+20
Introduce imx_icc_provider as a wrapper of icc_provider to add i.MX specific information. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20220703091132.1412063-7-peng.fan@oss.nxp.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-07-15interconnect: imx: set src nodePeng Fan1-0/+6
When set QoS for a icc path, only set dst icc node is not enough, also need to set src icc node. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20220703091132.1412063-6-peng.fan@oss.nxp.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-07-15interconnect: imx: fix max_node_idPeng Fan1-4/+4
max_node_id not equal to the ARRAY_SIZE of node array, need increase 1, otherwise xlate will fail for the last entry. And rename max_node_id to num_nodes to reflect the reality. Fixes: f0d8048525d7d ("interconnect: Add imx core driver") Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20220703091132.1412063-5-peng.fan@oss.nxp.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-07-12interconnect: qcom: icc-rpm: Set bandwidth and clock for bucket valuesLeo Yan1-14/+61
This commit uses buckets for support bandwidth and clock rates. It introduces a new function qcom_icc_bus_aggregate() to calculate the aggregate average and peak bandwidths for every bucket, and also it calculates the maximum value of aggregated average bandwidth across all buckets. The maximum aggregated average is used to calculate the final bandwidth requests. And we can set the clock rate per bucket, we use SLEEP bucket as default bucket if a platform doesn't enable the interconnect path tags in DT binding; otherwise, we use WAKE bucket to set active clock and use SLEEP bucket for other clocks. So far we don't use AMC bucket. Signed-off-by: Leo Yan <leo.yan@linaro.org> Link: https://lore.kernel.org/r/20220712015929.2789881-6-leo.yan@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-07-12interconnect: qcom: icc-rpm: Support multiple bucketsLeo Yan2-1/+56
The current interconnect rpm driver uses a single aggregate bandwidth to calculate the clock rates for both active and sleep clocks; therefore, it has no chance to separate bandwidth requests for these two kinds of clocks. This patch studies the implementation from interconnect rpmh driver to support multiple buckets. The rpmh driver provides three buckets for AMC, WAKE, and SLEEP; this driver only needs to use WAKE and SLEEP buckets, but we keep the same way with rpmh driver, this can allow us to reuse the DT binding and avoid to define duplicated data structures. This patch introduces two callbacks: qcom_icc_pre_bw_aggregate() is used to clean up bucket values before aggregate bandwidth requests, and qcom_icc_bw_aggregate() is to aggregate bandwidth for buckets. Signed-off-by: Leo Yan <leo.yan@linaro.org> Link: https://lore.kernel.org/r/20220712015929.2789881-5-leo.yan@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-07-12interconnect: qcom: icc-rpm: Change to use qcom_icc_xlate_extended()Leo Yan1-1/+2
This commit changes to use callback qcom_icc_xlate_extended(). This is a preparation for population path tags from the interconnect DT binding, it doesn't introduce functionality change for the existed DT binding without path tags. Signed-off-by: Leo Yan <leo.yan@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220712015929.2789881-4-leo.yan@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-07-12interconnect: qcom: Move qcom_icc_xlate_extended() to a common fileLeo Yan6-26/+52
since there have conflict between two headers icc-rpmh.h and icc-rpm.h, the function qcom_icc_xlate_extended() is declared in icc-rpmh.h thus it cannot be used by icc-rpm driver. Move the function to a new common file icc-common.c so that allow it to be called by multiple drivers. Signed-off-by: Leo Yan <leo.yan@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220712015929.2789881-3-leo.yan@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-07-07interconnect: icc-rpm: Set destination bandwidth as well as source bandwidthBryan O'Donoghue1-11/+30
Make it possible to set destination as well as source bandwidth. If the *dst pointer is non-NULL. Right now it appears that we never make the destination bw allocation call, which is inconsistent with the downstream way of doing this. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20220707093823.1691870-1-bryan.odonoghue@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-07-05Merge branch 'icc-sm6350' into icc-nextGeorgi Djakov5-0/+647
This series adds interconnect support for the various NoCs found on sm6350. A more special modification is allowing child NoC devices, like done for rpm-based qcm2290 which was already merged, but now for rpmh-based interconnect. See also downstream dts: https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/tags/android-11.0.0_r0.81/qcom/lagoon-bus.dtsi Link: https://lore.kernel.org/r/20220525144404.200390-1-luca.weiss@fairphone.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-01-21 21:47:34 +0300