Re: [PATCH 4/7] dt-bindings: timestamp: Add Tegra234 support

Re: [PATCH 4/7] dt-bindings: timestamp: Add Tegra234 support

[Dipen Patel]

On 11/7/22 12:06 PM, Rob Herring wrote:
> On Thu, Nov 03, 2022 at 10:45:20AM -0700, Dipen Patel wrote:
>> Added timestamp provider support for the Tegra234 in devicetree
>> bindings.
>>
>> Signed-off-by: Dipen Patel <dipenp@nvidia.com>
>> ---
>>  .../timestamp/nvidia,tegra194-hte.yaml        | 44 +++++++++++++++++--
>>  1 file changed, 40 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
>> index c31e207d1652..158dbe58c49f 100644
>> --- a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
>> +++ b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
>> @@ -4,7 +4,7 @@
>>  $id: http://devicetree.org/schemas/timestamp/nvidia,tegra194-hte.yaml#
>>  $schema: http://devicetree.org/meta-schemas/core.yaml#
>>  
>> -title: Tegra194 on chip generic hardware timestamping engine (HTE)
>> +title: Tegra on chip generic hardware timestamping engine (HTE) provider
>>  
>>  maintainers:
>>    - Dipen Patel <dipenp@nvidia.com>
>> @@ -23,6 +23,8 @@ properties:
>>      enum:
>>        - nvidia,tegra194-gte-aon
>>        - nvidia,tegra194-gte-lic
>> +      - nvidia,tegra234-gte-aon
>> +      - nvidia,tegra234-gte-lic
> 
> How is the h/w in this chip different from the existing one? I'm 
> assuming it must be because you don't have a fallback compatible.
t234-gte-lic has different slices and signal lines it can support. t234-gte-aon
has again different slices and more gpio lines it can support and has
different GTE-GPIO mapping than t194-gte-aon.
> 
>>  
>>    reg:
>>      maxItems: 1
>> @@ -43,9 +45,8 @@ properties:
>>      description:
>>        HTE lines are arranged in 32 bit slice where each bit represents different
>>        line/signal that it can enable/configure for the timestamp. It is u32
>> -      property and depends on the HTE instance in the chip. The value 3 is for
>> -      GPIO GTE and 11 for IRQ GTE.
>> -    enum: [3, 11]
>> +      property and the value depends on the HTE instance in the chip.
> 
> If this statement was true, then this property makes sense...
> 
>> +    enum: [3, 11, 17]
>>  
>>    '#timestamp-cells':
>>      description:
>> @@ -55,6 +56,41 @@ properties:
>>        mentioned in the nvidia GPIO device tree binding document.
>>      const: 1
>>  
>> +allOf:
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - nvidia,tegra194-gte-aon
>> +              - nvidia,tegra234-gte-aon
>> +    then:
>> +      properties:
>> +        nvidia,slices:
>> +          const: 3
>> +
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - nvidia,tegra194-gte-lic
>> +    then:
>> +      properties:
>> +        nvidia,slices:
>> +          const: 11
>> +
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - nvidia,tegra234-gte-lic
>> +    then:
>> +      properties:
>> +        nvidia,slices:
>> +          const: 17
> 
> However, if there is only one possible value for each compatible, then 
> being per instance can't really be true. I guess 'aon' or 'lic' define 
> the instance? That's not normal practice. Are there other differences?
aon and lic are gte hardware instances but meant for different signals i.e.
lic is for interrupt lines while aon is for always on domain GPIO lines.
> 
> It seems like 'nvidia,slices' should be implied from the compatible 
> string.
thats true, assuming we have all those specified compatible strings from this patch.
> 
> Rob

Re: [PATCH 2/7] hte: Add Tegra234 provider

[Dipen Patel]

