[PATCH 0/3] Add Tegra264 HTE provider

[PATCH 0/3] Add Tegra264 HTE provider

[Suneel Garapati]

This patch series mainly adds support for the Tegra264 HTE provider.
  - Update devicetree bindings to add Tegra264 support
  - Add support in driver for Tegra264 chip including new tsc clock
    parameters setup per SoC as values differ for Tegra264
  - Populate device-tree nodes for Tegra264 GTE instances
  - One of devicetree nodes has reference to gpio_aon node that is
    dependent on this series [1]

1 - https://patchwork.ozlabs.org/project/linux-gpio/patch/20260128085114.1137725-3-pshete@nvidia.com/

Suneel Garapati (3):
  dt-bindings: timestamp: Add Tegra264 support
  hte: tegra194: Add Tegra264 GTE support
  arm64: tegra: Add GTE nodes for Tegra264

 .../timestamp/nvidia,tegra194-hte.yaml        |   3 +
 arch/arm64/boot/dts/nvidia/tegra264.dtsi      |  19 +++
 drivers/hte/hte-tegra194.c                    | 133 +++++++++++++++++-
 3 files changed, 150 insertions(+), 5 deletions(-)

-- 
2.34.1

[PATCH 1/3] dt-bindings: timestamp: Add Tegra264 support

[Suneel Garapati]

Add timestamp provider support for the Tegra264 in devicetree
bindings. Tegra264 has two generic timestamping engines (GTE)
which are the always-on GTE (AON) and legacy interrupt
controller (LIC) GTE.

Signed-off-by: Suneel Garapati <suneelg@nvidia.com>
---
 .../devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml     | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
index 456797967adc..210200421a38 100644
--- a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
+++ b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
@@ -25,6 +25,8 @@ properties:
       - nvidia,tegra194-gte-lic
       - nvidia,tegra234-gte-aon
       - nvidia,tegra234-gte-lic
+      - nvidia,tegra264-gte-aon
+      - nvidia,tegra264-gte-lic
 
   reg:
     maxItems: 1
@@ -112,6 +114,7 @@ allOf:
           contains:
             enum:
               - nvidia,tegra234-gte-aon
+              - nvidia,tegra264-gte-aon
     then:
       required:
         - nvidia,gpio-controller
-- 
2.34.1

Re: [PATCH 1/3] dt-bindings: timestamp: Add Tegra264 support

[Krzysztof Kozlowski]

On Wed, Apr 01, 2026 at 09:38:29PM +0000, Suneel Garapati wrote:
>    reg:
>      maxItems: 1
> @@ -112,6 +114,7 @@ allOf:
>            contains:
>              enum:
>                - nvidia,tegra234-gte-aon
> +              - nvidia,tegra264-gte-aon

And why exactly the slices are variable here? Explain that in commit
msg.

Best regards,
Krzysztof

Re: [PATCH 1/3] dt-bindings: timestamp: Add Tegra264 support

[Krzysztof Kozlowski]

On 02/04/2026 10:47, Krzysztof Kozlowski wrote:
> On Wed, Apr 01, 2026 at 09:38:29PM +0000, Suneel Garapati wrote:
>>    reg:
>>      maxItems: 1
>> @@ -112,6 +114,7 @@ allOf:
>>            contains:
>>              enum:
>>                - nvidia,tegra234-gte-aon
>> +              - nvidia,tegra264-gte-aon
> 
> And why exactly the slices are variable here? Explain that in commit
> msg.

s/Explain/Shortly describe/

Best regards,
Krzysztof

Re: [PATCH 1/3] dt-bindings: timestamp: Add Tegra264 support

[Jon Hunter]

On 02/04/2026 09:47, Krzysztof Kozlowski wrote:
> On 02/04/2026 10:47, Krzysztof Kozlowski wrote:
>> On Wed, Apr 01, 2026 at 09:38:29PM +0000, Suneel Garapati wrote:
>>>     reg:
>>>       maxItems: 1
>>> @@ -112,6 +114,7 @@ allOf:
>>>             contains:
>>>               enum:
>>>                 - nvidia,tegra234-gte-aon
>>> +              - nvidia,tegra264-gte-aon
>>
>> And why exactly the slices are variable here? Explain that in commit
>> msg.
> 
> s/Explain/Shortly describe/

So this is not related to slices, but indicating the 
'nvidia,gpio-controller' property is required for the AON controller. 
However, maybe your comment still applies and you want the commit 
message to be explicit that for the AON instance the 
'nvidia,gpio-controller' is needed?

Jon

-- 
nvpublic

Re: [PATCH 1/3] dt-bindings: timestamp: Add Tegra264 support

