On 4/4/23 7:24 PM, Bagas Sanjaya wrote: > On 3/23/23 08:29, Dipen Patel wrote: >> Make Tegra194 API document generic to make it applicable for >> current and future tegra hte providers. >> >> Signed-off-by: Dipen Patel <dipenp@xxxxxxxxxx> >> --- >> Documentation/driver-api/hte/tegra194-hte.rst | 33 +++++++++---------- >> 1 file changed, 16 insertions(+), 17 deletions(-) >> > > While generalizing the doc, the doc file name should also be renamed > (i.e. to tegra-hte.rst). make sense, I will do rename it in the next patch series. > >> 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 > > The wording LGTM, thanks! > > Reviewed-by: Bagas Sanjaya <bagasdotme@xxxxxxxxx> >