On 11/11/22 8:01 AM, Thierry Reding wrote:
> On Thu, Nov 03, 2022 at 10:45:18AM -0700, Dipen Patel wrote:
>> The Tegra234 AON GPIO instance and LIC IRQ support HTE. For the GPIO
>> HTE support, it requires to add mapping between GPIO and HTE framework.
>>
>> Signed-off-by: Dipen Patel <dipenp@nvidia.com>
>> ---
>>  drivers/hte/hte-tegra194-test.c |   2 +-
>>  drivers/hte/hte-tegra194.c      | 124 ++++++++++++++++++++++++++++++--
>>  2 files changed, 121 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/hte/hte-tegra194-test.c b/drivers/hte/hte-tegra194-test.c
>> index 5d776a185bd6..d79c28a80517 100644
>> --- a/drivers/hte/hte-tegra194-test.c
>> +++ b/drivers/hte/hte-tegra194-test.c
>> @@ -16,7 +16,7 @@
>>  #include <linux/hte.h>
>>  
>>  /*
>> - * This sample HTE GPIO test driver demonstrates HTE API usage by enabling
>> + * This sample HTE test driver demonstrates HTE API usage by enabling
>>   * hardware timestamp on gpio_in and specified LIC IRQ lines.
>>   *
>>   * Note: gpio_out and gpio_in need to be shorted externally in order for this
>> diff --git a/drivers/hte/hte-tegra194.c b/drivers/hte/hte-tegra194.c
>> index 49a27af22742..5d1f947db0f6 100644
>> --- a/drivers/hte/hte-tegra194.c
>> +++ b/drivers/hte/hte-tegra194.c
>> @@ -62,6 +62,10 @@
>>  #define NV_AON_HTE_SLICE2_IRQ_GPIO_25	25
>>  #define NV_AON_HTE_SLICE2_IRQ_GPIO_26	26
>>  #define NV_AON_HTE_SLICE2_IRQ_GPIO_27	27
>> +#define NV_AON_HTE_SLICE2_IRQ_GPIO_28	28
>> +#define NV_AON_HTE_SLICE2_IRQ_GPIO_29	29
>> +#define NV_AON_HTE_SLICE2_IRQ_GPIO_30	30
>> +#define NV_AON_HTE_SLICE2_IRQ_GPIO_31	31
>>  
>>  #define HTE_TECTRL		0x0
>>  #define HTE_TETSCH		0x4
>> @@ -220,7 +224,100 @@ static const struct tegra_hte_line_mapped tegra194_aon_gpio_sec_map[] = {
>>  	[39] = {NV_AON_SLICE_INVALID, 0},
>>  };
>>  
>> -static const struct tegra_hte_data aon_hte = {
>> +static const struct tegra_hte_line_mapped tegra234_aon_gpio_map[] = {
>> +	/* gpio, slice, bit_index */
>> +	/* AA port */
>> +	[0]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
>> +	[1]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
>> +	[2]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
>> +	[3]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
>> +	[4]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
>> +	[5]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
>> +	[6]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
>> +	[7]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
>> +	/* BB port */
>> +	[8]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
>> +	[9]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
>> +	[10] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
>> +	[11] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
>> +	/* CC port */
>> +	[12] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
>> +	[13] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
>> +	[14] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
>> +	[15] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
>> +	[16] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
>> +	[17] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
>> +	[18] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
>> +	[19] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
>> +	/* DD port */
>> +	[20] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
>> +	[21] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
>> +	[22] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
>> +	/* EE port */
>> +	[23] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_31},
>> +	[24] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_30},
>> +	[25] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
>> +	[26] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
>> +	[27] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
>> +	[28] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
>> +	[29] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
>> +	[30] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
>> +	/* GG port */
>> +	[31] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
>> +};
>> +
>> +static const struct tegra_hte_line_mapped tegra234_aon_gpio_sec_map[] = {
>> +	/* gpio, slice, bit_index */
>> +	/* AA port */
>> +	[0]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
>> +	[1]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
>> +	[2]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
>> +	[3]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
>> +	[4]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
>> +	[5]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
>> +	[6]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
>> +	[7]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
>> +	/* BB port */
>> +	[8]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
>> +	[9]  = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
>> +	[10] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
>> +	[11] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_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] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
>> +	[17] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
>> +	[18] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
>> +	[19] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
>> +	[20] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
>> +	[21] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
>> +	[22] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
>> +	[23] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
>> +	/* DD port */
>> +	[24] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
>> +	[25] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
>> +	[26] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
>> +	[27] = {NV_AON_SLICE_INVALID, 0},
>> +	[28] = {NV_AON_SLICE_INVALID, 0},
>> +	[29] = {NV_AON_SLICE_INVALID, 0},
>> +	[30] = {NV_AON_SLICE_INVALID, 0},
>> +	[31] = {NV_AON_SLICE_INVALID, 0},
>> +	/* EE port */
>> +	[32] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_31},
>> +	[33] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_30},
>> +	[34] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
>> +	[35] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
>> +	[36] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
>> +	[37] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
>> +	[38] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
>> +	[39] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
>> +	/* GG port */
>> +	[40] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
>> +};
>> +
>> +static const struct tegra_hte_data t194_aon_hte = {
>>  	.map_sz = ARRAY_SIZE(tegra194_aon_gpio_map),
>>  	.map = tegra194_aon_gpio_map,
>>  	.sec_map_sz = ARRAY_SIZE(tegra194_aon_gpio_sec_map),
>> @@ -228,6 +325,14 @@ static const struct tegra_hte_data aon_hte = {
>>  	.type = HTE_TEGRA_TYPE_GPIO,
>>  };
>>  
>> +static const struct tegra_hte_data t234_aon_hte = {
>> +	.map_sz = ARRAY_SIZE(tegra234_aon_gpio_map),
>> +	.map = tegra234_aon_gpio_map,
>> +	.sec_map_sz = ARRAY_SIZE(tegra234_aon_gpio_sec_map),
>> +	.sec_map = tegra234_aon_gpio_sec_map,
>> +	.type = HTE_TEGRA_TYPE_GPIO,
>> +};
>> +
>>  static const struct tegra_hte_data lic_hte = {
>>  	.map_sz = 0,
>>  	.map = NULL,
>> @@ -535,7 +640,9 @@ static bool tegra_hte_match_from_linedata(const struct hte_chip *chip,
>>  
>>  static const struct of_device_id tegra_hte_of_match[] = {
>>  	{ .compatible = "nvidia,tegra194-gte-lic", .data = &lic_hte},
>> -	{ .compatible = "nvidia,tegra194-gte-aon", .data = &aon_hte},
>> +	{ .compatible = "nvidia,tegra194-gte-aon", .data = &t194_aon_hte},
>> +	{ .compatible = "nvidia,tegra234-gte-lic", .data = &lic_hte},
>> +	{ .compatible = "nvidia,tegra234-gte-aon", .data = &t234_aon_hte},
>>  	{ }
>>  };
>>  MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
>> @@ -635,8 +742,17 @@ static int tegra_hte_probe(struct platform_device *pdev)
>>  
>>  		gc->match_from_linedata = tegra_hte_match_from_linedata;
>>  
>> -		hte_dev->c = gpiochip_find("tegra194-gpio-aon",
>> -					   tegra_get_gpiochip_from_name);
>> +		if (of_device_is_compatible(dev->of_node,
>> +					    "nvidia,tegra194-gte-aon"))
>> +			hte_dev->c = gpiochip_find("tegra194-gpio-aon",
>> +						tegra_get_gpiochip_from_name);
>> +		else if (of_device_is_compatible(dev->of_node,
>> +						 "nvidia,tegra234-gte-aon"))
>> +			hte_dev->c = gpiochip_find("tegra234-gpio-aon",
>> +						tegra_get_gpiochip_from_name);
>> +		else
>> +			return -ENODEV;
> 
> I'm wondering: instead of doing this cumbersome lookup, perhaps it would
> be easier to create a direct link to the right GPIO controller with a
> phandle?
Possible, need to see if gpiod framework has API exposed to get the gpiochip from
the phandle.
> 
> Thierry

Re: [PATCH 5/7] hte: Re-phrase tegra API document

[Dipen Patel]

On 11/4/22 8:33 PM, Bagas Sanjaya wrote:
> On Thu, Nov 03, 2022 at 10:45:21AM -0700, Dipen Patel wrote:
>>  Description
>>  -----------
>> -The Nvidia tegra194 HTE provider driver implements two GTE
>> -(Generic Timestamping Engine) instances: 1) GPIO GTE and 2) LIC
>> -(Legacy Interrupt Controller) IRQ GTE. Both GTE instances get the
>> -timestamp from the system counter TSC which has 31.25MHz clock rate, and the
>> -driver converts clock tick rate to nanoseconds before storing it as timestamp
>> -value.
>> +The Nvidia tegra HTE provider also known as GTE (Generic Timestamping Engine)
>> +driver implements two GTE instances: 1) GPIO GTE and 2) LIC
>> +(Legacy Interrupt Controller) IRQ GTE. Both GTE instances get the timestamp
>> +from the system counter TSC which has 31.25MHz clock rate, and the driver
>> +converts clock tick rate to nanoseconds before storing it as timestamp value.
>>  
>>  GPIO GTE
>>  --------
>>  
>>  This GTE instance timestamps GPIO in real time. For that to happen GPIO
>> -needs to be configured as input. The always on (AON) GPIO controller instance
>> -supports timestamping GPIOs in real time and it has 39 GPIO lines. The GPIO GTE
>> -and AON GPIO controller are tightly coupled as it requires very specific bits
>> -to be set in GPIO config register before GPIO GTE can be used, for that GPIOLIB
>> -adds two optional APIs as below. The GPIO GTE code supports both kernel
>> -and userspace consumers. The kernel space consumers can directly talk to HTE
>> -subsystem while userspace consumers timestamp requests go through GPIOLIB CDEV
>> -framework to HTE subsystem.
>> +needs to be configured as input. Only the always on (AON) GPIO controller
>> +instance supports timestamping GPIOs in real time as it is tightly coupled with
>> +the GPIO GTE. To support this, GPIOLIB adds two optional APIs as mentioned
>> +below. The GPIO GTE code supports both kernel and userspace consumers. The
>> +kernel space consumers can directly talk to HTE subsystem while userspace
>> +consumers timestamp requests go through GPIOLIB CDEV framework to HTE
>> +subsystem. The hte devicetree binding described at
>> +``Documentation/devicetree/bindings/timestamp`` provides an example of how a
>> +consumer can request an GPIO line.
>>  
>>  See gpiod_enable_hw_timestamp_ns() and gpiod_disable_hw_timestamp_ns().
>>  
> 
> I think the wording can be better:
I do  not understand, can you please elaborate?
> 
> ---- >8 ----
> 
> diff --git a/Documentation/driver-api/hte/tegra194-hte.rst b/Documentation/driver-api/hte/tegra194-hte.rst
> index 85e654772782c1..13c45bfc03a75e 100644
> --- a/Documentation/driver-api/hte/tegra194-hte.rst
> +++ b/Documentation/driver-api/hte/tegra194-hte.rst
> @@ -5,11 +5,11 @@ HTE Kernel provider driver
>  
>  Description
>  -----------
> -The Nvidia tegra HTE provider also known as GTE (Generic Timestamping Engine)
> -driver implements two GTE instances: 1) GPIO GTE and 2) LIC
> -(Legacy Interrupt Controller) IRQ GTE. Both GTE instances get the timestamp
> -from the system counter TSC which has 31.25MHz clock rate, and the driver
> -converts clock tick rate to nanoseconds before storing it as timestamp value.
> +The Nvidia tegra HTE provider, also known as GTE (Generic Timestamping Engine)
> +driver implements two GTE instances: GPIO GTE and LIC (Legacy Interrupt
> +Controller) IRQ GTE. Both GTE instances get the timestamp from system counter
> +TSC which has 31.25MHz clock rate, and the driver converts clock tick rate to
> +nanoseconds before storing it as timestamp value.
>  
>  GPIO GTE
>  --------
> @@ -19,17 +19,17 @@ needs to be configured as input. Only the always on (AON) GPIO controller
>  instance supports timestamping GPIOs in real time as it is tightly coupled with
>  the GPIO GTE. To support this, GPIOLIB adds two optional APIs as mentioned
>  below. The GPIO GTE code supports both kernel and userspace consumers. The
> -kernel space consumers can directly talk to HTE subsystem while userspace
> -consumers timestamp requests go through GPIOLIB CDEV framework to HTE
> -subsystem. The hte devicetree binding described at
> -``Documentation/devicetree/bindings/timestamp`` provides an example of how a
> -consumer can request an GPIO line.
> +kernel space consumers can directly talk to HTE subsystem while requests from
> +userspace consumers go through GPIOLIB CDEV framework to HTE subsystem. The hte
> +devicetree binding described at ``Documentation/devicetree/bindings/timestamp``
> +provides an example of how a consumer can request an GPIO line.
>  
> -See gpiod_enable_hw_timestamp_ns() and gpiod_disable_hw_timestamp_ns().
> +To toggle hardware timestamp, use gpiod_enable_hw_timestamp_ns() and
> +gpiod_disable_hw_timestamp_ns().
>  
>  For userspace consumers, GPIO_V2_LINE_FLAG_EVENT_CLOCK_HTE flag must be
> -specified during IOCTL calls. Refer to ``tools/gpio/gpio-event-mon.c``, which
> -returns the timestamp in nanoseconds.
> +specified during IOCTL calls. Refer to ``tools/gpio/gpio-event-mon.c`` for
> +example.
>  
>  LIC (Legacy Interrupt Controller) IRQ GTE
>  -----------------------------------------
> 
> Thanks.
> 

