Re: [PATCH] interconnect: Restore sync state by ignoring ipa-virt in provider count

[Alex Elder]

On 4/27/22 3:52 PM, Georgi Djakov wrote:
> On 27.04.22 15:00, Alex Elder wrote:
> > On 4/26/22 8:32 PM, Stephen Boyd wrote:
> > > Ignore compatible strings for the IPA virt drivers that were removed in
> > > commits 2fb251c26560 ("interconnect: qcom: sdx55: Drop IP0
> > > interconnects") and 2f3724930eb4 ("interconnect: qcom: sc7180: Drop IP0
> > > interconnects") so that the sync state logic can kick in again.
> > > Otherwise all the interconnects in the system will stay pegged at max
> > > speeds because 'providers_count' is always going to be one larger than
> > > the number of drivers that will ever probe on sc7180 or sdx55. This
> > > fixes suspend on sc7180 and sdx55 devices when you don't have a
> > > devicetree patch to remove the ipa-virt compatible node.
> > >
> > > Cc: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>
> > > Cc: Doug Anderson <dianders@xxxxxxxxxxxx>
> > > Cc: Alex Elder <elder@xxxxxxxxxx>
> > > Cc: Taniya Das <quic_tdas@xxxxxxxxxxx>
> > > Cc: Mike Tipton <quic_mdtipton@xxxxxxxxxxx>
> > > Fixes: 2fb251c26560 ("interconnect: qcom: sdx55: Drop IP0 
> > > interconnects")
> > > Fixes: 2f3724930eb4 ("interconnect: qcom: sc7180: Drop IP0 
> > > interconnects")
> > > Signed-off-by: Stephen Boyd <swboyd@xxxxxxxxxxxx>
> >
> > So of_count_icc_providers() counts the number of
> > interconnect providers defined in the DTB, regardless
> > of whether anything in the code supports it.
>
> Yes, that's the case currently. There could be multiple provider drivers
> in different modules, and the modules may be loaded even not during boot,
> but later. So we rely on DT.

Georgi, do you have any other ideas about how to improve this?

What you say makes sense--you figure out the total number of
providers at init time based on what's defined in DT.

But when all is said and done, what if even *one* of those
has no provider driver?  Isn't that what causes the problem
here, that icc_sync_state assumes all providers specified in
DT will eventually have a driver that calls icc_sync_state()?

(I don't claim to know the interconnect code in detail, so
I might not be quite understanding how this works.)

					-Alex

> Thanks,
> Georgi
>
> > This seems to be a more general problem, but I
> > suppose in practice it's not likely to occur.
> >
> > I think your solution looks fine, but I'm interested
> > in what Georgi has to say.
> >
> > Reviewed-by: Alex Elder <elder@xxxxxxxxxx>
> >
> >
> > > ---
> > >   drivers/interconnect/core.c | 8 +++++++-
> > >   1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> > > index 9050ca1f4285..c52915a58b22 100644
> > > --- a/drivers/interconnect/core.c
> > > +++ b/drivers/interconnect/core.c
> > > @@ -1087,9 +1087,15 @@ static int of_count_icc_providers(struct 
> > > device_node *np)
> > >   {
> > >       struct device_node *child;
> > >       int count = 0;
> > > +    const struct of_device_id ignore_list[] = {
> > > +        { .compatible = "qcom,sc7180-ipa-virt" },
> > > +        { .compatible = "qcom,sdx55-ipa-virt" },
> > > +        {}
> > > +    };
> > >       for_each_available_child_of_node(np, child) {
> > > -        if (of_property_read_bool(child, "#interconnect-cells"))
> > > +        if (of_property_read_bool(child, "#interconnect-cells") &&
> > > +            likely(!of_match_node(ignore_list, child)))
> > >               count++;
> > >           count += of_count_icc_providers(child);
> > >       }
> > >
> > > base-commit: 2fb251c265608636fc961b7d38e1a03937e57371