[Krzysztof Kozlowski]

On 02/04/2026 11:49, Jon Hunter wrote:
> 
> On 02/04/2026 09:47, Krzysztof Kozlowski wrote:
>> On 02/04/2026 10:47, Krzysztof Kozlowski wrote:
>>> On Wed, Apr 01, 2026 at 09:38:29PM +0000, Suneel Garapati wrote:
>>>>     reg:
>>>>       maxItems: 1
>>>> @@ -112,6 +114,7 @@ allOf:
>>>>             contains:
>>>>               enum:
>>>>                 - nvidia,tegra234-gte-aon
>>>> +              - nvidia,tegra264-gte-aon
>>>
>>> And why exactly the slices are variable here? Explain that in commit
>>> msg.
>>
>> s/Explain/Shortly describe/
> 
> So this is not related to slices, but indicating the 
> 'nvidia,gpio-controller' property is required for the AON controller. 
> However, maybe your comment still applies and you want the commit 
> message to be explicit that for the AON instance the 
> 'nvidia,gpio-controller' is needed?

You have two devices there - AON and LIC - and variable properties. I
want answer why things are variable. HW is rarely variable. It is
opposite of variable - afixed.

Best regards,
Krzysztof

Re: [PATCH 1/3] dt-bindings: timestamp: Add Tegra264 support

[Jon Hunter]

On 02/04/2026 10:53, Krzysztof Kozlowski wrote:
> On 02/04/2026 11:49, Jon Hunter wrote:
>>
>> On 02/04/2026 09:47, Krzysztof Kozlowski wrote:
>>> On 02/04/2026 10:47, Krzysztof Kozlowski wrote:
>>>> On Wed, Apr 01, 2026 at 09:38:29PM +0000, Suneel Garapati wrote:
>>>>>      reg:
>>>>>        maxItems: 1
>>>>> @@ -112,6 +114,7 @@ allOf:
>>>>>              contains:
>>>>>                enum:
>>>>>                  - nvidia,tegra234-gte-aon
>>>>> +              - nvidia,tegra264-gte-aon
>>>>
>>>> And why exactly the slices are variable here? Explain that in commit
>>>> msg.
>>>
>>> s/Explain/Shortly describe/
>>
>> So this is not related to slices, but indicating the
>> 'nvidia,gpio-controller' property is required for the AON controller.
>> However, maybe your comment still applies and you want the commit
>> message to be explicit that for the AON instance the
>> 'nvidia,gpio-controller' is needed?
> 
> You have two devices there - AON and LIC - and variable properties. I
> want answer why things are variable. HW is rarely variable. It is
> opposite of variable - afixed.

So note that 'nvidia,slices' is a deprecated property ...

1815e37b6e67 ("dt-bindings: timestamp: Deprecate nvidia,slices property")

I am guessing we did not bother to specify the slices for Tegra264 
because this is no longer being used/supported. And yes, we should have 
made this clear in the commit message :-)

Do you want the commit message updated?

Jon

-- 
nvpublic

Re: [PATCH 1/3] dt-bindings: timestamp: Add Tegra264 support

[Krzysztof Kozlowski]

On 02/04/2026 12:21, Jon Hunter wrote:
> 
> On 02/04/2026 10:53, Krzysztof Kozlowski wrote:
>> On 02/04/2026 11:49, Jon Hunter wrote:
>>>
>>> On 02/04/2026 09:47, Krzysztof Kozlowski wrote:
>>>> On 02/04/2026 10:47, Krzysztof Kozlowski wrote:
>>>>> On Wed, Apr 01, 2026 at 09:38:29PM +0000, Suneel Garapati wrote:
>>>>>>      reg:
>>>>>>        maxItems: 1
>>>>>> @@ -112,6 +114,7 @@ allOf:
>>>>>>              contains:
>>>>>>                enum:
>>>>>>                  - nvidia,tegra234-gte-aon
>>>>>> +              - nvidia,tegra264-gte-aon
>>>>>
>>>>> And why exactly the slices are variable here? Explain that in commit
>>>>> msg.
>>>>
>>>> s/Explain/Shortly describe/
>>>
>>> So this is not related to slices, but indicating the
>>> 'nvidia,gpio-controller' property is required for the AON controller.
>>> However, maybe your comment still applies and you want the commit
>>> message to be explicit that for the AON instance the
>>> 'nvidia,gpio-controller' is needed?
>>
>> You have two devices there - AON and LIC - and variable properties. I
>> want answer why things are variable. HW is rarely variable. It is
>> opposite of variable - afixed.
> 
> So note that 'nvidia,slices' is a deprecated property ...
> 
> 1815e37b6e67 ("dt-bindings: timestamp: Deprecate nvidia,slices property")
> 
> I am guessing we did not bother to specify the slices for Tegra264 
> because this is no longer being used/supported. And yes, we should have 
> made this clear in the commit message :-)
> 