Re: [PATCH 5/7] hte: Re-phrase tegra API document

[Bagas Sanjaya]

On 11/30/22 10:34, Dipen Patel wrote:
>> I think the wording can be better:
> I do  not understand, can you please elaborate?

Exactly where? Please quote appropriate hunks from below where do you not
understand.

>>
>> ---- >8 ----
>>
>> diff --git a/Documentation/driver-api/hte/tegra194-hte.rst b/Documentation/driver-api/hte/tegra194-hte.rst
>> index 85e654772782c1..13c45bfc03a75e 100644
>> --- a/Documentation/driver-api/hte/tegra194-hte.rst
>> +++ b/Documentation/driver-api/hte/tegra194-hte.rst
>> @@ -5,11 +5,11 @@ HTE Kernel provider driver
>>  
>>  Description
>>  -----------
>> -The Nvidia tegra HTE provider also known as GTE (Generic Timestamping Engine)
>> -driver implements two GTE instances: 1) GPIO GTE and 2) LIC
>> -(Legacy Interrupt Controller) IRQ GTE. Both GTE instances get the timestamp
>> -from the system counter TSC which has 31.25MHz clock rate, and the driver
>> -converts clock tick rate to nanoseconds before storing it as timestamp value.
>> +The Nvidia tegra HTE provider, also known as GTE (Generic Timestamping Engine)
>> +driver implements two GTE instances: GPIO GTE and LIC (Legacy Interrupt
>> +Controller) IRQ GTE. Both GTE instances get the timestamp from system counter
>> +TSC which has 31.25MHz clock rate, and the driver converts clock tick rate to
>> +nanoseconds before storing it as timestamp value.
>>  
>>  GPIO GTE
>>  --------
>> @@ -19,17 +19,17 @@ needs to be configured as input. Only the always on (AON) GPIO controller
>>  instance supports timestamping GPIOs in real time as it is tightly coupled with
>>  the GPIO GTE. To support this, GPIOLIB adds two optional APIs as mentioned
>>  below. The GPIO GTE code supports both kernel and userspace consumers. The
>> -kernel space consumers can directly talk to HTE subsystem while userspace
>> -consumers timestamp requests go through GPIOLIB CDEV framework to HTE
>> -subsystem. The hte devicetree binding described at
>> -``Documentation/devicetree/bindings/timestamp`` provides an example of how a
>> -consumer can request an GPIO line.
>> +kernel space consumers can directly talk to HTE subsystem while requests from
>> +userspace consumers go through GPIOLIB CDEV framework to HTE subsystem. The hte
>> +devicetree binding described at ``Documentation/devicetree/bindings/timestamp``
>> +provides an example of how a consumer can request an GPIO line.
>>  
>> -See gpiod_enable_hw_timestamp_ns() and gpiod_disable_hw_timestamp_ns().
>> +To toggle hardware timestamp, use gpiod_enable_hw_timestamp_ns() and
>> +gpiod_disable_hw_timestamp_ns().
>>  
>>  For userspace consumers, GPIO_V2_LINE_FLAG_EVENT_CLOCK_HTE flag must be
>> -specified during IOCTL calls. Refer to ``tools/gpio/gpio-event-mon.c``, which
>> -returns the timestamp in nanoseconds.
>> +specified during IOCTL calls. Refer to ``tools/gpio/gpio-event-mon.c`` for
>> +example.
>>  
>>  LIC (Legacy Interrupt Controller) IRQ GTE
>>  -----------------------------------------
>>

