Thread (13 messages) 13 messages, 4 authors, 2025-11-21

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

From: Ashish Mhetre <hidden>
Date: 2025-11-21 05:48:12
Also in: linux-devicetree, linux-iommu, linux-tegra, lkml

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:
quoted
On 11/3/2025 7:24 PM, Ashish Mhetre wrote:
quoted
On 10/31/2025 1:44 PM, Krzysztof Kozlowski wrote:
quoted
External email: Use caution opening links or attachments


On Fri, Oct 31, 2025 at 06:29:58AM +0000, Ashish Mhetre wrote:
quoted
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.
quoted
Will it be fine to add separate compatible
string
for Nvidia Tegra264 SMMU to restrict the usage of CMDQV?
quoted
quoted
quoted
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 <redacted>
---
  .../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.
quoted
quoted
+description: |
Do not need '|' unless you need to preserve formatting.
Okay, I'll remove this in next version.
quoted
quoted
+  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 [off-list ref]
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.
quoted
quoted
+
+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.
quoted
quoted
+
+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.
quoted
Best regards,
Krzysztof
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help