[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <829c2da7-4f88-4669-a114-c80603ccd4e1@linaro.org>
Date: Wed, 26 Jul 2023 19:19:34 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Stephan Gerhold <stephan@...hold.net>
Cc: Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Georgi Djakov <djakov@...nel.org>,
Marijn Suijten <marijn.suijten@...ainline.org>,
linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] interconnect: qcom: icc-rpm: Add AB/IB calculations
coefficients
On 26.07.2023 19:16, Stephan Gerhold wrote:
> On Wed, Jul 26, 2023 at 06:25:43PM +0200, Konrad Dybcio wrote:
>> Presumably due to the hardware being so complex, some nodes (or busses)
>> have different (usually higher) requirements for bandwidth than what
>> the usual calculations would suggest.
>>
>
> Weird. I just hope this was never abused to workaround other broken
> configuration. A nice round ib_percent = 200 has mostly the same effect as
>
> - Doubling the requested peek bandwidth in the consumer driver (perhaps
> they were too lazy to fix the driver in downstream at some point)
> - Halving the node buswidth
>
> It's probably hard to say for sure...
As per usual..
[...]
>>
>> /*
>> @@ -315,6 +317,12 @@ static void qcom_icc_bus_aggregate(struct icc_provider *provider, u64 *agg_clk_r
>> else
>> agg_avg_rate = qn->sum_avg[i];
>>
>> + percent = qp->ab_percent ? qp->ab_percent : 100;
>> + agg_avg_rate = mult_frac(percent, agg_avg_rate, 100);
>
> if (qp->ab_percent)
> agg_avg_rate = mult_frac(qp->ab_percent, agg_avg_rate, 100);
>
> Would be likely more efficient (no calculation if unspecified) and not
> much harder to read.
Oh right!
>
>> +
>> + percent = qn->ib_percent ? qn->ib_percent : 100;
>> + agg_peak_rate = mult_frac(percent, qn->max_peak[i], 100);
>> +
>
> agg_peak_rate doesn't seem to be used anywhere else? 🤔
Whoooooops....
Konrad
Powered by blists - more mailing lists