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

[Alex Elder <elder@linaro.org>]

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@linaro.org>
>>> Cc: Doug Anderson <dianders@chromium.org>
>>> Cc: Alex Elder <elder@linaro.org>
>>> Cc: Taniya Das <quic_tdas@quicinc.com>
>>> Cc: Mike Tipton <quic_mdtipton@quicinc.com>
>>> Fixes: 2fb251c26560 ("interconnect: qcom: sdx55: Drop IP0 
>>> interconnects")
>>> Fixes: 2f3724930eb4 ("interconnect: qcom: sc7180: Drop IP0 
>>> interconnects")
>>> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
>>
>> 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@linaro.org>
>>
>>
>>> ---
>>>   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
>>
>