From: Chris Zhong <zyw@rock-chips.com> To: Doug Anderson <dianders@chromium.org> Cc: Julius Werner <jwerner@chromium.org>, Andrew Morton <akpm@linux-foundation.org>, Alessandro Zummo <a.zummo@towertech.it>, Sonny Rao <sonnyrao@chromium.org>, Heiko Stuebner <heiko@sntech.de>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, rtc-linux@googlegroups.com Subject: Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st Date: Mon, 7 Dec 2015 11:08:39 +0800 [thread overview] Message-ID: <5664F837.607@rock-chips.com> (raw) In-Reply-To: <CAD=FV=VJKHK2Eu75UJPf+3i7Gaxa09g+Hwfy7nwWYrgMvocarg@mail.gmail.com> On 12/07/2015 10:52 AM, Doug Anderson wrote: > Hi, > > On Sun, Dec 6, 2015 at 6:50 PM, Doug Anderson <dianders@chromium.org> wrote: >> Chris, >> >> On Sun, Dec 6, 2015 at 5:33 PM, Chris Zhong <zyw@rock-chips.com> wrote: >>> Hi Doug >>> >>> RK808 has a shadowed register for saving a "frozen" RTC time. >>> When we setting "GET_TIME" to 1, the time will save in this shadowed >>> register. So if we do not set the "GET_TIME", we always get the last time. >>> >>> read the old time before "get_time", and then read the time again for new >>> time. If the old time earlier than 12.1 && new time later than 12.1, we >>> should >>> +1 day for the correct rtc time. >>> >>> On the other hand, we should set the "GET_TIME" after rk808_rtc_set_time, >>> for restore the time before suspend/shut_down. >> Ah, good idea using the shadow registers. The whole point of the >> shadow registers is to enable atomic read of time, right? So if the >> clock ticks as you are reading 23:59:59 you don't end up reading >> 23:59:00 or 24:59:59 (you'll get either 23:59:59 or 24:00:00). So >> right, time read will now be: >> >> 1. Read GET_TIME. Confirm it's 1. >> 2. Read the time. >> 3. Set GET_TIME to 0. >> 4. Set GET_TIME to 1. >> 5. Read the time. >> >> If time from #2 < 11/31 and time from #5 >= 11/31 then we do the >> adjust. If GET_TIME wasn't 1 in step #1 then we won't do any >> adjusting unless the time is actually 11/31. >> >> Between steps #4 and #5 we'll need to add a small delay since old code >> used to use the setting to 0 as a delay (as commented). >> >> We should presumably always leave GET_TIME as 1 unless we're actively >> reading the time for the most reliability. Also, if we've already >> read the time this bootup, we can certainly optimize the above by >> skipping #1 and #2. GET_TIME: Rising transition of this register transfers dynamic registers into static shadowed registers. So only the rising of GET_TIME would update the "static shadowed registers". We only need ensure that the rising occurs on condition that we want to the really time. > Oh, but also we still need to know whether to adjust the alarm. I > think you said that all existing rk808 chips have this bug and that > you'll set a bit (to be determined later) if/when this bug is fixed. > So we still need to assume that all rk808 chips have this bug... I think so, all rk808 chips have this bug. And we can read the version register to differentiate the PMICs, once this bug is fixed. > > -Doug > > >
WARNING: multiple messages have this Message-ID (diff)
From: Chris Zhong <zyw@rock-chips.com> To: Doug Anderson <dianders@chromium.org> Cc: Julius Werner <jwerner@chromium.org>, Andrew Morton <akpm@linux-foundation.org>, Alessandro Zummo <a.zummo@towertech.it>, Sonny Rao <sonnyrao@chromium.org>, Heiko Stuebner <heiko@sntech.de>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, rtc-linux@googlegroups.com Subject: [rtc-linux] Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st Date: Mon, 7 Dec 2015 11:08:39 +0800 [thread overview] Message-ID: <5664F837.607@rock-chips.com> (raw) In-Reply-To: <CAD=FV=VJKHK2Eu75UJPf+3i7Gaxa09g+Hwfy7nwWYrgMvocarg@mail.gmail.com> On 12/07/2015 10:52 AM, Doug Anderson wrote: > Hi, > > On Sun, Dec 6, 2015 at 6:50 PM, Doug Anderson <dianders@chromium.org> wrote: >> Chris, >> >> On Sun, Dec 6, 2015 at 5:33 PM, Chris Zhong <zyw@rock-chips.com> wrote: >>> Hi Doug >>> >>> RK808 has a shadowed register for saving a "frozen" RTC time. >>> When we setting "GET_TIME" to 1, the time will save in this shadowed >>> register. So if we do not set the "GET_TIME", we always get the last time. >>> >>> read the old time before "get_time", and then read the time again for new >>> time. If the old time earlier than 12.1 && new time later than 12.1, we >>> should >>> +1 day for the correct rtc time. >>> >>> On the other hand, we should set the "GET_TIME" after rk808_rtc_set_time, >>> for restore the time before suspend/shut_down. >> Ah, good idea using the shadow registers. The whole point of the >> shadow registers is to enable atomic read of time, right? So if the >> clock ticks as you are reading 23:59:59 you don't end up reading >> 23:59:00 or 24:59:59 (you'll get either 23:59:59 or 24:00:00). So >> right, time read will now be: >> >> 1. Read GET_TIME. Confirm it's 1. >> 2. Read the time. >> 3. Set GET_TIME to 0. >> 4. Set GET_TIME to 1. >> 5. Read the time. >> >> If time from #2 < 11/31 and time from #5 >= 11/31 then we do the >> adjust. If GET_TIME wasn't 1 in step #1 then we won't do any >> adjusting unless the time is actually 11/31. >> >> Between steps #4 and #5 we'll need to add a small delay since old code >> used to use the setting to 0 as a delay (as commented). >> >> We should presumably always leave GET_TIME as 1 unless we're actively >> reading the time for the most reliability. Also, if we've already >> read the time this bootup, we can certainly optimize the above by >> skipping #1 and #2. GET_TIME: Rising transition of this register transfers dynamic registers into static shadowed registers. So only the rising of GET_TIME would update the "static shadowed registers". We only need ensure that the rising occurs on condition that we want to the really time. > Oh, but also we still need to know whether to adjust the alarm. I > think you said that all existing rk808 chips have this bug and that > you'll set a bit (to be determined later) if/when this bug is fixed. > So we still need to assume that all rk808 chips have this bug... I think so, all rk808 chips have this bug. And we can read the version register to differentiate the PMICs, once this bug is fixed. > > -Doug > > > -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
next prev parent reply other threads:[~2015-12-07 3:08 UTC|newest] Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-12-03 1:53 [PATCH] RTC: RK808: Work around hardware bug on November 31st Julius Werner 2015-12-03 1:53 ` [rtc-linux] " Julius Werner 2015-12-03 14:42 ` Alexandre Belloni 2015-12-03 14:42 ` Alexandre Belloni 2015-12-03 16:53 ` Julius Werner 2015-12-03 16:53 ` Julius Werner 2015-12-04 23:50 ` Doug Anderson 2015-12-04 23:50 ` [rtc-linux] " Doug Anderson 2015-12-05 0:25 ` Julius Werner 2015-12-05 0:25 ` [rtc-linux] " Julius Werner 2015-12-05 0:58 ` Doug Anderson 2015-12-05 0:58 ` [rtc-linux] " Doug Anderson 2015-12-05 1:54 ` Julius Werner 2015-12-05 1:54 ` [rtc-linux] " Julius Werner 2015-12-05 4:02 ` Doug Anderson 2015-12-05 4:02 ` [rtc-linux] " Doug Anderson 2015-12-05 4:53 ` Doug Anderson 2015-12-05 4:53 ` [rtc-linux] " Doug Anderson 2015-12-05 7:17 ` Julius Werner 2015-12-05 7:17 ` [rtc-linux] " Julius Werner 2015-12-06 0:36 ` Doug Anderson 2015-12-06 0:36 ` [rtc-linux] " Doug Anderson 2015-12-07 1:33 ` Chris Zhong 2015-12-07 1:33 ` [rtc-linux] " Chris Zhong 2015-12-07 2:50 ` Doug Anderson 2015-12-07 2:50 ` [rtc-linux] " Doug Anderson 2015-12-07 2:52 ` Doug Anderson 2015-12-07 2:52 ` [rtc-linux] " Doug Anderson 2015-12-07 3:08 ` Chris Zhong [this message] 2015-12-07 3:08 ` Chris Zhong 2015-12-07 20:28 ` Julius Werner 2015-12-07 20:28 ` [rtc-linux] " Julius Werner 2015-12-07 22:40 ` Julius Werner 2015-12-07 22:40 ` [rtc-linux] " Julius Werner 2015-12-08 1:17 ` Doug Anderson 2015-12-08 1:17 ` [rtc-linux] " Doug Anderson 2015-12-08 1:41 ` Julius Werner 2015-12-08 1:41 ` [rtc-linux] " Julius Werner 2015-12-08 5:19 ` Julius Werner 2015-12-08 5:19 ` [rtc-linux] " Julius Werner 2015-12-08 5:21 ` [PATCH v2] " Julius Werner 2015-12-08 5:21 ` [rtc-linux] " Julius Werner 2015-12-09 5:44 ` Doug Anderson 2015-12-09 5:44 ` [rtc-linux] " Doug Anderson 2015-12-09 21:32 ` Julius Werner 2015-12-09 21:32 ` [rtc-linux] " Julius Werner 2015-12-10 18:41 ` Alexandre Belloni 2015-12-10 18:41 ` [rtc-linux] " Alexandre Belloni 2015-12-10 18:57 ` Julius Werner 2015-12-10 18:57 ` [rtc-linux] " Julius Werner 2015-12-15 23:02 ` [PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation " Julius Werner 2015-12-15 23:02 ` [rtc-linux] " Julius Werner 2015-12-15 23:14 ` Julius Werner 2015-12-15 23:14 ` [rtc-linux] " Julius Werner 2015-12-19 0:25 ` Doug Anderson 2015-12-19 0:25 ` [rtc-linux] " Doug Anderson 2015-12-19 0:31 ` Julius Werner 2015-12-19 0:31 ` [rtc-linux] " Julius Werner 2015-12-19 0:26 ` Doug Anderson 2015-12-19 0:26 ` [rtc-linux] " Doug Anderson 2015-12-21 8:16 ` Alexandre Belloni 2015-12-21 8:16 ` [rtc-linux] " Alexandre Belloni
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5664F837.607@rock-chips.com \ --to=zyw@rock-chips.com \ --cc=a.zummo@towertech.it \ --cc=akpm@linux-foundation.org \ --cc=dianders@chromium.org \ --cc=heiko@sntech.de \ --cc=jwerner@chromium.org \ --cc=linux-kernel@vger.kernel.org \ --cc=rtc-linux@googlegroups.com \ --cc=sonnyrao@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.