[PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st
diff mbox series

Message ID 1450220569-10670-1-git-send-email-jwerner@chromium.org
State New, archived
Headers show
Series
  • [PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st
Related show

Commit Message

Julius Werner Dec. 15, 2015, 11:02 p.m. UTC
In A.D. 1582 Pope Gregory XIII found that the existing Julian calendar
insufficiently represented reality, and changed the rules about
calculating leap years to account for this. Similarly, in A.D. 2013
Rockchip hardware engineers found that the new Gregorian calendar still
contained flaws, and that the month of November should be counted up to
31 days instead. Unfortunately it takes a long time for calendar changes
to gain widespread adoption, and just like more than 300 years went by
before the last Protestant nation implemented Greg's proposal, we will
have to wait a while until all religions and operating system kernels
acknowledge the inherent advantages of the Rockchip system. Until then
we need to translate dates read from (and written to) Rockchip hardware
back to the Gregorian format.

This patch works by defining Jan 1st, 2016 as the arbitrary anchor date
on which Rockchip and Gregorian calendars are in sync. From that we can
translate arbitrary later dates back and forth by counting the number
of November/December transitons since the anchor date to determine the
offset between the calendars. We choose this method (rather than trying
to regularly "correct" the date stored in hardware) since it's the only
way to ensure perfect time-keeping even if the system may be shut down
for an unknown number of years. The drawback is that other software
reading the same hardware (e.g. mainboard firmware) must use the same
translation convention (including the same anchor date) to be able to
read and write correct timestamps from/to the RTC.

Signed-off-by: Julius Werner <jwerner@chromium.org>
---
 drivers/rtc/rtc-rk808.c | 48 ++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 44 insertions(+), 4 deletions(-)

Comments

Julius Werner Dec. 15, 2015, 11:14 p.m. UTC | #1
Okay, wrote up and tested the anchor date version. I think once you
get over the initial weirdness of the approach this one is really much
cleaner and safer.

I tested this with the older rtc_tm_to_time() API and only ported it
over to rtc_tm_to_time64() for submission, since my 3.14 kernel didn't
have that yet... but it still compiles fine and the change was very
trivial so I'm confident that it should work.

I also did a big manual test for my conversion functions where I just
threw a whole bunch of dates at them, results below for reference:

[    1.431216] jwerner: Testing translation functions:
[    1.431221] 2015-01-01 to_rockchip: 2015-01-02 to_gregorian: 2014-12-31
[    1.431224] 2015-10-30 to_rockchip: 2015-10-31 to_gregorian: 2015-10-29
[    1.431228] 2015-10-31 to_rockchip: 2015-11-01 to_gregorian: 2015-10-30
[    1.431231] 2015-11-01 to_rockchip: 2015-11-02 to_gregorian: 2015-10-31
[    1.431235] 2015-11-27 to_rockchip: 2015-11-28 to_gregorian: 2015-11-26
[    1.431238] 2015-11-28 to_rockchip: 2015-11-29 to_gregorian: 2015-11-27
[    1.431242] 2015-11-29 to_rockchip: 2015-11-30 to_gregorian: 2015-11-28
[    1.431245] 2015-11-30 to_rockchip: 2015-12-01 to_gregorian: 2015-11-29

This one is actually a bug... to_rockchip should be 2015-11-31 here.
It happens because the "compensate if we went back over" part of
gregorian_to_rockchip() only checks whether we went over *backwards*,
which happens if the date is after the anchor date. If it was before
we can go back over forwards and I didn't bother to handle that case.
I think this is fine since all affected dates lie in the past and
there's no real-world use case where you'd ever need them to work
again.

[    1.431249] 2015-11-31 to_rockchip: 2015-12-02 to_gregorian: 2015-11-30
[    1.431252] 2015-12-01 to_rockchip: 2015-12-01 to_gregorian: 2015-12-01
[    1.431256] 2015-12-02 to_rockchip: 2015-12-02 to_gregorian: 2015-12-02
[    1.431259] 2015-12-03 to_rockchip: 2015-12-03 to_gregorian: 2015-12-03
[    1.431262] 2015-12-04 to_rockchip: 2015-12-04 to_gregorian: 2015-12-04
[    1.431266] 2015-12-05 to_rockchip: 2015-12-05 to_gregorian: 2015-12-05
[    1.431269] 2015-12-30 to_rockchip: 2015-12-30 to_gregorian: 2015-12-30
[    1.431273] 2015-12-31 to_rockchip: 2015-12-31 to_gregorian: 2015-12-31
[    1.431276] 2016-01-01 to_rockchip: 2016-01-01 to_gregorian: 2016-01-01
[    1.431279] 2016-10-30 to_rockchip: 2016-10-30 to_gregorian: 2016-10-30
[    1.431283] 2016-10-31 to_rockchip: 2016-10-31 to_gregorian: 2016-10-31
[    1.431287] 2016-11-01 to_rockchip: 2016-11-01 to_gregorian: 2016-11-01
[    1.431291] 2016-11-27 to_rockchip: 2016-11-27 to_gregorian: 2016-11-27
[    1.431295] 2016-11-28 to_rockchip: 2016-11-28 to_gregorian: 2016-11-28
[    1.431299] 2016-11-29 to_rockchip: 2016-11-29 to_gregorian: 2016-11-29
[    1.431302] 2016-11-30 to_rockchip: 2016-11-30 to_gregorian: 2016-11-30
[    1.431306] 2016-11-31 to_rockchip: 2016-12-01 to_gregorian: 2016-12-01
[    1.431310] 2016-12-01 to_rockchip: 2016-11-31 to_gregorian: 2016-12-02
[    1.431313] 2016-12-02 to_rockchip: 2016-12-01 to_gregorian: 2016-12-03
[    1.431317] 2016-12-03 to_rockchip: 2016-12-02 to_gregorian: 2016-12-04
[    1.431321] 2016-12-04 to_rockchip: 2016-12-03 to_gregorian: 2016-12-05
[    1.431324] 2016-12-05 to_rockchip: 2016-12-04 to_gregorian: 2016-12-06
[    1.431328] 2016-12-30 to_rockchip: 2016-12-29 to_gregorian: 2016-12-31
[    1.431332] 2016-12-31 to_rockchip: 2016-12-30 to_gregorian: 2017-01-01
[    1.431335] 2017-01-01 to_rockchip: 2016-12-31 to_gregorian: 2017-01-02
[    1.431338] 2017-10-30 to_rockchip: 2017-10-29 to_gregorian: 2017-10-31
[    1.431342] 2017-10-31 to_rockchip: 2017-10-30 to_gregorian: 2017-11-01
[    1.431345] 2017-11-01 to_rockchip: 2017-10-31 to_gregorian: 2017-11-02
[    1.431349] 2017-11-27 to_rockchip: 2017-11-26 to_gregorian: 2017-11-28
[    1.431352] 2017-11-28 to_rockchip: 2017-11-27 to_gregorian: 2017-11-29
[    1.431356] 2017-11-29 to_rockchip: 2017-11-28 to_gregorian: 2017-11-30
[    1.431359] 2017-11-30 to_rockchip: 2017-11-29 to_gregorian: 2017-12-01
[    1.431363] 2017-11-31 to_rockchip: 2017-11-30 to_gregorian: 2017-12-02
[    1.431366] 2017-12-01 to_rockchip: 2017-11-30 to_gregorian: 2017-12-03
[    1.431369] 2017-12-02 to_rockchip: 2017-11-31 to_gregorian: 2017-12-04
[    1.431373] 2017-12-03 to_rockchip: 2017-12-01 to_gregorian: 2017-12-05
[    1.431376] 2017-12-04 to_rockchip: 2017-12-02 to_gregorian: 2017-12-06
[    1.431380] 2017-12-05 to_rockchip: 2017-12-03 to_gregorian: 2017-12-07
[    1.431383] 2017-12-30 to_rockchip: 2017-12-28 to_gregorian: 2018-01-01
[    1.431386] 2017-12-31 to_rockchip: 2017-12-29 to_gregorian: 2018-01-02
[    1.431389] 2020-01-01 to_rockchip: 2019-12-28 to_gregorian: 2020-01-05
[    1.431393] 2020-10-30 to_rockchip: 2020-10-26 to_gregorian: 2020-11-03
[    1.431397] 2020-10-31 to_rockchip: 2020-10-27 to_gregorian: 2020-11-04
[    1.431400] 2020-11-01 to_rockchip: 2020-10-28 to_gregorian: 2020-11-05
[    1.431404] 2020-11-27 to_rockchip: 2020-11-23 to_gregorian: 2020-12-01
[    1.431408] 2020-11-28 to_rockchip: 2020-11-24 to_gregorian: 2020-12-02
[    1.431411] 2020-11-29 to_rockchip: 2020-11-25 to_gregorian: 2020-12-03
[    1.431415] 2020-11-30 to_rockchip: 2020-11-26 to_gregorian: 2020-12-04
[    1.431419] 2020-11-31 to_rockchip: 2020-11-27 to_gregorian: 2020-12-05
[    1.431422] 2020-12-01 to_rockchip: 2020-11-27 to_gregorian: 2020-12-06
[    1.431426] 2020-12-02 to_rockchip: 2020-11-28 to_gregorian: 2020-12-07
[    1.431430] 2020-12-03 to_rockchip: 2020-11-29 to_gregorian: 2020-12-08
[    1.431434] 2020-12-04 to_rockchip: 2020-11-30 to_gregorian: 2020-12-09
[    1.431437] 2020-12-05 to_rockchip: 2020-11-31 to_gregorian: 2020-12-10
[    1.431441] 2020-12-30 to_rockchip: 2020-12-25 to_gregorian: 2021-01-04
[    1.431444] 2020-12-31 to_rockchip: 2020-12-26 to_gregorian: 2021-01-05
[    1.431447] 2030-01-01 to_rockchip: 2029-12-18 to_gregorian: 2030-01-15
[    1.431450] 2030-10-30 to_rockchip: 2030-10-16 to_gregorian: 2030-11-13
[    1.431454] 2030-10-31 to_rockchip: 2030-10-17 to_gregorian: 2030-11-14
[    1.431457] 2030-11-01 to_rockchip: 2030-10-18 to_gregorian: 2030-11-15
[    1.431461] 2030-11-27 to_rockchip: 2030-11-13 to_gregorian: 2030-12-11
[    1.431464] 2030-11-28 to_rockchip: 2030-11-14 to_gregorian: 2030-12-12
[    1.431468] 2030-11-29 to_rockchip: 2030-11-15 to_gregorian: 2030-12-13
[    1.431471] 2030-11-30 to_rockchip: 2030-11-16 to_gregorian: 2030-12-14
[    1.431474] 2030-11-31 to_rockchip: 2030-11-17 to_gregorian: 2030-12-15
[    1.431478] 2030-12-01 to_rockchip: 2030-11-17 to_gregorian: 2030-12-16
[    1.431481] 2030-12-02 to_rockchip: 2030-11-18 to_gregorian: 2030-12-17
[    1.431485] 2030-12-03 to_rockchip: 2030-11-19 to_gregorian: 2030-12-18
[    1.431488] 2030-12-04 to_rockchip: 2030-11-20 to_gregorian: 2030-12-19
[    1.431492] 2030-12-05 to_rockchip: 2030-11-21 to_gregorian: 2030-12-20
[    1.431495] 2030-12-30 to_rockchip: 2030-12-15 to_gregorian: 2031-01-14
[    1.431498] 2030-12-31 to_rockchip: 2030-12-16 to_gregorian: 2031-01-15
[    1.431501] 2060-01-01 to_rockchip: 2059-11-19 to_gregorian: 2060-02-14
[    1.431505] 2060-10-30 to_rockchip: 2060-09-16 to_gregorian: 2060-12-13
[    1.431509] 2060-10-31 to_rockchip: 2060-09-17 to_gregorian: 2060-12-14
[    1.431512] 2060-11-01 to_rockchip: 2060-09-18 to_gregorian: 2060-12-15
[    1.431516] 2060-11-27 to_rockchip: 2060-10-14 to_gregorian: 2061-01-10
[    1.431519] 2060-11-28 to_rockchip: 2060-10-15 to_gregorian: 2061-01-11
[    1.431522] 2060-11-29 to_rockchip: 2060-10-16 to_gregorian: 2061-01-12
[    1.431525] 2060-11-30 to_rockchip: 2060-10-17 to_gregorian: 2061-01-13
[    1.431528] 2060-11-31 to_rockchip: 2060-10-18 to_gregorian: 2061-01-14
[    1.431532] 2060-12-01 to_rockchip: 2060-10-18 to_gregorian: 2061-01-15
[    1.431536] 2060-12-02 to_rockchip: 2060-10-19 to_gregorian: 2061-01-16
[    1.431540] 2060-12-03 to_rockchip: 2060-10-20 to_gregorian: 2061-01-17
[    1.431544] 2060-12-04 to_rockchip: 2060-10-21 to_gregorian: 2061-01-18
[    1.431548] 2060-12-05 to_rockchip: 2060-10-22 to_gregorian: 2061-01-19
[    1.431551] 2060-12-30 to_rockchip: 2060-11-16 to_gregorian: 2061-02-13
[    1.431554] 2060-12-31 to_rockchip: 2060-11-17 to_gregorian: 2061-02-14
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Doug Anderson Dec. 19, 2015, 12:25 a.m. UTC | #2
Julius,

On Tue, Dec 15, 2015 at 3:14 PM, Julius Werner <jwerner@chromium.org> wrote:
> Okay, wrote up and tested the anchor date version. I think once you
> get over the initial weirdness of the approach this one is really much
> cleaner and safer.
>
> I tested this with the older rtc_tm_to_time() API and only ported it
> over to rtc_tm_to_time64() for submission, since my 3.14 kernel didn't
> have that yet... but it still compiles fine and the change was very
> trivial so I'm confident that it should work.
>
> I also did a big manual test for my conversion functions where I just
> threw a whole bunch of dates at them, results below for reference:
>
> [    1.431216] jwerner: Testing translation functions:
> [    1.431221] 2015-01-01 to_rockchip: 2015-01-02 to_gregorian: 2014-12-31
> [    1.431224] 2015-10-30 to_rockchip: 2015-10-31 to_gregorian: 2015-10-29
> [    1.431228] 2015-10-31 to_rockchip: 2015-11-01 to_gregorian: 2015-10-30
> [    1.431231] 2015-11-01 to_rockchip: 2015-11-02 to_gregorian: 2015-10-31
> [    1.431235] 2015-11-27 to_rockchip: 2015-11-28 to_gregorian: 2015-11-26
> [    1.431238] 2015-11-28 to_rockchip: 2015-11-29 to_gregorian: 2015-11-27
> [    1.431242] 2015-11-29 to_rockchip: 2015-11-30 to_gregorian: 2015-11-28
> [    1.431245] 2015-11-30 to_rockchip: 2015-12-01 to_gregorian: 2015-11-29
>
> This one is actually a bug... to_rockchip should be 2015-11-31 here.
> It happens because the "compensate if we went back over" part of
> gregorian_to_rockchip() only checks whether we went over *backwards*,
> which happens if the date is after the anchor date. If it was before
> we can go back over forwards and I didn't bother to handle that case.
> I think this is fine since all affected dates lie in the past and
> there's no real-world use case where you'd ever need them to work
> again.

Thanks for the testing.

Ah, I see, so the problem with your patch is only right around 11/31
in years past.  That seems OK to me.

There's actually a real world case that's pretty common where we want
to work with dates before 2016.  When I power cycle my device and it
totally loses battery, I notice that the firmware seems to start as:

 2013-01-21 00:50:02

It's possible we could need to run for a while in this state and we
possibly could even need alarms to fire.  ...but that's nowhere near
the problematic dates and presumably someone wouldn't have a system in
the "clock set totally wrong" state for a really long time.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Doug Anderson Dec. 19, 2015, 12:26 a.m. UTC | #3
Julius,

On Tue, Dec 15, 2015 at 3:02 PM, Julius Werner <jwerner@chromium.org> wrote:
> In A.D. 1582 Pope Gregory XIII found that the existing Julian calendar
> insufficiently represented reality, and changed the rules about
> calculating leap years to account for this. Similarly, in A.D. 2013
> Rockchip hardware engineers found that the new Gregorian calendar still
> contained flaws, and that the month of November should be counted up to
> 31 days instead. Unfortunately it takes a long time for calendar changes
> to gain widespread adoption, and just like more than 300 years went by
> before the last Protestant nation implemented Greg's proposal, we will
> have to wait a while until all religions and operating system kernels
> acknowledge the inherent advantages of the Rockchip system. Until then
> we need to translate dates read from (and written to) Rockchip hardware
> back to the Gregorian format.
>
> This patch works by defining Jan 1st, 2016 as the arbitrary anchor date
> on which Rockchip and Gregorian calendars are in sync. From that we can
> translate arbitrary later dates back and forth by counting the number
> of November/December transitons since the anchor date to determine the
> offset between the calendars. We choose this method (rather than trying
> to regularly "correct" the date stored in hardware) since it's the only
> way to ensure perfect time-keeping even if the system may be shut down
> for an unknown number of years. The drawback is that other software
> reading the same hardware (e.g. mainboard firmware) must use the same
> translation convention (including the same anchor date) to be able to
> read and write correct timestamps from/to the RTC.
>
> Signed-off-by: Julius Werner <jwerner@chromium.org>
> ---
>  drivers/rtc/rtc-rk808.c | 48 ++++++++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 44 insertions(+), 4 deletions(-)

I'm not terribly worried about the date in the past problem that you
brought up in your own response.  So:

Reviewed-by: Douglas Anderson <dianders@chromium.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Julius Werner Dec. 19, 2015, 12:31 a.m. UTC | #4
> There's actually a real world case that's pretty common where we want
> to work with dates before 2016.  When I power cycle my device and it
> totally loses battery, I notice that the firmware seems to start as:
>
>  2013-01-21 00:50:02
>
> It's possible we could need to run for a while in this state and we
> possibly could even need alarms to fire.  ...but that's nowhere near
> the problematic dates and presumably someone wouldn't have a system in
> the "clock set totally wrong" state for a really long time.

Yeah... I don't think it really makes much sense to worry about that.
At that point it's much more likely that you will loose an alarm
because the user finally fixes the clock at some point (either
manually or by connecting to a network and having some automated sync
service jump in), and we never worry about something like that either.
I mean, fixing it wouldn't be a big deal (another 5 lines or so
maybe), but I just don't think it's worth adding any complexity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Alexandre Belloni Dec. 21, 2015, 8:16 a.m. UTC | #5
On 15/12/2015 at 15:02:49 -0800, Julius Werner wrote :
> In A.D. 1582 Pope Gregory XIII found that the existing Julian calendar
> insufficiently represented reality, and changed the rules about
> calculating leap years to account for this. Similarly, in A.D. 2013
> Rockchip hardware engineers found that the new Gregorian calendar still
> contained flaws, and that the month of November should be counted up to
> 31 days instead. Unfortunately it takes a long time for calendar changes
> to gain widespread adoption, and just like more than 300 years went by
> before the last Protestant nation implemented Greg's proposal, we will
> have to wait a while until all religions and operating system kernels
> acknowledge the inherent advantages of the Rockchip system. Until then
> we need to translate dates read from (and written to) Rockchip hardware
> back to the Gregorian format.
> 
> This patch works by defining Jan 1st, 2016 as the arbitrary anchor date
> on which Rockchip and Gregorian calendars are in sync. From that we can
> translate arbitrary later dates back and forth by counting the number
> of November/December transitons since the anchor date to determine the
> offset between the calendars. We choose this method (rather than trying
> to regularly "correct" the date stored in hardware) since it's the only
> way to ensure perfect time-keeping even if the system may be shut down
> for an unknown number of years. The drawback is that other software
> reading the same hardware (e.g. mainboard firmware) must use the same
> translation convention (including the same anchor date) to be able to
> read and write correct timestamps from/to the RTC.
> 
> Signed-off-by: Julius Werner <jwerner@chromium.org>

I forgot to inform you but I've applied it and it landed in 4.4-rc6.


> ---
>  drivers/rtc/rtc-rk808.c | 48 ++++++++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 44 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk808.c
> index 91ca0bc..35c9aad 100644
> --- a/drivers/rtc/rtc-rk808.c
> +++ b/drivers/rtc/rtc-rk808.c
> @@ -56,6 +56,42 @@ struct rk808_rtc {
>  	int irq;
>  };
>  
> +/*
> + * The Rockchip calendar used by the RK808 counts November with 31 days. We use
> + * these translation functions to convert its dates to/from the Gregorian
> + * calendar used by the rest of the world. We arbitrarily define Jan 1st, 2016
> + * as the day when both calendars were in sync, and treat all other dates
> + * relative to that.
> + * NOTE: Other system software (e.g. firmware) that reads the same hardware must
> + * implement this exact same conversion algorithm, with the same anchor date.
> + */
> +static time64_t nov2dec_transitions(struct rtc_time *tm)
> +{
> +	return (tm->tm_year + 1900) - 2016 + (tm->tm_mon + 1 > 11 ? 1 : 0);
> +}
> +
> +static void rockchip_to_gregorian(struct rtc_time *tm)
> +{
> +	/* If it's Nov 31st, rtc_tm_to_time64() will count that like Dec 1st */
> +	time64_t time = rtc_tm_to_time64(tm);
> +	rtc_time64_to_tm(time + nov2dec_transitions(tm) * 86400, tm);
> +}
> +
> +static void gregorian_to_rockchip(struct rtc_time *tm)
> +{
> +	time64_t extra_days = nov2dec_transitions(tm);
> +	time64_t time = rtc_tm_to_time64(tm);
> +	rtc_time64_to_tm(time - extra_days * 86400, tm);
> +
> +	/* Compensate if we went back over Nov 31st (will work up to 2381) */
> +	if (nov2dec_transitions(tm) < extra_days) {
> +		if (tm->tm_mon + 1 == 11)
> +			tm->tm_mday++;	/* This may result in 31! */
> +		else
> +			rtc_time64_to_tm(time - (extra_days - 1) * 86400, tm);
> +	}
> +}
> +
>  /* Read current time and date in RTC */
>  static int rk808_rtc_readtime(struct device *dev, struct rtc_time *tm)
>  {
> @@ -101,9 +137,10 @@ static int rk808_rtc_readtime(struct device *dev, struct rtc_time *tm)
>  	tm->tm_mon = (bcd2bin(rtc_data[4] & MONTHS_REG_MSK)) - 1;
>  	tm->tm_year = (bcd2bin(rtc_data[5] & YEARS_REG_MSK)) + 100;
>  	tm->tm_wday = bcd2bin(rtc_data[6] & WEEKS_REG_MSK);
> +	rockchip_to_gregorian(tm);
>  	dev_dbg(dev, "RTC date/time %4d-%02d-%02d(%d) %02d:%02d:%02d\n",
>  		1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
> -		tm->tm_wday, tm->tm_hour , tm->tm_min, tm->tm_sec);
> +		tm->tm_wday, tm->tm_hour, tm->tm_min, tm->tm_sec);
>  
>  	return ret;
>  }
> @@ -116,6 +153,10 @@ static int rk808_rtc_set_time(struct device *dev, struct rtc_time *tm)
>  	u8 rtc_data[NUM_TIME_REGS];
>  	int ret;
>  
> +	dev_dbg(dev, "set RTC date/time %4d-%02d-%02d(%d) %02d:%02d:%02d\n",
> +		1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
> +		tm->tm_wday, tm->tm_hour, tm->tm_min, tm->tm_sec);
> +	gregorian_to_rockchip(tm);
>  	rtc_data[0] = bin2bcd(tm->tm_sec);
>  	rtc_data[1] = bin2bcd(tm->tm_min);
>  	rtc_data[2] = bin2bcd(tm->tm_hour);
> @@ -123,9 +164,6 @@ static int rk808_rtc_set_time(struct device *dev, struct rtc_time *tm)
>  	rtc_data[4] = bin2bcd(tm->tm_mon + 1);
>  	rtc_data[5] = bin2bcd(tm->tm_year - 100);
>  	rtc_data[6] = bin2bcd(tm->tm_wday);
> -	dev_dbg(dev, "set RTC date/time %4d-%02d-%02d(%d) %02d:%02d:%02d\n",
> -		1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
> -		tm->tm_wday, tm->tm_hour , tm->tm_min, tm->tm_sec);
>  
>  	/* Stop RTC while updating the RTC registers */
>  	ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
> @@ -170,6 +208,7 @@ static int rk808_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
>  	alrm->time.tm_mday = bcd2bin(alrm_data[3] & DAYS_REG_MSK);
>  	alrm->time.tm_mon = (bcd2bin(alrm_data[4] & MONTHS_REG_MSK)) - 1;
>  	alrm->time.tm_year = (bcd2bin(alrm_data[5] & YEARS_REG_MSK)) + 100;
> +	rockchip_to_gregorian(&alrm->time);
>  
>  	ret = regmap_read(rk808->regmap, RK808_RTC_INT_REG, &int_reg);
>  	if (ret) {
> @@ -227,6 +266,7 @@ static int rk808_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
>  		alrm->time.tm_mday, alrm->time.tm_wday, alrm->time.tm_hour,
>  		alrm->time.tm_min, alrm->time.tm_sec);
>  
> +	gregorian_to_rockchip(&alrm->time);
>  	alrm_data[0] = bin2bcd(alrm->time.tm_sec);
>  	alrm_data[1] = bin2bcd(alrm->time.tm_min);
>  	alrm_data[2] = bin2bcd(alrm->time.tm_hour);
> -- 
> 2.1.2
>

