* [GIT PULL] hte: New subsystem for v5.19-rc1
@ 2022-06-03 11:39 Thierry Reding
2022-06-04 4:37 ` Linus Torvalds
2022-06-05 17:16 ` pr-tracker-bot
0 siblings, 2 replies; 8+ messages in thread
From: Thierry Reding @ 2022-06-03 11:39 UTC (permalink / raw
To: Linus Torvalds
Cc: Dipen Patel, Linus Walleij, Bartosz Golaszewski, linux-tegra,
linux-kernel
Hi Linus,
The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17:
Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/hte/for-5.19-rc1
for you to fetch changes up to 5dad4eccd2b4316a84209603a28d34c6346392bb:
dt-bindings: timestamp: Correct id path (2022-06-02 15:56:59 +0200)
This is a new subsystem that introduces support for associating
hardware timestamps with certain events (such as GPIOs and IRQs). Dipen
has worked on this for a couple of months and it's been in linux-next
for a couple of weeks. We think it's now ready for inclusion in v5.19.
Dipen's the official maintainer, but I volunteered to help out with the
logistics while he gets set up with the necessary key signatures and a
kernel.org account. Hopefully this will all be done by the next merge
window, enabling Dipen to take over.
Apologies for this being a little late, but there were a few last-minute
tweaks in the device tree bindings that I wanted to give an extra day in
linux-next just to make sure. The impact of this should be minimal since
it is all new code.
Thanks,
Thierry
----------------------------------------------------------------
hte: New subsystem for v5.19-rc1
This contains the new HTE subsystem that has been in the works for a
couple of months now. The infrastructure provided allows for drivers to
register as hardware timestamp providers, while consumers will be able
to request events that they are interested in (such as GPIOs and IRQs)
to be timestamped by the hardware providers.
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.
----------------------------------------------------------------
Dan Carpenter (2):
hte: Fix off by one in hte_push_ts_ns()
hte: Uninitialized variable in hte_ts_get()
Dipen Patel (12):
Documentation: Add HTE subsystem guide
drivers: Add hardware timestamp engine (HTE) subsystem
hte: Add Tegra194 HTE kernel provider
dt-bindings: Add HTE bindings
gpiolib: Add HTE support
gpio: tegra186: Add HTE support
gpiolib: cdev: Add hardware timestamp clock type
tools: gpio: Add new hardware clock type
hte: Add Tegra HTE test driver
MAINTAINERS: Add HTE Subsystem
dt-bindings: Renamed hte directory to timestamp
dt-bindings: timestamp: Correct id path
Jiapeng Chong (1):
hte: Remove unused including <linux/version.h>
Yang Yingliang (1):
hte: Fix possible use-after-free in tegra_hte_test_remove()
.../timestamp/hardware-timestamps-common.yaml | 29 +
.../bindings/timestamp/hte-consumer.yaml | 39 +
.../bindings/timestamp/nvidia,tegra194-hte.yaml | 88 ++
Documentation/hte/hte.rst | 79 ++
Documentation/hte/index.rst | 22 +
Documentation/hte/tegra194-hte.rst | 49 ++
Documentation/index.rst | 1 +
MAINTAINERS | 8 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/gpio/gpio-tegra186.c | 81 +-
drivers/gpio/gpiolib-cdev.c | 252 +++++-
drivers/gpio/gpiolib.c | 58 ++
drivers/gpio/gpiolib.h | 1 +
drivers/hte/Kconfig | 33 +
drivers/hte/Makefile | 3 +
drivers/hte/hte-tegra194-test.c | 238 ++++++
drivers/hte/hte-tegra194.c | 730 ++++++++++++++++
drivers/hte/hte.c | 947 +++++++++++++++++++++
include/linux/gpio/consumer.h | 16 +-
include/linux/gpio/driver.h | 10 +
include/linux/hte.h | 271 ++++++
include/uapi/linux/gpio.h | 3 +
tools/gpio/gpio-event-mon.c | 6 +-
24 files changed, 2930 insertions(+), 37 deletions(-)
create mode 100644 Documentation/devicetree/bindings/timestamp/hardware-timestamps-common.yaml
create mode 100644 Documentation/devicetree/bindings/timestamp/hte-consumer.yaml
create mode 100644 Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
create mode 100644 Documentation/hte/hte.rst
create mode 100644 Documentation/hte/index.rst
create mode 100644 Documentation/hte/tegra194-hte.rst
create mode 100644 drivers/hte/Kconfig
create mode 100644 drivers/hte/Makefile
create mode 100644 drivers/hte/hte-tegra194-test.c
create mode 100644 drivers/hte/hte-tegra194.c
create mode 100644 drivers/hte/hte.c
create mode 100644 include/linux/hte.h
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [GIT PULL] hte: New subsystem for v5.19-rc1
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
2022-06-05 17:16 ` pr-tracker-bot
1 sibling, 1 reply; 8+ messages in thread
From: Linus Torvalds @ 2022-06-04 4:37 UTC (permalink / raw
To: Thierry Reding
Cc: Dipen Patel, Linus Walleij, Bartosz Golaszewski, linux-tegra,
Linux Kernel Mailing List
On Fri, Jun 3, 2022 at 4:39 AM Thierry Reding <thierry.reding@gmail.com> 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
window.
And it's a bit odd in other ways.
The DT bindings got the comment "why call it 'hardware timestamp'"
when no other case seems sane.
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
"timestamp".
Hmm.
Linus
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [GIT PULL] hte: New subsystem for v5.19-rc1
2022-06-04 4:37 ` Linus Torvalds
@ 2022-06-04 8:11 ` Linus Walleij
2022-06-05 16:16 ` Linus Torvalds
2022-06-05 16:27 ` Thierry Reding
0 siblings, 2 replies; 8+ messages in thread
From: Linus Walleij @ 2022-06-04 8:11 UTC (permalink / raw
To: Linus Torvalds, D, Lakshmi Sowjanya
Cc: Thierry Reding, Dipen Patel, Bartosz Golaszewski, linux-tegra,
Linux Kernel Mailing List, Mark Gross, Andy Shevchenko,
Saha, Tamal, bala.senthil
On Sat, Jun 4, 2022 at 6:38 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Jun 3, 2022 at 4:39 AM Thierry Reding <thierry.reding@gmail.com> 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
> window.
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:
https://patchwork.ozlabs.org/project/linux-gpio/cover/20210824164801.28896-1-lakshmi.sowjanya.d@intel.com/#2766453
[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
> "timestamp".
HTE is "hardware timestamping engine", we have hwmon, hwspinlock,
hwtracing so maybe hwstamping would be a more natural name then?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [GIT PULL] hte: New subsystem for v5.19-rc1
2022-06-04 8:11 ` Linus Walleij
@ 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
1 sibling, 2 replies; 8+ messages in thread
From: Linus Torvalds @ 2022-06-05 16:16 UTC (permalink / raw
To: Linus Walleij
Cc: D, Lakshmi Sowjanya, Thierry Reding, Dipen Patel,
Bartosz Golaszewski, linux-tegra, Linux Kernel Mailing List,
Mark Gross, Andy Shevchenko, Saha, Tamal, bala.senthil
On Sat, Jun 4, 2022 at 1:11 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> 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
Ok, I've pulled this now, even if I don't love the "hte" name. I
despise specialized TLA's that aren't some obvious "if you're a kernel
developer, you know what this means".
Linus
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [GIT PULL] hte: New subsystem for v5.19-rc1
2022-06-04 8:11 ` Linus Walleij
2022-06-05 16:16 ` Linus Torvalds
@ 2022-06-05 16:27 ` Thierry Reding
1 sibling, 0 replies; 8+ messages in thread
From: Thierry Reding @ 2022-06-05 16:27 UTC (permalink / raw
To: Linus Walleij
Cc: Linus Torvalds, D, Lakshmi Sowjanya, Dipen Patel,
Bartosz Golaszewski, linux-tegra, Linux Kernel Mailing List,
Mark Gross, Andy Shevchenko, Saha, Tamal, bala.senthil
[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]
On Sat, Jun 04, 2022 at 10:11:17AM +0200, Linus Walleij wrote:
> On Sat, Jun 4, 2022 at 6:38 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Fri, Jun 3, 2022 at 4:39 AM Thierry Reding <thierry.reding@gmail.com> 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
> > window.
>
> 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:
> https://patchwork.ozlabs.org/project/linux-gpio/cover/20210824164801.28896-1-lakshmi.sowjanya.d@intel.com/#2766453
>
> [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
> > "timestamp".
>
> HTE is "hardware timestamping engine", we have hwmon, hwspinlock,
> hwtracing so maybe hwstamping would be a more natural name then?
Another alternative would be just drivers/timestamp since pretty much
anything in drivers/ is for "hw".
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [GIT PULL] hte: New subsystem for v5.19-rc1
2022-06-05 16:16 ` Linus Torvalds
@ 2022-06-05 16:32 ` Thierry Reding
2022-06-16 18:30 ` Dipen Patel
1 sibling, 0 replies; 8+ messages in thread
From: Thierry Reding @ 2022-06-05 16:32 UTC (permalink / raw
To: Linus Torvalds
Cc: Linus Walleij, D, Lakshmi Sowjanya, Dipen Patel,
Bartosz Golaszewski, linux-tegra, Linux Kernel Mailing List,
Mark Gross, Andy Shevchenko, Saha, Tamal, bala.senthil
[-- Attachment #1: Type: text/plain, Size: 953 bytes --]
On Sun, Jun 05, 2022 at 09:16:21AM -0700, Linus Torvalds wrote:
> On Sat, Jun 4, 2022 at 1:11 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > 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
>
> Ok, I've pulled this now, even if I don't love the "hte" name. I
> despise specialized TLA's that aren't some obvious "if you're a kernel
> developer, you know what this means".
Thanks. If you prefer we could follow up with a rename for v5.20 and
name this similar to the device tree bindings. There are other cases
where the device tree bindings are named differently from the Linux
subsystem and/or driver directories, but admittedly it'd be easy to
make them match in this case. Given how little this is exposed at
this point, renaming should be fairly unintrusive.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [GIT PULL] hte: New subsystem for v5.19-rc1
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-05 17:16 ` pr-tracker-bot
1 sibling, 0 replies; 8+ messages in thread
From: pr-tracker-bot @ 2022-06-05 17:16 UTC (permalink / raw
To: Thierry Reding
Cc: Linus Torvalds, Dipen Patel, Linus Walleij, Bartosz Golaszewski,
linux-tegra, linux-kernel
The pull request you sent on Fri, 3 Jun 2022 13:39:08 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/hte/for-5.19-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2981436374177f78539b026ce5bcbab8c251818e
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [GIT PULL] hte: New subsystem for v5.19-rc1
2022-06-05 16:16 ` Linus Torvalds
2022-06-05 16:32 ` Thierry Reding
@ 2022-06-16 18:30 ` Dipen Patel
1 sibling, 0 replies; 8+ messages in thread
From: Dipen Patel @ 2022-06-16 18:30 UTC (permalink / raw
To: Linus Torvalds
Cc: D, Lakshmi Sowjanya, Thierry Reding, Bartosz Golaszewski,
linux-tegra, Linux Kernel Mailing List, Mark Gross,
Andy Shevchenko, Saha, Tamal, bala.senthil, Linus Walleij
Hi Linus,
Thanks for pulling in the hte subsystem. I wanted to check with you if renaming hte subsystem to "timestamp" as suggested by Thierry is ok or do you prefer to keep it as it is?
Best Regards,
Dipen Patel
On 6/5/22 9:16 AM, Linus Torvalds wrote:
> On Sat, Jun 4, 2022 at 1:11 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>> 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
> Ok, I've pulled this now, even if I don't love the "hte" name. I
> despise specialized TLA's that aren't some obvious "if you're a kernel
> developer, you know what this means".
>
> Linus
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-06-16 18:30 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
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).