Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp857964pxb; Thu, 12 Nov 2020 19:42:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJxevBDJpAkitA+gzNgFaYWB9joEquWs2CG0Iag0M4t2xxTT6yqlCFhWKJczVXUIu60W1UHo X-Received: by 2002:a17:906:5e45:: with SMTP id b5mr150014eju.46.1605238977523; Thu, 12 Nov 2020 19:42:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605238977; cv=none; d=google.com; s=arc-20160816; b=eKDFy2Y5zAocINACL23S0QL08vn07KTQezXbKQm/D8AUgpYHmiF1FRDzPGmIOi3IWr YfhHvYRWaqieH8jSrOQPP6QBmoLNrtNMEqVGOm+EJ6m1CFW1ssRZXBfpFg8taz97z424 dXwLo1gFq8v3QRjKZkbbqBFLxvfQUbXnNKIsDGBPvxDTnMDkl+kL3276SB5w4dSTnWkI v5vYVwcpH/oyhoeLdiIG8gw24Bap4AMtRogj/+Jzh5VG9j2zpdldI6/9Dp2qUW3FPUs/ ELz7IS8ETtH9H5Rt+u8ejfzHXcYd5s5wvQBYoBf/3vFMW9o0CmwZobASL9HNJle3dww/ ry/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=trM8z+Ic6asLkFFzUXUaqd6yjbT/6ObeZd25/ZW+eCs=; b=cG/+Z9IIWoMqEQXvFG7s/+CKZdzArAEYq4fbGk/iS/rE1+iF1AmoiGUktoVpQ+mQx2 yAk41+1p3RVvM4zWEYS1fjlXHOFzZWxFaRw6Y4YhlKmoYp80E+nMCXi8UygABEKg8MCT iAYhFZeUKJ+zATl7IQtoKnfssGjn54sA0EgLds6VTqZniDH6b4gCDPSk3uh4gYQuEtOM MLnlDxLXJPrLupGCvaGS4FTc3ZGSydri+8GyyqJJMy7V4TSAP2RQAAuecNUL3G50kMFG zdTbTYyjJcZWo31L3iENXwaw9Nfu646yiCVDkmPoj70/4W+eZmoLE6Hfk+tiSFozbqLl XyOQ== 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 jz23si4589462ejb.221.2020.11.12.19.42.35; Thu, 12 Nov 2020 19:42:57 -0800 (PST) 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 S1726202AbgKMDlH (ORCPT + 99 others); Thu, 12 Nov 2020 22:41:07 -0500 Received: from mail.loongson.cn ([114.242.206.163]:60740 "EHLO loongson.cn" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726011AbgKMDlH (ORCPT ); Thu, 12 Nov 2020 22:41:07 -0500 Received: from [10.130.0.80] (unknown [113.200.148.30]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9AxOtBNAK5fkjUNAA--.19164S3; Fri, 13 Nov 2020 11:41:02 +0800 (CST) Subject: Re: [PATCH] MIPS: Loongson64: Add read_persistent_clock64() To: Jiaxun Yang , Thomas Bogendoerfer , Huacai Chen References: <1605169793-10481-1-git-send-email-yangtiezhu@loongson.cn> <8d6ebfe2-e300-3f38-6316-196cba947d36@flygoat.com> <6f0a7a43-4eac-65d8-61ff-778dc13f925c@loongson.cn> <1e01b317-b315-443c-a53b-db360ea17254@flygoat.com> Cc: linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, Xuefeng Li , Yinglu Yang , WANG Xuerui From: Tiezhu Yang Message-ID: Date: Fri, 13 Nov 2020 11:41:01 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1e01b317-b315-443c-a53b-db360ea17254@flygoat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf9AxOtBNAK5fkjUNAA--.19164S3 X-Coremail-Antispam: 1UD129KBjvJXoWxWFWDGrWxXrWUWF4fXr1kZrb_yoW5Aw1rp3 y8Aay5Kr4UXryUuw42yrn8CFyjg3y3GF4jq3s8J345Zryqvr13GrykC3yj9F9rXr1fCw4v vrW5t3sxWa1UAFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvl14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26r4j6ryUM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4j 6r4UJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r xl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj 6xIIjxv20xvE14v26r106r15McIj6I8E87Iv67AKxVW8JVWxJwAm72CE4IkC6x0Yz7v_Jr 0_Gr1lF7xvr2IY64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7Mxk0xIA0c2IEe2xFo4CE bIxvr21lc2xSY4AK67AK6r48MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r 4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF 67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2I x0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY 6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvj DU0xZFpf9x0JUa0PhUUUUU= X-CM-SenderInfo: p1dqw3xlh2x3gn0dqz5rrqw2lrqou0/ Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/13/2020 10:21 AM, Jiaxun Yang wrote: > > > 在 2020/11/12 20:03, Tiezhu Yang 写道: >> On 11/12/2020 06:09 PM, Jiaxun Yang wrote: >>> >>> >>> 在 2020/11/12 18:04, Jiaxun Yang 写道: >>>> Hi Tiezhu, >>>> >>>> 在 2020/11/12 16:29, Tiezhu Yang 写道: >>>>> Add read_persistent_clock64() to read the time from the battery >>>>> backed >>>>> persistent clock. With this patch, we can fix the wrong time issue >>>>> due >>>>> to the system clock is not consistent with hardware clock after >>>>> resume >>>>> from sleep state S3 (suspend to RAM), at the same time, the system >>>>> time >>>>> can be right instead of "Thu Jan 1 08:00:00 CST 1970" without rtc >>>>> driver. >>>>> >>>>> start_kernel() >>>>> timekeeping_init() >>>>> read_persistent_wall_and_boot_offset() >>>>> read_persistent_clock64() >>>>> >>>>> timekeeping_resume() >>>>> read_persistent_clock64() >>>>> >>>>> timekeeping_suspend() >>>>> read_persistent_clock64() >>>> >>>> It is highly discoraged to do anything with bridgetype, which isn't >>>> probed via >>>> devicetree. >>>> >>>> Please check if you can deal with that inside RTC framework, or >>>> make it as >>>> a part of RTC driver (e.g. set up a callback). >>>> >>>> Also you should submit RTC driver at first if you intend to >>>> complete LS7A support. >>> >>> Oops, >>> Just dig it deeper, I guess simply select RTC_HCTOSYS would solve >>> the issue. >>> We're trying very hard to decouple all the drivers and conponents, >>> DeviceTree for all! >> >> +cc WANG Xuerui >> >> Hi Jiaxun, >> >> Thanks for your reply. >> >> Xuerui has already submitted the patch of LS7A rtc driver [1], >> but not yet been merged into the mainline kernel, I discussed >> with him early today. >> >> Do you mean that read_persistent_clock64() can call the function >> like rtc_read_time() defined in rtc driver? > > I do think select RTC_HCTOSYS after getting RTC driver applied can help. Yes, I agree. > What's your point to have read_persistent_clock64 for Loongson64? (1) Currently, the LS7A RTC driver has not been merged into the mainline kernel, read_persistent_clock64() is useful in the following call path: start_kernel() timekeeping_init() read_persistent_wall_and_boot_offset() read_persistent_clock64() (2) When the LS7A RTC driver is merged into the mainline kernel some time later, if RTC_HCTOSYS and RTC_DRV_LS2X are not set, read_persistent_clock64() is also useful unless RTC_HCTOSYS and RTC_DRV_LS2X are set by default in Kconfig instead of loongson3_defconfig. So I think read_persistent_clock64() looks like a backup function. > > Thanks > > - Jiaxun > >> >> Thanks, >> Tiezhu >> >> [1] >> https://patchwork.kernel.org/project/linux-mips/patch/20200923075845.360974-2-git@xen0n.name/ >> >>> >>>> >>>> Thanks. >>>> >>>> - Jiaxun >>>> >>>>> >>>>> Signed-off-by: Yinglu Yang >>>>> Signed-off-by: Tiezhu Yang >>>>> --- >>>>>