Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1204538pxb; Tue, 17 Aug 2021 06:23:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzp2YUmoaNCfyfyxkbCce0zjaN/Hf4x7JWiiFu2PjseQc0z6U32mGTsWY+GQ/+Zwv5+qa0+ X-Received: by 2002:a02:7094:: with SMTP id f142mr2929863jac.19.1629206604371; Tue, 17 Aug 2021 06:23:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629206604; cv=none; d=google.com; s=arc-20160816; b=lqsIByMw85yp1MLDvuiRE9UMPaiEZrNKmY8QcagMxrLvBWnpsUj/AGwQOo9JzxKYkF 43KMhwqqO0AFe4V+gdUnb/MIQ3O6sHXoq19SBVGmrGM1LDQUGXa0oQDT6o2hzlPLjpw1 JbSG6jbcTQyc6Iqnt+pci2lwHV20lwYLvDCg0HGFHQqZPjKgy3Ycvi6w65F3LALHvLhZ ROWDYVnNAMRLR60j5EqWh8cTLl+WoYu2jt08r4X1ngXE4oPL7CFQ41FFsAuB8Sd9+S7o EZMJWJoe4nlcCqBUiFoXhHkTy7rJcGVmYzavdEvQ6ZXkjiiWfaqFzwZVfhPGugEjEgot d6YQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=flN0Gz536/l7218THlUC/oFAza521QnDW7PWK8dQh4M=; b=fKJdwe0kilVe3/iakiPgifMHkThc8tawsHPGMsO3gJ3UWkj+ODclFgav8ytaE/sHoq +H0XWI8T6F8REcJwmYTAoGO1JQgQ5XMgaxHE6UtjR02bTwLfZpVX6gDfPXkDoKLo1nFK gtZd9SG6FVszYAUNSvmldkEqfIU3sXNQcRtCuAJKPI2Px+W4NOJYrTERgH1cpy85QYLi FG6gfOvznYdAdDyr64iHbmrFStkslNWx0knoe67h2wjJYcbiME/ilRpGcteMkHOIwagt PXa3qR0IwiTr1iMwbSd63Y+HHt4FYf8q6A5twBwunyB1zp2dMqiuUVmQJfHD0yLcTA3b BAUA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a21si2417143iot.52.2021.08.17.06.23.12; Tue, 17 Aug 2021 06:23:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237475AbhHQNVl (ORCPT + 99 others); Tue, 17 Aug 2021 09:21:41 -0400 Received: from relay12.mail.gandi.net ([217.70.178.232]:51071 "EHLO relay12.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235267AbhHQNVj (ORCPT ); Tue, 17 Aug 2021 09:21:39 -0400 Received: (Authenticated sender: alexandre.belloni@bootlin.com) by relay12.mail.gandi.net (Postfix) with ESMTPSA id 53CB8200004; Tue, 17 Aug 2021 13:21:03 +0000 (UTC) Date: Tue, 17 Aug 2021 15:21:03 +0200 From: Alexandre Belloni To: tonywwang-oc@zhaoxin.com Cc: a.zummo@towertech.it, linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org, TimGuo-oc@zhaoxin.com, CooperYan@zhaoxin.com, QiyuanWang@zhaoxin.com, HerryYang@zhaoxin.com, CobeChen@zhaoxin.com, YanchenSun@zhaoxin.com Subject: Re: [PATCH] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs Message-ID: References: <1629121638-3246-1-git-send-email-TonyWWang-oc@zhaoxin.com> <7EA395FF-EB66-4274-9EDE-EC28450A0259@zhaoxin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7EA395FF-EB66-4274-9EDE-EC28450A0259@zhaoxin.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/08/2021 19:09:28+0800, tonywwang-oc@zhaoxin.com wrote: > > > On August 16, 2021 8:36:48 PM GMT+08:00, Alexandre Belloni wrote: > >On 16/08/2021 18:03:13+0800, Tony W Wang-oc wrote: > >> > >> On 16/08/2021 16:24, Alexandre Belloni wrote: > >> > Hello, > >> > > >> > On 16/08/2021 21:47:18+0800, Tony W Wang-oc wrote: > >> >> When the RTC divider is changed from reset to an operating time > >base, > >> >> the first update cycle should be 500ms later. But on some Zhaoxin > >SOCs, > >> >> this first update cycle is one second later. > >> >> > >> >> So set RTC time on these Zhaoxin SOCs will causing 500ms delay. > >> >> > >> > > >> > Can you explain what is the relationship between writing the > >divider and > >> > the 500ms delay? > >> >> Isn't the issue that you are using systohc and set_offset_nsec is > >set to > >> > NSEC_PER_SEC / 2 ? > >> > > >> No. > >> When using #hwclock -s to set RTC time and set_offset_nsec is > >> NSEC_PER_SEC / 2, the function mc146818_set_time() requires the first > >> update cycle after RTC divider be changed from reset to an operating > >> mode is 500ms as the MC146818A spec specified. But on some Zhaoxin > >SOCs, > >> the first update cycle of RTC is one second later after RTC divider > >be > >> changed from reset to an operating mode. So the first update cycle > >after > >> RTC divider be changed from reset to an operation mode on These SOCs > >> will causing 500ms delay with current mc146818_set_time() > >implementation. > >> > > > >What happens with hwclock --delay=0 -s ? > > With "hwclock --delay=0 -s" still have this problem. Actually, this 500ms delay caused by writing the RTC time on these Zhaoxin SOCs. > As I've tested, with hwclock --delay=0 -w can fix it too. > Both -s and -w end up calling set_hardware_clock_exact() so both should end up with the correct time. If this is not the case, then hwclock needs to be fixed. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com