Patch
diff mbox series

diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk808.c
index 91ca0bc..35c9aad 100644
--- a/drivers/rtc/rtc-rk808.c
+++ b/drivers/rtc/rtc-rk808.c
@@ -56,6 +56,42 @@  struct rk808_rtc {
 	int irq;
 };
 
+/*
+ * The Rockchip calendar used by the RK808 counts November with 31 days. We use
+ * these translation functions to convert its dates to/from the Gregorian
+ * calendar used by the rest of the world. We arbitrarily define Jan 1st, 2016
+ * as the day when both calendars were in sync, and treat all other dates
+ * relative to that.
+ * NOTE: Other system software (e.g. firmware) that reads the same hardware must
+ * implement this exact same conversion algorithm, with the same anchor date.
+ */
+static time64_t nov2dec_transitions(struct rtc_time *tm)
+{
+	return (tm->tm_year + 1900) - 2016 + (tm->tm_mon + 1 > 11 ? 1 : 0);
+}
+
+static void rockchip_to_gregorian(struct rtc_time *tm)
+{
+	/* If it's Nov 31st, rtc_tm_to_time64() will count that like Dec 1st */
+	time64_t time = rtc_tm_to_time64(tm);
+	rtc_time64_to_tm(time + nov2dec_transitions(tm) * 86400, tm);
+}
+
+static void gregorian_to_rockchip(struct rtc_time *tm)
+{
+	time64_t extra_days = nov2dec_transitions(tm);
+	time64_t time = rtc_tm_to_time64(tm);
+	rtc_time64_to_tm(time - extra_days * 86400, tm);
+
+	/* Compensate if we went back over Nov 31st (will work up to 2381) */
+	if (nov2dec_transitions(tm) < extra_days) {
+		if (tm->tm_mon + 1 == 11)
+			tm->tm_mday++;	/* This may result in 31! */
+		else
+			rtc_time64_to_tm(time - (extra_days - 1) * 86400, tm);
+	}
+}
+
 /* Read current time and date in RTC */
 static int rk808_rtc_readtime(struct device *dev, struct rtc_time *tm)
 {
@@ -101,9 +137,10 @@  static int rk808_rtc_readtime(struct device *dev, struct rtc_time *tm)
 	tm->tm_mon = (bcd2bin(rtc_data[4] & MONTHS_REG_MSK)) - 1;
 	tm->tm_year = (bcd2bin(rtc_data[5] & YEARS_REG_MSK)) + 100;
 	tm->tm_wday = bcd2bin(rtc_data[6] & WEEKS_REG_MSK);
+	rockchip_to_gregorian(tm);
 	dev_dbg(dev, "RTC date/time %4d-%02d-%02d(%d) %02d:%02d:%02d\n",
 		1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
-		tm->tm_wday, tm->tm_hour , tm->tm_min, tm->tm_sec);
+		tm->tm_wday, tm->tm_hour, tm->tm_min, tm->tm_sec);
 
 	return ret;
 }
