| Message ID | 20210625235532.19575-1-dipenp@nvidia.com |
|---|---|
| Headers | show |
| Series | Intro to Hardware timestamping engine | expand |
On Sat, Jun 26, 2021 at 2:48 AM Dipen Patel <dipenp@nvidia.com> wrote: > > This patch series introduces new subsystem called hardware timestamping > engine (HTE). It offers functionality such as timestamping through hardware > means in realtime. The HTE subsystem centralizes HTE provider and consumers > where providers can register themselves with subsystem and the consumers can > request interested entity which could be lines, GPIO, signals or buses. The > HTE subsystem provides timestamp in nano seconds, having said that the provider > need to convert the timestamp if its not in that unit. There was upstream > discussion about the same at > https://lore.kernel.org/lkml/4c46726d-fa35-1a95-4295-bca37c8b6fe3@nvidia.com/ > > To summarize upstream discussion: > - It was heavily favoured by Linus and Kent to extend GPIOLIB and supporting > GPIO drivers to add HTE functionality and I agreed to experiment with it. I guess this series should include more people from different companies, especially documentation parts. This may be used by different hardware and quite different vendors. Developing a framework like this for only one vendor is no go in general. > This patch series implements and extends GPIOLIB and GPIO tegra driver. > - Discussed possibility to add HTE provider as irqchip instead which > was argued against as HTE devices are not necessarily event emitting > devices. > - Discussed other possibility if HTE device can be added as posix clock > type like PTP clocks. That was also argues against since HTE devices > are not necessarily tightly coupled with hardware clock. > > Typical HTE provider does following: > - Register itself with HTE subsystem > - Provide *request, *release, *enable, *disable timestamp callbacks and > optional get_clk_src_info callback to HTE subsystem. > - Provide optional xlate callback to the subsystem which can translate > consumer provided logical ids into actual ids of the entity, where entity here > is the provider dependent and could be GPIO, in chip lines or signals, buses > etc...This converted id will be used between HTE subsystem and the provider for > below bullet point. > - Push timestamps to the subsystem. This happens when HTE provider has > timestamp data available and willing to push it to HTE subsystem. The HTE > subsystem stores it into software buffer for the consumers. > - Unregister itself > > Typical HTE consumer does following: > - Request interested entity it wishes to timestamp in realtime to the > subsystem. During this call HTE subsystem allocates software buffer to > store timestamps data. > - The subsystem does necessary communications with the provider to > complete the request, which includes translating logical id of the entity to > provider dependent physical/actual id and enabling hardware timestamping on > requested id. > - It can optionally specify callback during registration, this cb will > be called when provider pushes timestamps. Once notified through cb, the > consumer can call retrieve API to read the data from the software buffer. > If cb is not provided, the consumers can elect to call blocking version of > retrieve API. > - Manage pre allocated software buffer if needed. It includes changing buffer > length and watermark/threshold. The subsystem automatically sets watermark or > threshold at 1, consumers can later change it to any other value it wishes. The > main purpose for having threshold functionality is to notify consumer either > through callback if provided or unblock waiting consumer when threshold is > reached. > - Retrieve timestamp using various means provided by subsystem. > - Release entity and its resources. > > HTE and GPIOLIB: > - For the HTE provider which can timestamp GPIO lines. > - For the GPIO consumers, either in kernel or userspace, The GPIOLIB and its > CDEV framework are extended as frontend to the HTE by introducing new APIs. > - Tegra194 AON GPIO controller has HTE support also known as GTE > (Generic Timestamping Engine). The tegra gpio driver is modified to accommodate > HTE functionality. > > Dipen Patel (11): > Documentation: Add HTE subsystem guide > drivers: Add HTE subsystem > hte: Add tegra194 HTE kernel provider > dt-bindings: Add HTE bindings > hte: Add Tegra194 IRQ HTE test driver > gpiolib: Add HTE support > gpio: tegra186: Add HTE in gpio-tegra186 driver > gpiolib: cdev: Add hardware timestamp clock type > tools: gpio: Add new hardware clock type > hte: Add tegra GPIO HTE test driver > MAINTAINERS: Added HTE Subsystem > > .../bindings/gpio/nvidia,tegra186-gpio.txt | 7 + > .../devicetree/bindings/hte/hte-consumer.yaml | 47 + > .../devicetree/bindings/hte/hte.yaml | 34 + > .../bindings/hte/nvidia,tegra194-hte.yaml | 83 + > Documentation/hte/hte.rst | 198 +++ > Documentation/hte/index.rst | 21 + > Documentation/hte/tegra194-hte.rst | 65 + > Documentation/index.rst | 1 + > MAINTAINERS | 8 + > drivers/Kconfig | 2 + > drivers/Makefile | 1 + > drivers/gpio/gpio-tegra186.c | 78 + > drivers/gpio/gpiolib-cdev.c | 65 +- > drivers/gpio/gpiolib.c | 92 ++ > drivers/gpio/gpiolib.h | 11 + > drivers/hte/Kconfig | 49 + > drivers/hte/Makefile | 4 + > drivers/hte/hte-tegra194-gpio-test.c | 255 +++ > drivers/hte/hte-tegra194-irq-test.c | 400 +++++ > drivers/hte/hte-tegra194.c | 554 +++++++ > drivers/hte/hte.c | 1368 +++++++++++++++++ > include/linux/gpio/consumer.h | 21 +- > include/linux/gpio/driver.h | 13 + > include/linux/hte.h | 278 ++++ > include/uapi/linux/gpio.h | 1 + > tools/gpio/gpio-event-mon.c | 6 +- > 26 files changed, 3657 insertions(+), 5 deletions(-) > create mode 100644 Documentation/devicetree/bindings/hte/hte-consumer.yaml > create mode 100644 Documentation/devicetree/bindings/hte/hte.yaml > create mode 100644 Documentation/devicetree/bindings/hte/nvidia,tegra194-hte.yaml > create mode 100644 Documentation/hte/hte.rst > create mode 100644 Documentation/hte/index.rst > create mode 100644 Documentation/hte/tegra194-hte.rst > create mode 100644 drivers/hte/Kconfig > create mode 100644 drivers/hte/Makefile > create mode 100644 drivers/hte/hte-tegra194-gpio-test.c > create mode 100644 drivers/hte/hte-tegra194-irq-test.c > create mode 100644 drivers/hte/hte-tegra194.c > create mode 100644 drivers/hte/hte.c > create mode 100644 include/linux/hte.h > > -- > 2.17.1 >
On Sun, Jun 27, 2021 at 3:08 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > To summarize upstream discussion: > > - It was heavily favoured by Linus and Kent to extend GPIOLIB and supporting > > GPIO drivers to add HTE functionality and I agreed to experiment with it. > > I guess this series should include more people from different > companies, especially documentation parts. This may be used by > different hardware and quite different vendors. Developing a framework > like this for only one vendor is no go in general. I forwarded patch 00 to the IIO list and Jonathan Cameron, and let's page Ye Xiang who made a bunch of contributions from Intel's side to IIO directly. (Hi Ye, please check this concept if you have time!) The actually most important target group would be people doing things like sensor fusion where a common timebase is important, I don't know who does really, but Sandeep Singh from AMD has contributed the AMD Sensor Fusion hub in drivers/hid/amd-sfh-hid and might know a few things about this though I don't think SFH would need this directly. https://en.wikipedia.org/wiki/Sensor_fusion Also Paging Drew Fustini, who knows a lot of maker and tinker people, he might know a bit about this or know someone who knows. Yours, Linus Walleij
On Sun, Jun 27, 2021 at 5:41 PM Linus Walleij <linus.walleij@linaro.org> wrote: > On Sun, Jun 27, 2021 at 3:08 PM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > > > To summarize upstream discussion: > > > - It was heavily favoured by Linus and Kent to extend GPIOLIB and supporting > > > GPIO drivers to add HTE functionality and I agreed to experiment with it. > > > > I guess this series should include more people from different > > companies, especially documentation parts. This may be used by > > different hardware and quite different vendors. Developing a framework > > like this for only one vendor is no go in general. > > I forwarded patch 00 to the IIO list and Jonathan Cameron, > and let's page Ye Xiang who made a bunch of contributions > from Intel's side to IIO directly. (Hi Ye, please check this concept > if you have time!) > > The actually most important target group would be people > doing things like sensor fusion where a common timebase is > important, I don't know who does really, but Sandeep Singh from > AMD has contributed the AMD Sensor Fusion hub in > drivers/hid/amd-sfh-hid and might know a few things about this > though I don't think SFH would need this directly. > https://en.wikipedia.org/wiki/Sensor_fusion > > Also Paging Drew Fustini, who knows a lot of maker and tinker > people, he might know a bit about this or know someone who > knows. Thank you! -- With Best Regards, Andy Shevchenko