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@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Jun 3, 2022 at 4:39 AM Thierry Reding <thierry.reding@xxxxxxxxx> 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@xxxxxxxxx/#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:
signature.asc
Description: PGP signature