Thanks anyway.

-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH 2/7] hte: Add Tegra234 provider

[Dipen Patel]

On 11/29/22 7:00 PM, Dipen Patel wrote:
> On 11/11/22 8:01 AM, Thierry Reding wrote:
>> On Thu, Nov 03, 2022 at 10:45:18AM -0700, Dipen Patel wrote:
>>> The Tegra234 AON GPIO instance and LIC IRQ support HTE. For the GPIO
>>> HTE support, it requires to add mapping between GPIO and HTE framework.
>>>
>>> Signed-off-by: Dipen Patel <dipenp@nvidia.com>
>>> ---
>>>  drivers/hte/hte-tegra194-test.c |   2 +-
>>>  drivers/hte/hte-tegra194.c      | 124 ++++++++++++++++++++++++++++++--
>>>  2 files changed, 121 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/hte/hte-tegra194-test.c b/drivers/hte/hte-tegra194-test.c
>>> index 5d776a185bd6..d79c28a80517 100644
>>> --- a/drivers/hte/hte-tegra194-test.c
>>> +++ b/drivers/hte/hte-tegra194-test.c
>>> @@ -16,7 +16,7 @@
>>>  #include <linux/hte.h>
>>>  
<snip>
>>>  MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
>>> @@ -635,8 +742,17 @@ static int tegra_hte_probe(struct platform_device *pdev)
>>>  
>>>  		gc->match_from_linedata = tegra_hte_match_from_linedata;
>>>  
>>> -		hte_dev->c = gpiochip_find("tegra194-gpio-aon",
>>> -					   tegra_get_gpiochip_from_name);
>>> +		if (of_device_is_compatible(dev->of_node,
>>> +					    "nvidia,tegra194-gte-aon"))
>>> +			hte_dev->c = gpiochip_find("tegra194-gpio-aon",
>>> +						tegra_get_gpiochip_from_name);
>>> +		else if (of_device_is_compatible(dev->of_node,
>>> +						 "nvidia,tegra234-gte-aon"))
>>> +			hte_dev->c = gpiochip_find("tegra234-gpio-aon",
>>> +						tegra_get_gpiochip_from_name);
>>> +		else
>>> +			return -ENODEV;
>>
>> I'm wondering: instead of doing this cumbersome lookup, perhaps it would
>> be easier to create a direct link to the right GPIO controller with a
>> phandle?
> Possible, need to see if gpiod framework has API exposed to get the gpiochip from
> the phandle.

