her, Jeffrey T;
> > Ronciak, John; H. Peter Anvin; x...@kernel.org; lkml;
> > netdev@vger.kernel.org
> > Subject: Re: [PATCH 1/5] Add functions producing system time given a
> > backing counter value
> >
> > On Mon, Jul 27, 2015 at 5:46 PM, Christopher Ha
On Wed, 29 Jul 2015, Peter Zijlstra wrote:
> On Wed, Jul 29, 2015 at 12:19:06PM +0200, Thomas Gleixner wrote:
> > I don't know whether we need functionality to convert arbitrary
> > timestamps at all, but if we really need them then they are going to
> > be pretty simple and explicitely not precise
On Wed, Jul 29, 2015 at 01:48:41PM +0200, Richard Cochran wrote:
> On Wed, Jul 29, 2015 at 12:49:44PM +0200, Peter Zijlstra wrote:
> > This is still fuzzy, right? The hardware ART timestamp could be from
> > _before_ the NTP adjust; or the NTP adjust could happen while we do this
> > conversion and
On Wed, Jul 29, 2015 at 12:23:27PM +0200, Thomas Gleixner wrote:
> > Something like the below untested patch should be all we need for PTP
> > to be as precise as possible.
Yes, that is as good as it can be. The code protects against
concurrent NTP adjustments, and the PTP driver will have to blo
On Wed, Jul 29, 2015 at 12:49:44PM +0200, Peter Zijlstra wrote:
> This is still fuzzy, right? The hardware ART timestamp could be from
> _before_ the NTP adjust; or the NTP adjust could happen while we do this
> conversion and we'll take the retry loop.
In the original series, yes.
> In both cas
On Wed, Jul 29, 2015 at 12:23:27PM +0200, Thomas Gleixner wrote:
> +/*
> + * CHECKME: Do we need the adjust value? It should be 0, but if we run
> + * in a VM this might be a different story.
> + */
> +static u64 tsc_adjust;
Urgh, VMs have !0 values here?
--
To unsubscribe from this list: send the
On Wed, Jul 29, 2015 at 12:19:06PM +0200, Thomas Gleixner wrote:
> I don't know whether we need functionality to convert arbitrary
> timestamps at all, but if we really need them then they are going to
> be pretty simple and explicitely not precise for anything else than
> clock monotonic raw. But
On Wed, 29 Jul 2015, Thomas Gleixner wrote:
> On Mon, 27 Jul 2015, John Stultz wrote:
> > On Mon, Jul 27, 2015 at 8:44 PM, John Stultz wrote:
> > > On Mon, Jul 27, 2015 at 5:46 PM, Christopher Hall
> > > wrote:
> > >> * counter_to_rawmono64
> > >> * counter_to_mono64
> > >> * counter_to_realtime6
On Mon, 27 Jul 2015, John Stultz wrote:
> On Mon, Jul 27, 2015 at 8:44 PM, John Stultz wrote:
> > On Mon, Jul 27, 2015 at 5:46 PM, Christopher Hall
> > wrote:
> >> * counter_to_rawmono64
> >> * counter_to_mono64
> >> * counter_to_realtime64
> >>
> >> Enables drivers to translate a captured system
rg; lkml;
> netdev@vger.kernel.org
> Subject: Re: [PATCH 1/5] Add functions producing system time given a
> backing counter value
>
> On Mon, Jul 27, 2015 at 5:46 PM, Christopher Hall
> wrote:
> > * counter_to_rawmono64
> > * counter_to_mono64
> > * counter_to_realtime64
On Mon, Jul 27, 2015 at 8:44 PM, John Stultz wrote:
> On Mon, Jul 27, 2015 at 5:46 PM, Christopher Hall
> wrote:
>> * counter_to_rawmono64
>> * counter_to_mono64
>> * counter_to_realtime64
>>
>> Enables drivers to translate a captured system clock counter to system
>> time. This is useful for net
On Mon, Jul 27, 2015 at 5:46 PM, Christopher Hall
wrote:
> * counter_to_rawmono64
> * counter_to_mono64
> * counter_to_realtime64
>
> Enables drivers to translate a captured system clock counter to system
> time. This is useful for network and audio devices that capture timestamps
> in terms of bo
* counter_to_rawmono64
* counter_to_mono64
* counter_to_realtime64
Enables drivers to translate a captured system clock counter to system
time. This is useful for network and audio devices that capture timestamps
in terms of both the system clock and device clock.
Signed-off-by: Christopher Hall
13 matches
Mail list logo
