John Stultz writes:
> On Mon, Mar 2, 2015 at 12:56 PM, Harald Geyer <harald@xxxxxxxxx> wrote:
> > This has been tested on i386, sunxi and mxs.
>
> So the patch needs to have the actual rational for inclusion here, not
> in the cover-letter, since the cover-letter gets thrown away.
Hm, to show the rational I included Patch 3 which is probably not
apt for the commit message. How about the following:
| This patch series introduces a new function
| u32 ktime_get_resolution_ns(void)
| which allows to clean up some driver code.
|
| In particular the IIO subsystem has a function to provide timestamps for
| events but no means to get their resolution. So currently the dht11 driver
| tries to guess the resolution in a rather messy and convoluted way. We
| can do much better with the new code.
> > Signed-off-by: Harald Geyer <harald@xxxxxxxxx>
> > ---
> > include/linux/timekeeping.h | 1 +
> > kernel/time/timekeeping.c | 18 ++++++++++++++++++
> > 2 files changed, 19 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
> > index 3eaae47..983b61e 100644
> > --- a/include/linux/timekeeping.h
> > +++ b/include/linux/timekeeping.h
> > @@ -163,6 +163,7 @@ extern ktime_t ktime_get(void);
> > extern ktime_t ktime_get_with_offset(enum tk_offsets offs);
> > extern ktime_t ktime_mono_to_any(ktime_t tmono, enum tk_offsets offs);
> > extern ktime_t ktime_get_raw(void);
> > +extern u32 ktime_get_resolution_ns(void);
> >
> > /**
> > * ktime_get_real - get the real (wall-) time in ktime_t format
> > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> > index 91db941..b823eba 100644
> > --- a/kernel/time/timekeeping.c
> > +++ b/kernel/time/timekeeping.c
> > @@ -586,6 +586,24 @@ ktime_t ktime_get(void)
> > }
> > EXPORT_SYMBOL_GPL(ktime_get);
> >
> > +u32 ktime_get_resolution_ns(void)
> > +{
> > + struct timekeeper *tk = &tk_core.timekeeper;
> > + unsigned int seq;
> > + u32 nsecs;
> > +
> > + WARN_ON(timekeeping_suspended);
> > +
> > + do {
> > + seq = read_seqcount_begin(&tk_core.seq);
> > + nsecs = tk->tkr.mult >> tk->tkr.shift;
> > + } while (read_seqcount_retry(&tk_core.seq, seq));
> > +
> > + return nsecs;
> > +}
> > +
> > +EXPORT_SYMBOL_GPL(ktime_get_resolution_ns);
> > +
>
> So is this always going to be an internal-only interface?
As far as I'm concerned: yes.
> I know in
> the past folks have wanted clock_getres() to return similar hardware
> granular resolution, but Thomas has pushed back against this due to
> the fact that the resolution could fluctuate during the lifetime of a
> system and there's no way to correlate a resolution returned from
> clock_getres and a a value returns from clock_gettime.
I don't see why this would be a hard problem: Just have some counter
incremented every time the clock source changes and expose that counter
to userspace too. But I'm not interested in this. If anybody want's
this information in userspace, it's theirs to make the case and propose
a solution that suits them.
> So while for internal purposes, we could probably support something
> like this, we really do need to make sure we're not exposing uselessly
> racy interfaces to userland.
Right now I report the resolution in the kernel log (if it is too low).
I think this is okay by your standards. Anything else you have in mind?
thanks,
Harald
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
