| Message ID | 20221103174523.29592-6-dipenp@nvidia.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add Tegra234 HTE support | expand |
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: ---- >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.
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. >
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.
diff --git a/Documentation/driver-api/hte/tegra194-hte.rst b/Documentation/driver-api/hte/tegra194-hte.rst index f2d617265546..85e654772782 100644 --- a/Documentation/driver-api/hte/tegra194-hte.rst +++ b/Documentation/driver-api/hte/tegra194-hte.rst @@ -5,25 +5,25 @@ HTE Kernel provider driver 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(). @@ -34,9 +34,8 @@ returns the timestamp in nanoseconds. LIC (Legacy Interrupt Controller) IRQ GTE ----------------------------------------- -This GTE instance timestamps LIC IRQ lines in real time. There are 352 IRQ -lines which this instance can add timestamps to in real time. The hte -devicetree binding described at ``Documentation/devicetree/bindings/timestamp`` +This GTE instance timestamps LIC IRQ lines in real time. The hte devicetree +binding described at ``Documentation/devicetree/bindings/timestamp`` provides an example of how a consumer can request an IRQ line. Since it is a one-to-one mapping with IRQ GTE provider, consumers can simply specify the IRQ number that they are interested in. There is no userspace consumer support for
Make Tegra194 API document generic to make it applicable for current and future tegra hte providers. Signed-off-by: Dipen Patel <dipenp@nvidia.com> --- Documentation/driver-api/hte/tegra194-hte.rst | 33 +++++++++---------- 1 file changed, 16 insertions(+), 17 deletions(-)