Re: [PATCH 02/53] dt-bindings: interconnect: qcom,bcm-voter: Add qcom,bcm-voter-idx

[Konrad Dybcio <konrad.dybcio@linaro.org>]

On 5.08.2023 23:21, Krzysztof Kozlowski wrote:
> On 15/07/2023 17:09, Konrad Dybcio wrote:
>> On 12.07.2023 22:43, Krzysztof Kozlowski wrote:
>>> On 11/07/2023 14:18, Konrad Dybcio wrote:
>>>> In order to (at least partially) untangle the global BCM voter lookup
>>>> (as again, they are shared throughout the entire system and not bound to
>>>> individual buses/providers), introduce a new required property to assign
>>>> a unique identifier to each BCM voter.
>>>>
>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>>>> ---
>>>>  .../devicetree/bindings/interconnect/qcom,bcm-voter.yaml       | 10 ++++++++++
>>>>  1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml b/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml
>>>> index eec987640b37..09321c1918bf 100644
>>>> --- a/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml
>>>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml
>>>> @@ -38,8 +38,14 @@ properties:
>>>>  
>>>>      $ref: /schemas/types.yaml#/definitions/uint32
>>>>  
>>>> +  qcom,bcm-voter-idx:
>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>> +    description:
>>>> +      A globally unique predefined discrimnator, identifying each BCM voter.
>>>
>>> s/each/this/ ?
>> Right, this makes more sense
>>
>>> If I understand correctly, there might be more than one instance. The
>>> problem is that I cannot find such case in upstream sources.
>> I don't think there can be more than one per RSC.
>>
>> SM8550 splits some RSCs into "channels" and these channels have their
>> individual voters, however they would still be attached to these
>> channel subnodes/subdevices and no, we don't support that yet.
> 
> Then shouldn't this be one number, not an array?
> 
>>
>>>
>>>
>>>> +
>>>>  required:
>>>>    - compatible
>>>> +  - qcom,bcm-voter-idx
>>>
>>> This should not be really required, because it affects the ABI.
>> Hm.. can I deprecate lack of it somehow?
> 
> In general: no. Anyway, it depends how much you need it. Breaking ABI
> might be justified, but I just did not get such need from the commit
> msg. Your commit msg looks to me closer to a cleanup.
+ Mike

Yes and no. But mostly yes.

The current way of depicting the BCM voter as a child of the RSC
is rather stupid. Think of the discussion that we had with
Bartosz about adding child devices to SCM only to bind Linux
drivers.

The "voters" are totally a Linux software construct - there is a
piece of hw called BCM (Bus Clock Manager) to which you send votes
through the RSC (Resource State Coordinator). Each major subsystem
has its own RSC (APPS, display, pcie on newer/compute, camera
starting from 8550 etc.) that you submit these through.

Currently the bcm-voter driver provides a structure where vote data
is stored and everything is concluded with a pair of rpmh_write_batch
(one for wake-only and one for sleep buckets).

After reading what I just wrote, maybe we can just reference the RSC
directly. Or in the aforementioned case of 8550 CAMSS RSC having
multiple channels per RSC, its subchannel.

Perhaps this cleanup should be extended to get rid of this subnode.
Or maybe even the driver, or part of it.

Actually, I need to think about this a bit more, as we also need to
reuse half of BCM voter logic in the Adreno code (to shove the
generated RPMh commands into the GPU Management Unit which pokes at
RPMh on its own)...

I think Mike should comment on this rather incoherent monologue of
mine..

Konrad