MSM8974 requires a separate get_bw callback, since on that platform
increasing the clock rate for some of the NoCs during boot may lead to
hangs. For the details see commit 9caf2d956cfa ("interconnect: qcom:
msm8974: Don't boost the NoC rate during boot").

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 drivers/interconnect/qcom/icc-rpm.c | 1 +
 drivers/interconnect/qcom/icc-rpm.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/interconnect/qcom/icc-rpm.c b/drivers/interconnect/qcom/icc-rpm.c
index ea1042d38128..aec2f84cd56f 100644
--- a/drivers/interconnect/qcom/icc-rpm.c
+++ b/drivers/interconnect/qcom/icc-rpm.c
@@ -553,6 +553,7 @@ int qnoc_probe(struct platform_device *pdev)
 	provider->aggregate = qcom_icc_bw_aggregate;
 	provider->xlate_extended = qcom_icc_xlate_extended;
 	provider->data = data;
+	provider->get_bw = desc->get_bw;
 
 	icc_provider_init(provider);
 
diff --git a/drivers/interconnect/qcom/icc-rpm.h b/drivers/interconnect/qcom/icc-rpm.h
index 3366531f66fc..cbf0a365839d 100644
--- a/drivers/interconnect/qcom/icc-rpm.h
+++ b/drivers/interconnect/qcom/icc-rpm.h
@@ -135,6 +135,7 @@ struct qcom_icc_desc {
 	unsigned int qos_offset;
 	u16 ab_coeff;
 	u16 ib_coeff;
+	int (*get_bw)(struct icc_node *node, u32 *avg, u32 *peak);
 };
 
 /* Valid for all bus types */

-- 
2.47.3

On 3/23/26 2:17 AM, Dmitry Baryshkov wrote:
> MSM8974 requires a separate get_bw callback, since on that platform
> increasing the clock rate for some of the NoCs during boot may lead to
> hangs. For the details see commit 9caf2d956cfa ("interconnect: qcom:
> msm8974: Don't boost the NoC rate during boot").

Is there a single specific bus where this causes an issue, or is
setting *any* resource to INT_MAX problematic?

Konrad

On Mon, Mar 23, 2026 at 11:32:33AM +0100, Konrad Dybcio wrote:
> On 3/23/26 2:17 AM, Dmitry Baryshkov wrote:
> > MSM8974 requires a separate get_bw callback, since on that platform
> > increasing the clock rate for some of the NoCs during boot may lead to
> > hangs. For the details see commit 9caf2d956cfa ("interconnect: qcom:
> > msm8974: Don't boost the NoC rate during boot").
> 
> Is there a single specific bus where this causes an issue, or is
> setting *any* resource to INT_MAX problematic?

I'd refer this to Luca. I didn't experiment that much (and also note,
this behaviour might be firmware-specific).

My goal for this patchset was to port as close as possible. We can drop
the get_bw later, after enabling more interconnects, writing the QoS,
etc.

-- 
With best wishes
Dmitry

On 3/24/26 12:14 AM, Dmitry Baryshkov wrote:
> On Mon, Mar 23, 2026 at 11:32:33AM +0100, Konrad Dybcio wrote:
>> On 3/23/26 2:17 AM, Dmitry Baryshkov wrote:
>>> MSM8974 requires a separate get_bw callback, since on that platform
>>> increasing the clock rate for some of the NoCs during boot may lead to
>>> hangs. For the details see commit 9caf2d956cfa ("interconnect: qcom:
>>> msm8974: Don't boost the NoC rate during boot").
>>
>> Is there a single specific bus where this causes an issue, or is
>> setting *any* resource to INT_MAX problematic?
> 
> I'd refer this to Luca. I didn't experiment that much (and also note,
> this behaviour might be firmware-specific).

In case anyone's interested, it _seems like_ it's

(RPM_KEY_BW + RPM_BUS_MASTER_REQ/RPM_BUS_SLAVE_REQ) failing with certain
nodes

> My goal for this patchset was to port as close as possible. We can drop
> the get_bw later, after enabling more interconnects, writing the QoS,
> etc.

That's fine

Konrad

On Tue, Mar 24, 2026 at 12:34:35PM +0100, Konrad Dybcio wrote:
> On 3/24/26 12:14 AM, Dmitry Baryshkov wrote:
> > On Mon, Mar 23, 2026 at 11:32:33AM +0100, Konrad Dybcio wrote:
> >> On 3/23/26 2:17 AM, Dmitry Baryshkov wrote:
> >>> MSM8974 requires a separate get_bw callback, since on that platform
> >>> increasing the clock rate for some of the NoCs during boot may lead to
> >>> hangs. For the details see commit 9caf2d956cfa ("interconnect: qcom:
> >>> msm8974: Don't boost the NoC rate during boot").
> >>
> >> Is there a single specific bus where this causes an issue, or is
> >> setting *any* resource to INT_MAX problematic?
> > 
> > I'd refer this to Luca. I didn't experiment that much (and also note,
> > this behaviour might be firmware-specific).
> 
> In case anyone's interested, it _seems like_ it's
> 
> (RPM_KEY_BW + RPM_BUS_MASTER_REQ/RPM_BUS_SLAVE_REQ) failing with certain
> nodes

Yes. And if you check, these nodes have QoS settings in the DT. Later
kernels have added a guard check (.qos.ap_owned) and dropped mas/slv IDs
for similar nodes.

> > My goal for this patchset was to port as close as possible. We can drop
> > the get_bw later, after enabling more interconnects, writing the QoS,
> > etc.
> 
> That's fine

Rb?

-- 
With best wishes
Dmitry