Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: 500 ms delay in time saved into RTC
To:     Igor Plyatov <plyatov@gmail.com>, <linux-kernel@vger.kernel.org>,
        Alessandro Zummo <a.zummo@towertech.it>,
        Alexandre Belloni <alexandre.belloni@free-electrons.com>,
        <rtc-linux@googlegroups.com>
References: <30ae185f-28c9-54f1-2884-4ee7801b130e@gmail.com>
From:   Rasmus Villemoes <rasmus.villemoes@prevas.dk>
CC:     <util-linux@vger.kernel.org>
Message-ID: <34f50661-85f5-eb46-3ff7-45f0c2bb5960@prevas.dk>
Date:   Mon, 19 Feb 2018 08:11:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <30ae185f-28c9-54f1-2884-4ee7801b130e@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 2018-02-19 07:40, Igor Plyatov wrote:
> Hi!
> 
> I have board based on AT91SAM9G20 (ARM926EJ-S CPU), Linux-4.9.36 kernel
> and RTC chip DS1340 (rtc-ds1307.c driver).
> 
> RTC chip connected by means of I2C-bus, without HW IRQ line connected.
> 
> Kernel configured to not use embedded functions for time getting at
> startup and saving at shutdown:
> CONFIG_RTC_CLASS=y
> # CONFIG_RTC_HCTOSYS is not set
> # CONFIG_RTC_SYSTOHC is not set
> CONFIG_RTC_INTF_DEV_UIE_EMUL=y
> CONFIG_RTC_DRV_DS1307=y
> CONFIG_RTC_DRV_DS1307_CENTURY=y
> 
> The hwclock utility is from util-linux-2.29.1.
> 
> The OS does not have external time synchronization sources like NTP, PTP
> or else.
> 
> Generally I need to achieve error within +-20 ms when RTC's time copied
> into OS or back from OS into RTC.
> 
> I have made measurements during startup and shutdown of OS and have
> found 500 ms delay introduced into RTC's time, when "hwclock --utc
> --systohc" executed.
> 
> Logical analyzer show to me I2C-bus transactions and PPS signal
> generated by Linux. And I see 500 ms delay is between of rising edge of
> PPS signal (start of OS second) and moment when time saved into RTC.
> 
> Please explain, why this happens? Is this due to absence of IRQ line for
> RTC or due to a bug in the hwclock, or kernel bug or I have missed
> something else?

cc += util-linux@vger.kernel.org

It's because util-linux's hwclock still assumes the world is x86. See
this comment in the util-linux source code:

        /*
         * The Hardware Clock can only be set to any integer time plus one
         * half second.  The integer time is required because there is no
         * interface to set or get a fractional second.  The additional half
         * second is because the Hardware Clock updates to the following
         * second precisely 500 ms (not 1 second!) after you release the
         * divider reset (after setting the new time) - see description of
         * DV2, DV1, DV0 in Register A in the MC146818A data sheet (and note

So if hwclock is asked to --systohc at time 01:02:03.x, it waits until
the time is 01:02:03.5 to set the rtc to 01:02:03, or if that has
already passed, waits until  01:02:04.5 and sets it to 01:02:04.

On our ARM BSP we patch util-linux to have the "implicit fractional
part" configurable, and trying to upstream something like that has been
on my todo-list for quite a while. See

https://raw.githubusercontent.com/oe-lite/base/master/recipes/util-linux/util-linux-2.29/hwclock-tweak-delay.patch

for the patch we currently use (on top of that, we change the 0.5
initializer to 0.0 to avoid having to always pass the --delay argument).
Incidentally, it seems we're on the same util-linux version, so you
should be able to try out that patch and see if it works for you.

Rasmus