Re: [PATCH] interconnect: Skip call into provider if initial bw is zero

[Mike Tipton]

On 1/30/2023 6:53 AM, Abel Vesa wrote:
> On 23-01-23 22:58:49, Bryan O'Donoghue wrote:
> > On 23/01/2023 20:37, Mike Tipton wrote:
> > > This isn't actually changing it for all providers. Only for those that
> > > define the get_bw() callback. Right now that's only qcom/msm8974 and
> > > imx/imx. If get_bw() isn't defined, then icc_node_add() defaults to
> > > INT_MAX. So, the logical behavior in that case is unchanged. Which means
> > > this isn't even changing the behavior for rpmh yet, either.
> >
> > Yes that adds up.
> >
> > Looking at the commit for get_bw() for the 8974, I think this change would
> > be OK with the intent of this commit
> >
> > commit 9caf2d956cfa254c6d89c5f4d7b3f8235d75b28f
> > Author: Georgi Djakov <georgi.djakov@xxxxxxxxxx>
> > Date:   Mon Nov 9 14:45:12 2020 +0200
> >
> > @Abel what effect will skipping pre->aggregation() have on i.MX ?
>
> I don't think there is any impact on i.MX platforms.
>
> Peng, any input?

It should only have an impact if there are nodes left enabled from 
bootloaders that nobody votes for and need to be turned off.

The imx get_bw() callback returns zero for everything. So, the previous 
icc_node_add() behavior would call set() with zero for everything and 
give the provider an opportunity to disable all nodes by default. After 
this change, set() won't be called from icc_node_add() anymore. And 
because init_bw is zero, set() won't be called in icc_sync_state() 
either. So, it's possible for certain nodes to be left enabled whereas 
previously they were disabled during imx probe.

If this change does result in nodes being left enabled, then the ideal 
fix would be for get_bw() to return non-zero for nodes enabled from 
boot. That would result in them being disabled in icc_sync_state().

Should be same possible impact for qcom/msm8974.

> > ---
> > bod