[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <B79D786B7111A34A8CF09F833429C493A90B2D1F@ORSMSX109.amr.corp.intel.com>
Date: Thu, 3 Sep 2015 23:20:37 +0000
From: "Hall, Christopher S" <christopher.s.hall@...el.com>
To: Thomas Gleixner <tglx@...utronix.de>
CC: "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"hpa@...or.com" <hpa@...or.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"john.stultz@...aro.org" <john.stultz@...aro.org>,
"richardcochran@...il.com" <richardcochran@...il.com>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
"peterz@...radead.org" <peterz@...radead.org>
Subject: RE: [PATCH v3 1/4] Add correlated clocksource deriving system time
from an auxiliary clocksource
> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx@...utronix.de]
> Sent: Saturday, August 22, 2015 1:17 PM
> To: Hall, Christopher S
> Cc: Kirsher, Jeffrey T; hpa@...or.com; mingo@...hat.com;
> john.stultz@...aro.org; richardcochran@...il.com; x86@...nel.org; linux-
> kernel@...r.kernel.org; netdev@...r.kernel.org; intel-wired-
> lan@...ts.osuosl.org; peterz@...radead.org
> Subject: Re: [PATCH v3 1/4] Add correlated clocksource deriving system time
> from an auxiliary clocksource
>
> > +/**
> > + * get_correlated_timestamp - Get a correlated timestamp
> > + *
> > + * Reads a timestamp from a device and correlates it to system time
> > + */
> > +int get_correlated_timestamp(struct correlated_ts *crt,
> > + struct correlated_cs *crs)
> > +{
> > + struct timekeeper *tk = &tk_core.timekeeper;
> > + unsigned long seq;
> > + cycles_t cycles;
> > + ktime_t base;
> > + s64 nsecs;
> > + int ret;
> > +
> > + do {
> > + seq = read_seqcount_begin(&tk_core.seq);
> > + /*
> > + * Verify that the correlated clocksoure is related to
> > + * the currently installed timekeeper clocksoure
> > + */
> > + if (tk->tkr_mono.clock != crs->related_cs)
> > + return -ENODEV;
> > +
> > + /*
> > + * Try to get a timestamp from the device.
> > + */
> > + ret = crt->get_ts(crt);
> > + if (ret)
> > + return ret;
> > +
[Re-added code for context]
In addition to the network interface, ART will be used in the audio interface as well.
We need to support the case where an audio co-processor will control the audio device.
In this case, the get_ts() function supplied by the audio driver will be very slow
(several milliseconds) and the result will be out of date by some fraction of that
amount.
This loop makes strict requirements on the latency and recency. Is it possible to relax
that requirement in some way?
For example, supply the ART value as an argument and, in the case of the realtime
clock, keep a short history of clock changes. It would fail in cases where there
are a lot of calls to adjtimex(), but it will would work most of the time.
What can you suggest? Thanks
Chris
> > + } while (read_seqcount_retry(&tk_core.seq, seq));
> > + return 0;
> > +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists