[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151015055734.GB4784@netboy>
Date: Thu, 15 Oct 2015 07:57:35 +0200
From: Richard Cochran <richardcochran@...il.com>
To: Christopher Hall <christopher.s.hall@...el.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, jeffrey.t.kirsher@...el.com,
hpa@...or.com, mingo@...hat.com, john.stultz@...aro.org,
peterz@...radead.org, x86@...nel.org,
intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, kevin.b.stanton@...el.com
Subject: Re: [PATCH v4 1/4] Produce system time from correlated clocksource
On Wed, Oct 14, 2015 at 06:57:33PM -0700, Christopher Hall wrote:
> >>+#define SHADOW_HISTORY_DEPTH 7
> >
> >And that number is 7 because?
>
> Due to power of 2 it will be 8 instead. As above the useful history is 8-2*1
> ms (1 ms is the minimum jiffy length). Array size 4 would not be enough
> history for the DSP which requires 4 ms of history, in the worst case.
Just as I suspected, the magic number 7 is based on the needs of one
particular user. What about the next user who comes along needing 10
milliseconds? That will not do. Any new interface should be generic
enough to support a wide range of users.
So I think this approach is all wrong. Here is an idea for you to
consider. Instead of mucking with the TK, let the user code (possibly
in-kernel) sample ART/sys pairs and interpolate the ART/dev time
stamps. That way, the user can choose the range and resolution that
he needs.
> The audio driver is structured in such a way that it's simpler to provide a
> value rather than a callback.
Can you please provide a link to the audio driver that uses this new
interface?
Thanks,
Richard
--
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