Re: [PATCH 2/3] dt-bindings: iommu: Add NVIDIA Tegra CMDQV support

[Ashish Mhetre <amhetre@nvidia.com>]

On 11/20/2025 3:53 PM, Robin Murphy wrote:
> External email: Use caution opening links or attachments
>
>
> On 2025-11-20 6:07 am, Ashish Mhetre wrote:
>>
>> On 11/3/2025 7:24 PM, Ashish Mhetre wrote:
>>>
>>> On 10/31/2025 1:44 PM, Krzysztof Kozlowski wrote:
>>>> External email: Use caution opening links or attachments
>>>>
>>>>
>>>> On Fri, Oct 31, 2025 at 06:29:58AM +0000, Ashish Mhetre wrote:
>>>>> The Command Queue Virtualization (CMDQV) hardware is part of the
>>>>> SMMUv3 implementation on NVIDIA Tegra SoCs. It assists in
>>>>> virtualizing the command queue for the SMMU.
>>>> If this is specific to Nvidia, then I think you need specific front
>>>> compatible and disallow it for other vendors.
>>>
>>> Yes, CMDQV is specific to Nvidia. There isn't currently a 
>>> vendor-specific
>>> compatible for Nvidia's arm,smmu-v3 implementation. Would it be
>>> acceptable
>>> to document this as Nvidia-specific in the description? Or can we add a
>>> new Nvidia-specific compatible string like "nvidia,smmu-v3" if that's
>>> preferred and use conditional schema to restrict the property?
>>
>> Hi Will, Robin,
>>
>> Do you have any suggestions on this? I have followed existing ACPI 
>> approach
>> for implementing DT support.
>
> No, the way the ACPI binding is implemented has the lookup going *from*
> the CMDQV node back to the SMMU instance (via the matching identifier) -
> this is entirely the opposite. The literal DT equivalent would be to use
> for_each_matching_node/for_each_compatible_node to scan the CMDQV nodes
> for a property indicating the relevant SMMU.
>
> I'm not hugely fussed either way though - since the fact is the Tegra234
> SMMU does have this custom modification, a specific
> "nvidia,tegra234-smmu", "arm,smmu-v3" compatible isn't inappropriate,
> even if it really doesn't make any difference to architectural SMMU
> operation without awareness of the other CMDQV nodes.
>
> Thanks,
> Robin.
>

Thanks for the suggestions Robin. Approach 2 is much simpler with current
implementation I have. I will proceed with adding Nvidia specific compatible
string "nvidia,tegra264-smmu", "arm,smmu-v3" in V2.

>> Will it be fine to add separate compatible
>> string
>> for Nvidia Tegra264 SMMU to restrict the usage of CMDQV?
>>
>>>>> Add a new device tree binding document for nvidia,tegra264-cmdqv.
>>>>>
>>>>> Also update the arm,smmu-v3 binding to include an optional 
>>>>> nvidia,cmdqv
>>>>> property. This property is a phandle to the CMDQV device node, 
>>>>> allowing
>>>>> the SMMU driver to associate with its corresponding CMDQV instance.
>>>>>
>>>>> Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
>>>>> ---
>>>>>   .../bindings/iommu/arm,smmu-v3.yaml           | 10 ++++
>>>>>   .../bindings/iommu/nvidia,tegra264-cmdqv.yaml | 46 +++++++++++++++
>>>>> ++++
>>>>>   2 files changed, 56 insertions(+)
>>>>>   create mode 100644 Documentation/devicetree/bindings/iommu/
>>>>> nvidia,tegra264-cmdqv.yaml
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-
>>>>> v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
>>>>> index 75fcf4cb52d9..edc0c20a0c80 100644
>>>>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
>>>>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
>>>>> @@ -58,6 +58,15 @@ properties:
>>>>>
>>>>>     msi-parent: true
>>>>>
>>>>> +  nvidia,cmdqv:
>>>>> +    description: |
>>>>> +      A phandle to its pairing CMDQV extension for an
>>>>> implementation on NVIDIA
>>>>> +      Tegra SoC.
>>>>> +
>>>>> +      If this property is absent, CMDQ-Virtualization won't be used
>>>>> and SMMU
>>>>> +      will only use its own CMDQ.
>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>>> +
>>>>>     hisilicon,broken-prefetch-cmd:
>>>>>       type: boolean
>>>>>       description: Avoid sending CMD_PREFETCH_* commands to the SMMU.
>>>>> @@ -92,4 +101,5 @@ examples:
>>>>>               dma-coherent;
>>>>>               #iommu-cells = <1>;
>>>>>               msi-parent = <&its 0xff0000>;
>>>>> +            nvidia,cmdqv = <&cmdqv>;
>>>>>       };
>>>>> diff --git a/Documentation/devicetree/bindings/iommu/
>>>>> nvidia,tegra264-cmdqv.yaml b/Documentation/devicetree/bindings/
>>>>> iommu/nvidia,tegra264-cmdqv.yaml
>>>>> new file mode 100644
>>>>> index 000000000000..f22c370278a3
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/iommu/nvidia,tegra264-
>>>>> cmdqv.yaml
>>>>> @@ -0,0 +1,46 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: NVIDIA Tegra264 CMDQV
>>>> Missing blank line
>>>
>>> Ack, I will correct this in V2.
>>>>> +description: |
>>>> Do not need '|' unless you need to preserve formatting.
>>>
>>> Okay, I'll remove this in next version.
>>>>> +  The CMDQ-Virtualization hardware block is part of the SMMUv3
>>>>> implementation
>>>>> +  on Tegra264 SoCs. It assists in virtualizing the command queue
>>>>> for the SMMU.
>>>>> +
>>>>> +maintainers:
>>>>> +  - NVIDIA Corporation <linux-tegra@nvidia.com>
>>>> No. It should be a person. If entire Nvidia cannot find a person, I
>>>> don't think we are interested in having this in the kernel.
>>>
>>> Okay, I'll add Nicolin as maintainer.
>>>>> +
>>>>> +properties:
>>>>> +  compatible:
>>>>> +    const: nvidia,tegra264-cmdqv
>>>>> +
>>>>> +  reg:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  interrupts:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  interrupt-names:
>>>>> +    items:
>>>>> +      - const: cmdqv
>>>> Drop interript names, obvious.
>>>
>>> Sure, I will update in V2.
>>>>> +
>>>>> +required:
>>>>> +  - compatible
>>>>> +  - reg
>>>>> +  - interrupts
>>>>> +  - interrupt-names
>>>>> +
>>>>> +additionalProperties: false
>>>>> +
>>>>> +examples:
>>>>> +  - |
>>>>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>> +    #include <dt-bindings/interrupt-controller/irq.h>
>>>>> +
>>>>> +    cmdqv: cmdqv@8105200000 {
>>>> Drop unused label
>>>
>>> Okay, I will remove the label.
>>>> Best regards,
>>>> Krzysztof
>>>>