[PATCH 0/2] qcom-geni: Fix QUP Core ICC votes

[PATCH 0/2] qcom-geni: Fix QUP Core ICC votes

[Viken Dadhaniya]

The GENI_TO_CORE ("qup-core") interconnect vote selects the QUP Core 2X
clock rate. The Core 2X bandwidth constants currently contain values that
are several orders of magnitude too small. Also, at baud rates up to
115200, the serial console uses only a 1 kBps keepalive vote, which does
not request a Core clock and can leave console RX unresponsive after the
system enters a deep CPU idle state.

Correct the common Core 2X bandwidth constants and use the 19.2 MHz Core
2X vote for the low-baud console path. Higher baud rates continue to use
the 50 MHz vote.

Patch 1 corrects the common Core 2X bandwidth constants. Patch 2 updates
the serial console's low-baud vote to use the corrected 19.2 MHz value.

Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
Viken Dadhaniya (2):
      soc: qcom: geni-se: Correct QUP Core ICC vote constants
      tty: serial: qcom_geni_serial: Keep console RX functional after deep idle

 drivers/tty/serial/qcom_geni_serial.c |  5 ++---
 include/linux/soc/qcom/geni-se.h      | 21 +++++++++++----------
 2 files changed, 13 insertions(+), 13 deletions(-)
---
base-commit: 944a035ecca915ae947905dcfb03f2b9dc6d032c
change-id: 20260908-correct-icc-bandwidth-vote-constants-49001bf6e03b

Best regards,
--  
Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>

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

[Viken Dadhaniya]

The GENI_TO_CORE ("qup-core") ICC vote selects the QUP Core 2X clock
rate. The CORE_2X_*_MHZ constants are expressed in Bps, but their
values are several orders of magnitude too small. For example, the
50 MHz threshold is represented by 2500 rather than 25000000 Bps.

As a result, clients using these constants can severely under-vote the
QUP Core clock.

Correct the constants to their intended Bps thresholds so that the ICC
provider selects the corresponding QUP Core 2X clock rate.

Fixes: 58ffbba6a399 ("soc: qcom: geni: Support for ICC voting")
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
 include/linux/soc/qcom/geni-se.h | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/include/linux/soc/qcom/geni-se.h b/include/linux/soc/qcom/geni-se.h
