[v4,1/3] dt-bindings: interconnect: Add rpmh virt devices

  Add documentation for virtual rpmh devices. These interconnects
are not controlled by the application processor and thus
require separate bindings. Also, move compatibles for sm8450 to
this document and add them for QDU1000/QRU1000 platforms.

Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
---
 .../bindings/interconnect/qcom,rpmh-virt.yaml | 55 +++++++++++++++++++
 .../bindings/interconnect/qcom,rpmh.yaml      |  2 -
 2 files changed, 55 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
  

On 18/11/2022 19:22, Melody Olvera wrote:
> Add documentation for virtual rpmh devices. These interconnects
> are not controlled by the application processor and thus
> require separate bindings. Also, move compatibles for sm8450 to
> this document and add them for QDU1000/QRU1000 platforms.
> 
> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
> ---
>  .../bindings/interconnect/qcom,rpmh-virt.yaml | 55 +++++++++++++++++++
>  .../bindings/interconnect/qcom,rpmh.yaml      |  2 -
>  2 files changed, 55 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
> 
> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
> new file mode 100644
> index 000000000000..5cbaa51df863
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/interconnect/qcom,rpmh-virt.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm RPMh Virtual Network-On-Chip Interconnect
> +
> +maintainers:
> +  - Georgi Djakov <georgi.djakov@linaro.org>
> +  - Odelu Kukatla <quic_okukatla@quicinc.com>
> +
> +description: |
> +   RPMh interconnect providers support system bandwidth requirements through
> +   RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
> +   able to communicate with the BCM through the Resource State Coordinator (RSC)
> +   associated with each execution environment. Provider nodes must point to at
> +   least one RPMh device child node pertaining to their RSC and each provider
> +   can map to multiple RPMh resources. Virtual interconnect providers are not
> +   controlled by AP and do not support QoS; they should not have associated
> +   register regions.
> +
> +allOf:
> +  - $ref: qcom,rpmh-common.yaml#
> +
> +properties:
> +  compatible:
> +    enum:
> +      - qcom,qdu1000-clk-virt
> +      - qcom,qdu1000-mc-virt
> +      - qcom,sm8450-clk-virt
> +      - qcom,sm8450-mc-virt

You should also move qcom,sdx65-mc-virt, qcom,sc8280xp-mc-virt,
qcom,sc8280xp-clk-virt and more.

> +
> +  '#interconnect-cells': true
> +
> +required:
> +  - compatible
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +      #include <dt-bindings/interconnect/qcom,sm8450.h>
> +
> +      clk_virt: interconnect-0 {
> +             compatible = "qcom,sm8450-clk-virt";
> +             #interconnect-cells = <2>;
> +             qcom,bcm-voters = <&apps_bcm_voter>;
> +      };
> +
> +      mc_virt: interconnect-1 {
> +             compatible = "qcom,sm8450-mc-virt";
> +             #interconnect-cells = <2>;
> +             qcom,bcm-voters = <&apps_bcm_voter>;

These are exactly the same examples, so just keep one.

Best regards,
Krzysztof
  

Hi Melody,

On 18.11.22 20:22, Melody Olvera wrote:
> Add documentation for virtual rpmh devices. These interconnects
> are not controlled by the application processor and thus
> require separate bindings. Also, move compatibles for sm8450 to
> this document and add them for QDU1000/QRU1000 platforms.
> 
> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
> ---
>   .../bindings/interconnect/qcom,rpmh-virt.yaml | 55 +++++++++++++++++++
>   .../bindings/interconnect/qcom,rpmh.yaml      |  2 -
>   2 files changed, 55 insertions(+), 2 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
> 
> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
> new file mode 100644
> index 000000000000..5cbaa51df863
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/interconnect/qcom,rpmh-virt.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm RPMh Virtual Network-On-Chip Interconnect
> +
> +maintainers:
> +  - Georgi Djakov <georgi.djakov@linaro.org>

This email is not valid anymore, so please replace it with djakov@kernel.org.

Thanks,
Georgi

> +  - Odelu Kukatla <quic_okukatla@quicinc.com>
> +
> +description: |
> +   RPMh interconnect providers support system bandwidth requirements through
> +   RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
> +   able to communicate with the BCM through the Resource State Coordinator (RSC)
> +   associated with each execution environment. Provider nodes must point to at
> +   least one RPMh device child node pertaining to their RSC and each provider
> +   can map to multiple RPMh resources. Virtual interconnect providers are not
> +   controlled by AP and do not support QoS; they should not have associated
> +   register regions.
> +
> +allOf:
> +  - $ref: qcom,rpmh-common.yaml#
> +
> +properties:
> +  compatible:
> +    enum:
> +      - qcom,qdu1000-clk-virt
> +      - qcom,qdu1000-mc-virt
> +      - qcom,sm8450-clk-virt
> +      - qcom,sm8450-mc-virt
> +
> +  '#interconnect-cells': true
> +
> +required:
> +  - compatible
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +      #include <dt-bindings/interconnect/qcom,sm8450.h>
> +
> +      clk_virt: interconnect-0 {
> +             compatible = "qcom,sm8450-clk-virt";
> +             #interconnect-cells = <2>;
> +             qcom,bcm-voters = <&apps_bcm_voter>;
> +      };
> +
> +      mc_virt: interconnect-1 {
> +             compatible = "qcom,sm8450-mc-virt";
> +             #interconnect-cells = <2>;
> +             qcom,bcm-voters = <&apps_bcm_voter>;
> +      };
> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
> index a429a1ed1006..bd474f49deb0 100644
> --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
> +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
> @@ -123,11 +123,9 @@ properties:
>         - qcom,sm8350-system-noc
>         - qcom,sm8450-aggre1-noc
>         - qcom,sm8450-aggre2-noc
> -      - qcom,sm8450-clk-virt
>         - qcom,sm8450-config-noc
>         - qcom,sm8450-gem-noc
>         - qcom,sm8450-lpass-ag-noc
> -      - qcom,sm8450-mc-virt
>         - qcom,sm8450-mmss-noc
>         - qcom,sm8450-nsp-noc
>         - qcom,sm8450-pcie-anoc
  

On 21/11/2022 16:23, Georgi Djakov wrote:
> Hi Melody,
> 
> On 18.11.22 20:22, Melody Olvera wrote:
>> Add documentation for virtual rpmh devices. These interconnects
>> are not controlled by the application processor and thus
>> require separate bindings. Also, move compatibles for sm8450 to
>> this document and add them for QDU1000/QRU1000 platforms.
>>
>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
>> ---
>>   .../bindings/interconnect/qcom,rpmh-virt.yaml | 55 +++++++++++++++++++
>>   .../bindings/interconnect/qcom,rpmh.yaml      |  2 -
>>   2 files changed, 55 insertions(+), 2 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
>> new file mode 100644
>> index 000000000000..5cbaa51df863
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
>> @@ -0,0 +1,55 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/interconnect/qcom,rpmh-virt.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm RPMh Virtual Network-On-Chip Interconnect
>> +
>> +maintainers:
>> +  - Georgi Djakov <georgi.djakov@linaro.org>
> 
> This email is not valid anymore, so please replace it with djakov@kernel.org.

It's still listed in bindings maintainers, so people copy what is there.
Can you update your emails? Mailmap is also missing.

Best regards,
Krzysztof
  

On 11/21/2022 9:23 AM, Georgi Djakov wrote:
> Hi Melody,
>
> On 18.11.22 20:22, Melody Olvera wrote:
>> Add documentation for virtual rpmh devices. These interconnects
>> are not controlled by the application processor and thus
>> require separate bindings. Also, move compatibles for sm8450 to
>> this document and add them for QDU1000/QRU1000 platforms.
>>
>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
>> ---
>>   .../bindings/interconnect/qcom,rpmh-virt.yaml | 55 +++++++++++++++++++
>>   .../bindings/interconnect/qcom,rpmh.yaml      |  2 -
>>   2 files changed, 55 insertions(+), 2 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
>> new file mode 100644
>> index 000000000000..5cbaa51df863
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
>> @@ -0,0 +1,55 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/interconnect/qcom,rpmh-virt.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm RPMh Virtual Network-On-Chip Interconnect
>> +
>> +maintainers:
>> +  - Georgi Djakov <georgi.djakov@linaro.org>
>
> This email is not valid anymore, so please replace it with djakov@kernel.org.

Sounds good.

Melody
>
> Thanks,
> Georgi
>
>> +  - Odelu Kukatla <quic_okukatla@quicinc.com>
>> +
>> +description: |
>> +   RPMh interconnect providers support system bandwidth requirements through
>> +   RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
>> +   able to communicate with the BCM through the Resource State Coordinator (RSC)
>> +   associated with each execution environment. Provider nodes must point to at
>> +   least one RPMh device child node pertaining to their RSC and each provider
>> +   can map to multiple RPMh resources. Virtual interconnect providers are not
>> +   controlled by AP and do not support QoS; they should not have associated
>> +   register regions.
>> +
>> +allOf:
>> +  - $ref: qcom,rpmh-common.yaml#
>> +
>> +properties:
>> +  compatible:
>> +    enum:
>> +      - qcom,qdu1000-clk-virt
>> +      - qcom,qdu1000-mc-virt
>> +      - qcom,sm8450-clk-virt
>> +      - qcom,sm8450-mc-virt
>> +
>> +  '#interconnect-cells': true
>> +
>> +required:
>> +  - compatible
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> +  - |
>> +      #include <dt-bindings/interconnect/qcom,sm8450.h>
>> +
>> +      clk_virt: interconnect-0 {
>> +             compatible = "qcom,sm8450-clk-virt";
>> +             #interconnect-cells = <2>;
>> +             qcom,bcm-voters = <&apps_bcm_voter>;
>> +      };
>> +
>> +      mc_virt: interconnect-1 {
>> +             compatible = "qcom,sm8450-mc-virt";
>> +             #interconnect-cells = <2>;
>> +             qcom,bcm-voters = <&apps_bcm_voter>;
>> +      };
>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
>> index a429a1ed1006..bd474f49deb0 100644
>> --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
>> @@ -123,11 +123,9 @@ properties:
>>         - qcom,sm8350-system-noc
>>         - qcom,sm8450-aggre1-noc
>>         - qcom,sm8450-aggre2-noc
>> -      - qcom,sm8450-clk-virt
>>         - qcom,sm8450-config-noc
>>         - qcom,sm8450-gem-noc
>>         - qcom,sm8450-lpass-ag-noc
>> -      - qcom,sm8450-mc-virt
>>         - qcom,sm8450-mmss-noc
>>         - qcom,sm8450-nsp-noc
>>         - qcom,sm8450-pcie-anoc
>
  

On 11/20/2022 5:13 AM, Krzysztof Kozlowski wrote:
> On 18/11/2022 19:22, Melody Olvera wrote:
>> Add documentation for virtual rpmh devices. These interconnects
>> are not controlled by the application processor and thus
>> require separate bindings. Also, move compatibles for sm8450 to
>> this document and add them for QDU1000/QRU1000 platforms.
>>
>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
>> ---
>>  .../bindings/interconnect/qcom,rpmh-virt.yaml | 55 +++++++++++++++++++
>>  .../bindings/interconnect/qcom,rpmh.yaml      |  2 -
>>  2 files changed, 55 insertions(+), 2 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
>> new file mode 100644
>> index 000000000000..5cbaa51df863
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
>> @@ -0,0 +1,55 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/interconnect/qcom,rpmh-virt.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm RPMh Virtual Network-On-Chip Interconnect
>> +
>> +maintainers:
>> +  - Georgi Djakov <georgi.djakov@linaro.org>
>> +  - Odelu Kukatla <quic_okukatla@quicinc.com>
>> +
>> +description: |
>> +   RPMh interconnect providers support system bandwidth requirements through
>> +   RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
>> +   able to communicate with the BCM through the Resource State Coordinator (RSC)
>> +   associated with each execution environment. Provider nodes must point to at
>> +   least one RPMh device child node pertaining to their RSC and each provider
>> +   can map to multiple RPMh resources. Virtual interconnect providers are not
>> +   controlled by AP and do not support QoS; they should not have associated
>> +   register regions.
>> +
>> +allOf:
>> +  - $ref: qcom,rpmh-common.yaml#
>> +
>> +properties:
>> +  compatible:
>> +    enum:
>> +      - qcom,qdu1000-clk-virt
>> +      - qcom,qdu1000-mc-virt
>> +      - qcom,sm8450-clk-virt
>> +      - qcom,sm8450-mc-virt
> You should also move qcom,sdx65-mc-virt, qcom,sc8280xp-mc-virt,
> qcom,sc8280xp-clk-virt and more.

Ok. I wasn't sure since some of these entries don't seem to conform to
these bindings, even though it seems they should.

>
>> +
>> +  '#interconnect-cells': true
>> +
>> +required:
>> +  - compatible
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> +  - |
>> +      #include <dt-bindings/interconnect/qcom,sm8450.h>
>> +
>> +      clk_virt: interconnect-0 {
>> +             compatible = "qcom,sm8450-clk-virt";
>> +             #interconnect-cells = <2>;
>> +             qcom,bcm-voters = <&apps_bcm_voter>;
>> +      };
>> +
>> +      mc_virt: interconnect-1 {
>> +             compatible = "qcom,sm8450-mc-virt";
>> +             #interconnect-cells = <2>;
>> +             qcom,bcm-voters = <&apps_bcm_voter>;
> These are exactly the same examples, so just keep one.

Sounds good.

Thanks,
Melody
>
> Best regards,
> Krzysztof
>
  

On 21/11/2022 18:39, Melody Olvera wrote:
> 
> 
> On 11/20/2022 5:13 AM, Krzysztof Kozlowski wrote:
>> On 18/11/2022 19:22, Melody Olvera wrote:
>>> Add documentation for virtual rpmh devices. These interconnects
>>> are not controlled by the application processor and thus
>>> require separate bindings. Also, move compatibles for sm8450 to
>>> this document and add them for QDU1000/QRU1000 platforms.
>>>
>>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
>>> ---
>>>  .../bindings/interconnect/qcom,rpmh-virt.yaml | 55 +++++++++++++++++++
>>>  .../bindings/interconnect/qcom,rpmh.yaml      |  2 -
>>>  2 files changed, 55 insertions(+), 2 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
>>> new file mode 100644
>>> index 000000000000..5cbaa51df863
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
>>> @@ -0,0 +1,55 @@
>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/interconnect/qcom,rpmh-virt.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Qualcomm RPMh Virtual Network-On-Chip Interconnect
>>> +
>>> +maintainers:
>>> +  - Georgi Djakov <georgi.djakov@linaro.org>
>>> +  - Odelu Kukatla <quic_okukatla@quicinc.com>
>>> +
>>> +description: |
>>> +   RPMh interconnect providers support system bandwidth requirements through
>>> +   RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
>>> +   able to communicate with the BCM through the Resource State Coordinator (RSC)
>>> +   associated with each execution environment. Provider nodes must point to at
>>> +   least one RPMh device child node pertaining to their RSC and each provider
>>> +   can map to multiple RPMh resources. Virtual interconnect providers are not
>>> +   controlled by AP and do not support QoS; they should not have associated
>>> +   register regions.
>>> +
>>> +allOf:
>>> +  - $ref: qcom,rpmh-common.yaml#
>>> +
>>> +properties:
>>> +  compatible:
>>> +    enum:
>>> +      - qcom,qdu1000-clk-virt
>>> +      - qcom,qdu1000-mc-virt
>>> +      - qcom,sm8450-clk-virt
>>> +      - qcom,sm8450-mc-virt
>> You should also move qcom,sdx65-mc-virt, qcom,sc8280xp-mc-virt,
>> qcom,sc8280xp-clk-virt and more.
> 
> Ok. I wasn't sure since some of these entries don't seem to conform to
> these bindings, even though it seems they should.

I have impression that devices I listed conform to these bindings, this
is why I listed them. But if you are sure that they do not, then they
should not be moved.

Best regards,
Krzysztof
  

On 11/22/2022 1:50 AM, Krzysztof Kozlowski wrote:
> On 21/11/2022 18:39, Melody Olvera wrote:
>>
>> On 11/20/2022 5:13 AM, Krzysztof Kozlowski wrote:
>>> On 18/11/2022 19:22, Melody Olvera wrote:
>>>> Add documentation for virtual rpmh devices. These interconnects
>>>> are not controlled by the application processor and thus
>>>> require separate bindings. Also, move compatibles for sm8450 to
>>>> this document and add them for QDU1000/QRU1000 platforms.
>>>>
>>>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
>>>> ---
>>>>  .../bindings/interconnect/qcom,rpmh-virt.yaml | 55 +++++++++++++++++++
>>>>  .../bindings/interconnect/qcom,rpmh.yaml      |  2 -
>>>>  2 files changed, 55 insertions(+), 2 deletions(-)
>>>>  create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
>>>> new file mode 100644
>>>> index 000000000000..5cbaa51df863
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml
>>>> @@ -0,0 +1,55 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/interconnect/qcom,rpmh-virt.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Qualcomm RPMh Virtual Network-On-Chip Interconnect
>>>> +
>>>> +maintainers:
>>>> +  - Georgi Djakov <georgi.djakov@linaro.org>
>>>> +  - Odelu Kukatla <quic_okukatla@quicinc.com>
>>>> +
>>>> +description: |
>>>> +   RPMh interconnect providers support system bandwidth requirements through
>>>> +   RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
>>>> +   able to communicate with the BCM through the Resource State Coordinator (RSC)
>>>> +   associated with each execution environment. Provider nodes must point to at
>>>> +   least one RPMh device child node pertaining to their RSC and each provider
>>>> +   can map to multiple RPMh resources. Virtual interconnect providers are not
>>>> +   controlled by AP and do not support QoS; they should not have associated
>>>> +   register regions.
>>>> +
>>>> +allOf:
>>>> +  - $ref: qcom,rpmh-common.yaml#
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    enum:
>>>> +      - qcom,qdu1000-clk-virt
>>>> +      - qcom,qdu1000-mc-virt
>>>> +      - qcom,sm8450-clk-virt
>>>> +      - qcom,sm8450-mc-virt
>>> You should also move qcom,sdx65-mc-virt, qcom,sc8280xp-mc-virt,
>>> qcom,sc8280xp-clk-virt and more.
>> Ok. I wasn't sure since some of these entries don't seem to conform to
>> these bindings, even though it seems they should.
> I have impression that devices I listed conform to these bindings, this
> is why I listed them. But if you are sure that they do not, then they
> should not be moved.

You're correct; those you listed do conform to the new bindings and should be moved.
I also caught qcom,sc7280-clk-virt which needs to be moved. I'll add to the new bindings.

Thanks,
Melody
>
> Best regards,
> Krzysztof
>
  

On 22/11/2022 18:57, Melody Olvera wrote:
>>>>> +
>>>>> +maintainers:
>>>>> +  - Georgi Djakov <georgi.djakov@linaro.org>
>>>>> +  - Odelu Kukatla <quic_okukatla@quicinc.com>
>>>>> +
>>>>> +description: |
>>>>> +   RPMh interconnect providers support system bandwidth requirements through
>>>>> +   RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
>>>>> +   able to communicate with the BCM through the Resource State Coordinator (RSC)
>>>>> +   associated with each execution environment. Provider nodes must point to at
>>>>> +   least one RPMh device child node pertaining to their RSC and each provider
>>>>> +   can map to multiple RPMh resources. Virtual interconnect providers are not
>>>>> +   controlled by AP and do not support QoS; they should not have associated
>>>>> +   register regions.
>>>>> +
>>>>> +allOf:
>>>>> +  - $ref: qcom,rpmh-common.yaml#
>>>>> +
>>>>> +properties:
>>>>> +  compatible:
>>>>> +    enum:
>>>>> +      - qcom,qdu1000-clk-virt
>>>>> +      - qcom,qdu1000-mc-virt
>>>>> +      - qcom,sm8450-clk-virt
>>>>> +      - qcom,sm8450-mc-virt
>>>> You should also move qcom,sdx65-mc-virt, qcom,sc8280xp-mc-virt,
>>>> qcom,sc8280xp-clk-virt and more.
>>> Ok. I wasn't sure since some of these entries don't seem to conform to
>>> these bindings, even though it seems they should.
>> I have impression that devices I listed conform to these bindings, this
>> is why I listed them. But if you are sure that they do not, then they
>> should not be moved.
> 
> You're correct; those you listed do conform to the new bindings and should be moved.
> I also caught qcom,sc7280-clk-virt which needs to be moved. I'll add to the new bindings.

Actually let's wait a bit with this. For SM8550 we had an idea to move
interconnect to their own bindings file, because they will grow a bit
with allOf:if:then clauses.

Maybe SM8450 and QDU1000 should also go to their own files which will
describe all their interconnects (the virt and the ones requiring clocks)?

Apologies for bringing it late for your patches, but SM8550 is also
happening right now, so new things pop-up :)

Best regards,
Krzysztof
  

On 11/24/2022 2:30 AM, Krzysztof Kozlowski wrote:
> On 22/11/2022 18:57, Melody Olvera wrote:
>>>>>> +
>>>>>> +maintainers:
>>>>>> +  - Georgi Djakov <georgi.djakov@linaro.org>
>>>>>> +  - Odelu Kukatla <quic_okukatla@quicinc.com>
>>>>>> +
>>>>>> +description: |
>>>>>> +   RPMh interconnect providers support system bandwidth requirements through
>>>>>> +   RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
>>>>>> +   able to communicate with the BCM through the Resource State Coordinator (RSC)
>>>>>> +   associated with each execution environment. Provider nodes must point to at
>>>>>> +   least one RPMh device child node pertaining to their RSC and each provider
>>>>>> +   can map to multiple RPMh resources. Virtual interconnect providers are not
>>>>>> +   controlled by AP and do not support QoS; they should not have associated
>>>>>> +   register regions.
>>>>>> +
>>>>>> +allOf:
>>>>>> +  - $ref: qcom,rpmh-common.yaml#
>>>>>> +
>>>>>> +properties:
>>>>>> +  compatible:
>>>>>> +    enum:
>>>>>> +      - qcom,qdu1000-clk-virt
>>>>>> +      - qcom,qdu1000-mc-virt
>>>>>> +      - qcom,sm8450-clk-virt
>>>>>> +      - qcom,sm8450-mc-virt
>>>>> You should also move qcom,sdx65-mc-virt, qcom,sc8280xp-mc-virt,
>>>>> qcom,sc8280xp-clk-virt and more.
>>>> Ok. I wasn't sure since some of these entries don't seem to conform to
>>>> these bindings, even though it seems they should.
>>> I have impression that devices I listed conform to these bindings, this
>>> is why I listed them. But if you are sure that they do not, then they
>>> should not be moved.
>> You're correct; those you listed do conform to the new bindings and should be moved.
>> I also caught qcom,sc7280-clk-virt which needs to be moved. I'll add to the new bindings.
> Actually let's wait a bit with this. For SM8550 we had an idea to move
> interconnect to their own bindings file, because they will grow a bit
> with allOf:if:then clauses.
>
> Maybe SM8450 and QDU1000 should also go to their own files which will
> describe all their interconnects (the virt and the ones requiring clocks)?
>
> Apologies for bringing it late for your patches, but SM8550 is also
> happening right now, so new things pop-up :)