Deprecated properties should not be allowed by the schema for new devices.

> Do you want the commit message updated?

It's enough to disallow the property.


Best regards,
Krzysztof

[PATCH 2/3] hte: tegra194: Add Tegra264 GTE support

[Suneel Garapati]

Add AON-GTE mapping and LIC GTE instance support for the Tegra264.
Move TSC clock parameters from macros to members of SoC data
as values differ for Tegra264 chip.

Signed-off-by: Suneel Garapati <suneelg@nvidia.com>
---
 drivers/hte/hte-tegra194.c | 133 +++++++++++++++++++++++++++++++++++--
 1 file changed, 128 insertions(+), 5 deletions(-)

diff --git a/drivers/hte/hte-tegra194.c b/drivers/hte/hte-tegra194.c
index 690eb9be30fb..4a7702b32b24 100644
--- a/drivers/hte/hte-tegra194.c
+++ b/drivers/hte/hte-tegra194.c
@@ -20,10 +20,11 @@
 
 #define HTE_SUSPEND	0
 
-/* HTE source clock TSC is 31.25MHz */
+/* HTE source clock TSC is 1GHz for T264 and 31.25MHz for others */
 #define HTE_TS_CLK_RATE_HZ	31250000ULL
+#define HTE_TS_CLK_RATE_1G	1000000000ULL
 #define HTE_CLK_RATE_NS		32
-#define HTE_TS_NS_SHIFT	__builtin_ctz(HTE_CLK_RATE_NS)
+#define HTE_CLK_RATE_NS_1G	1
 
 #define NV_AON_SLICE_INVALID	-1
 #define NV_LINES_IN_SLICE	32
@@ -120,6 +121,8 @@ struct tegra_hte_data {
 	u32 slices;
 	u32 map_sz;
 	u32 sec_map_sz;
+	u64 tsc_clkrate_hz;
+	u32 tsc_clkrate_ns;
 	const struct tegra_hte_line_mapped *map;
 	const struct tegra_hte_line_mapped *sec_map;
 };
@@ -317,6 +320,94 @@ static const struct tegra_hte_line_mapped tegra234_aon_gpio_sec_map[] = {
 	[40] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
 };
 
