mbox series

[v3,0/3] Add interconnect support for QDU1000/QRU1000 SoCs

Message ID 20221026190520.4004264-1-quic_molvera@quicinc.com
Headers show
Series Add interconnect support for QDU1000/QRU1000 SoCs | expand

Message

Melody Olvera Oct. 26, 2022, 7:05 p.m. UTC 
Add dt bindings and driver support for the Qualcomm QDU1000 and QRU1000
SoCs.

The Qualcomm Technologies, Inc. Distributed Unit 1000 and Radio Unit
1000 are new SoCs meant for enabling Open RAN solutions. See more at
https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/qualcomm_5g_ran_platforms_product_brief.pdf

Changes from v2:
- Dropped qru compat strings
- Removed required reg string for interconnects

Melody Olvera (3):
  dt-bindings: interconnect: Remove required reg field
  dt-bindings: interconnect: Add QDU1000/QRU1000 dt bindings
  interconnect: qcom: Add QDU1000/QRU1000 interconnect driver

 .../bindings/interconnect/qcom,rpmh.yaml      |    5 +-
 drivers/interconnect/qcom/Kconfig             |    9 +
 drivers/interconnect/qcom/Makefile            |    2 +
 drivers/interconnect/qcom/qdu1000.c           | 1079 +++++++++++++++++
 drivers/interconnect/qcom/qdu1000.h           |   95 ++
 .../dt-bindings/interconnect/qcom,qdu1000.h   |   98 ++
 6 files changed, 1287 insertions(+), 1 deletion(-)
 create mode 100644 drivers/interconnect/qcom/qdu1000.c
 create mode 100644 drivers/interconnect/qcom/qdu1000.h
 create mode 100644 include/dt-bindings/interconnect/qcom,qdu1000.h


base-commit: 60eac8672b5b6061ec07499c0f1b79f6d94311ce

Comments

Melody Olvera Oct. 31, 2022, 11:29 p.m. UTC | #1 
On 10/27/2022 8:29 AM, Krzysztof Kozlowski wrote:
> On 26/10/2022 15:05, Melody Olvera wrote:
>> Many of the *-virt compatible devices do not have a reg field
>> so remove it as required from the bindings.
> and some virt have it... This should be probably separate binding or if
> the list is small - allOf:if:then.
I attempted this; however I'm still seeing failures in dtb_check. I've added this
to the binding; does this look correct?
 allOf:
   - $ref: qcom,rpmh-common.yaml#
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - qcom,qdu1000-clk-virt
+              - qcom,qdu1000-mc-virt
+
+    then:
+      required:
+        - compatible

>
> Anyway you need to resend everything to Cc all maintainers, not some subset.
Discussed earlier.

Thanks,
Melody
Georgi Djakov Nov. 7, 2022, 2:36 p.m. UTC | #2 
Hi,

On 2.11.22 23:11, Krzysztof Kozlowski wrote:
> On 31/10/2022 19:29, Melody Olvera wrote:
>>
>>
>> On 10/27/2022 8:29 AM, Krzysztof Kozlowski wrote:
>>> On 26/10/2022 15:05, Melody Olvera wrote:
>>>> Many of the *-virt compatible devices do not have a reg field
>>>> so remove it as required from the bindings.
>>> and some virt have it... This should be probably separate binding or if
>>> the list is small - allOf:if:then.
>> I attempted this; however I'm still seeing failures in dtb_check. I've added this
>> to the binding; does this look correct?
>>   allOf:
>>     - $ref: qcom,rpmh-common.yaml#
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - qcom,qdu1000-clk-virt
>> +              - qcom,qdu1000-mc-virt
>> +
>> +    then:
>> +      required:
>> +        - compatible
> 
> No, because we talk about reg, not compatible. You should not require
> reg instead for some compatibles... but then the schema is getting
> complicated.
> 
> It's difficult to give you recommendation because I do not know what are
> all these "virt" interconnects. Why some have unit address, why some do not?

My understanding is that the "reg" property is required for the NoCs that have
registers for controlling the QoS settings for the ports from Linux side.
Other NoCs might be controlled by some remote processor and direct access from
Linux may not be possible, so they do not have unit address and are outside of
the soc DT node.
Do we need to strictly define when exactly the "reg" property is required,
can't we just mark it as optional?

