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
