Re: [PATCH 1/2] soc: qcom: geni-se: Correct QUP Core ICC vote constants
From: sashiko-bot@kernel.org
Date: 2026-09-08 19:25:08
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 [off-list ref] 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.
quoted hunk ↗ jump to hunk
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