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.
+
 required:
   - compatible
+  - qcom,bcm-voter-idx
 
 additionalProperties: false
 
@@ -48,8 +54,11 @@ examples:
   # as defined in Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
   - |
 
+    #include <dt-bindings/interconnect/qcom,icc.h>
+
     apps_bcm_voter: bcm-voter {
         compatible = "qcom,bcm-voter";
+        qcom,bcm-voter-idx = <ICC_BCM_VOTER_APPS>;
     };
 
   # Example 2: disp bcm_voter on SDM845 should be defined inside &disp_rsc node
@@ -61,5 +70,6 @@ examples:
     disp_bcm_voter: bcm-voter {
         compatible = "qcom,bcm-voter";
         qcom,tcs-wait = <QCOM_ICC_TAG_AMC>;
+        qcom,bcm-voter-idx = <ICC_BCM_VOTER_DISP>;
     };
 ...

-- 
2.41.0

On Tue, 11 Jul 2023 14:18:01 +0200, 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(+)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.example.dtb: rsc@18200000: bcm-voter: 'qcom,bcm-voter-idx' is a required property
	from schema $id: http://devicetree.org/schemas/soc/qcom/qcom,rpmh-rsc.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.example.dtb: bcm-voter: 'qcom,bcm-voter-idx' is a required property
	from schema $id: http://devicetree.org/schemas/interconnect/qcom,bcm-voter.yaml#

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230708-topic-rpmh_icc_rsc-v1-2-b223bd2ac8dd@linaro.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

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/ ?
If I understand correctly, there might be more than one instance. The
problem is that I cannot find such case in upstream sources.


> +
>  required:
>    - compatible
> +  - qcom,bcm-voter-idx

This should not be really required, because it affects the ABI. You also
need to fix the reported warning.

Best regards,
Krzysztof

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.

> 
> 
>> +
>>  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?

> You also
> need to fix the reported warning.
Ack

Konrad
> 
> Best regards,
> Krzysztof
>

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.

Best regards,
Krzysztof

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