[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALAqxLVkwJ5cmvSZ9bL-F7YTFprZ+CvZW4MrMN0sEkk5yFqMRQ@mail.gmail.com>
Date: Mon, 27 Jul 2015 21:05:27 -0700
From: John Stultz <john.stultz@...aro.org>
To: Christopher Hall <christopher.s.hall@...el.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Richard Cochran <richardcochran@...il.com>,
Ingo Molnar <mingo@...hat.com>,
Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
john.ronciak@...el.com, "H. Peter Anvin" <hpa@...or.com>,
"x86@...nel.org" <x86@...nel.org>,
lkml <linux-kernel@...r.kernel.org>, netdev@...r.kernel.org
Subject: Re: [PATCH 1/5] Add functions producing system time given a backing
counter value
On Mon, Jul 27, 2015 at 8:44 PM, John Stultz <john.stultz@...aro.org> wrote:
> On Mon, Jul 27, 2015 at 5:46 PM, Christopher Hall
> <christopher.s.hall@...el.com> 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 both the system clock and device clock.
>
> Huh. So for counter_to_realtime64 & mono64, this seems to ignore the
> fact that the multiplier is constantly adjusted and corrected. So that
> calling the function twice with the same counter value may result in
> different returned values.
>
> I've not yet groked the whole patchset, but it seems like there needs
> to be some mechanism that ensures the counter value is captured and
> used in the same (or at least close) interval that the timekeeper data
> is valid for.
So reading through. It looks like you only use art_to_realtime(), right?
So again, since CLOCK_MONOTONIC and CLOCK_REALTIME are constaly being
frequency adjusted, it might be best to construct this delta in the
following way.
Add counter_to_rawmono64(), which should be able to safely calculate
the corresponding CLOCK_MONOTONIC_RAW time from any given cycle value.
Use getnstime_raw_and_real() to get a immediate snapshot of current
MONOTONIC_RAW and REALTIME clocks.
Then calculate the delta between the snapshotted counter raw time, and
the current raw time. Then apply that offset to the current realtime.
The larger the raw-time delta, the larger the possible realtime error.
But I think that will be as good as it gets.
This should simplify the interfaces you're adding to the timekeeping core.
thanks
-john
--
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