From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752249AbbJTTMT (ORCPT ); Tue, 20 Oct 2015 15:12:19 -0400 Received: from www.linutronix.de ([62.245.132.108]:52036 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751578AbbJTTMQ (ORCPT ); Tue, 20 Oct 2015 15:12:16 -0400 Date: Tue, 20 Oct 2015 21:11:21 +0200 (CEST) From: Thomas Gleixner To: Richard Cochran cc: John Stultz , Christopher Hall , Jeff Kirsher , "H. Peter Anvin" , Ingo Molnar , Peter Zijlstra , "x86@kernel.org" , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, lkml , kevin.b.stanton@intel.com Subject: Re: [PATCH v4 1/4] Produce system time from correlated clocksource In-Reply-To: <20151020145523.GA5207@netboy> Message-ID: References: <1444675522-4198-1-git-send-email-christopher.s.hall@intel.com> <1444675522-4198-2-git-send-email-christopher.s.hall@intel.com> <20151020085408.GA2542@netboy> <20151020115113.GA23428@netboy> <20151020145523.GA5207@netboy> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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