On 18/10/2017 at 23:56:38 +0200, Pavel Machek wrote:
> > Some RTCs will tell you when they lost time/time accuracy and this
> > should be properly reported by the driver. If not, this has to be
> > implemented.
>
> How is it reported to the userspace?
>
Userspace will get -EINVAL when using the
On Wed 2017-10-18 23:26:45, Alexandre Belloni wrote:
> On 18/10/2017 at 23:08:28 +0200, Pavel Machek wrote:
> > On Wed 2017-10-18 21:34:49, Alan Cox wrote:
> > > > And even the boring ones have pretty imprecise RTCs... For example
> > > > Nokia N9.
> > > > I only power it up from time to time, I b
On 18/10/2017 at 23:08:28 +0200, Pavel Machek wrote:
> On Wed 2017-10-18 21:34:49, Alan Cox wrote:
> > > And even the boring ones have pretty imprecise RTCs... For example Nokia
> > > N9.
> > > I only power it up from time to time, I believe it drifts something like
> > > minute per month... For n
On Wed 2017-10-18 21:34:49, Alan Cox wrote:
> > And even the boring ones have pretty imprecise RTCs... For example Nokia N9.
> > I only power it up from time to time, I believe it drifts something like
> > minute per month... For normal use with SIM card, it can probably correct
> > from GSM networ
> And even the boring ones have pretty imprecise RTCs... For example Nokia N9.
> I only power it up from time to time, I believe it drifts something like
> minute per month... For normal use with SIM card, it can probably correct
> from GSM network if you happen to have a cell phone signal, but...
H!
> We have been developing a device that has very a very aggressive power
> policy, doing suspend/resume cycles a few times a minute ("echo mem >
> /sys/power/state"). In doing so, we found that the system time
> experiences a lot of jitter (compared to, say, an NTP server). It was
> not uncommo
On Thu, 5 Oct 2017, Thomas Gleixner wrote:
> On Thu, 5 Oct 2017, Gabriel Beddingfield wrote:
>
> > Hi Thomas,
> >
> > On Thu, Oct 5, 2017 at 11:01 AM, Thomas Gleixner wrote:
> > >> > Which SoC/clocksource driver are you talking about?
> > >>
> > >> NXP i.MX 6SoloX
> > >> drivers/clocksource/time
Gabriel,
On Thu, 5 Oct 2017, Gabriel Beddingfield wrote:
> Hi John,
>
> On Wed, Oct 4, 2017 at 5:16 PM, John Stultz wrote:
> >> Please let me know what you think -- and what the right approach for
> >> solving this would be.
> >
> > So I suspect the best solution for you here is: provide some
>
On Thu, Oct 5, 2017 at 2:04 PM, Thomas Gleixner wrote:
>> > So that clocksource driver looks correct. Do you have an idea in which
>> > context this time jump happens? Does it happen when you exercise your high
>> > frequency suspend/resume dance or is that happening just when you let the
>> > mac
On Thu, 5 Oct 2017, Gabriel Beddingfield wrote:
> Hi Thomas,
>
> On Thu, Oct 5, 2017 at 11:01 AM, Thomas Gleixner wrote:
> >> > Which SoC/clocksource driver are you talking about?
> >>
> >> NXP i.MX 6SoloX
> >> drivers/clocksource/timer-imx-gpt.c
> >
> > So that clocksource driver looks correct.
Hi Thomas,
On Thu, Oct 5, 2017 at 11:01 AM, Thomas Gleixner wrote:
>> > Which SoC/clocksource driver are you talking about?
>>
>> NXP i.MX 6SoloX
>> drivers/clocksource/timer-imx-gpt.c
>
> So that clocksource driver looks correct. Do you have an idea in which
> context this time jump happens? Doe
Hi John,
On Wed, Oct 4, 2017 at 5:16 PM, John Stultz wrote:
>> Please let me know what you think -- and what the right approach for
>> solving this would be.
>
> So I suspect the best solution for you here is: provide some
> infrastructure so clocksources that set CLOCK_SOURCE_SUSPEND_NONSTOP
> w
Gabriel,
On Thu, 5 Oct 2017, Gabriel Beddingfield wrote:
> On Thu, Oct 5, 2017 at 4:01 AM, Thomas Gleixner wrote:
> > i.e. the 32bit rollover of the clocksource. So, if the clocksource->read()
> > function returns a full 64bit counter value, then it must have protection
> > against observing the
Hi Thomas,
On Thu, Oct 5, 2017 at 4:01 AM, Thomas Gleixner wrote:
> > The SoC we use backs the monotonic clock (sched_clock_register()) with a
>
> Again. monotonic clock != sched clock. The clocksource which feeds the
> monotonic timekeeper clock is registered via clocksource_register() & al.
So
Hi John,
First, my apologies for calling it a "hack." I just went back and looked at the
commit history and this is first-class stuff... and you explained it very well
(including the NTP interaction) in the commit message. I'm pretty sure I
read this before, but I reckon most of it went over my he
On Thu, 5 Oct 2017, Thomas Gleixner wrote:
> On Wed, 4 Oct 2017, John Stultz wrote:
> > So, on resume when we call __timekeeping_inject_sleeptime(), that uses
> > the TK_CLEAR_NTP which clears the NTP state (sets STA_UNSYNC, etc) .
> > I'm not sure how else we can notify userspace. It may be that
On Wed, Oct 04, 2017 at 05:16:31PM -0700, John Stultz wrote:
> On Wed, Oct 4, 2017 at 9:11 AM, Gabriel Beddingfield
> wrote:
> > We found that the problem is an interaction between the NTP code and
> > what I call the "delta_delta hack." (see [1] and [2]) This code
> > allocates a static variable
On Wed, 4 Oct 2017, John Stultz wrote:
> On Wed, Oct 4, 2017 at 9:11 AM, Gabriel Beddingfield
> wrote:
> > TL;DR: the "delta_delta" hack[1 and 2] in kernel/time/timekeeping.c
> > and drivers/rtc/class.c undermines the NTP system. It's not
> > appropriate to use if sub-second precision is availabl
On Wed, 4 Oct 2017, Gabriel Beddingfield wrote:
> On Wed, Oct 4, 2017 at 11:22 AM, Thomas Gleixner wrote:
> Long story short: you can't always have your low-power clock be your
> monotonic/sched clock.
sched_clock and the clocksource for timekeeping, which feeds monotonic are
not required to be t
On Wed, Oct 4, 2017 at 4:10 PM, Gabriel Beddingfield wrote:
> Hi Thomas,
>
> Thanks for your reply!
>
> On Wed, Oct 4, 2017 at 11:22 AM, Thomas Gleixner wrote:
>> Calling things a hack which might have been thought out carefully does not
>> make people more receptive.
>
> My bad... sorry! You're
On Wed, Oct 4, 2017 at 9:11 AM, Gabriel Beddingfield wrote:
> TL;DR: the "delta_delta" hack[1 and 2] in kernel/time/timekeeping.c
> and drivers/rtc/class.c undermines the NTP system. It's not
> appropriate to use if sub-second precision is available. I've attached
> a patch to resolve this... plea
Hi Thomas,
Thanks for your reply!
On Wed, Oct 4, 2017 at 11:22 AM, Thomas Gleixner wrote:
> Calling things a hack which might have been thought out carefully does not
> make people more receptive.
My bad... sorry! You're right. The code in question is better than a "hack."
>> Many ARM systems
Gabriel,
On Wed, 4 Oct 2017, Gabriel Beddingfield wrote:
thanks for bringing this up. Let's see where this goes.
Disclaimer: I did not bother to look at the patch yet because:
1) It's an attachment and I'm too lazy to open and convert it to inline
for reply. Sending patches inline is the
23 matches
Mail list logo
