Re: [PATCH v3] soc: qcom: icc-bwmon: Update zone1_thres_count to 3

[Konrad Dybcio]

On 2/27/26 12:10 PM, Pushpendra Singh wrote:
> From: Shivnandan Kumar <quic_kshivnan@xxxxxxxxxxx>
> 
> Reduce zone1_thres_count from 16 to 3 so the driver can lower the bus
> vote after 3 sample windows instead of waiting for 16. The previous
> 16‑window delay (~64 ms) is too long at higher FPS workloads,
> causing delayed decision making and measurable power regression.
> 
> Empirical tuning showed that lower values (e.g., 2) made bwmon behavior
> jittery, while higher values (4–6) were stable but less responsive and
> reduced power savings. A value of 3 provided the best balance: responsive
> enough for timely power reduction while maintaining stable bwmon
> operation.
> 
> Significant power savings were observed across multiple use cases when
> reducing the threshold from 16 to 3:
> 
> USECASE			zone1_thres_count=16     zone1_thres_count=3
> 4K video playback	   236.15 mA                  203.15 mA
> Sleep			    7mA			        6.9mA
> Display (idle display)	  71.95mA			67.11mA
> 
> Signed-off-by: Shivnandan Kumar <quic_kshivnan@xxxxxxxxxxx>
> Signed-off-by: Pushpendra Singh <pussin@xxxxxxxxxxxxxxxx>
> ---

Since this patch does not seem to be moving on its own, I will gladly
hijack the discussion..

I was wondering if we could transplant the bwmon devfreq+governor+memlat
setup from downstream. It seems to be way "smarter", in the sense that
it keeps some hysteresis information, unlike icc-bwmon, which is purely
reactive to immediate signals, in addition to (in my brief understanding)
sampling other data sources, such as the PMU 

Konrad