Thierry, I can not find any API which can help retrieve gpio_chip from the GPIO controller
phandle. I need gpio_chip->base to map GPIO line to GTE mapping.

>>
>> Thierry
> 

Re: [PATCH 2/7] hte: Add Tegra234 provider

[Thierry Reding]

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

On Tue, Dec 27, 2022 at 04:43:48PM -0800, Dipen Patel wrote:
> On 11/29/22 7:00 PM, Dipen Patel wrote:
> > On 11/11/22 8:01 AM, Thierry Reding wrote:
> >> On Thu, Nov 03, 2022 at 10:45:18AM -0700, Dipen Patel wrote:
> >>> The Tegra234 AON GPIO instance and LIC IRQ support HTE. For the GPIO
> >>> HTE support, it requires to add mapping between GPIO and HTE framework.
> >>>
> >>> Signed-off-by: Dipen Patel <dipenp@nvidia.com>
> >>> ---
> >>>  drivers/hte/hte-tegra194-test.c |   2 +-
> >>>  drivers/hte/hte-tegra194.c      | 124 ++++++++++++++++++++++++++++++--
> >>>  2 files changed, 121 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/hte/hte-tegra194-test.c b/drivers/hte/hte-tegra194-test.c
> >>> index 5d776a185bd6..d79c28a80517 100644
> >>> --- a/drivers/hte/hte-tegra194-test.c
> >>> +++ b/drivers/hte/hte-tegra194-test.c
> >>> @@ -16,7 +16,7 @@
> >>>  #include <linux/hte.h>
> >>>  
> <snip>
> >>>  MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
> >>> @@ -635,8 +742,17 @@ static int tegra_hte_probe(struct platform_device *pdev)
> >>>  
> >>>  		gc->match_from_linedata = tegra_hte_match_from_linedata;
> >>>  
> >>> -		hte_dev->c = gpiochip_find("tegra194-gpio-aon",
> >>> -					   tegra_get_gpiochip_from_name);
> >>> +		if (of_device_is_compatible(dev->of_node,
> >>> +					    "nvidia,tegra194-gte-aon"))
> >>> +			hte_dev->c = gpiochip_find("tegra194-gpio-aon",
> >>> +						tegra_get_gpiochip_from_name);
> >>> +		else if (of_device_is_compatible(dev->of_node,
> >>> +						 "nvidia,tegra234-gte-aon"))
> >>> +			hte_dev->c = gpiochip_find("tegra234-gpio-aon",
> >>> +						tegra_get_gpiochip_from_name);
> >>> +		else
> >>> +			return -ENODEV;
> >>
> >> I'm wondering: instead of doing this cumbersome lookup, perhaps it would
> >> be easier to create a direct link to the right GPIO controller with a
> >> phandle?
> > Possible, need to see if gpiod framework has API exposed to get the gpiochip from
> > the phandle.
> 
> Thierry, I can not find any API which can help retrieve gpio_chip from the GPIO controller
> phandle. I need gpio_chip->base to map GPIO line to GTE mapping.

