user/sven/linux.git/drivers/interconnect, branch v5.18.16

interconnect: Restore sync state by ignoring ipa-virt in provider count

2022-05-03T19:24:21Z

Ignore compatible strings for the IPA virt drivers that were removed in commits 2fb251c26560 ("interconnect: qcom: sdx55: Drop IP0 interconnects") and 2f3724930eb4 ("interconnect: qcom: sc7180: Drop IP0 interconnects") so that the sync state logic can kick in again. Otherwise all the interconnects in the system will stay pegged at max speeds because 'providers_count' is always going to be one larger than the number of drivers that will ever probe on sc7180 or sdx55. This fixes suspend on sc7180 and sdx55 devices when you don't have a devicetree patch to remove the ipa-virt compatible node. Cc: Bjorn Andersson Cc: Doug Anderson Cc: Alex Elder Cc: Taniya Das Cc: Mike Tipton Fixes: 2fb251c26560 ("interconnect: qcom: sdx55: Drop IP0 interconnects") Fixes: 2f3724930eb4 ("interconnect: qcom: sc7180: Drop IP0 interconnects") Signed-off-by: Stephen Boyd Reviewed-by: Alex Elder Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20220427013226.341209-1-swboyd@chromium.org Signed-off-by: Georgi Djakov

interconnect: qcom: sdx55: Drop IP0 interconnects

2022-04-14T06:47:16Z

Similar to the sc7180 commit, let's drop the IP0 interconnects here because the IP0 resource is also used in the clk-rpmh driver on sdx55. It's bad to have the clk framework and interconnect framework control the same RPMh resource without any coordination. The rpmh driver in the kernel doesn't aggregate resources between clients either, so leaving control to clk-rpmh avoids any issues with unused interconnects turning off IP0 behind the back of the clk framework. Cc: Alex Elder Cc: Manivannan Sadhasivam Cc: Bjorn Andersson Cc: Taniya Das Cc: Mike Tipton Fixes: b2150cab9a97 ("clk: qcom: rpmh: add support for SDX55 rpmh IPA clock") Signed-off-by: Stephen Boyd Reviewed-by: Alex Elder Acked-by: Manivannan Sadhasivam Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220412220033.1273607-3-swboyd@chromium.org Signed-off-by: Georgi Djakov

interconnect: qcom: sc7180: Drop IP0 interconnects

2022-04-14T06:45:56Z

