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

[Dipen Patel <dipenp@xxxxxxxxxx>]

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.
>