[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d6f53bbc-34b9-dcef-b37f-d4babb8b7a4d@gmail.com>
Date: Wed, 30 Nov 2022 10:43:47 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Dipen Patel <dipenp@...dia.com>
Cc: thierry.reding@...il.com, jonathanh@...dia.com,
linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org,
linux-gpio@...r.kernel.org, linus.walleij@...aro.org,
devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
robh+dt@...nel.org, timestamp@...ts.linux.dev
Subject: Re: [PATCH 5/7] hte: Re-phrase tegra API document
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
Powered by blists - more mailing lists