Re: [PATCH 1/2] soc: qcom: geni-se: Correct QUP Core ICC vote constants

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The new Bps constants for QUP Core 2X clock votes are too large and will be clamped by the RPMh BCM voter, breaking dynamic bandwidth scaling for frequencies >= 150 MHz.
--

commit 4b7db07800053a04e9ce8152ed56486618d8f495
Author: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Date:   Tue Sep 8 19:05:33 2026 +0000

soc: qcom: geni-se: Correct QUP Core ICC vote constants

This commit corrects the QUP Core 2X clock rate constants by scaling
them up to their intended raw Bps thresholds. The previous values were
under-voting the QUP Core clock.

> diff --git a/include/linux/soc/qcom/geni-se.h b/include/linux/soc/qcom/geni-se.h
> index 29a53bbc0dd49..2243005f5e2ee 100644
> --- a/include/linux/soc/qcom/geni-se.h
> +++ b/include/linux/soc/qcom/geni-se.h

[ ... ]

> -#define CORE_2X_100_MHZ			5000
> -#define CORE_2X_150_MHZ			7500
> -#define CORE_2X_200_MHZ			10000
> -#define CORE_2X_236_MHZ			16383
> +#define CORE_2X_100_MHZ			50000000
> +#define CORE_2X_150_MHZ			75000000
> +#define CORE_2X_200_MHZ			100000000
> +#define CORE_2X_236_MHZ			118000000

[Severity: Medium]
Will these higher bandwidth values be clamped by the interconnect framework?

When these values are converted to kBps via Bps_to_icc() (e.g., 75,000 for
the 150 MHz state) and passed to the RPMh BCM voter, they undergo scaling
in bcm_aggregate(). 

With standard QUP parameters (vote_scale=1000, buswidth=4, unit=1000), a
kBps vote of 75,000 evaluates to a calculated vote of 18,750 or higher
depending on aux_data.width.

The hardware TCS command mask in the RPMh voter is limited to 14 bits:

drivers/interconnect/qcom/bcm-voter.c:tcs_cmd_gen() {
	...
	if (vote_x > BCM_TCS_CMD_VOTE_MASK)
		vote_x = BCM_TCS_CMD_VOTE_MASK;
	...
}

Because BCM_TCS_CMD_VOTE_MASK is 16383, any vote resulting from these new
thresholds for >= 150 MHz will exceed the mask and be clamped to 16383.

Does this result in a loss of dynamic bandwidth scaling granularity for
these higher frequency requests, effectively always requesting the maximum
frequency state?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909-correct-icc-bandwidth-vote-constants-v1-0-fbebf6b3c341@oss.qualcomm.com?part=1