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:     Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Cc:     linux-kernel@vger.kernel.org,
        Alessandro Zummo <a.zummo@towertech.it>,
        Alexandre Belloni <alexandre.belloni@free-electrons.com>,
        rtc-linux@googlegroups.com, util-linux@vger.kernel.org
References: <30ae185f-28c9-54f1-2884-4ee7801b130e@gmail.com>
 <34f50661-85f5-eb46-3ff7-45f0c2bb5960@prevas.dk>
From:   Igor Plyatov <plyatov@gmail.com>
Message-ID: <c91e0079-c31f-715d-bb2e-648af34565d7@gmail.com>
Date:   Mon, 19 Feb 2018 12:16:04 +0300
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: <34f50661-85f5-eb46-3ff7-45f0c2bb5960@prevas.dk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Dear Rasmus,

thank you very much for explanation!

I have set "RTC_SET_DELAY_SECS = 0.0" in hwclock.c and got acceptable 
result.

It wonder why such critical function does not implemented on kernel 
level in RTC driver?
It is very strange to rely on specific HW in user space SW.

Best wishes.
--
Igor Plyatov

> 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