Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1310039

Re: [PATCH v6 3/9] Add correlated clocksource relating aliased auxiliary and system clocks

From Thomas Gleixner <tglx@linutronix.de>
Newsgroups linux.kernel
Subject Re: [PATCH v6 3/9] Add correlated clocksource relating aliased auxiliary and system clocks
Date 2016-01-15 11:40 +0100
Message-ID <qR9Xs-4OZ-15@gated-at.bofh.it> (permalink)
References <qQz7A-44Y-5@gated-at.bofh.it> <qQzhh-48x-23@gated-at.bofh.it> <qR0r7-6xt-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, 14 Jan 2016, John Stultz wrote:
> On Wed, Jan 13, 2016 at 4:12 AM, Christopher S. Hall
> <christopher.s.hall@intel.com> wrote:
> > +/*
> > + * struct correlated_cs - Descriptor for a clocksource correlated to another
> > + *     clocksource
> > + * @related_cs:                Pointer to the related timekeeping clocksource
> > + * @convert:           Conversion function to convert a timestamp from
> > + *                     the correlated clocksource to cycles of the related
> > + *                     timekeeping clocksource
> > + */
> > +struct correlated_cs {
> > +       struct clocksource      *related_cs;
> > +       cycle_t                 (*convert)(struct correlated_cs *cs,
> > +                                          cycle_t cycles);
> > +};
> > +
> 
> So.. In reworking your patch set, I've preserved this, but I'm still
> not totally convinced. Its a generic structure, but not used by any
> generic code and its only used by hardware specific implementations
> (ie: the tsc and e1000e_hwts logic). It seems like this could be a
> tsc.h specific structure w/o a real issue.

That correlated_cs is my fault. I invented that when I had that first stab on
the cross time stamp thing.
 
> And really this doesn't seem to be a generic thing. The e1000e hwts is
> always the ART based. Its not likely these sorts of cross hardware
> timestamps are going to be completely abstract and interchangeable,
> is it?

They might be in future. I guess other archs will provide similar means to
distribute an always on timer to PCIe for timestamping purposes.

So the question is whether we should expose that timestamp reference via a
generic mechanism, e.g. store it somewhere in the pci root complex or wherever
the appropriate point for it is.

Though for now, we certainly can make that x86 private and deal with it when
others come along.

Thanks,

	tglx

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v6 0/9] Patchset enabling hardware based cross-timestamps for next gen Intel platforms "Christopher S. Hall" <christopher.s.hall@intel.com> - 2016-01-13 20:30 +0100
  [PATCH v6 3/9] Add correlated clocksource relating aliased auxiliary and system clocks "Christopher S. Hall" <christopher.s.hall@intel.com> - 2016-01-13 20:30 +0100
    Re: [PATCH v6 3/9] Add correlated clocksource relating aliased  auxiliary and system clocks John Stultz <john.stultz@linaro.org> - 2016-01-15 01:30 +0100
      Re: [PATCH v6 3/9] Add correlated clocksource relating aliased  auxiliary and system clocks Thomas Gleixner <tglx@linutronix.de> - 2016-01-15 11:40 +0100
  Re: [PATCH v6 0/9] Patchset enabling hardware based cross-timestamps  for next gen Intel platforms John Stultz <john.stultz@linaro.org> - 2016-01-15 01:50 +0100

csiph-web