index 29a53bbc0dd4..2243005f5e2e 100644
--- a/include/linux/soc/qcom/geni-se.h
+++ b/include/linux/soc/qcom/geni-se.h
@@ -347,17 +347,18 @@ struct geni_se {
 #define QUP_SE_VERSION_2_5                  0x20050000
 
 /*
- * Define bandwidth thresholds that cause the underlying Core 2X interconnect
- * clock to run at the named frequency. These baseline values are recommended
- * by the hardware team, and are not dynamically scaled with GENI bandwidth
- * beyond basic on/off.
+ * ICC bandwidth values in Bps for the GENI_TO_CORE ("qup-core") path.
+ * Convert them with Bps_to_icc() before setting avg_bw. The QUP ICC provider
+ * maps each threshold to the Core 2X rate named by the macro suffix.
+ *
+ * These values are core clock votes, not GENI transfer bandwidths.
  */
-#define CORE_2X_19_2_MHZ		960
-#define CORE_2X_50_MHZ			2500
-#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_19_2_MHZ		9600000
+#define CORE_2X_50_MHZ			25000000
+#define CORE_2X_100_MHZ			50000000
+#define CORE_2X_150_MHZ			75000000
+#define CORE_2X_200_MHZ			100000000
+#define CORE_2X_236_MHZ			118000000
 
 #define GENI_DEFAULT_BW			Bps_to_icc(1000)
 

-- 
2.34.1

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

[sashiko-bot]

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

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

[Konrad Dybcio]

On 9/8/26 9:05 PM, Viken Dadhaniya wrote:
> The GENI_TO_CORE ("qup-core") ICC vote selects the QUP Core 2X clock
> rate. The CORE_2X_*_MHZ constants are expressed in Bps, but their
> values are several orders of magnitude too small. For example, the
> 50 MHz threshold is represented by 2500 rather than 25000000 Bps.

[...]

>  /*
> - * Define bandwidth thresholds that cause the underlying Core 2X interconnect
> - * clock to run at the named frequency. These baseline values are recommended
> - * by the hardware team, and are not dynamically scaled with GENI bandwidth
> - * beyond basic on/off.
> + * ICC bandwidth values in Bps for the GENI_TO_CORE ("qup-core") path.
> + * Convert them with Bps_to_icc() before setting avg_bw. The QUP ICC provider
> + * maps each threshold to the Core 2X rate named by the macro suffix.
> + *
> + * These values are core clock votes, not GENI transfer bandwidths.
>   */
> -#define CORE_2X_19_2_MHZ		960
> -#define CORE_2X_50_MHZ			2500
> -#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_19_2_MHZ		9600000
> +#define CORE_2X_50_MHZ			25000000
> +#define CORE_2X_100_MHZ			50000000
> +#define CORE_2X_150_MHZ			75000000
> +#define CORE_2X_200_MHZ			100000000
> +#define CORE_2X_236_MHZ			118000000

Today, even with patch 2 applied, many of these rates are unused.
Are we going to?

Is there any logic we could apply to derive them?

Konrad

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

[Viken Dadhaniya]

On 9/9/2026 5:12 PM, Konrad Dybcio wrote:
> On 9/8/26 9:05 PM, Viken Dadhaniya wrote:
>> The GENI_TO_CORE ("qup-core") ICC vote selects the QUP Core 2X clock
>> rate. The CORE_2X_*_MHZ constants are expressed in Bps, but their
>> values are several orders of magnitude too small. For example, the
>> 50 MHz threshold is represented by 2500 rather than 25000000 Bps.
> 
> [...]
> 
>>  /*
>> - * Define bandwidth thresholds that cause the underlying Core 2X interconnect
>> - * clock to run at the named frequency. These baseline values are recommended
>> - * by the hardware team, and are not dynamically scaled with GENI bandwidth
>> - * beyond basic on/off.
>> + * ICC bandwidth values in Bps for the GENI_TO_CORE ("qup-core") path.
>> + * Convert them with Bps_to_icc() before setting avg_bw. The QUP ICC provider
>> + * maps each threshold to the Core 2X rate named by the macro suffix.
>> + *
>> + * These values are core clock votes, not GENI transfer bandwidths.
>>   */
>> -#define CORE_2X_19_2_MHZ		960
>> -#define CORE_2X_50_MHZ			2500
>> -#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_19_2_MHZ		9600000
>> +#define CORE_2X_50_MHZ			25000000
>> +#define CORE_2X_100_MHZ			50000000
>> +#define CORE_2X_150_MHZ			75000000
>> +#define CORE_2X_200_MHZ			100000000
>> +#define CORE_2X_236_MHZ			118000000
> 
> Today, even with patch 2 applied, many of these rates are unused.
> Are we going to?
> 
> Is there any logic we could apply to derive them?

These represent QUP Core 2X clock-rate levels for GENI clients, not
protocol bandwidth. Currently only the 19.2 and 50 MHz levels are used;
there is no planned user for the higher levels. I’ll drop the unused
definitions.

> 
> Konrad

[PATCH 2/2] tty: serial: qcom_geni_serial: Keep console RX functional after deep idle

[Viken Dadhaniya]

At baud rates up to 115200, the serial console uses only a 1 kBps keepalive
vote for the GENI_TO_CORE ("qup-core") ICC path. This vote keeps the path
active but does not request a QUP Core 2X clock rate.

When the CPU enters a deeper idle state, the missing Core clock vote can
leave the console RX path unresponsive.

Use the 19.2 MHz Core 2X vote at low baud rates, while retaining the 50 MHz
vote at higher baud rates, so that console RX remains functional after deep
idle transitions.

Fixes: 7cf563b2c846 ("tty: serial: qcom_geni_serial: Add interconnect support")
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
 drivers/tty/serial/qcom_geni_serial.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index 3633723acef8..b4b4724f1c5b 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -1482,9 +1482,8 @@ static int geni_serial_set_rate(struct geni_se *se, unsigned long baud)
 	 * Bump up BW vote on CPU and CORE path as driver supports FIFO mode
 	 * only.
 	 */
-	avg_bw_core = (baud > 115200) ? Bps_to_icc(CORE_2X_50_MHZ)
-						: GENI_DEFAULT_BW;
-	port->se.icc_paths[GENI_TO_CORE].avg_bw = avg_bw_core;
+	avg_bw_core = (baud > 115200) ? CORE_2X_50_MHZ : CORE_2X_19_2_MHZ;
+	port->se.icc_paths[GENI_TO_CORE].avg_bw = Bps_to_icc(avg_bw_core);
 	port->se.icc_paths[CPU_TO_GENI].avg_bw = Bps_to_icc(baud);
 	geni_icc_set_bw(&port->se);
 

-- 
2.34.1

Re: [PATCH 2/2] tty: serial: qcom_geni_serial: Keep console RX functional after deep idle

[sashiko-bot]

> At baud rates up to 115200, the serial console uses only a 1 kBps keepalive
> vote for the GENI_TO_CORE ("qup-core") ICC path. This vote keeps the path
> active but does not request a QUP Core 2X clock rate.
> 
> When the CPU enters a deeper idle state, the missing Core clock vote can
> leave the console RX path unresponsive.
> 
> Use the 19.2 MHz Core 2X vote at low baud rates, while retaining the 50 MHz
> vote at higher baud rates, so that console RX remains functional after deep
> idle transitions.
> 
> Fixes: 7cf563b2c846 ("tty: serial: qcom_geni_serial: Add interconnect support")
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>

Sashiko has reviewed this patch and found no issues. It looks great!

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

Re: [PATCH 2/2] tty: serial: qcom_geni_serial: Keep console RX functional after deep idle

[Konrad Dybcio]

On 9/8/26 9:05 PM, Viken Dadhaniya wrote:
> At baud rates up to 115200, the serial console uses only a 1 kBps keepalive
> vote for the GENI_TO_CORE ("qup-core") ICC path. This vote keeps the path
> active but does not request a QUP Core 2X clock rate.
> 
> When the CPU enters a deeper idle state, the missing Core clock vote can
> leave the console RX path unresponsive.
> 
> Use the 19.2 MHz Core 2X vote at low baud rates, while retaining the 50 MHz
> vote at higher baud rates, so that console RX remains functional after deep
> idle transitions.
> 
> Fixes: 7cf563b2c846 ("tty: serial: qcom_geni_serial: Add interconnect support")
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
>  drivers/tty/serial/qcom_geni_serial.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
> index 3633723acef8..b4b4724f1c5b 100644
> --- a/drivers/tty/serial/qcom_geni_serial.c
> +++ b/drivers/tty/serial/qcom_geni_serial.c
> @@ -1482,9 +1482,8 @@ static int geni_serial_set_rate(struct geni_se *se, unsigned long baud)
>  	 * Bump up BW vote on CPU and CORE path as driver supports FIFO mode
>  	 * only.
>  	 */
> -	avg_bw_core = (baud > 115200) ? Bps_to_icc(CORE_2X_50_MHZ)
> -						: GENI_DEFAULT_BW;
> -	port->se.icc_paths[GENI_TO_CORE].avg_bw = avg_bw_core;
> +	avg_bw_core = (baud > 115200) ? CORE_2X_50_MHZ : CORE_2X_19_2_MHZ;

Downstream selects this based on whether the UART is a console, but
I believe baud rate is much more likely to be a good discriminant
here

FWIW you can remove the parentheses

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad