[PATCH 0/8] Add more Tegra264 support

[PATCH 0/8] Add more Tegra264 support

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

Hi,

continuing from a previous series, this adds more Tegra264 support,
which is mostly device tree compatible strings. Towards the end of the
series, a DT is added for the P3971-0089+P3971-0008 engineering
reference platform. This should be enough to boot to an initial ramdisk,
but patches are in the works to enable booting to a login prompt using a
root filesystem on UFS, as well as other connectivity options such as
Ethernet.

Thierry

[0]: https://lore.kernel.org/linux-tegra/20250506133118.1011777-1-thierry.reding@gmail.com/

Thierry Reding (8):
  dt-bindings: dma: Add Tegra264 compatible string
  dt-bindings: rtc: tegra: Document Tegra264 RTC
  dt-bindings: tegra: Document P3971-0089+P3834-0008 Platform
  dt-bindings: Add Tegra264 clock and reset definitions
  dt-bindings: memory: Add Tegra264 definitions
  arm64: tegra: Add Tegra264 support
  arm64: tegra: Add p3971-0089+p3834-0008 support
  arm64: defconfig: Enable Tegra241 and Tegra264

 .../devicetree/bindings/arm/tegra.yaml        |   5 +
 .../bindings/dma/nvidia,tegra186-gpc-dma.yaml |   1 +
 .../bindings/rtc/nvidia,tegra20-rtc.yaml      |   1 +
 arch/arm64/boot/dts/nvidia/Makefile           |   2 +
 .../boot/dts/nvidia/tegra264-p3834-0008.dtsi  |   7 +
 .../arm64/boot/dts/nvidia/tegra264-p3834.dtsi |  30 ++
 .../nvidia/tegra264-p3971-0089+p3834-0008.dts |  11 +
 .../dts/nvidia/tegra264-p3971-0089+p3834.dtsi |  14 +
 .../boot/dts/nvidia/tegra264-p3971-0089.dtsi  |   3 +
 .../arm64/boot/dts/nvidia/tegra264-p3971.dtsi |   4 +
 arch/arm64/boot/dts/nvidia/tegra264.dtsi      | 363 ++++++++++++++++++
 arch/arm64/configs/defconfig                  |   2 +
 include/dt-bindings/clock/tegra264-clock.h    |   9 +
 include/dt-bindings/memory/tegra264-mc.h      |  13 +
 include/dt-bindings/reset/tegra264-reset.h    |   7 +
 15 files changed, 472 insertions(+)
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p3834-0008.dtsi
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p3834.dtsi
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p3971-0089+p3834-0008.dts
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p3971-0089+p3834.dtsi
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p3971-0089.dtsi
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p3971.dtsi
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra264.dtsi
 create mode 100644 include/dt-bindings/clock/tegra264-clock.h
 create mode 100644 include/dt-bindings/memory/tegra264-mc.h
 create mode 100644 include/dt-bindings/reset/tegra264-reset.h

-- 
2.49.0

[PATCH 1/8] dt-bindings: dma: Add Tegra264 compatible string

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

Document the compatible string used for the GPCDMA controller on
Tegra264.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 .../devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml         | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
index a790e5687844..0dabe9bbb219 100644
--- a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
@@ -24,6 +24,7 @@ properties:
       - const: nvidia,tegra186-gpcdma
       - items:
           - enum:
+              - nvidia,tegra264-gpcdma
               - nvidia,tegra234-gpcdma
               - nvidia,tegra194-gpcdma
           - const: nvidia,tegra186-gpcdma
-- 
2.49.0

[PATCH 2/8] dt-bindings: rtc: tegra: Document Tegra264 RTC

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

Add the compatible string for the RTC block found on the Tegra264 SoC.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.yaml b/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.yaml
index 17d6280e5515..a86e926ae3d1 100644
--- a/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.yaml
@@ -28,6 +28,7 @@ properties:
               - nvidia,tegra186-rtc
               - nvidia,tegra194-rtc
               - nvidia,tegra234-rtc
+              - nvidia,tegra264-rtc
           - const: nvidia,tegra20-rtc
 
   reg:
-- 
2.49.0

[PATCH 3/8] dt-bindings: tegra: Document P3971-0089+P3834-0008 Platform

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

This is an engineering reference platform for the Tegra264 SoC.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 Documentation/devicetree/bindings/arm/tegra.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml
index 65e0ff1fdf1e..cdf5a730d8a9 100644
--- a/Documentation/devicetree/bindings/arm/tegra.yaml
+++ b/Documentation/devicetree/bindings/arm/tegra.yaml
@@ -245,5 +245,10 @@ properties:
           - const: nvidia,p3768-0000+p3767-0005
           - const: nvidia,p3767-0005
           - const: nvidia,tegra234
+      - description: NVIDIA P3971-0089+P3834-0008 Engineering Reference Platform
+        items:
+          - const: nvidia,p3971-0089+p3834-0008
+          - const: nvidia,p3834-0008
+          - const: nvidia,tegra264
 
 additionalProperties: true
-- 
2.49.0

[PATCH 4/8] dt-bindings: Add Tegra264 clock and reset definitions

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 include/dt-bindings/clock/tegra264-clock.h | 9 +++++++++
 include/dt-bindings/reset/tegra264-reset.h | 7 +++++++
 2 files changed, 16 insertions(+)
 create mode 100644 include/dt-bindings/clock/tegra264-clock.h
 create mode 100644 include/dt-bindings/reset/tegra264-reset.h

diff --git a/include/dt-bindings/clock/tegra264-clock.h b/include/dt-bindings/clock/tegra264-clock.h
new file mode 100644
index 000000000000..7af85b401dd0
--- /dev/null
+++ b/include/dt-bindings/clock/tegra264-clock.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/* Copyright (c) 2022-2023, NVIDIA CORPORATION. All rights reserved. */
+
+#ifndef DT_BINDINGS_CLOCK_TEGRA264_CLOCK_H
+#define DT_BINDINGS_CLOCK_TEGRA264_CLOCK_H
+
+#define TEGRA264_CLK_CLK_S			2U
+
+#endif /* DT_BINDINGS_CLOCK_TEGRA264_CLOCK_H */
diff --git a/include/dt-bindings/reset/tegra264-reset.h b/include/dt-bindings/reset/tegra264-reset.h
new file mode 100644
index 000000000000..31d89dcf62fa
--- /dev/null
+++ b/include/dt-bindings/reset/tegra264-reset.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/* Copyright (c) 2022-2023, NVIDIA CORPORATION. All rights reserved. */
+
+#ifndef DT_BINDINGS_RESET_TEGRA264_RESET_H
+#define DT_BINDINGS_RESET_TEGRA264_RESET_H
+
+#endif /* DT_BINDINGS_RESET_TEGRA264_RESET_H */
-- 
2.49.0

[PATCH 5/8] dt-bindings: memory: Add Tegra264 definitions

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

This doesn't currently contain any stream ID or memory client ID
definitions, but they will be added in subsquent patches.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 include/dt-bindings/memory/tegra264-mc.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)
 create mode 100644 include/dt-bindings/memory/tegra264-mc.h

diff --git a/include/dt-bindings/memory/tegra264-mc.h b/include/dt-bindings/memory/tegra264-mc.h
new file mode 100644
index 000000000000..128073d05895
--- /dev/null
+++ b/include/dt-bindings/memory/tegra264-mc.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
+/* Copyright (c) 2024, NVIDIA CORPORATION. All rights reserved. */
+
+#ifndef DT_BINDINGS_MEMORY_TEGRA264_MC_H
+#define DT_BINDINGS_MEMORY_TEGRA264_MC_H
+
+#define TEGRA264_SID(x) ((x) << 8)
+
+/*
+ * memory client IDs
+ */
+
+#endif
-- 
2.49.0

[PATCH 6/8] arm64: tegra: Add Tegra264 support

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

Add basic support for the Tegra264 SoC, sufficient for booting into an
initial ramdisk.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 arch/arm64/boot/dts/nvidia/tegra264.dtsi | 363 +++++++++++++++++++++++
 1 file changed, 363 insertions(+)
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra264.dtsi

diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
new file mode 100644
index 000000000000..468c94137ef1
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
@@ -0,0 +1,363 @@
+// SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+
+#include <dt-bindings/clock/tegra264-clock.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/mailbox/tegra186-hsp.h>
+#include <dt-bindings/memory/tegra264-mc.h>
+#include <dt-bindings/reset/tegra264-reset.h>
+
+/ {
+	compatible = "nvidia,tegra264";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+	numa-node-id = <0>;
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		shmem_bpmp: shmem@86070000 {
+			compatible = "nvidia,tegra264-bpmp-shmem";
+			reg = <0x0 0x86070000 0x0 0x2000>;
+			no-map;
+		};
+	};
+
+	/* SYSTEM MMIO */
+	bus@0 {
+		compatible = "simple-bus";
+
+		#address-cells = <2>;
+		#size-cells = <2>;
+
+		ranges = <0x00 0x00000000 0x00 0x00000000 0x01 0x00000000>;
+
+		misc@100000 {
+			compatible = "nvidia,tegra234-misc";
+			reg = <0x0 0x00100000 0x0 0x0f000>,
+			      <0x0 0x0c140000 0x0 0x10000>;
+		};
+
+		timer@8000000 {
+			compatible = "nvidia,tegra234-timer";
+			reg = <0x0 0x08000000 0x0 0x140000>;
+			interrupts = <GIC_SPI 773 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 774 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 775 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 776 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		gpcdma: dma-controller@8400000 {
+			compatible = "nvidia,tegra264-gpcdma", "nvidia,tegra186-gpcdma";
+			reg = <0x0 0x08400000 0x0 0x210000>;
+			interrupts = <GIC_SPI 584 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 585 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 586 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 587 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 588 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 589 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 590 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 591 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 592 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 593 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 594 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 595 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 596 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 597 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 598 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 599 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 600 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 609 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 610 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 611 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 612 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 613 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 614 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 615 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			iommus = <&smmu1 0x00000800>;
+			dma-coherent;
+			dma-channel-mask = <0xfffffffe>;
+			status = "disabled";
+		};
+
+		hsp_top: hsp@8800000 {
+			compatible = "nvidia,tegra264-hsp";
+			reg = <0x0 0x08800000 0x0 0xd0000>;
+			interrupts = <GIC_SPI 620 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 622 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 623 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 624 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 626 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 637 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 638 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 639 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "doorbell", "shared0", "shared1", "shared2",
+					  "shared3", "shared4", "shared5", "shared6",
+					  "shared7";
+			#mbox-cells = <2>;
+		};
+
+		rtc: rtc@c2c0000 {
+			compatible = "nvidia,tegra264-rtc", "nvidia,tegra20-rtc";
+			reg = <0x0 0x0c2c0000 0x0 0x10000>;
+			interrupt-parent = <&pmc>;
+			interrupts = <65 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&bpmp TEGRA264_CLK_CLK_S>;
+			clock-names = "rtc";
+			status = "disabled";
+		};
+
+		serial@c4e0000 {
+			compatible = "nvidia,tegra264-utc";
+			reg = <0x0 0x0c4e0000 0x0 0x8000>,
+			      <0x0 0x0c4e8000 0x0 0x8000>;
+			reg-names = "tx", "rx";
+			interrupts = <GIC_SPI 515 IRQ_TYPE_LEVEL_HIGH>;
+			rx-threshold = <4>;
+			tx-threshold = <4>;
+			status = "disabled";
+		};
+
+		serial@c5a0000 {
+			compatible = "nvidia,tegra264-utc";
+			reg = <0x0 0x0c5a0000 0x0 0x8000>,
+			      <0x0 0x0c5a8000 0x0 0x8000>;
+			reg-names = "tx", "rx";
+			interrupts = <GIC_SPI 527 IRQ_TYPE_LEVEL_HIGH>;
+			rx-threshold = <4>;
+			tx-threshold = <4>;
+			status = "disabled";
+		};
+
+		uart0: serial@c5f0000 {
+			compatible = "arm,sbsa-uart";
+			reg = <0x0 0x0c5f0000 0x0 0x10000>;
+			interrupts = <GIC_SPI 514 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		pmc: pmc@c800000 {
+			compatible = "nvidia,tegra264-pmc";
+			reg = <0x0 0x0c800000 0x0 0x100000>,
+			      <0x0 0x0c990000 0x0 0x10000>,
+			      <0x0 0x0ca00000 0x0 0x10000>,
+			      <0x0 0x0c980000 0x0 0x10000>,
+			      <0x0 0x0c9c0000 0x0 0x40000>;
+			reg-names = "pmc", "wake", "aotag", "scratch", "misc";
+			#interrupt-cells = <2>;
+			interrupt-controller;
+		};
+	};
+
+	/* TOP_MMIO */
+	bus@8100000000 {
+		compatible = "simple-bus";
+
+		#address-cells = <2>;
+		#size-cells = <2>;
+
+		ranges = <0x00 0x00000000 0x81 0x00000000 0x01 0x00000000>, /* MMIO */
+			 <0x01 0x00000000 0x00 0x20000000 0x00 0x40000000>, /* non-prefetchable memory (32-bit) */
+			 <0x02 0x00000000 0xd0 0x00000000 0x08 0x80000000>; /* ECAM, prefetchable memory, I/O */
+
+		smmu1: iommu@5000000 {
+			compatible = "arm,smmu-v3";
+			reg = <0x00 0x5000000 0x0 0x200000>;
+			interrupts = <GIC_SPI 12 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 13 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "eventq", "gerror";
+			status = "disabled";
+
+			#iommu-cells = <1>;
+			dma-coherent;
+		};
+
+		smmu2: iommu@6000000 {
+			compatible = "arm,smmu-v3";
+			reg = <0x00 0x6000000 0x0 0x200000>;
+			interrupts = <GIC_SPI 1 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 2 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "eventq", "gerror";
+			status = "disabled";
+
+			#iommu-cells = <1>;
+			dma-coherent;
+		};
+
+		smmu0: iommu@a000000 {
+			compatible = "arm,smmu-v3";
+			reg = <0x00 0xa000000 0x0 0x200000>;
+			interrupts = <GIC_SPI 21 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 22 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "eventq", "gerror";
+			status = "disabled";
+
+			#iommu-cells = <1>;
+			dma-coherent;
+		};
+
+		smmu4: iommu@b000000 {
+			compatible = "arm,smmu-v3";
+			reg = <0x00 0xb000000 0x0 0x200000>;
+			interrupts = <GIC_SPI 30 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 31 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "eventq", "gerror";
+			status = "disabled";
+
+			#iommu-cells = <1>;
+			dma-coherent;
+		};
+
+		gic: interrupt-controller@46000000 {
+			compatible = "arm,gic-v3";
+			reg = <0x00 0x46000000 0x0 0x010000>, /* GICD */
+			      <0x00 0x46080000 0x0 0x400000>; /* GICR */
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
+
+			redistributor-stride = <0x0 0x40000>;
+			#redistributor-regions = <1>;
+			#interrupt-cells = <3>;
+			interrupt-controller;
+
+			#address-cells = <2>;
+			#size-cells = <2>;
+
+			ranges = <0x0 0x0 0x00 0x46000000 0x0 0x1000000>;
+
+			its: msi-controller@40000 {
+				compatible = "arm,gic-v3-its";
+				reg = <0x0 0x40000 0x0 0x40000>;
+				#msi-cells = <1>;
+				msi-controller;
+			};
+		};
+	};
+
+	/* DISP_USB MMIO */
+	bus@8800000000 {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+
+		ranges = <0x00 0x00000000 0x88 0x00000000 0x01 0x00000000>;
+
+		smmu3: iommu@6000000 {
+			compatible = "arm,smmu-v3";
+			reg = <0x00 0x6000000 0x0 0x200000>;
+			interrupts = <GIC_SPI 225 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 226 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "eventq", "gerror";
+			status = "disabled";
+
+			#iommu-cells = <1>;
+			dma-coherent;
+		};
+	};
+
+	/* UPHY MMIO */
+	bus@a800000000 {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+
+		ranges = <0x00 0x00000000 0xa8 0x00000000 0x40 0x00000000>, /* MMIO, ECAM, prefetchable memory, I/O */
+			 <0x80 0x00000000 0x00 0x20000000 0x00 0x40000000>; /* non-prefetchable memory (32-bit) */
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu@0 {
+			compatible = "arm,armv8";
+			device_type = "cpu";
+			reg = <0x00000>;
+			status = "okay";
+
+			enable-method = "psci";
+			numa-node-id = <0>;
+
+			i-cache-size = <65536>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <65536>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <256>;
+		};
+
+		cpu1: cpu@1 {
+			compatible = "arm,armv8";
+			device_type = "cpu";
+			reg = <0x10000>;
+			status = "okay";
+
+			enable-method = "psci";
+			numa-node-id = <0>;
+
+			i-cache-size = <65536>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <65536>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <256>;
+		};
+	};
+
+	bpmp: bpmp {
+		compatible = "nvidia,tegra264-bpmp", "nvidia,tegra186-bpmp";
+		mboxes = <&hsp_top TEGRA_HSP_MBOX_TYPE_DB
+				   TEGRA_HSP_DB_MASTER_BPMP>;
+		memory-region = <&shmem_bpmp>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+		#power-domain-cells = <1>;
+
+		i2c {
+			compatible = "nvidia,tegra186-bpmp-i2c";
+			nvidia,bpmp-bus-id = <5>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		thermal {
+			compatible = "nvidia,tegra186-bpmp-thermal";
+			#thermal-sensor-cells = <1>;
+		};
+	};
+
+	pmu {
+		compatible = "arm,armv8-pmuv3";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
+		status = "okay";
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		status = "okay";
+		method = "smc";
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 12 IRQ_TYPE_LEVEL_LOW>;
+		status = "okay";
+	};
+};
-- 
2.49.0

[PATCH 7/8] arm64: tegra: Add p3971-0089+p3834-0008 support

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

The P3971-0089+P3834-0008 is an engineering reference platform for the
Tegra264 SoC.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 arch/arm64/boot/dts/nvidia/Makefile           |  2 ++
 .../boot/dts/nvidia/tegra264-p3834-0008.dtsi  |  7 +++++
 .../arm64/boot/dts/nvidia/tegra264-p3834.dtsi | 30 +++++++++++++++++++
 .../nvidia/tegra264-p3971-0089+p3834-0008.dts | 11 +++++++
 .../dts/nvidia/tegra264-p3971-0089+p3834.dtsi | 14 +++++++++
 .../boot/dts/nvidia/tegra264-p3971-0089.dtsi  |  3 ++
 .../arm64/boot/dts/nvidia/tegra264-p3971.dtsi |  4 +++
 7 files changed, 71 insertions(+)
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p3834-0008.dtsi
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p3834.dtsi
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p3971-0089+p3834-0008.dts
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p3971-0089+p3834.dtsi
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p3971-0089.dtsi
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p3971.dtsi

diff --git a/arch/arm64/boot/dts/nvidia/Makefile b/arch/arm64/boot/dts/nvidia/Makefile
index 0fbb8a494dba..171e08c94d5a 100644
--- a/arch/arm64/boot/dts/nvidia/Makefile
+++ b/arch/arm64/boot/dts/nvidia/Makefile
@@ -12,6 +12,7 @@ DTC_FLAGS_tegra234-p3737-0000+p3701-0000 := -@
 DTC_FLAGS_tegra234-p3740-0002+p3701-0008 := -@
 DTC_FLAGS_tegra234-p3768-0000+p3767-0000 := -@
 DTC_FLAGS_tegra234-p3768-0000+p3767-0005 := -@
+DTC_FLAGS_tegra264-p3971-0089+p3834-0008 := -@
 
 dtb-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra132-norrin.dtb
 dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2371-0000.dtb
@@ -31,3 +32,4 @@ dtb-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra234-p3737-0000+p3701-0008.dtb
 dtb-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra234-p3740-0002+p3701-0008.dtb
 dtb-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra234-p3768-0000+p3767-0000.dtb
 dtb-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra234-p3768-0000+p3767-0005.dtb
+dtb-$(CONFIG_ARCH_TEGRA_264_SOC) += tegra264-p3971-0089+p3834-0008.dtb
diff --git a/arch/arm64/boot/dts/nvidia/tegra264-p3834-0008.dtsi b/arch/arm64/boot/dts/nvidia/tegra264-p3834-0008.dtsi
new file mode 100644
index 000000000000..94ace6784749
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra264-p3834-0008.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+
+#include "tegra264-p3834.dtsi"
+
+/ {
+	compatible = "nvidia,p3834-0008", "nvidia,tegra264";
+};
diff --git a/arch/arm64/boot/dts/nvidia/tegra264-p3834.dtsi b/arch/arm64/boot/dts/nvidia/tegra264-p3834.dtsi
new file mode 100644
index 000000000000..06795c82427a
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra264-p3834.dtsi
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+
+#include "tegra264.dtsi"
+
+/ {
+	compatible = "nvidia,p3834", "nvidia,tegra264";
+
+	aliases {
+	};
+
+	bus@0 {
+		serial@c4e0000 {
+			status = "okay";
+		};
+
+		serial@c5a0000 {
+			status = "okay";
+		};
+	};
+
+	bus@8100000000 {
+		iommu@5000000 {
+			status = "okay";
+		};
+
+		iommu@6000000 {
+			status = "okay";
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/nvidia/tegra264-p3971-0089+p3834-0008.dts b/arch/arm64/boot/dts/nvidia/tegra264-p3971-0089+p3834-0008.dts
new file mode 100644
index 000000000000..3a6f4b7e6b75
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra264-p3971-0089+p3834-0008.dts
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+/dts-v1/;
+
+// module files must be included first
+#include "tegra264-p3834-0008.dtsi"
+#include "tegra264-p3971-0089+p3834.dtsi"
+
+/ {
+	model = "NVIDIA P3971-0089+P3834-0008 Engineering Reference Platform";
+	compatible = "nvidia,p3971-0089+p3834-0008", "nvidia,p3834-0008", "nvidia,tegra264";
+};
diff --git a/arch/arm64/boot/dts/nvidia/tegra264-p3971-0089+p3834.dtsi b/arch/arm64/boot/dts/nvidia/tegra264-p3971-0089+p3834.dtsi
new file mode 100644
index 000000000000..46cfa8f1da1c
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra264-p3971-0089+p3834.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+
+#include "tegra264-p3971-0089.dtsi"
+
+/ {
+	aliases {
+		serial0 = &{/bus@0/serial@c4e0000};
+		serial1 = &{/bus@0/serial@c5a0000};
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
diff --git a/arch/arm64/boot/dts/nvidia/tegra264-p3971-0089.dtsi b/arch/arm64/boot/dts/nvidia/tegra264-p3971-0089.dtsi
new file mode 100644
index 000000000000..e8576cf2a0b6
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra264-p3971-0089.dtsi
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+
+#include "tegra264-p3971.dtsi"
diff --git a/arch/arm64/boot/dts/nvidia/tegra264-p3971.dtsi b/arch/arm64/boot/dts/nvidia/tegra264-p3971.dtsi
new file mode 100644
index 000000000000..6b6259b7310f
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra264-p3971.dtsi
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+
+/ {
+};
-- 
2.49.0

[PATCH 8/8] arm64: defconfig: Enable Tegra241 and Tegra264

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

Enable the configuration options for these newer generations of Tegra so
that support for them gets built by default.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 arch/arm64/configs/defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 696bd4043c99..c5342a35fc15 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1491,6 +1491,8 @@ CONFIG_ARCH_TEGRA_210_SOC=y
 CONFIG_ARCH_TEGRA_186_SOC=y
 CONFIG_ARCH_TEGRA_194_SOC=y
 CONFIG_ARCH_TEGRA_234_SOC=y
+CONFIG_ARCH_TEGRA_241_SOC=y
+CONFIG_ARCH_TEGRA_264_SOC=y
 CONFIG_TI_PRUSS=m
 CONFIG_OWL_PM_DOMAINS=y
 CONFIG_RASPBERRYPI_POWER=y
-- 
2.49.0

Re: [PATCH 5/8] dt-bindings: memory: Add Tegra264 definitions

[Krzysztof Kozlowski]

On 07/05/2025 16:37, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> This doesn't currently contain any stream ID or memory client ID
> definitions, but they will be added in subsquent patches.
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>

<form letter>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC (and consider --no-git-fallback argument, so you will
not CC people just because they made one commit years ago). It might
happen, that command when run on an older kernel, gives you outdated
entries. Therefore please be sure you base your patches on recent Linux
kernel.

Tools like b4 or scripts/get_maintainer.pl provide you proper list of
people, so fix your workflow. Tools might also fail if you work on some
ancient tree (don't, instead use mainline) or work on fork of kernel
(don't, instead use mainline). Just use b4 and everything should be
fine, although remember about `b4 prep --auto-to-cc` if you added new
patches to the patchset.
</form letter>

> ---
>  include/dt-bindings/memory/tegra264-mc.h | 13 +++++++++++++

Filename based on compatible.

Best regards,
Krzysztof

Re: [PATCH 5/8] dt-bindings: memory: Add Tegra264 definitions

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1876 bytes --]

On Thu, May 08, 2025 at 07:48:22AM +0200, Krzysztof Kozlowski wrote:
> On 07/05/2025 16:37, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > This doesn't currently contain any stream ID or memory client ID
> > definitions, but they will be added in subsquent patches.
> > 
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> 
> <form letter>
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC (and consider --no-git-fallback argument, so you will
> not CC people just because they made one commit years ago). It might
> happen, that command when run on an older kernel, gives you outdated
> entries. Therefore please be sure you base your patches on recent Linux
> kernel.
> 
> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
> people, so fix your workflow. Tools might also fail if you work on some
> ancient tree (don't, instead use mainline) or work on fork of kernel
> (don't, instead use mainline). Just use b4 and everything should be
> fine, although remember about `b4 prep --auto-to-cc` if you added new
> patches to the patchset.
> </form letter>

get_maintainers.pl lists 13 people and 7 lists. That's *way* too many
recipients for something as trivial as this series, in my opinion, so I
tend to curate the list of recipients manually. I guess I went a bit
overboard and should've at least listed all DT maintainers explicitly.

> > ---
> >  include/dt-bindings/memory/tegra264-mc.h | 13 +++++++++++++
> 
> Filename based on compatible.

The compatible string for this is nvidia,tegra264-mc, so I don't know
how much more you'd like me to make it based on that. Do you expect me
to add the nvidia, prefix? In that case it would be inconsistent with
all of the 8 other Tegra MC includes that we have in that directory.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 5/8] dt-bindings: memory: Add Tegra264 definitions

[Krzysztof Kozlowski]

On 08/05/2025 09:31, Thierry Reding wrote:
> On Thu, May 08, 2025 at 07:48:22AM +0200, Krzysztof Kozlowski wrote:
>> On 07/05/2025 16:37, Thierry Reding wrote:
>>> From: Thierry Reding <treding@nvidia.com>
>>>
>>> This doesn't currently contain any stream ID or memory client ID
>>> definitions, but they will be added in subsquent patches.
>>>
>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>>
>> <form letter>
>> Please use scripts/get_maintainers.pl to get a list of necessary people
>> and lists to CC (and consider --no-git-fallback argument, so you will
>> not CC people just because they made one commit years ago). It might
>> happen, that command when run on an older kernel, gives you outdated
>> entries. Therefore please be sure you base your patches on recent Linux
>> kernel.
>>
>> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
>> people, so fix your workflow. Tools might also fail if you work on some
>> ancient tree (don't, instead use mainline) or work on fork of kernel
>> (don't, instead use mainline). Just use b4 and everything should be
>> fine, although remember about `b4 prep --auto-to-cc` if you added new
>> patches to the patchset.
>> </form letter>
> 
> get_maintainers.pl lists 13 people and 7 lists. That's *way* too many
> recipients for something as trivial as this series, in my opinion, so I
> tend to curate the list of recipients manually. I guess I went a bit
> overboard and should've at least listed all DT maintainers explicitly.


Usually that's a sign you combine too many subsystems into one patchset,
so the solution is to split, not remove maintainers/lists from CC.

> 
>>> ---
>>>  include/dt-bindings/memory/tegra264-mc.h | 13 +++++++++++++
>>
>> Filename based on compatible.
> 
> The compatible string for this is nvidia,tegra264-mc, so I don't know


so nvidia,tegra264-mc.h


> how much more you'd like me to make it based on that. Do you expect me
> to add the nvidia, prefix? In that case it would be inconsistent with
> all of the 8 other Tegra MC includes that we have in that directory.


Same story as for every other case, why this would be different? All of
them - amlogic, mediatek, samsung, qcom, every soc - move to new style
since some years, why this one should be different?

Best regards,
Krzysztof

Re: [PATCH 4/8] dt-bindings: Add Tegra264 clock and reset definitions

[Krzysztof Kozlowski]

On 07/05/2025 16:37, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>

Missing commit msg

> ---
>  include/dt-bindings/clock/tegra264-clock.h | 9 +++++++++
>  include/dt-bindings/reset/tegra264-reset.h | 7 +++++++
>  2 files changed, 16 insertions(+)
>  create mode 100644 include/dt-bindings/clock/tegra264-clock.h
>  create mode 100644 include/dt-bindings/reset/tegra264-reset.h


Filename equal to the compatible. That's the standard convention for all
the headers since some years.

Best regards,
Krzysztof

Re: [PATCH 4/8] dt-bindings: Add Tegra264 clock and reset definitions

[Krzysztof Kozlowski]

On 07/05/2025 16:37, Thierry Reding wrote:
> @@ -0,0 +1,9 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/* Copyright (c) 2022-2023, NVIDIA CORPORATION. All rights reserved. */
> +
> +#ifndef DT_BINDINGS_CLOCK_TEGRA264_CLOCK_H
> +#define DT_BINDINGS_CLOCK_TEGRA264_CLOCK_H
> +
> +#define TEGRA264_CLK_CLK_S			2U

Abstract IDs start from 0 or 1, not 2. Also drop "U".

> +
> +#endif /* DT_BINDINGS_CLOCK_TEGRA264_CLOCK_H */
> diff --git a/include/dt-bindings/reset/tegra264-reset.h b/include/dt-bindings/reset/tegra264-reset.h
> new file mode 100644
> index 000000000000..31d89dcf62fa
> --- /dev/null
> +++ b/include/dt-bindings/reset/tegra264-reset.h
> @@ -0,0 +1,7 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/* Copyright (c) 2022-2023, NVIDIA CORPORATION. All rights reserved. */
> +
> +#ifndef DT_BINDINGS_RESET_TEGRA264_RESET_H
> +#define DT_BINDINGS_RESET_TEGRA264_RESET_H
> +
This is empty, drop.

Best regards,
Krzysztof

Re: [PATCH 4/8] dt-bindings: Add Tegra264 clock and reset definitions

[Krzysztof Kozlowski]

On 08/05/2025 09:39, Krzysztof Kozlowski wrote:
> On 07/05/2025 16:37, Thierry Reding wrote:
>> From: Thierry Reding <treding@nvidia.com>
>>
>> Signed-off-by: Thierry Reding <treding@nvidia.com>
> 
> Missing commit msg
> 
>> ---
>>  include/dt-bindings/clock/tegra264-clock.h | 9 +++++++++
>>  include/dt-bindings/reset/tegra264-reset.h | 7 +++++++
>>  2 files changed, 16 insertions(+)
>>  create mode 100644 include/dt-bindings/clock/tegra264-clock.h
>>  create mode 100644 include/dt-bindings/reset/tegra264-reset.h
> 
> 
> Filename equal to the compatible. That's the standard convention for all
> the headers since some years.

Huh, I cannot find the binding in this patchset. Where is the actual
binding added?

Best regards,
Krzysztof

Re: [PATCH 4/8] dt-bindings: Add Tegra264 clock and reset definitions

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

On Thu, May 08, 2025 at 09:40:38AM +0200, Krzysztof Kozlowski wrote:
> On 08/05/2025 09:39, Krzysztof Kozlowski wrote:
> > On 07/05/2025 16:37, Thierry Reding wrote:
> >> From: Thierry Reding <treding@nvidia.com>
> >>
> >> Signed-off-by: Thierry Reding <treding@nvidia.com>
> > 
> > Missing commit msg
> > 
> >> ---
> >>  include/dt-bindings/clock/tegra264-clock.h | 9 +++++++++
> >>  include/dt-bindings/reset/tegra264-reset.h | 7 +++++++
> >>  2 files changed, 16 insertions(+)
> >>  create mode 100644 include/dt-bindings/clock/tegra264-clock.h
> >>  create mode 100644 include/dt-bindings/reset/tegra264-reset.h
> > 
> > 
> > Filename equal to the compatible. That's the standard convention for all
> > the headers since some years.
> 
> Huh, I cannot find the binding in this patchset. Where is the actual
> binding added?

The bindings for this are in

  Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml

There's no 1:1 mapping to a compatible for this because BPMP is many
things. It's a clock provider, a reset provider, a power domain
provider. These definitions reflect the IDs assigned by the BPMP ABI
and we've used this structure ever since this was introduced back in
2016.

I don't think changing the convention for this is a net advantage.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 4/8] dt-bindings: Add Tegra264 clock and reset definitions

[Krzysztof Kozlowski]

On 08/05/2025 09:46, Thierry Reding wrote:
> On Thu, May 08, 2025 at 09:40:38AM +0200, Krzysztof Kozlowski wrote:
>> On 08/05/2025 09:39, Krzysztof Kozlowski wrote:
>>> On 07/05/2025 16:37, Thierry Reding wrote:
>>>> From: Thierry Reding <treding@nvidia.com>
>>>>
>>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>>>
>>> Missing commit msg
>>>
>>>> ---
>>>>  include/dt-bindings/clock/tegra264-clock.h | 9 +++++++++
>>>>  include/dt-bindings/reset/tegra264-reset.h | 7 +++++++
>>>>  2 files changed, 16 insertions(+)
>>>>  create mode 100644 include/dt-bindings/clock/tegra264-clock.h
>>>>  create mode 100644 include/dt-bindings/reset/tegra264-reset.h
>>>
>>>
>>> Filename equal to the compatible. That's the standard convention for all
>>> the headers since some years.
>>
>> Huh, I cannot find the binding in this patchset. Where is the actual
>> binding added?
> 
> The bindings for this are in
> 
>   Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml

There is no tegra264 in that binding.

The header always goes with the binding and the drivers.

> 
> There's no 1:1 mapping to a compatible for this because BPMP is many
> things. It's a clock provider, a reset provider, a power domain

Sure, that's fine.

> provider. These definitions reflect the IDs assigned by the BPMP ABI
> and we've used this structure ever since this was introduced back in
> 2016.
> 
> I don't think changing the convention for this is a net advantage.

Headers still should match the compatible one way or another. Can be
nvidia,tegra264.h
(because -clock is redundant and you do not want to use the actual
compatible)


Best regards,
Krzysztof

Re: [PATCH 4/8] dt-bindings: Add Tegra264 clock and reset definitions

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1968 bytes --]

On Thu, May 08, 2025 at 09:40:02AM +0200, Krzysztof Kozlowski wrote:
> On 07/05/2025 16:37, Thierry Reding wrote:
> > @@ -0,0 +1,9 @@
> > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> > +/* Copyright (c) 2022-2023, NVIDIA CORPORATION. All rights reserved. */
> > +
> > +#ifndef DT_BINDINGS_CLOCK_TEGRA264_CLOCK_H
> > +#define DT_BINDINGS_CLOCK_TEGRA264_CLOCK_H
> > +
> > +#define TEGRA264_CLK_CLK_S			2U
> 
> Abstract IDs start from 0 or 1, not 2. Also drop "U".

These are not abstract IDs, they are defined by the BPMP ABI. We cannot
change them, otherwise it'll completely break.

For similar reasons I'd like to keep the "U". These definitions are for
the most part directly imported from the BPMP ABI headers, though we do
try to be selective about what we add, to avoid adding hundreds of new
lines in one go, and several safety-checking tools run on these headers
that happen to require the "U" suffix to make sure these have a defined
type.

> > +
> > +#endif /* DT_BINDINGS_CLOCK_TEGRA264_CLOCK_H */
> > diff --git a/include/dt-bindings/reset/tegra264-reset.h b/include/dt-bindings/reset/tegra264-reset.h
> > new file mode 100644
> > index 000000000000..31d89dcf62fa
> > --- /dev/null
> > +++ b/include/dt-bindings/reset/tegra264-reset.h
> > @@ -0,0 +1,7 @@
> > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> > +/* Copyright (c) 2022-2023, NVIDIA CORPORATION. All rights reserved. */
> > +
> > +#ifndef DT_BINDINGS_RESET_TEGRA264_RESET_H
> > +#define DT_BINDINGS_RESET_TEGRA264_RESET_H
> > +
> This is empty, drop.

We have three people currently working on additional drivers for this
SoC and they all need to add to these two files. Adding the empty file
here makes it a bit easier to coordinate things, making the resulting
conflicts trivial to resolve.

I know this looks out of place, but I promise this will soon gain
content and won't stay empty forever. =)

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 4/8] dt-bindings: Add Tegra264 clock and reset definitions

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]

On Thu, May 08, 2025 at 09:49:12AM +0200, Krzysztof Kozlowski wrote:
> On 08/05/2025 09:46, Thierry Reding wrote:
> > On Thu, May 08, 2025 at 09:40:38AM +0200, Krzysztof Kozlowski wrote:
> >> On 08/05/2025 09:39, Krzysztof Kozlowski wrote:
> >>> On 07/05/2025 16:37, Thierry Reding wrote:
> >>>> From: Thierry Reding <treding@nvidia.com>
> >>>>
> >>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
> >>>
> >>> Missing commit msg
> >>>
> >>>> ---
> >>>>  include/dt-bindings/clock/tegra264-clock.h | 9 +++++++++
> >>>>  include/dt-bindings/reset/tegra264-reset.h | 7 +++++++
> >>>>  2 files changed, 16 insertions(+)
> >>>>  create mode 100644 include/dt-bindings/clock/tegra264-clock.h
> >>>>  create mode 100644 include/dt-bindings/reset/tegra264-reset.h
> >>>
> >>>
> >>> Filename equal to the compatible. That's the standard convention for all
> >>> the headers since some years.
> >>
> >> Huh, I cannot find the binding in this patchset. Where is the actual
> >> binding added?
> > 
> > The bindings for this are in
> > 
> >   Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
> 
> There is no tegra264 in that binding.

That's part of an earlier series I sent out (and linked to from the
cover letter). It's here:

	https://lore.kernel.org/linux-tegra/20250506133118.1011777-1-thierry.reding@gmail.com/T/#m96bb396b352659581a9e71a4610c51e6ab4d5b6a

> The header always goes with the binding and the drivers.
> 
> > 
> > There's no 1:1 mapping to a compatible for this because BPMP is many
> > things. It's a clock provider, a reset provider, a power domain
> 
> Sure, that's fine.
> 
> > provider. These definitions reflect the IDs assigned by the BPMP ABI
> > and we've used this structure ever since this was introduced back in
> > 2016.
> > 
> > I don't think changing the convention for this is a net advantage.
> 
> Headers still should match the compatible one way or another. Can be
> nvidia,tegra264.h
> (because -clock is redundant and you do not want to use the actual
> compatible)

I get it. You want consistency. But what about consistency with earlier
chip generations? Do you want me to go and rename all of these files?

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 5/8] dt-bindings: memory: Add Tegra264 definitions

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2906 bytes --]

On Thu, May 08, 2025 at 09:37:27AM +0200, Krzysztof Kozlowski wrote:
> On 08/05/2025 09:31, Thierry Reding wrote:
> > On Thu, May 08, 2025 at 07:48:22AM +0200, Krzysztof Kozlowski wrote:
> >> On 07/05/2025 16:37, Thierry Reding wrote:
> >>> From: Thierry Reding <treding@nvidia.com>
> >>>
> >>> This doesn't currently contain any stream ID or memory client ID
> >>> definitions, but they will be added in subsquent patches.
> >>>
> >>> Signed-off-by: Thierry Reding <treding@nvidia.com>
> >>
> >> <form letter>
> >> Please use scripts/get_maintainers.pl to get a list of necessary people
> >> and lists to CC (and consider --no-git-fallback argument, so you will
> >> not CC people just because they made one commit years ago). It might
> >> happen, that command when run on an older kernel, gives you outdated
> >> entries. Therefore please be sure you base your patches on recent Linux
> >> kernel.
> >>
> >> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
> >> people, so fix your workflow. Tools might also fail if you work on some
> >> ancient tree (don't, instead use mainline) or work on fork of kernel
> >> (don't, instead use mainline). Just use b4 and everything should be
> >> fine, although remember about `b4 prep --auto-to-cc` if you added new
> >> patches to the patchset.
> >> </form letter>
> > 
> > get_maintainers.pl lists 13 people and 7 lists. That's *way* too many
> > recipients for something as trivial as this series, in my opinion, so I
> > tend to curate the list of recipients manually. I guess I went a bit
> > overboard and should've at least listed all DT maintainers explicitly.
> 
> 
> Usually that's a sign you combine too many subsystems into one patchset,
> so the solution is to split, not remove maintainers/lists from CC.

This is literally only DT bindings, includes and DT files. These can't
be split apart any further without causing other objections.

> 
> > 
> >>> ---
> >>>  include/dt-bindings/memory/tegra264-mc.h | 13 +++++++++++++
> >>
> >> Filename based on compatible.
> > 
> > The compatible string for this is nvidia,tegra264-mc, so I don't know
> 
> 
> so nvidia,tegra264-mc.h
> 
> 
> > how much more you'd like me to make it based on that. Do you expect me
> > to add the nvidia, prefix? In that case it would be inconsistent with
> > all of the 8 other Tegra MC includes that we have in that directory.
> 
> 
> Same story as for every other case, why this would be different? All of
> them - amlogic, mediatek, samsung, qcom, every soc - move to new style
> since some years, why this one should be different?

Because we've used exactly this naming convention for more than a
decade. I get that it's nice to have consistency, but do you really want
me to go and churn all of these files just so we can add a vendor-prefix
and drop a redundant suffix?

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 4/8] dt-bindings: Add Tegra264 clock and reset definitions

[Krzysztof Kozlowski]

On 08/05/2025 09:53, Thierry Reding wrote:
> On Thu, May 08, 2025 at 09:40:02AM +0200, Krzysztof Kozlowski wrote:
>> On 07/05/2025 16:37, Thierry Reding wrote:
>>> @@ -0,0 +1,9 @@
>>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
>>> +/* Copyright (c) 2022-2023, NVIDIA CORPORATION. All rights reserved. */
>>> +
>>> +#ifndef DT_BINDINGS_CLOCK_TEGRA264_CLOCK_H
>>> +#define DT_BINDINGS_CLOCK_TEGRA264_CLOCK_H
>>> +
>>> +#define TEGRA264_CLK_CLK_S			2U
>>
>> Abstract IDs start from 0 or 1, not 2. Also drop "U".
> 
> These are not abstract IDs, they are defined by the BPMP ABI. We cannot
> change them, otherwise it'll completely break.


You mean from the firmware? Sure. You have entire commit msg to explain
all unusual things here...

> 
> For similar reasons I'd like to keep the "U". These definitions are for
> the most part directly imported from the BPMP ABI headers, though we do
> try to be selective about what we add, to avoid adding hundreds of new
> lines in one go, and several safety-checking tools run on these headers
> that happen to require the "U" suffix to make sure these have a defined
> type.
> 
>>> +
>>> +#endif /* DT_BINDINGS_CLOCK_TEGRA264_CLOCK_H */
>>> diff --git a/include/dt-bindings/reset/tegra264-reset.h b/include/dt-bindings/reset/tegra264-reset.h
>>> new file mode 100644
>>> index 000000000000..31d89dcf62fa
>>> --- /dev/null
>>> +++ b/include/dt-bindings/reset/tegra264-reset.h
>>> @@ -0,0 +1,7 @@
>>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
>>> +/* Copyright (c) 2022-2023, NVIDIA CORPORATION. All rights reserved. */
>>> +
>>> +#ifndef DT_BINDINGS_RESET_TEGRA264_RESET_H
>>> +#define DT_BINDINGS_RESET_TEGRA264_RESET_H
>>> +
>> This is empty, drop.
> 
> We have three people currently working on additional drivers for this
> SoC and they all need to add to these two files. Adding the empty file
> here makes it a bit easier to coordinate things, making the resulting
> conflicts trivial to resolve.


Bindings are supposed to be complete (see writing bindings doc), this
means also bindings headers. If the constants come from firmware, they
are defined so I really do not understands why they cannot be published now.

Unless you mean that this is a new SoC and the firmware is not yet
fixed/finished, but all this must be explained in the commit msg.

Best regards,
Krzysztof

Re: [PATCH 5/8] dt-bindings: memory: Add Tegra264 definitions

[Krzysztof Kozlowski]

On 08/05/2025 10:02, Thierry Reding wrote:
>>
>>
>>> how much more you'd like me to make it based on that. Do you expect me
>>> to add the nvidia, prefix? In that case it would be inconsistent with
>>> all of the 8 other Tegra MC includes that we have in that directory.
>>
>>
>> Same story as for every other case, why this would be different? All of
>> them - amlogic, mediatek, samsung, qcom, every soc - move to new style
>> since some years, why this one should be different?
> 
> Because we've used exactly this naming convention for more than a
> decade. I get that it's nice to have consistency, but do you really want
> me to go and churn all of these files just so we can add a vendor-prefix
> and drop a redundant suffix?
No, I want new files. Look:
1. Some time ago tegra-1.h was added.
2. Someone spotted that there was tegra-1.h, so added now tegra-2.h.
3. Now this is a pattern so of course next person, even if asked to use
vendor prefix, will not, right? Because it would break the pattern. So
we have tegra-3.h
4. tegra.4 - no vendor prefix, because you have already three cases.
5. You see where I am going?

All of above - amlogic, mediatek, samsung, qcom - had decade of such
convention. I asked to changed, they used the same argument as you
("decade") and then changed.

Why this is different case than decade in amlogic, mediatek, samsung and
qcom?


Best regards,
Krzysztof

Re: [PATCH 4/8] dt-bindings: Add Tegra264 clock and reset definitions

[Krzysztof Kozlowski]

On 08/05/2025 09:59, Thierry Reding wrote:
> On Thu, May 08, 2025 at 09:49:12AM +0200, Krzysztof Kozlowski wrote:
>> On 08/05/2025 09:46, Thierry Reding wrote:
>>> On Thu, May 08, 2025 at 09:40:38AM +0200, Krzysztof Kozlowski wrote:
>>>> On 08/05/2025 09:39, Krzysztof Kozlowski wrote:
>>>>> On 07/05/2025 16:37, Thierry Reding wrote:
>>>>>> From: Thierry Reding <treding@nvidia.com>
>>>>>>
>>>>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>>>>>
>>>>> Missing commit msg
>>>>>
>>>>>> ---
>>>>>>  include/dt-bindings/clock/tegra264-clock.h | 9 +++++++++
>>>>>>  include/dt-bindings/reset/tegra264-reset.h | 7 +++++++
>>>>>>  2 files changed, 16 insertions(+)
>>>>>>  create mode 100644 include/dt-bindings/clock/tegra264-clock.h
>>>>>>  create mode 100644 include/dt-bindings/reset/tegra264-reset.h
>>>>>
>>>>>
>>>>> Filename equal to the compatible. That's the standard convention for all
>>>>> the headers since some years.
>>>>
>>>> Huh, I cannot find the binding in this patchset. Where is the actual
>>>> binding added?
>>>
>>> The bindings for this are in
>>>
>>>   Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
>>
>> There is no tegra264 in that binding.
> 
> That's part of an earlier series I sent out (and linked to from the
> cover letter). It's here:
> 
> 	https://lore.kernel.org/linux-tegra/20250506133118.1011777-1-thierry.reding@gmail.com/T/#m96bb396b352659581a9e71a4610c51e6ab4d5b6a


Then this patch belongs there. Standard rules apply: binding headers go
with the binding itself and the binding itself go with driver patch via
driver subsystem tree. At least usually. Nothing here is different than
all other vendors who follow such convention.

> 
>> The header always goes with the binding and the drivers.
>>
>>>
>>> There's no 1:1 mapping to a compatible for this because BPMP is many
>>> things. It's a clock provider, a reset provider, a power domain
>>
>> Sure, that's fine.
>>
>>> provider. These definitions reflect the IDs assigned by the BPMP ABI
>>> and we've used this structure ever since this was introduced back in
>>> 2016.
>>>
>>> I don't think changing the convention for this is a net advantage.
>>
>> Headers still should match the compatible one way or another. Can be
>> nvidia,tegra264.h
>> (because -clock is redundant and you do not want to use the actual
>> compatible)
> 
> I get it. You want consistency. But what about consistency with earlier
> chip generations?


I will fix them after finishing my time machine. :)

> Do you want me to go and rename all of these files?


No, I don't want to change them, but I would be fine if someone does the
change (although someone else might claim this is a churn). That ship
has sailed, but at least we can start with new bindings.

Best regards,
Krzysztof

Re: [PATCH 4/8] dt-bindings: Add Tegra264 clock and reset definitions

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3403 bytes --]

On Thu, May 08, 2025 at 10:51:57AM +0200, Krzysztof Kozlowski wrote:
> On 08/05/2025 09:59, Thierry Reding wrote:
> > On Thu, May 08, 2025 at 09:49:12AM +0200, Krzysztof Kozlowski wrote:
> >> On 08/05/2025 09:46, Thierry Reding wrote:
> >>> On Thu, May 08, 2025 at 09:40:38AM +0200, Krzysztof Kozlowski wrote:
> >>>> On 08/05/2025 09:39, Krzysztof Kozlowski wrote:
> >>>>> On 07/05/2025 16:37, Thierry Reding wrote:
> >>>>>> From: Thierry Reding <treding@nvidia.com>
> >>>>>>
> >>>>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
> >>>>>
> >>>>> Missing commit msg
> >>>>>
> >>>>>> ---
> >>>>>>  include/dt-bindings/clock/tegra264-clock.h | 9 +++++++++
> >>>>>>  include/dt-bindings/reset/tegra264-reset.h | 7 +++++++
> >>>>>>  2 files changed, 16 insertions(+)
> >>>>>>  create mode 100644 include/dt-bindings/clock/tegra264-clock.h
> >>>>>>  create mode 100644 include/dt-bindings/reset/tegra264-reset.h
> >>>>>
> >>>>>
> >>>>> Filename equal to the compatible. That's the standard convention for all
> >>>>> the headers since some years.
> >>>>
> >>>> Huh, I cannot find the binding in this patchset. Where is the actual
> >>>> binding added?
> >>>
> >>> The bindings for this are in
> >>>
> >>>   Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
> >>
> >> There is no tegra264 in that binding.
> > 
> > That's part of an earlier series I sent out (and linked to from the
> > cover letter). It's here:
> > 
> > 	https://lore.kernel.org/linux-tegra/20250506133118.1011777-1-thierry.reding@gmail.com/T/#m96bb396b352659581a9e71a4610c51e6ab4d5b6a
> 
> 
> Then this patch belongs there. Standard rules apply: binding headers go
> with the binding itself and the binding itself go with driver patch via
> driver subsystem tree. At least usually. Nothing here is different than
> all other vendors who follow such convention.

This has nothing to do with the bindings. We add clock and reset ID
definitions that are used by the device tree nodes added in this series.
There will be other patches in the future that add ID definitions to
these files when they will be needed by the device tree nodes that will
be added at the time.

> >> The header always goes with the binding and the drivers.
> >>
> >>>
> >>> There's no 1:1 mapping to a compatible for this because BPMP is many
> >>> things. It's a clock provider, a reset provider, a power domain
> >>
> >> Sure, that's fine.
> >>
> >>> provider. These definitions reflect the IDs assigned by the BPMP ABI
> >>> and we've used this structure ever since this was introduced back in
> >>> 2016.
> >>>
> >>> I don't think changing the convention for this is a net advantage.
> >>
> >> Headers still should match the compatible one way or another. Can be
> >> nvidia,tegra264.h
> >> (because -clock is redundant and you do not want to use the actual
> >> compatible)
> > 
> > I get it. You want consistency. But what about consistency with earlier
> > chip generations?
> 
> 
> I will fix them after finishing my time machine. :)
> 
> > Do you want me to go and rename all of these files?
> 
> 
> No, I don't want to change them, but I would be fine if someone does the
> change (although someone else might claim this is a churn). That ship
> has sailed, but at least we can start with new bindings.

Totally pointless, but... whatever.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 4/8] dt-bindings: Add Tegra264 clock and reset definitions

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3034 bytes --]

On Thu, May 08, 2025 at 10:42:33AM +0200, Krzysztof Kozlowski wrote:
> On 08/05/2025 09:53, Thierry Reding wrote:
> > On Thu, May 08, 2025 at 09:40:02AM +0200, Krzysztof Kozlowski wrote:
> >> On 07/05/2025 16:37, Thierry Reding wrote:
> >>> @@ -0,0 +1,9 @@
> >>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> >>> +/* Copyright (c) 2022-2023, NVIDIA CORPORATION. All rights reserved. */
> >>> +
> >>> +#ifndef DT_BINDINGS_CLOCK_TEGRA264_CLOCK_H
> >>> +#define DT_BINDINGS_CLOCK_TEGRA264_CLOCK_H
> >>> +
> >>> +#define TEGRA264_CLK_CLK_S			2U
> >>
> >> Abstract IDs start from 0 or 1, not 2. Also drop "U".
> > 
> > These are not abstract IDs, they are defined by the BPMP ABI. We cannot
> > change them, otherwise it'll completely break.
> 
> 
> You mean from the firmware? Sure. You have entire commit msg to explain
> all unusual things here...

It's not unusual, though. This has been the convention for a number of
years now. But yeah, I guess I can be verbose and repeat all of these
details for each new generation...

> 
> > 
> > For similar reasons I'd like to keep the "U". These definitions are for
> > the most part directly imported from the BPMP ABI headers, though we do
> > try to be selective about what we add, to avoid adding hundreds of new
> > lines in one go, and several safety-checking tools run on these headers
> > that happen to require the "U" suffix to make sure these have a defined
> > type.
> > 
> >>> +
> >>> +#endif /* DT_BINDINGS_CLOCK_TEGRA264_CLOCK_H */
> >>> diff --git a/include/dt-bindings/reset/tegra264-reset.h b/include/dt-bindings/reset/tegra264-reset.h
> >>> new file mode 100644
> >>> index 000000000000..31d89dcf62fa
> >>> --- /dev/null
> >>> +++ b/include/dt-bindings/reset/tegra264-reset.h
> >>> @@ -0,0 +1,7 @@
> >>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> >>> +/* Copyright (c) 2022-2023, NVIDIA CORPORATION. All rights reserved. */
> >>> +
> >>> +#ifndef DT_BINDINGS_RESET_TEGRA264_RESET_H
> >>> +#define DT_BINDINGS_RESET_TEGRA264_RESET_H
> >>> +
> >> This is empty, drop.
> > 
> > We have three people currently working on additional drivers for this
> > SoC and they all need to add to these two files. Adding the empty file
> > here makes it a bit easier to coordinate things, making the resulting
> > conflicts trivial to resolve.
> 
> 
> Bindings are supposed to be complete (see writing bindings doc), this
> means also bindings headers. If the constants come from firmware, they
> are defined so I really do not understands why they cannot be published now.
> 
> Unless you mean that this is a new SoC and the firmware is not yet
> fixed/finished, but all this must be explained in the commit msg.

These are fully defined, but they are also close to 500 IDs, most of
which we won't be using for a long time, so it seems wasteful to dump
them all in here at once.

But I don't care all that much, if you want all of them, then that's
what you'll get.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 5/8] dt-bindings: memory: Add Tegra264 definitions

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]

On Thu, May 08, 2025 at 10:45:29AM +0200, Krzysztof Kozlowski wrote:
> On 08/05/2025 10:02, Thierry Reding wrote:
> >>
> >>
> >>> how much more you'd like me to make it based on that. Do you expect me
> >>> to add the nvidia, prefix? In that case it would be inconsistent with
> >>> all of the 8 other Tegra MC includes that we have in that directory.
> >>
> >>
> >> Same story as for every other case, why this would be different? All of
> >> them - amlogic, mediatek, samsung, qcom, every soc - move to new style
> >> since some years, why this one should be different?
> > 
> > Because we've used exactly this naming convention for more than a
> > decade. I get that it's nice to have consistency, but do you really want
> > me to go and churn all of these files just so we can add a vendor-prefix
> > and drop a redundant suffix?
> No, I want new files. Look:
> 1. Some time ago tegra-1.h was added.
> 2. Someone spotted that there was tegra-1.h, so added now tegra-2.h.
> 3. Now this is a pattern so of course next person, even if asked to use
> vendor prefix, will not, right? Because it would break the pattern. So
> we have tegra-3.h
> 4. tegra.4 - no vendor prefix, because you have already three cases.
> 5. You see where I am going?
> 
> All of above - amlogic, mediatek, samsung, qcom - had decade of such
> convention. I asked to changed, they used the same argument as you
> ("decade") and then changed.
> 
> Why this is different case than decade in amlogic, mediatek, samsung and
> qcom?

