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@xxxxxxxxxx> >>>> --- >>>> .../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
