From: Linus Walleij <firstname.lastname@example.org>
To: Linus Torvalds <email@example.com>,
"D, Lakshmi Sowjanya" <firstname.lastname@example.org>
Cc: Thierry Reding <email@example.com>,
Dipen Patel <firstname.lastname@example.org>,
Bartosz Golaszewski <email@example.com>,
Linux Kernel Mailing List <firstname.lastname@example.org>,
Mark Gross <email@example.com>,
Andy Shevchenko <firstname.lastname@example.org>,
"Saha, Tamal" <email@example.com>,
Subject: Re: [GIT PULL] hte: New subsystem for v5.19-rc1
Date: Sat, 4 Jun 2022 10:11:17 +0200 [thread overview]
Message-ID: <CACRpkda0KiyjV27WEP_MYpvWXyG787L9PJZaP_hnXh_DFpSj5Q@mail.gmail.com> (raw)
On Sat, Jun 4, 2022 at 6:38 AM Linus Torvalds
> On Fri, Jun 3, 2022 at 4:39 AM Thierry Reding <firstname.lastname@example.org> wrote:
> > Note that this currently supports only one provider, but there seems to
> > be enough interest in this functionality and we expect to see more
> > drivers added once this is merged.
> So the "one provider" worries me, but the part that really doesn't
> make me all warm and fuzzy is how this came in at the end of the merge
Another provider did come up, and were requested (by me) to work with
Dipen on the subsystem in august last year, that was the Intel PMC in the
Elkhart and Tiger Lake platforms and forward:
[I added the other Intel people on that submission to CC]
Intel wanted to put this into the GPIO subsystem and what I saw as maintainer
was that this is a general problem and general purpose (binary) I/O just isn't
going to be the only thing they timestamp. Other events will be for IIO and
hwmon or whatever. They have been
requested to contribute to Dipens work the recent 9 months ... so... well I
understand people can get other priorities and stuff.
Dipen did the right thing and created a separate subsystem that is a provider
to GPIO and can be a provider to things like IIO as well, which is what
it needs to be because for things like sensor fusion and industrial control
systems in general precise timestamps are
of uttermost importance. And IIO handle a lot of sensors.
> The DT bindings got the comment "why call it 'hardware timestamp'"
> when no other case seems sane.
Intel is talking about "input timestamping", admittedly it is done in hardware
but the point is to timestamp input I/O events.
> So the DT bindings got renamed. So now part of the code calls it "hte"
> (which nobody understands outside of the hte community that is
> apparently one single device: Tegra) and part of the code calls it
HTE is "hardware timestamping engine", we have hwmon, hwspinlock,
hwtracing so maybe hwstamping would be a more natural name then?
next prev parent reply other threads:[~2022-06-04 8:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-03 11:39 [GIT PULL] hte: New subsystem for v5.19-rc1 Thierry Reding
2022-06-04 4:37 ` Linus Torvalds
2022-06-04 8:11 ` Linus Walleij [this message]
2022-06-05 16:16 ` Linus Torvalds
2022-06-05 16:32 ` Thierry Reding
2022-06-16 18:30 ` Dipen Patel
2022-06-05 16:27 ` Thierry Reding
2022-06-05 17:16 ` pr-tracker-bot
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 NNTP newsgroup(s).