Re: [PATCH 2/6] interconnect: qcom: icc-rpm: Don't skip small votes

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 9/9/26 8:38 PM, Dmitry Baryshkov wrote:
> On Wed, Sep 09, 2026 at 06:41:55PM +0200, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> Small votes (such as 1 or 100) can end up being rounded down to 0
>> midway through the calculations. Use qcom_bw_div() when dividing to
>> prevent that.
>>
>> Assisted-by: LLM
>> Fixes: 30c8fa3ec61a ("interconnect: qcom: Add MSM8916 interconnect provider driver")
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>> ---
>>  drivers/interconnect/qcom/icc-rpm.c | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
> 
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> 
> What is the reason for the drivers to cast such small votes? Isn't it a
> mistake on the driver side?

Yes and no.. the interconnect infrastructure on RPM/RPMH is a bit
"meh" given it accept kBps values that it then converts to bus clock
frequencies in MHz that are then clamped to one of the predefined DVFS
levels. Many drivers want "level X specifically" or "anything that's non
zero" or "anything just above the first nonzero level", but due to the
differences in topology, that may translate to different values on
different platforms.

So 1 was at one point deemed okay for "i don't care, just need the
bus on". I'm not sure if the uses of it are valid, given that doesn't
*actually* reserve the bandwidth on the [most often] config path
while the driver may hammer register i/o pretty hard, but at least I'd
like for that to give the expected result.

These "safe-divisions" are more meaningful in the RPMH world, because
each BCM defines the units in which it accepts bandwidth (may be N
Bps, kBps etc.), so there's much more potential for truncation there

Konrad