Message ID | 20220603113908.78777-1-thierry.reding@gmail.com |
---|---|
State | Accepted |
Headers | show |
Series | [GIT,PULL] hte: New subsystem for v5.19-rc1 | expand |
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
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
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
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
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
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!
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