+static const struct tegra_hte_line_mapped tegra264_aon_gpio_map[] = {
+	/* gpio, slice, bit_index */
+	/* AA port */
+	[0]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
+	[1]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
+	[2]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
+	[3]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
+	[4]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
+	[5]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
+	[6]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
+	[7]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
+	/* BB port */
+	[8]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
+	[9]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
+	/* CC port */
+	[10] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
+	[11] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
+	[12] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
+	[13] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
+	[14] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
+	[15] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
+	[16] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
+	[17] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
+	/* DD port */
+	[18] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
+	[19] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
+	[20] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
+	[21] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
+	[22] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
+	[23] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
+	[24] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
+	[25] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
+	/* EE port */
+	[26] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
+	[27] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
+	[28] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
+	[29] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
+};
+
+static const struct tegra_hte_line_mapped tegra264_aon_gpio_sec_map[] = {
+	/* gpio, slice, bit_index */
+	/* AA port */
+	[0]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
+	[1]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
+	[2]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
+	[3]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
+	[4]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
+	[5]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
+	[6]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
+	[7]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
+	/* BB port */
+	[8]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
+	[9]  = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
+	[10] = {NV_AON_SLICE_INVALID, 0},
+	[11] = {NV_AON_SLICE_INVALID, 0},
+	[12] = {NV_AON_SLICE_INVALID, 0},
+	[13] = {NV_AON_SLICE_INVALID, 0},
+	[14] = {NV_AON_SLICE_INVALID, 0},
+	[15] = {NV_AON_SLICE_INVALID, 0},
+	/* CC port */
+	[16] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
+	[17] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
+	[18] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
+	[19] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
+	[20] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
+	[21] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
+	[22] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
+	[23] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
+	/* DD port */
+	[24] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
+	[25] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
+	[26] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
+	[27] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
+	[28] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
+	[29] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
+	[30] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
+	[31] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
+	/* EE port */
+	[32] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
+	[33] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
+	[34] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
+	[35] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
+	[36] = {NV_AON_SLICE_INVALID, 0},
+	[37] = {NV_AON_SLICE_INVALID, 0},
+	[38] = {NV_AON_SLICE_INVALID, 0},
+	[39] = {NV_AON_SLICE_INVALID, 0},
+};
+
 static const struct tegra_hte_data t194_aon_hte = {
 	.map_sz = ARRAY_SIZE(tegra194_aon_gpio_map),
 	.map = tegra194_aon_gpio_map,
@@ -324,6 +415,8 @@ static const struct tegra_hte_data t194_aon_hte = {
 	.sec_map = tegra194_aon_gpio_sec_map,
 	.type = HTE_TEGRA_TYPE_GPIO,
 	.slices = 3,
+	.tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
+	.tsc_clkrate_ns = HTE_CLK_RATE_NS,
 };
 
 static const struct tegra_hte_data t234_aon_hte = {
@@ -333,6 +426,19 @@ static const struct tegra_hte_data t234_aon_hte = {
 	.sec_map = tegra234_aon_gpio_sec_map,
 	.type = HTE_TEGRA_TYPE_GPIO,
 	.slices = 3,
+	.tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
+	.tsc_clkrate_ns = HTE_CLK_RATE_NS,
+};
+
+static const struct tegra_hte_data t264_aon_hte = {
+	.map_sz = ARRAY_SIZE(tegra264_aon_gpio_map),
+	.map = tegra264_aon_gpio_map,
+	.sec_map_sz = ARRAY_SIZE(tegra264_aon_gpio_sec_map),
+	.sec_map = tegra264_aon_gpio_sec_map,
+	.type = HTE_TEGRA_TYPE_GPIO,
+	.slices = 4,
+	.tsc_clkrate_hz = HTE_TS_CLK_RATE_1G,
+	.tsc_clkrate_ns = HTE_CLK_RATE_NS_1G,
 };
 
 static const struct tegra_hte_data t194_lic_hte = {
@@ -340,6 +446,8 @@ static const struct tegra_hte_data t194_lic_hte = {
 	.map = NULL,
 	.type = HTE_TEGRA_TYPE_LIC,
 	.slices = 11,
+	.tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
+	.tsc_clkrate_ns = HTE_CLK_RATE_NS,
 };
 
 static const struct tegra_hte_data t234_lic_hte = {
@@ -347,6 +455,17 @@ static const struct tegra_hte_data t234_lic_hte = {
 	.map = NULL,
 	.type = HTE_TEGRA_TYPE_LIC,
 	.slices = 17,
+	.tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
+	.tsc_clkrate_ns = HTE_CLK_RATE_NS,
+};
+
+static const struct tegra_hte_data t264_lic_hte = {
+	.map_sz = 0,
+	.map = NULL,
+	.type = HTE_TEGRA_TYPE_LIC,
+	.slices = 10,
+	.tsc_clkrate_hz = HTE_TS_CLK_RATE_1G,
+	.tsc_clkrate_ns = HTE_CLK_RATE_NS_1G,
 };
 
 static inline u32 tegra_hte_readl(struct tegra_hte_soc *hte, u32 reg)
@@ -574,12 +693,12 @@ static int tegra_hte_release(struct hte_chip *chip, struct hte_ts_desc *desc,
 static int tegra_hte_clk_src_info(struct hte_chip *chip,
 				  struct hte_clk_info *ci)
 {
-	(void)chip;
+	struct tegra_hte_soc *hte_dev = chip->data;
 
 	if (!ci)
 		return -EINVAL;
 
-	ci->hz = HTE_TS_CLK_RATE_HZ;
+	ci->hz = hte_dev->prov_data->tsc_clkrate_hz;
 	ci->type = CLOCK_MONOTONIC;
 
 	return 0;
@@ -602,8 +721,10 @@ static void tegra_hte_read_fifo(struct tegra_hte_soc *gs)
 {
 	u32 tsh, tsl, src, pv, cv, acv, slice, bit_index, line_id;
 	u64 tsc;
+	u8 tsc_ns_shift;
 	struct hte_ts_data el;
 
+	tsc_ns_shift = __builtin_ctz(gs->prov_data->tsc_clkrate_ns);
 	while ((tegra_hte_readl(gs, HTE_TESTATUS) >>
 		HTE_TESTATUS_OCCUPANCY_SHIFT) &
 		HTE_TESTATUS_OCCUPANCY_MASK) {
@@ -621,7 +742,7 @@ static void tegra_hte_read_fifo(struct tegra_hte_soc *gs)
 		while (acv) {
 			bit_index = __builtin_ctz(acv);
 			line_id = bit_index + (slice << 5);
-			el.tsc = tsc << HTE_TS_NS_SHIFT;
+			el.tsc = tsc << tsc_ns_shift;
 			el.raw_level = tegra_hte_get_level(gs, line_id);
 			hte_push_ts_ns(gs->chip, line_id, &el);
 			acv &= ~BIT(bit_index);
@@ -656,6 +777,8 @@ static const struct of_device_id tegra_hte_of_match[] = {
 	{ .compatible = "nvidia,tegra194-gte-aon", .data = &t194_aon_hte},
 	{ .compatible = "nvidia,tegra234-gte-lic", .data = &t234_lic_hte},
 	{ .compatible = "nvidia,tegra234-gte-aon", .data = &t234_aon_hte},
+	{ .compatible = "nvidia,tegra264-gte-lic", .data = &t264_lic_hte},
+	{ .compatible = "nvidia,tegra264-gte-aon", .data = &t264_aon_hte},
 	{ }
 };
 MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
-- 
2.34.1

[PATCH 3/3] arm64: tegra: Add GTE nodes for Tegra264

[Suneel Garapati]

Add AON GPIO and system LIC GTE instances for Tegra264.

Signed-off-by: Suneel Garapati <suneelg@nvidia.com>
---
 arch/arm64/boot/dts/nvidia/tegra264.dtsi | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
index 06d8357bdf52..c6630733d5e3 100644
--- a/arch/arm64/boot/dts/nvidia/tegra264.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
@@ -3207,6 +3207,15 @@ agic_page5: interrupt-controller@99b0000 {
 			};
 		};
 
+		hte_lic: hardware-timestamp@8380000 {
+			compatible = "nvidia,tegra264-gte-lic";
+			reg = <0x0 0x08380000 0x0 0x10000>;
+			interrupts = <GIC_SPI 0x00000268 IRQ_TYPE_LEVEL_HIGH>;
+			nvidia,int-threshold = <1>;
+			#timestamp-cells = <1>;
+			status = "disabled";
+		};
+
 		gpcdma: dma-controller@8400000 {
 			compatible = "nvidia,tegra264-gpcdma", "nvidia,tegra186-gpcdma";
 			reg = <0x0 0x08400000 0x0 0x210000>;
@@ -3267,6 +3276,16 @@ hsp_top: hsp@8800000 {
 			#mbox-cells = <2>;
 		};
 
+		hte_aon: hardware-timestamp@c2b0000 {
+			compatible = "nvidia,tegra264-gte-aon";
+			reg = <0x0 0x0c2b0000 0x0 0x10000>;
+			interrupts = <GIC_SPI 0x00000226 IRQ_TYPE_LEVEL_HIGH>;
+			nvidia,int-threshold = <1>;
+			#timestamp-cells = <1>;
+			nvidia,gpio-controller = <&gpio_aon>;
+			status = "disabled";
+		};
+
 		rtc: rtc@c2c0000 {
 			compatible = "nvidia,tegra264-rtc", "nvidia,tegra20-rtc";
 			reg = <0x0 0x0c2c0000 0x0 0x10000>;
-- 
2.34.1

[PATCH 1/3] dt-bindings: timestamp: Add Tegra264 support

[Suneel Garapati]

Add timestamp provider support for the Tegra264 in devicetree
bindings. Tegra264 has two generic timestamping engines (GTE)
which are the always-on GTE (AON) and legacy interrupt
controller (LIC) GTE.

Signed-off-by: Suneel Garapati <suneelg@nvidia.com>
---
 .../devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml     | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
index 456797967adc..210200421a38 100644
--- a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
+++ b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
@@ -25,6 +25,8 @@ properties:
       - nvidia,tegra194-gte-lic
       - nvidia,tegra234-gte-aon
       - nvidia,tegra234-gte-lic
+      - nvidia,tegra264-gte-aon
+      - nvidia,tegra264-gte-lic
 
   reg:
     maxItems: 1
@@ -112,6 +114,7 @@ allOf:
           contains:
             enum:
               - nvidia,tegra234-gte-aon
+              - nvidia,tegra264-gte-aon
     then:
       required:
         - nvidia,gpio-controller
-- 
2.34.1

Re: [PATCH 1/3] dt-bindings: timestamp: Add Tegra264 support

[Krzysztof Kozlowski]

On 31/03/2026 22:04, Suneel Garapati wrote:
> Add timestamp provider support for the Tegra264 in devicetree
> bindings. Tegra264 has two generic timestamping engines (GTE)
> which are the always-on GTE (AON) and legacy interrupt
> controller (LIC) GTE.


Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. 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.

You missed at least devicetree list (maybe more), so this won't be
tested by automated tooling. Performing review on untested code might be
a waste of time.

Please kindly resend and include all necessary To/Cc entries.

Best regards,
Krzysztof