Yeah no worries. I can definitely make this change; if this is how we want to do
things going forward I'm happy to oblige.

Thanks,
Melody
>
> Best regards,
> Krzysztof
>
  

On 11/28/2022 9:25 AM, Melody Olvera wrote:
>
> On 11/24/2022 2:30 AM, Krzysztof Kozlowski wrote:
>> On 22/11/2022 18:57, Melody Olvera wrote:
>>>>>>> +
>>>>>>> +maintainers:
>>>>>>> +  - Georgi Djakov <georgi.djakov@linaro.org>
>>>>>>> +  - Odelu Kukatla <quic_okukatla@quicinc.com>
>>>>>>> +
>>>>>>> +description: |
>>>>>>> +   RPMh interconnect providers support system bandwidth requirements through
>>>>>>> +   RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
>>>>>>> +   able to communicate with the BCM through the Resource State Coordinator (RSC)
>>>>>>> +   associated with each execution environment. Provider nodes must point to at
>>>>>>> +   least one RPMh device child node pertaining to their RSC and each provider
>>>>>>> +   can map to multiple RPMh resources. Virtual interconnect providers are not
>>>>>>> +   controlled by AP and do not support QoS; they should not have associated
>>>>>>> +   register regions.
>>>>>>> +
>>>>>>> +allOf:
>>>>>>> +  - $ref: qcom,rpmh-common.yaml#
>>>>>>> +
>>>>>>> +properties:
>>>>>>> +  compatible:
>>>>>>> +    enum:
>>>>>>> +      - qcom,qdu1000-clk-virt
>>>>>>> +      - qcom,qdu1000-mc-virt
>>>>>>> +      - qcom,sm8450-clk-virt
>>>>>>> +      - qcom,sm8450-mc-virt
>>>>>> You should also move qcom,sdx65-mc-virt, qcom,sc8280xp-mc-virt,
>>>>>> qcom,sc8280xp-clk-virt and more.
>>>>> Ok. I wasn't sure since some of these entries don't seem to conform to
>>>>> these bindings, even though it seems they should.
>>>> I have impression that devices I listed conform to these bindings, this
>>>> is why I listed them. But if you are sure that they do not, then they
>>>> should not be moved.
>>> You're correct; those you listed do conform to the new bindings and should be moved.
>>> I also caught qcom,sc7280-clk-virt which needs to be moved. I'll add to the new bindings.
>> Actually let's wait a bit with this. For SM8550 we had an idea to move
>> interconnect to their own bindings file, because they will grow a bit
>> with allOf:if:then clauses.
>>
>> Maybe SM8450 and QDU1000 should also go to their own files which will
>> describe all their interconnects (the virt and the ones requiring clocks)?
>>
>> Apologies for bringing it late for your patches, but SM8550 is also
>> happening right now, so new things pop-up :)
> Yeah no worries. I can definitely make this change; if this is how we want to do
> things going forward I'm happy to oblige.
>
> Thanks,
> Melody

