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
