Message-ID: <4c46726d-fa35-1a95-4295-bca37c8b6fe3@nvidia.com>
Date:   Wed, 17 Mar 2021 15:33:51 -0700
From:   Dipen Patel <dipenp@...dia.com>
To:     <linux-kernel@...r.kernel.org>, <thierry.reding@...il.com>,
        <jonathanh@...dia.com>, <linus.walleij@...aro.org>,
        <bgolaszewski@...libre.com>, <linux-gpio@...r.kernel.org>
CC:     <linux-tegra@...r.kernel.org>
Subject: GTE - The hardware timestamping engine

Hi All,

I wanted to discuss few implementation details regarding the GTE module and
wanted to know your feedback on certain aspects as below.

==================
GTE introductions:
==================
Nvidia Tegra SoCs have generic timestamping engine (GTE) hardware module which
can monitor SoC signals like IRQ lines and GPIO lines for state change, upon
detecting the change, it can timestamp and store in its internal hardware FIFO.
The advantage of the GTE module can be realized in applications like robotics
or autonomous vehicle where it can help record events with precise timestamp.

The GTE module however complicates the thing for GPIO monitoring compare to
IRQ lines as it has dependency on GPIO controller and that is where I will
probably will need your feedback to figure few things out before sending the
patches for the review. The below is the rough sequence to enable the hw
timestamp for a given signal using GTE module to put things into perspective.

============
For GPIO:
============
1.  GPIO has to be configured as input and IRQ must be enabled.
2.  Ask GPIO controller driver to set corresponding timestamp bit in the
    specified GPIO config register.
3.  Translate GPIO specified by the client to its internal bitmap.
3.a For example, If client specifies GPIO line 31, it could be bit 13 of GTE
    register.
4.  Set internal bits to enable monitoring in GTE module
5.  Additionally GTE driver can open up lanes for the user space application
    as a client and can send timestamping events directly to the application.

============
For IRQ:
============
x. Client sends IRQ line number to GTE driver
y. There is no need to translate as there is one to one correspondence with its
   internal bitmap, for example, IRQ line 31 will be bit 31 of the GTE internal
   register.
z. Set the required bits.

====================================================================
Doubts (specifically for the bullet 1,2,3 from GPIO section above):
====================================================================
b. Should GTE driver expect its client to send GPIO number as per the GPIO
   controller/framework numbering/namespace scheme?
b.1 The possible issues with this approach are:
b.1.1  It hast to make of_find_gpiochip_by_node function public which GTE driver
	   can use to confirm GPIO number that client sent is indeed belongs to the
	   controller which supports the timestamp functions as not all the GPIO
	   controllers support it.
b.1.2  GTE driver will need GPIO controller node either passed through its own
       device tree or through some other methods (if at all exist) to
	   facilitate b.1.1
c.  How GTE driver can talk to GPIO framework regarding bullet 2?
c.1 If it is through some callbacks then have to add "timestamp_control" like
    function hook in the gpio framework structure. This is under assumption
	bullet b is GPIO numbering scheme, we can then pass the same GPIO number to
	this hook to enable timestamp bit in GPIO controller.
d   GPIO logical numbering happens at the run time so GTE driver has to take
    care b.1.1, b.1.2 and c.1.
e.  Using above b.1.1, b.1.2 and c.1, GTE module can do bullet 1 and 2 for its
    clients or at least bullet 2.

f.  The other alternative is to have GTE its own GPIO numbering for its clients.
f.1 This approach completely decouples GPIO controller and GTE, where client
    will be responsible for bullet 1 and gpio controller driver will be
	responsible for the bullet 2 and possibly set timestamp bit of all the GPIOs
	it supports during probe as real timestamping starts anyway after GTE driver
	programs its corresponding registers so can be considered harmless.
f.2. I am more leaning towards this approach.

===============================================
Doubts regarding the place it in the kernel:
===============================================
g. Does GTE deserve its own subsystem or should it be consumed as part of some
   other subsystems?
g.1 GTE GPIO timestamp monitoring comes very close to what we already have in
    the gpiolib, more specifically lineevent part. Having said that however if
	I were to add GTE inside GPIO framework "somehow", it will require
	non-trivial gpio framework changes and at the same time it will make GTE
	module fragmented since GTE also timestamps other signals besides GPIO like
	IRQ as mentioned previously.
h. I am more leaning towards having its own subsystem.

Best Regards,
Dipen Patel

Powered by blists - more mailing lists