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 <g...@xen0n.name>
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?
Thanks,
Tiezhu
[1]
https://patchwork.kernel.org/project/linux-mips/patch/20200923075845.360974-2-...@xen0n.name/
Thanks.
- Jiaxun
Signed-off-by: Yinglu Yang <yangyin...@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtie...@loongson.cn>
---