The IPA BCM resource ("IP0") on sc7180 was moved to the clk-rpmh driver in commit bcd63d222b60 ("clk: qcom: rpmh: Add IPA clock for SC7180") and modeled as a clk, but this interconnect driver still had it modeled as an interconnect. This was mostly OK because nobody used the interconnect definition, until the interconnect framework started dropping bandwidth requests on interconnects that aren't used via the sync_state callback in commit 7d3b0b0d8184 ("interconnect: qcom: Use icc_sync_state"). Once that patch was applied the IP0 resource was going to be controlled from two places, the clk framework and the interconnect framework. Even then, things were probably going to be OK, because commit b95b668eaaa2 ("interconnect: qcom: icc-rpmh: Add BCMs to commit list in pre_aggregate") was needed to actually drop bandwidth requests on unused interconnects, of which the IPA was one of the interconnect that wasn't getting dropped to zero. Combining the three commits together leads to bad behavior where the interconnect framework is disabling the IP0 resource because it has no users while the clk framework thinks the IP0 resource is on because the only user, the IPA driver, has turned it on via clk_prepare_enable(). Depending on when sync_state is called, we can get into a situation like below: IPA driver probes IPA driver gets notified modem started runtime PM get() IPA clk enabled -> IP0 resource is ON sync_state runs interconnect zeroes out the IP0 resource -> IP0 resource is off IPA driver tries to access a register and blows up The crash is an unclocked access that manifest as an SError. SError Interrupt on CPU0, code 0xbe000011 -- SError CPU: 0 PID: 3595 Comm: mmdata_mgr Not tainted 5.17.1+ #166 Hardware name: Google Lazor (rev1 - 2) with LTE (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mutex_lock+0x4c/0x80 lr : mutex_lock+0x30/0x80 sp : ffffffc00da9b9c0 x29: ffffffc00da9b9c0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffffc00da9bc90 x25: ffffff80c2024010 x24: ffffff80c2024000 x23: ffffff8083100000 x22: ffffff80831000d0 x21: ffffff80831000a8 x20: ffffff80831000a8 x19: ffffff8083100070 x18: 00000000ffff0a00 x17: 000000002f7254f1 x16: 0000000000000100 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 000000000001f0b8 x10: ffffffc00931f0b8 x9 : 0000000000000000 x8 : 0000000000000000 x7 : fefefefefeff2f60 x6 : 0000808080808080 x5 : 0000000000000000 x4 : 8080808080800000 x3 : ffffff80d2d4ee28 x2 : ffffff808c1d6e40 x1 : 0000000000000000 x0 : ffffff8083100070 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 0 PID: 3595 Comm: mmdata_mgr Not tainted 5.17.1+ #166 Hardware name: Google Lazor (rev1 - 2) with LTE (DT) Call trace: dump_backtrace+0xf4/0x114 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 panic+0x150/0x38c nmi_panic+0x88/0xa0 arm64_serror_panic+0x74/0x80 do_serror+0x0/0x80 do_serror+0x58/0x80 el1h_64_error_handler+0x34/0x4c el1h_64_error+0x78/0x7c mutex_lock+0x4c/0x80 __gsi_channel_start+0x50/0x17c gsi_channel_start+0x54/0x90 ipa_endpoint_enable_one+0x34/0xc0 ipa_open+0x4c/0x120 Remove all IP0 resource management from the interconnect driver so that clk-rpmh is the sole owner. This fixes the issue by preventing the interconnect driver from overwriting the IP0 resource data that the clk-rpmh driver wrote. Cc: Alex Elder Cc: Bjorn Andersson Cc: Taniya Das Cc: Mike Tipton Fixes: b95b668eaaa2 ("interconnect: qcom: icc-rpmh: Add BCMs to commit list in pre_aggregate") Fixes: bcd63d222b60 ("clk: qcom: rpmh: Add IPA clock for SC7180") Fixes: 7d3b0b0d8184 ("interconnect: qcom: Use icc_sync_state") Signed-off-by: Stephen Boyd Tested-by: Alex Elder Reviewed-by: Alex Elder Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220412220033.1273607-2-swboyd@chromium.org Signed-off-by: Georgi Djakov

Merge branch 'icc-msm8939' into icc-next

2022-03-01T14:31:35Z

Booting msm8939 on tip-of-tree I encountered the following error. [ 1.212340] qnoc-msm8939 580000.interconnect_mm: can't request region for resource [mem 0x00580000-0x0059407f] [ 1.212391] qnoc-msm8939 580000.interconnect_mm: Cannot ioremap interconnect bus resource [ 1.221524] qnoc-msm8939: probe of 580000.interconnect_mm failed with error -16 Initially I thought this was a bug with the interconnect driver but, examining it a bit more I realized the DTS I was working with based on downstream, declares snoc and snoc_mm as existing at the same address range. When we were developing the DTS for 8939 we weren't using the common rpm interconnect driver so we never saw the ioremap collision. Taking a hard look at the qcom documentation as well as the downstream code we see that yes downstream declares snoc and snoc_mm separately but, also at the same overlapping address. The qcom documentation for performance points for msm8936/msm8939 snoc, deliniates snoc_mm as simply two new performance-points i.e. a faster GPLL0 vote associated with new multi-media devices attached to the snoc. In other words the snoc had two new RPM vote indices added to it, to represent the higher performance clocks, should one of the multi-media IP blocks call for it. We can fix the ioremap collision and still represent the two higher performance point clock votes by coalsecing snoc and snoc_mm into snoc. The DTS clock references will take care of the appropriate votes. V2: Made snoc-mm into a child of snoc - Dmitry Removes redundant msm8939_snoc_mm_regmap_config - bod Link: https://lore.kernel.org/r/20220129032735.2410936-1-bryan.odonoghue@linaro.org Signed-off-by: Georgi Djakov