I think though for these PS, I'll stick to doing w QDU1000. So I'll have a file qcom,qdu1000-rpmh.yaml
and qcom,qdu1000-rpmh-virt.yaml

Thanks,
Melody

>> Best regards,
>> Krzysztof
>>
  

On 11/28/2022 3:08 PM, Melody Olvera wrote:
>
> On 11/28/2022 9:25 AM, Melody Olvera wrote:
>> On 11/24/2022 2:30 AM, Krzysztof Kozlowski wrote:
>>> On 22/11/2022 18:57, Melody Olvera wrote:
>>>>>>>> +
>>>>>>>> +maintainers:
>>>>>>>> +  - Georgi Djakov <georgi.djakov@linaro.org>
>>>>>>>> +  - Odelu Kukatla <quic_okukatla@quicinc.com>
>>>>>>>> +
>>>>>>>> +description: |
>>>>>>>> +   RPMh interconnect providers support system bandwidth requirements through
>>>>>>>> +   RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
>>>>>>>> +   able to communicate with the BCM through the Resource State Coordinator (RSC)
>>>>>>>> +   associated with each execution environment. Provider nodes must point to at
>>>>>>>> +   least one RPMh device child node pertaining to their RSC and each provider
>>>>>>>> +   can map to multiple RPMh resources. Virtual interconnect providers are not
>>>>>>>> +   controlled by AP and do not support QoS; they should not have associated
>>>>>>>> +   register regions.
>>>>>>>> +
>>>>>>>> +allOf:
>>>>>>>> +  - $ref: qcom,rpmh-common.yaml#
>>>>>>>> +
>>>>>>>> +properties:
>>>>>>>> +  compatible:
>>>>>>>> +    enum:
>>>>>>>> +      - qcom,qdu1000-clk-virt
>>>>>>>> +      - qcom,qdu1000-mc-virt
>>>>>>>> +      - qcom,sm8450-clk-virt
>>>>>>>> +      - qcom,sm8450-mc-virt
>>>>>>> You should also move qcom,sdx65-mc-virt, qcom,sc8280xp-mc-virt,
>>>>>>> qcom,sc8280xp-clk-virt and more.
>>>>>> Ok. I wasn't sure since some of these entries don't seem to conform to
>>>>>> these bindings, even though it seems they should.
>>>>> I have impression that devices I listed conform to these bindings, this
>>>>> is why I listed them. But if you are sure that they do not, then they
>>>>> should not be moved.
>>>> You're correct; those you listed do conform to the new bindings and should be moved.
>>>> I also caught qcom,sc7280-clk-virt which needs to be moved. I'll add to the new bindings.
>>> Actually let's wait a bit with this. For SM8550 we had an idea to move
>>> interconnect to their own bindings file, because they will grow a bit
>>> with allOf:if:then clauses.
>>>
>>> Maybe SM8450 and QDU1000 should also go to their own files which will
>>> describe all their interconnects (the virt and the ones requiring clocks)?
>>>
>>> Apologies for bringing it late for your patches, but SM8550 is also
>>> happening right now, so new things pop-up :)
>> Yeah no worries. I can definitely make this change; if this is how we want to do
>> things going forward I'm happy to oblige.
>>
>> Thanks,
>> Melody
> I think though for these PS, I'll stick to doing w QDU1000. So I'll have a file qcom,qdu1000-rpmh.yaml
> and qcom,qdu1000-rpmh-virt.yaml
>
> Thanks,
> Melody

Nevermind; looks like SM8550 is keeping all in one file, so I'll keep all in one file.

>
>>> Best regards,
>>> Krzysztof
>>>