From: Dipen Patel <dipenp@nvidia.com>
To: "N, Pandith" <pandith.n@intel.com>, linus.walleij@linaro.org
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Hall, Christopher S" <christopher.s.hall@intel.com>,
"Gross, Mark" <mark.gross@intel.com>,
"Sangannavar,
Mallikarjunappa" <mallikarjunappa.sangannavar@intel.com>,
"D, Lakshmi Sowjanya" <lakshmi.sowjanya.d@intel.com>,
"T R, Thejesh Reddy" <thejesh.reddy.t.r@intel.com>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>,
timestamp@lists.linux.dev, dipenp@nvidia.com
Subject: Re: Intel timed i/o driver in HTE
Date: Fri, 18 Nov 2022 18:33:30 -0800 [thread overview]
Message-ID: <7de35859-97ab-8e88-f590-d5851b81773b@nvidia.com> (raw)
In-Reply-To: <BYAPR11MB3240F382BD180FF90C7DF0B9E1069@BYAPR11MB3240.namprd11.prod.outlook.com>
On 11/17/22 10:47 AM, N, Pandith wrote:
> Hi Dipen,
>
> To support Intel timed i/o driver, it was suggested by Linux community to enhance hte framework.
> However, we see some limitations to support complete Intel timed i/o device.
>
> 1. The current framework supports Nvidia IP, which has two IP blocks (hw timestamping engine interfaced with GPIO)
> Intel timed i/o is a single IP block handling multiple functionalities like:
>
> a. Input timestamping with event counter.
> b. Timed output - single shot or periodic pulse train.
> Uses TSC(Timestamp counter) for timestamp or generate events, which could be translated to system time.
> c. Implement PPS functionality to export time.
Isn't 1c similar to 1b, where IO (mostly GPIO) is programmed to toggle/periodic pulse train at 1s.
>
> This requires new functionality(interface) to be developed in hte framework specific to timed-io device.
I can see 1a is straight case for the HTE.
For 1b, the timestamp part can be added as hte provider. I see opportunity to enhance hte framework to provide
translation facility between the domain, system time in this case. However programming interface to facilitate
timed IO output can not fit into HTE the way it is right now. May be one possible way is to enchance HTE with API something like
hte_configure_timestamp_periodic/timed could be possible in which case HTE does something more than just timestamping the event.
I have to see how in GPIO case that proposed API works out, if it will bypass gpio framework etc...
Adding Linus W into the discussion....
>
> 2. The current hte framework has a provider and consumer concept.
> Consumer is responsible for user space interaction.
> Currently Nvidia is using GPIO for input timestamping (by adding hw timestamps in gpiolib-cdev.c)
>
> For Intel timed i/o functionalities, current gpio user interfaces cannot support event counter
> or output modes.
Can you elaborate on event counter and output mode?
> Rather than jigging hte consumer into other subsystems to support timed i/o device.
> Any possibility of developing a native consumer in hte subsystem, which could handle user space interactions for timestamping engines.
yes, feel free to send patches to me and cc timestamp@lists.linux.dev, I guess you can register your IP as one of the provider.
To explain why GPIO was treated specially, there was already a
user facing framework i,e gpio-cdev and range of userspace tools which could be leveraged for the HTE GPIO consumers. However this does
not prevent kernel space GPIO HTE consumer from using HTE core directly.
>
> I cannot think of an existing subsystem that handles Intel timed i/o functionalities 1a, 1b and 1c (mentioned above).
>
> Regards,
> Pandith
>
>
>
>
Best Regards,
Dipen Patel
next parent reply other threads:[~2022-11-19 2:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <BYAPR11MB3240F382BD180FF90C7DF0B9E1069@BYAPR11MB3240.namprd11.prod.outlook.com>
2022-11-19 2:33 ` Dipen Patel [this message]
2022-11-20 22:33 ` Intel timed i/o driver in HTE Linus Walleij
2022-11-23 14:37 ` N, Pandith
2022-11-23 21:22 ` Linus Walleij
2022-11-29 18:10 ` N, Pandith
2022-11-30 9:00 ` Linus Walleij
2022-11-30 3:24 ` Dipen Patel
2022-12-02 3:00 ` N, Pandith
2022-12-03 9:49 ` Linus Walleij
2022-12-08 4:52 ` Hall, Christopher S
2022-12-08 22:10 ` Linus Walleij
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 \
--in-reply-to=7de35859-97ab-8e88-f590-d5851b81773b@nvidia.com \
--to=dipenp@nvidia.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=christopher.s.hall@intel.com \
--cc=lakshmi.sowjanya.d@intel.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mallikarjunappa.sangannavar@intel.com \
--cc=mark.gross@intel.com \
--cc=pandith.n@intel.com \
--cc=thejesh.reddy.t.r@intel.com \
--cc=timestamp@lists.linux.dev \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).