@@ -116,6 +153,10 @@  static int rk808_rtc_set_time(struct device *dev, struct rtc_time *tm)
 	u8 rtc_data[NUM_TIME_REGS];
 	int ret;
 
+	dev_dbg(dev, "set RTC date/time %4d-%02d-%02d(%d) %02d:%02d:%02d\n",
+		1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
+		tm->tm_wday, tm->tm_hour, tm->tm_min, tm->tm_sec);
+	gregorian_to_rockchip(tm);
 	rtc_data[0] = bin2bcd(tm->tm_sec);
 	rtc_data[1] = bin2bcd(tm->tm_min);
 	rtc_data[2] = bin2bcd(tm->tm_hour);
@@ -123,9 +164,6 @@  static int rk808_rtc_set_time(struct device *dev, struct rtc_time *tm)
 	rtc_data[4] = bin2bcd(tm->tm_mon + 1);
 	rtc_data[5] = bin2bcd(tm->tm_year - 100);
 	rtc_data[6] = bin2bcd(tm->tm_wday);
-	dev_dbg(dev, "set RTC date/time %4d-%02d-%02d(%d) %02d:%02d:%02d\n",
-		1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
-		tm->tm_wday, tm->tm_hour , tm->tm_min, tm->tm_sec);
 
 	/* Stop RTC while updating the RTC registers */
 	ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
@@ -170,6 +208,7 @@  static int rk808_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
 	alrm->time.tm_mday = bcd2bin(alrm_data[3] & DAYS_REG_MSK);
 	alrm->time.tm_mon = (bcd2bin(alrm_data[4] & MONTHS_REG_MSK)) - 1;
 	alrm->time.tm_year = (bcd2bin(alrm_data[5] & YEARS_REG_MSK)) + 100;
+	rockchip_to_gregorian(&alrm->time);
 
 	ret = regmap_read(rk808->regmap, RK808_RTC_INT_REG, &int_reg);
 	if (ret) {
@@ -227,6 +266,7 @@  static int rk808_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
 		alrm->time.tm_mday, alrm->time.tm_wday, alrm->time.tm_hour,
 		alrm->time.tm_min, alrm->time.tm_sec);
 
+	gregorian_to_rockchip(&alrm->time);
 	alrm_data[0] = bin2bcd(alrm->time.tm_sec);
 	alrm_data[1] = bin2bcd(alrm->time.tm_min);
 	alrm_data[2] = bin2bcd(alrm->time.tm_hour);