Re: [PATCH v3] interconnect: qcom: implement get_bw with rpmh_read

From: Shawn Guo

Date: Tue Sep 22 2026 - 03:15:54 EST


On Wed, Sep 09, 2026 at 05:26:29PM +0200, Neil Armstrong wrote:
> Since we can actually read back the APPS rpmh interconnect
> BCM votes we can actually implement the get_bw() callback
> and provide a coherent average and peak bandwidth at probe time.
>
> The benefits of that are:
> - keep disabled BCMs disabled
> - avoid voting unused BCMs to INT_MAX
>
> If the interconnects are correctly described for a platform,
> all the required BCMs would be voted to the maximum bandwidth
> until sync_state is reached.
>
> Since we only get the BCM vote, we need to redistribute
> the vote values to the associated nodes. The initial BCM
> votes are read back at probe time in order to be ready when
> the get_bw() is called when a node is added.
>
> Tested-by: Georgi Djakov <djakov@xxxxxxxxxx> #db845c
> Signed-off-by: Neil Armstrong <neil.armstrong@xxxxxxxxxx>

This causes a linux-next regression on Nord platforms. I guess it's more
than just Nord.

[ 1.729012] Internal error: synchronous external abort: 0000000096001610 [#1] SMP
[ 1.729014] Modules linked in:
[ 1.729019] CPU: 13 UID: 0 PID: 156 Comm: kworker/u75:1 Tainted: G M 7.3.0-rc4-next-20260921-00010-gb1438d2a2208 #248 PREEMPT(full)
[ 1.729196] vreg_l8a_1p8: Setting 1800000-1800000uV
[ 1.729375] vreg_s1a_vdd2h_l: Setting 904000-1096000uV
[ 1.729553] vreg_s3a_1p8: Setting 1800000-1800000uV
[ 1.729733] vreg_s5a_mv: Setting 1328000-1368000uV
[ 1.729913] vreg_s6a_vddq_l: Setting 504000-568000uV
[ 1.734224] vreg_l3f_vdd1: Setting 1800000-1800000uV
[ 1.739052] Tainted: [M]=MACHINE_CHECK
[ 1.739052] Hardware name: Qualcomm Technologies, Inc. SA8797P Ride Embedded (DT)
[ 1.739053] Workqueue: events_unbound deferred_probe_work_func
[ 1.744610] vreg_s7f_lv_sub: Setting 1040000-1136000uV
[ 1.749261]
[ 1.749262] pstate: 214000c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 1.749263] pc : regmap_mmio_read32le+0xc/0xa4
[ 1.754473] vreg_s8f_vddq_h: Setting 504000-568000uV
[ 1.759295] lr : regmap_mmio_read+0x44/0x70
[ 1.759297] sp : ffff80008153b9f0
[ 1.759298] x29: ffff80008153b9f0 x28: 0000000000000001 x27: ffffd5167fb5c7f0
[ 1.875707] x26: ffffd5167fb5c678 x25: 0000000000000000 x24: 0000000000000000
[ 1.883040] x23: 0000000001000000 x22: ffff000890e5a800 x21: ffff80008153ba84
[ 1.890372] x20: 0000000000057008 x19: ffff00088deff380 x18: 0000000000000000
[ 1.897705] x17: 000000000000000c x16: 0000000000000000 x15: 0000000000000018
[ 1.905037] x14: 0000000000000000 x13: 7463656e6e6f6372 x12: 65746e692e303030
[ 1.912369] x11: ffff8000828f4000 x10: 000000000006c9e8 x9 : 0000000000000004
[ 1.919702] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000
[ 1.927034] x5 : ffffd5167f1a0678 x4 : 0000000000057008 x3 : 0000000000057008
[ 1.934366] x2 : ffffd5167f1a0e4c x1 : 0000000000057008 x0 : ffff8000828d7008
[ 1.941699] Call trace:
[ 1.944220] regmap_mmio_read32le+0xc/0xa4 (P)
[ 1.948789] _regmap_bus_reg_read+0x70/0xb0
[ 1.953097] _regmap_read+0x60/0xd8
[ 1.956683] _regmap_update_bits+0xfc/0x14c
[ 1.960990] regmap_update_bits_base+0x64/0x98
[ 1.965558] qcom_icc_rpmh_probe+0x44c/0x540
[ 1.969954] platform_probe+0x5c/0x9c
[ 1.973725] really_probe+0xbc/0x29c
[ 1.977409] __driver_probe_device+0x16c/0x19c
[ 1.981977] driver_probe_device+0x3c/0x114
[ 1.986285] __device_attach_driver+0xb8/0x118
[ 1.990853] bus_for_each_drv+0x88/0xe8
[ 1.994796] __device_attach+0xa0/0x190
[ 1.998739] device_initial_probe+0x50/0x54
[ 2.003046] bus_probe_device+0x38/0xa0
[ 2.006989] deferred_probe_work_func+0x88/0xc0
[ 2.011653] process_one_work+0x180/0x2dc
[ 2.015784] worker_thread+0x184/0x2fc
[ 2.019639] kthread+0x118/0x124
[ 2.022959] ret_from_fork+0x10/0x20
[ 2.026647] Code: d65f03c0 f9400000 8b214000 d503201f (b9400000)
[ 2.032913] ---[ end trace 0000000000000000 ]---

I sent a fixup as:

https://lore.kernel.org/all/20260922020623.398913-1-shengchao.guo@xxxxxxxxxxxxxxxx/

Shawn