From: Dipen Patel <email@example.com> To: <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com> Cc: <firstname.lastname@example.org> Subject: GTE - The hardware timestamping engine Date: Wed, 17 Mar 2021 15:33:51 -0700 [thread overview] Message-ID: <email@example.com> (raw) 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
next reply other threads:[~2021-03-17 22:30 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-17 22:33 Dipen Patel [this message] 2021-03-20 11:56 ` Linus Walleij 2021-03-20 12:44 ` Arnd Bergmann 2021-03-20 15:38 ` Richard Cochran 2021-03-22 20:33 ` Dipen Patel 2021-03-23 9:03 ` Thierry Reding 2021-03-23 12:51 ` Richard Cochran 2021-03-22 6:00 ` Kent Gibson 2021-03-22 20:21 ` Dipen Patel 2021-03-23 0:32 ` Kent Gibson 2021-03-23 1:53 ` Dipen Patel 2021-03-23 2:59 ` Kent Gibson 2021-03-23 4:09 ` Dipen Patel 2021-03-23 5:22 ` Kent Gibson 2021-03-23 9:08 ` Linus Walleij 2021-03-23 10:06 ` Thierry Reding 2021-03-23 18:21 ` Marc Zyngier 2021-03-23 18:25 ` Dipen Patel 2021-03-23 21:19 ` Dipen Patel 2021-03-23 18:01 ` Dipen Patel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: GTE - The hardware timestamping engine' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).