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