It's a matter of principle. One convention is as good as another. There
are no clear advantages of one over another. It's pointless and frankly
there are more important things than changing filenames that everybody
has been okay with for the last 10 years.

But then again, I guess you're the boss, and I'm not going to change
your mind, so renaming these files is what I'll go do.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 5/8] dt-bindings: memory: Add Tegra264 definitions

[Rob Herring]

On Thu, May 08, 2025 at 11:09:12AM +0200, Thierry Reding wrote:
> On Thu, May 08, 2025 at 10:45:29AM +0200, Krzysztof Kozlowski wrote:
> > On 08/05/2025 10:02, Thierry Reding wrote:
> > >>
> > >>
> > >>> how much more you'd like me to make it based on that. Do you expect me
> > >>> to add the nvidia, prefix? In that case it would be inconsistent with
> > >>> all of the 8 other Tegra MC includes that we have in that directory.
> > >>
> > >>
> > >> Same story as for every other case, why this would be different? All of
> > >> them - amlogic, mediatek, samsung, qcom, every soc - move to new style
> > >> since some years, why this one should be different?
> > > 
> > > Because we've used exactly this naming convention for more than a
> > > decade. I get that it's nice to have consistency, but do you really want
> > > me to go and churn all of these files just so we can add a vendor-prefix
> > > and drop a redundant suffix?
> > No, I want new files. Look:
> > 1. Some time ago tegra-1.h was added.
> > 2. Someone spotted that there was tegra-1.h, so added now tegra-2.h.
> > 3. Now this is a pattern so of course next person, even if asked to use
> > vendor prefix, will not, right? Because it would break the pattern. So
> > we have tegra-3.h
> > 4. tegra.4 - no vendor prefix, because you have already three cases.
> > 5. You see where I am going?
> > 
> > All of above - amlogic, mediatek, samsung, qcom - had decade of such
> > convention. I asked to changed, they used the same argument as you
> > ("decade") and then changed.
> > 
> > Why this is different case than decade in amlogic, mediatek, samsung and
> > qcom?
> 
> It's a matter of principle. One convention is as good as another. There
> are no clear advantages of one over another. It's pointless and frankly
> there are more important things than changing filenames that everybody
> has been okay with for the last 10 years.

The issue is one convention is consistent for you and only you, the 
other is consistent for *everyone*. And then we'll have someone argue 
they are just following the same convention as Tegra...

If you had several drivers and add a new one, would you argue that the 
new one should follow the conventions of the old drivers rather than 
current conventions? No, you wouldn't.

Rob

Re: [PATCH 1/8] dt-bindings: dma: Add Tegra264 compatible string

[Rob Herring]

On Wed, May 07, 2025 at 04:37:55PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> Document the compatible string used for the GPCDMA controller on
> Tegra264.
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  .../devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml         | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH 2/8] dt-bindings: rtc: tegra: Document Tegra264 RTC

[Rob Herring (Arm)]

On Wed, 07 May 2025 16:37:56 +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> Add the compatible string for the RTC block found on the Tegra264 SoC.
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH 3/8] dt-bindings: tegra: Document P3971-0089+P3834-0008 Platform

[Rob Herring (Arm)]

On Wed, 07 May 2025 16:37:57 +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> This is an engineering reference platform for the Tegra264 SoC.
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  Documentation/devicetree/bindings/arm/tegra.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>