interconnect: qcom: msm8939: Remove snoc_mm specific regmap

2022-02-10T10:40:59Z

Booting tip-of-tree on msm8939 we find the following error caused by our modelling of snoc and snoc_mm as peer devices with the same address space. [ 1.212340] qnoc-msm8939 580000.interconnect_mm: can't request region for resource [mem 0x00580000-0x0059407f] [ 1.212391] qnoc-msm8939 580000.interconnect_mm: Cannot ioremap interconnect bus resource [ 1.221524] qnoc-msm8939: probe of 580000.interconnect_mm failed with error -16 Declaring snoc_mm as a child device of snoc mitigates the fault and is consistent with a similar extant implementation in qcm2290. Signed-off-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20220129032735.2410936-3-bryan.odonoghue@linaro.org Signed-off-by: Georgi Djakov

interconnect: imx: Add imx_icc_get_bw function to set initial avg and peak

2022-01-23T21:32:48Z

Set the initial avg and peak to 0 in order to avoid setting them to INT_MAX by the interconnect core. Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20220106170501.3513423-1-abel.vesa@nxp.com Signed-off-by: Georgi Djakov

Merge branch 'icc-qcm2290' into icc-next

2021-12-15T05:14:27Z

Add support for QCM2290 including a few prep changes. * icc-qcm2290 interconnect: icc-rpm: Define ICC device type interconnect: icc-rpm: Add QNOC type QoS support interconnect: icc-rpm: Support child NoC device probe dt-bindings: interconnect: Add Qualcomm QCM2290 NoC support interconnect: qcom: Add QCM2290 driver support Link: https://lore.kernel.org/r/20211215002324.1727-1-shawn.guo@linaro.org Signed-off-by: Georgi Djakov

interconnect: qcom: Add QCM2290 driver support

2021-12-15T05:13:16Z

It adds interconnect driver support for QCM2290 platform. The topology consists of 3 NoCs: BIMC, Config NoC (CNOC) and System NoC (SNOC). SNOC is a QCOM_ICC_QNOC type device, as well as its 3 virtual child devices, QUP, MMNRT and MMRT. QUP is owned by RPM and thus has no .regmap_cfg, while the other 2 share the same .regmap_cfg with SNOC (parent). Signed-off-by: Shawn Guo Link: https://lore.kernel.org/r/20211215002324.1727-6-shawn.guo@linaro.org Signed-off-by: Georgi Djakov

interconnect: icc-rpm: Support child NoC device probe

2021-12-15T05:12:56Z

As shown in downstream DT[1], the System NoC of QCM2290 is modelled using 4 fab/noc devices: sys_noc + qup_virt + mmnrt_virt + mmrt_virt. Among those 3 virtual devices, qup is owned by RPM and has no regmap resource, while mmnrt and mmrt are owned by AP and share the same regmap as sys_noc. So it's logical to represent these virtual devices as child nodes of sys_noc in DT, so that such configuration can be supported with a couple of changes on qnoc_probe(): - If there are child nodes, populate them. - If the device descriptor has .regmap_cfg but there is no IOMEM resource for the device, use parent's regmap. [1] https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/tags/android-11.0.0_r0.56/qcom/scuba-bus.dtsi Signed-off-by: Shawn Guo Link: https://lore.kernel.org/r/20211215002324.1727-4-shawn.guo@linaro.org Signed-off-by: Georgi Djakov

interconnect: icc-rpm: Add QNOC type QoS support

2021-12-15T05:12:46Z

It adds QoS support for QNOC type device which can be found on QCM2290 platform. The downstream driver[1] includes support for priority, limiter, regulator and forwarding setup. As QCM2290 support only requires priority and forwarding configuration, limiter and regulator support are omitted for this initial submission. [1] https://source.codeaurora.org/quic/la/kernel/msm-4.19/tree/drivers/soc/qcom/msm_bus/msm_bus_qnoc_adhoc.c?h=kernel.lnx.4.19.r22-rel Signed-off-by: Shawn Guo Link: https://lore.kernel.org/r/20211215002324.1727-3-shawn.guo@linaro.org Signed-off-by: Georgi Djakov