gpiochip_find() should allow you to implement that. So instead of
tegra_get_gpiochip_from_name() you could implement a function that
matches on the phandle that you've read from the HTE node.

You could probably add such a helper to the GPIO core, since it seems to
me like it would be universally helpful.

Actually there's of_find_gpiochip_by_node() in gpiolib-of.c already, so
you could propose to export it for external users.

Thierry

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

[PATCH 4/7] dt-bindings: timestamp: Add Tegra234 support

[Dipen Patel]

Added timestamp provider support for the Tegra234 in devicetree
bindings.

Signed-off-by: Dipen Patel <dipenp@nvidia.com>
---
 .../timestamp/nvidia,tegra194-hte.yaml        | 44 +++++++++++++++++--
 1 file changed, 40 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
index c31e207d1652..158dbe58c49f 100644
--- a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
+++ b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
@@ -4,7 +4,7 @@
 $id: http://devicetree.org/schemas/timestamp/nvidia,tegra194-hte.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 
-title: Tegra194 on chip generic hardware timestamping engine (HTE)
+title: Tegra on chip generic hardware timestamping engine (HTE) provider
 
 maintainers:
   - Dipen Patel <dipenp@nvidia.com>
@@ -23,6 +23,8 @@ properties:
     enum:
       - nvidia,tegra194-gte-aon
       - nvidia,tegra194-gte-lic
+      - nvidia,tegra234-gte-aon
+      - nvidia,tegra234-gte-lic
 
   reg:
     maxItems: 1
@@ -43,9 +45,8 @@ properties:
     description:
       HTE lines are arranged in 32 bit slice where each bit represents different
       line/signal that it can enable/configure for the timestamp. It is u32
-      property and depends on the HTE instance in the chip. The value 3 is for
-      GPIO GTE and 11 for IRQ GTE.
-    enum: [3, 11]
+      property and the value depends on the HTE instance in the chip.
+    enum: [3, 11, 17]
 
   '#timestamp-cells':
     description:
@@ -55,6 +56,41 @@ properties:
       mentioned in the nvidia GPIO device tree binding document.
     const: 1
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - nvidia,tegra194-gte-aon
+              - nvidia,tegra234-gte-aon
+    then:
+      properties:
+        nvidia,slices:
+          const: 3
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - nvidia,tegra194-gte-lic
+    then:
+      properties:
+        nvidia,slices:
+          const: 11
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - nvidia,tegra234-gte-lic
+    then:
+      properties:
+        nvidia,slices:
+          const: 17
+
 required:
   - compatible
   - reg
-- 
2.17.1