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;
AI-Spam-Status: Not processed
Date:   Fri, 13 Nov 2020 16:24:37 +0800
From:   Jiaxun Yang <jiaxun.yang@flygoat.com>
To:     Tiezhu Yang <yangtiezhu@loongson.cn>,
        Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
        Huacai Chen <chenhc@lemote.com>
CC:     linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
        Xuefeng Li <lixuefeng@loongson.cn>,
        Yinglu Yang <yangyinglu@loongson.cn>,
        WANG Xuerui <git@xen0n.name>
Subject: Re: [PATCH] MIPS: Loongson64: Add read_persistent_clock64()
User-Agent: K-9 Mail for Android
In-Reply-To: <bb0fbd42-07b2-397b-1a63-f7817a1a9d4b@loongson.cn>
References: <1605169793-10481-1-git-send-email-yangtiezhu@loongson.cn> <8d6ebfe2-e300-3f38-6316-196cba947d36@flygoat.com> <b84fe88b-7527-e88c-1efd-739f6d846518@flygoat.com> <6f0a7a43-4eac-65d8-61ff-778dc13f925c@loongson.cn> <1e01b317-b315-443c-a53b-db360ea17254@flygoat.com> <bb0fbd42-07b2-397b-1a63-f7817a1a9d4b@loongson.cn>
Message-ID: <C36B1D2E-5642-4399-9165-052EC1070D57@flygoat.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


=E4=BA=8E 2020=E5=B9=B411=E6=9C=8813=E6=97=A5 GMT+08:00 =E4=B8=8A=E5=8D=88=
11:41:01, Tiezhu Yang <yangtiezhu@loongson=2Ecn> =E5=86=99=E5=88=B0:
>On 11/13/2020 10:21 AM, Jiaxun Yang wrote:
>>
>>
>> =E5=9C=A8 2020/11/12 20:03, Tiezhu Yang =E5=86=99=E9=81=93:
>>> On 11/12/2020 06:09 PM, Jiaxun Yang wrote:
>>>>
>>>>
>>>> =E5=9C=A8 2020/11/12 18:04, Jiaxun Yang =E5=86=99=E9=81=93:
>>>>> Hi Tiezhu,
>>>>>
>>>>> =E5=9C=A8 2020/11/12 16:29, Tiezhu Yang =E5=86=99=E9=81=93:
>>>>>> Add read_persistent_clock64() to read the time from the battery=20
>>>>>> backed
>>>>>> persistent clock=2E With this patch, we can fix the wrong time issu=
e=20
>>>>>> due
>>>>>> to the system clock is not consistent with hardware clock after=20
>>>>>> resume
>>>>>> from sleep state S3 (suspend to RAM), at the same time, the system=
=20
>>>>>> time
>>>>>> can be right instead of "Thu Jan 1 08:00:00 CST 1970" without rtc=
=20
>>>>>> driver=2E
>>>>>>
>>>>>> 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=
=20
>>>>> probed via
>>>>> devicetree=2E
>>>>>
>>>>> Please check if you can deal with that inside RTC framework, or=20
>>>>> make it as
>>>>> a part of RTC driver (e=2Eg=2E set up a callback)=2E
>>>>>
>>>>> Also you should submit RTC driver at first if you intend to=20
>>>>> complete LS7A support=2E
>>>>
>>>> Oops,
>>>> Just dig it deeper, I guess simply select RTC_HCTOSYS would solve=20
>>>> the issue=2E
>>>> We're trying very hard to decouple all the drivers and conponents,
>>>> DeviceTree for all!
>>>
>>> +cc WANG Xuerui <git@xen0n=2Ename>
>>>
>>> Hi Jiaxun,
>>>
>>> Thanks for your reply=2E
>>>
>>> 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=2E
>>>
>>> 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=
=2E
>
>Yes, I agree=2E
>
>> 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=2E
>
>So I think read_persistent_clock64() looks like a backup function=2E

Still can't understand why this kind of backup is necessary=2E
If you wish to help please help with the RTC driver=2E

Duplication is not the way we work=2E
Please try to learn common solutions, all others are doing so=2E

Thanks

- Jiaxun


>
>>
>> Thanks
>>
>> - Jiaxun
>>
>>>
>>> Thanks,
>>> Tiezhu
>>>
>>> [1]=20
>>> https://patchwork=2Ekernel=2Eorg/project/linux-mips/patch/202009230758=
45=2E360974-2-git@xen0n=2Ename/
>>>
>>>>
>>>>>
>>>>> Thanks=2E
>>>>>
>>>>> - Jiaxun
>>>>>
>>>>>>
>>>>>> Signed-off-by: Yinglu Yang <yangyinglu@loongson=2Ecn>
>>>>>> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson=2Ecn>
>>>>>> ---
>>>>>>