Messages in this thread | | | Date | Wed, 1 Apr 2020 01:02:48 +0200 | From | Thierry Reding <> | Subject | Re: [PATCH] clocksource: Add debugfs support |
| |
On Tue, Mar 31, 2020 at 03:44:25PM -0700, John Stultz wrote: > On Tue, Mar 31, 2020 at 3:25 PM Thierry Reding <thierry.reding@gmail.com> wrote: > > On Tue, Mar 31, 2020 at 02:50:47PM -0700, John Stultz wrote: > > > On Tue, Mar 31, 2020 at 2:40 PM Thierry Reding <thierry.reding@gmail.com> wrote: > > > > > > > > From: Thierry Reding <treding@nvidia.com> > > > > > > > > Add a top-level "clocksource" directory to debugfs. For each clocksource > > > > registered with the system, a subdirectory will be added with attributes > > > > that can be queried to obtain information about the clocksource. > > > > > > > > > > Curious, what's the need/planned use for this? I know in the past > > > folks have tried to get timekeeping internals exported to userland so > > > they could create their own parallel userland timekeeping system, > > > which I worry is a poor idea. > > > > This was meant to be purely for debugging purposes. That is as an easy > > way to check that the code was working and that the counter is properly > > updated. > > > > I certainly wasn't planning on implementing any userland on top of this. > > Well, I guess it could be useful to use these values in test scripts > > perhaps, since one of the clock sources exposed by one of the drivers I > > have been working on is used across Tegra SoCs for hardware > > timestamping. For that it might be interesting to be able to compare > > those timestamp snapshots to something that I can read from userspace > > during testing. > > So, other platforms do similar, but utilizing the ktime_get_snapshot() > interface internally so drivers can share that SoC hardware > timestamping logic and export that via driver interfaces in a cleanly > abstracted way to userland, rather than exposing the timekeping > internals.
The hardware timestamping functionality is going to be exposed by a different driver. I was merely speculating that the debugfs interface could be used to also read out the counter value for the TSC as a means of correlating it to the values from the timestamping hardware. On second thought that may not be very useful given the non-deterministic delay between the hardware timestamp and the debugfs read.
Like I said, the original intent here was really only to make it easy to inspect the clocksources. I can add more fields if that's deemed useful. I can imagine that different engineers keep writing different test code to verify clock sources and thought that this might be a good addition to make this easier.
But if you have concerns that this might get abused for something unintended I understand that, so if you think exposing this is a bad idea, I'll just drop this patch.
Thierry [unhandled content-type:application/pgp-signature] | |