Thanks,
Georgi
Krzysztof Kozlowski Nov. 7, 2022, 6:28 p.m. UTC | #3 
On 07/11/2022 15:36, Georgi Djakov wrote:
> Hi,
> 
> On 2.11.22 23:11, Krzysztof Kozlowski wrote:
>> On 31/10/2022 19:29, Melody Olvera wrote:
>>>
>>>
>>> On 10/27/2022 8:29 AM, Krzysztof Kozlowski wrote:
>>>> On 26/10/2022 15:05, Melody Olvera wrote:
>>>>> Many of the *-virt compatible devices do not have a reg field
>>>>> so remove it as required from the bindings.
>>>> and some virt have it... This should be probably separate binding or if
>>>> the list is small - allOf:if:then.
>>> I attempted this; however I'm still seeing failures in dtb_check. I've added this
>>> to the binding; does this look correct?
>>>   allOf:
>>>     - $ref: qcom,rpmh-common.yaml#
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            enum:
>>> +              - qcom,qdu1000-clk-virt
>>> +              - qcom,qdu1000-mc-virt
>>> +
>>> +    then:
>>> +      required:
>>> +        - compatible
>>
>> No, because we talk about reg, not compatible. You should not require
>> reg instead for some compatibles... but then the schema is getting
>> complicated.
>>
>> It's difficult to give you recommendation because I do not know what are
>> all these "virt" interconnects. Why some have unit address, why some do not?
> 
> My understanding is that the "reg" property is required for the NoCs that have
> registers for controlling the QoS settings for the ports from Linux side.
> Other NoCs might be controlled by some remote processor and direct access from
> Linux may not be possible, so they do not have unit address and are outside of
> the soc DT node.
> Do we need to strictly define when exactly the "reg" property is required,
> can't we just mark it as optional?

It's preferred to make it strictly required or not allowed, so the
bindings are specific. This also allows to validate for mistakes. It
would be a bit different case if such test for req would make the
bindings complicated. I think it's not the case because we could just
split the bindings into two files:
1. One for controlled by AP, with reg.
2. One for controller by remote processors, without reg.

Best regards,
Krzysztof
Melody Olvera Nov. 7, 2022, 10:46 p.m. UTC | #4 
On 11/7/2022 10:28 AM, Krzysztof Kozlowski wrote:
> On 07/11/2022 15:36, Georgi Djakov wrote:
>> Hi,
>>
>> On 2.11.22 23:11, Krzysztof Kozlowski wrote:
>>> On 31/10/2022 19:29, Melody Olvera wrote:
>>>>
>>>> On 10/27/2022 8:29 AM, Krzysztof Kozlowski wrote:
>>>>> On 26/10/2022 15:05, Melody Olvera wrote:
>>>>>> Many of the *-virt compatible devices do not have a reg field
>>>>>> so remove it as required from the bindings.
>>>>> and some virt have it... This should be probably separate binding or if
>>>>> the list is small - allOf:if:then.
>>>> I attempted this; however I'm still seeing failures in dtb_check. I've added this
>>>> to the binding; does this look correct?
>>>>   allOf:
>>>>     - $ref: qcom,rpmh-common.yaml#
>>>> +  - if:
>>>> +      properties:
>>>> +        compatible:
>>>> +          contains:
>>>> +            enum:
>>>> +              - qcom,qdu1000-clk-virt
>>>> +              - qcom,qdu1000-mc-virt
>>>> +
>>>> +    then:
>>>> +      required:
>>>> +        - compatible
>>> No, because we talk about reg, not compatible. You should not require
>>> reg instead for some compatibles... but then the schema is getting
>>> complicated.
>>>
>>> It's difficult to give you recommendation because I do not know what are
>>> all these "virt" interconnects. Why some have unit address, why some do not?
>> My understanding is that the "reg" property is required for the NoCs that have
>> registers for controlling the QoS settings for the ports from Linux side.
>> Other NoCs might be controlled by some remote processor and direct access from
>> Linux may not be possible, so they do not have unit address and are outside of
>> the soc DT node.
>> Do we need to strictly define when exactly the "reg" property is required,
>> can't we just mark it as optional?
> It's preferred to make it strictly required or not allowed, so the
> bindings are specific. This also allows to validate for mistakes. It
> would be a bit different case if such test for req would make the
> bindings complicated. I think it's not the case because we could just
> split the bindings into two files:
> 1. One for controlled by AP, with reg.
> 2. One for controller by remote processors, without reg.
>
Sounds good. Will drop this change and add a new binding document.

Thanks,
Melody