RE: [PATCH v3 1/4] Add correlated clocksource deriving system time from an auxiliary clocksource

-----Original Message-----
From: Thomas Gleixner [mailto:tglx@linutronix.de]
Sent: Friday, September 04, 2015 9:35 AM
To: Peter Zijlstra
Cc: Richard Cochran; Hall, Christopher S; Kirsher, Jeffrey T;
hpa@zytor.com; mingo@redhat.com; john.stultz@linaro.org; x86@kernel.org;
linux-kernel@vger.kernel.org; netdev@vger.kernel.org; intel-wired-
lan@lists.osuosl.org
Subject: Re: [PATCH v3 1/4] Add correlated clocksource deriving system time
from an auxiliary clocksource

On Fri, 4 Sep 2015, Peter Zijlstra wrote:

quoted

On Fri, Sep 04, 2015 at 05:17:43PM +0200, Richard Cochran wrote:

quoted

On Fri, Sep 04, 2015 at 05:10:21PM +0200, Peter Zijlstra wrote:

quoted

I think what they're getting at is asking if there's a rate limit to
time adjustments, without that, saving the last n transition points

will

quoted

quoted

quoted

still not cover any given length of history.

As if the ntp code isn't complex enough already - now we're adding
sample histories and adjustment rating limiting?

And all for some unknown DSP in a mythical sound card??

Hehe, I'm just a 'translator' here. But going by you answer I'm taking
it there isn't in fact a rate-limit to adjustments. Which, even if you
were not opposed to that direction, makes it an unfeasible proposition.

Also, I'm not thinking its too mythical, sound/soc/intel/ is full of
audio DSP stuff, I think a newer version will just gain ART support.

Right, but we still do not know how that is going to be used. And
that's the key question. As long as that is not answered all can do is
wild guessing.

It's not wild guessing.  We do have it working on other OSs and have a pretty good 
idea of how it will work.  The DSP firmware will be largely identical for Linux.  I 
think now, we have a chicken and egg problem.

We can't post audio drivers that break, or are broken by, the current ART interface.  
How do I move this forward?  Should I minimally (I don't know exactly what that means 
just yet) rewrite the ART interface so that the audio driver is mostly not broken and 
post that along with the audio driver code?  Is this an acceptable approach?

Thanks,

	tglx