Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp118043pxb; Tue, 17 Aug 2021 20:58:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyPR1HABc0o70WswU89QDibzVYLnIW8Kf45vk3NDo/YSWvGCd/wk2REHB5/jfvDJZGOPWEx X-Received: by 2002:a17:906:919:: with SMTP id i25mr7272694ejd.171.1629259095873; Tue, 17 Aug 2021 20:58:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629259095; cv=none; d=google.com; s=arc-20160816; b=zbzFgMOCiQSeUJxYvuEslzv8dIk7tYdUQ4dOhbi8s3f6rkH316sE7n7ISdC/kSTSk4 2npusZ4f+r4DJls5Zt4wtQaotakH7K+iXzcnEM2mjTK6GabYgxhCGFXkVmzlc6BYM23f FQGGwSezQw42LQRaPbyr+mL+oZsljEa44U617SbvWETqUUYGvKKmrC+mtFHK3ST9xE16 mVhtqMcWFVSh61rwv1IhGBA+0kIiw0Kh4t7g1jWz3fufrLzRRZgIt5tSoZkdc7ScSSWG x2aampfMACpupZ9Nsbvybly0DRX0QGRZwrSXikGtRGKXEauw7iB8GcqhoSOBT5yOSN97 PEEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:references:in-reply-to:user-agent:subject:cc:to:from :date; bh=w/iviBiQwIsxRdIbRs98KpbPC5C2IEZne30XUVTQ91c=; b=TaupMt9AIBDSnfImFUwcRowAM99XxAhGx1oM3j68qa/T34TRYJQEUbS1KLNVrrkVdP ZkXMFbE/eU56LPGL7POiGRN+S9vZklibs65HXVZJd5nd382U1MX9CrnuZtWFbf9mz8BF AQ8lO9robVbEJGlVTTLa2Qg5pb+jraPiN+ZJEzjfksBauFtWSrOUwnw/EZF6yidB67sZ mB2bzGt4iv5YL9va1Oqzkw8MCZc26WnSUx3XXfKtZ3ekYXAOVyZwSf6jdMaasCUM6xYE ggvUl9AgXVENa32jUxJJIildfm2MkrX9WRar/qcpuvOsAPTw8zIje76DjHj5AMxTDgK5 cPcg== 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 u24si3926616ejt.108.2021.08.17.20.57.53; Tue, 17 Aug 2021 20:58:15 -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 S236690AbhHRDzH (ORCPT + 99 others); Tue, 17 Aug 2021 23:55:07 -0400 Received: from ZXSHCAS1.zhaoxin.com ([203.148.12.81]:17416 "EHLO ZXSHCAS1.zhaoxin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236105AbhHRDzE (ORCPT ); Tue, 17 Aug 2021 23:55:04 -0400 Received: from zxbjmbx1.zhaoxin.com (10.29.252.163) by ZXSHCAS1.zhaoxin.com (10.28.252.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Wed, 18 Aug 2021 11:54:27 +0800 Received: from [10.122.79.217] (221.11.61.182) by zxbjmbx1.zhaoxin.com (10.29.252.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Wed, 18 Aug 2021 11:54:25 +0800 Date: Wed, 18 Aug 2021 11:54:20 +0800 From: To: Alexandre Belloni CC: , , , , , , , , Subject: Re: [PATCH] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs User-Agent: K-9 Mail for Android In-Reply-To: References: <1629121638-3246-1-git-send-email-TonyWWang-oc@zhaoxin.com> <7EA395FF-EB66-4274-9EDE-EC28450A0259@zhaoxin.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [221.11.61.182] X-ClientProxiedBy: ZXSHCAS2.zhaoxin.com (10.28.252.162) To zxbjmbx1.zhaoxin.com (10.29.252.163) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On August 17, 2021 9:21:03 PM GMT+08:00, Alexandre Belloni wrote: >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. I checked Util-linux-2.37.2, hwclock -w will call set_hardware_clock_exact() and hwclock -s will not. Please correct me if I'm wrong. Sincerely TonyWWang-oc