[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1510202107410.8159@nanos>
Date: Tue, 20 Oct 2015 21:11:21 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Richard Cochran <richardcochran@...il.com>
cc: John Stultz <john.stultz@...aro.org>,
Christopher Hall <christopher.s.hall@...el.com>,
Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
"x86@...nel.org" <x86@...nel.org>,
intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
lkml <linux-kernel@...r.kernel.org>, kevin.b.stanton@...el.com
Subject: Re: [PATCH v4 1/4] Produce system time from correlated clocksource
On Tue, 20 Oct 2015, Richard Cochran wrote:
> On Tue, Oct 20, 2015 at 01:51:13PM +0200, Richard Cochran wrote:
> > You can, in fact, achieve "proper" correlation by sampling. As John
> > said, the question is whether the method in the patch set "measurably
> > improves the error" over using another, simpler method.
>
> Here is a short example to put some numbers on the expected error.
> Let the driver sample at an interval of 1 ms. If the system time's
> frequency hasn't changed between two samples, A and B, then the driver
> may interpolate without introducing any error.
Darn, we don't want to have that kind of sampling in every driver
which has this kind of problem even if it looks like the simpler
choice for this particular use case. This is going to be something
which next generation chips will have on more than just the audio
interface and we realy want to have a generic solution for this.
Thanks,
tglx
--
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