From: Doug Anderson <dianders@chromium.org> To: Julius Werner <jwerner@chromium.org> Cc: Chris Zhong <zyw@rock-chips.com>, 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, Alexandre Belloni <alexandre.belloni@free-electrons.com> Subject: Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st Date: Mon, 7 Dec 2015 17:17:58 -0800 [thread overview] Message-ID: <CAD=FV=Wx2E+sVOyMuNyzBnkJrzYuG_yoC7b54EApLg7QTu2sxQ@mail.gmail.com> (raw) In-Reply-To: <CAODwPW-zWHgmyHX8svgokEhVsaqyx6zZWwvm+-166aNYcj4z-A@mail.gmail.com> Julius, On Mon, Dec 7, 2015 at 12:28 PM, Julius Werner <jwerner@chromium.org> wrote: >> I was presuming that alarms were never set at power off time unless >> power off happened due to an exceptional case. AKA: normal Linux >> shutdown disables all alarms. > > Hmm... maybe I misunderstand how this works. Are alarms never used to > wake from S5? (It doesn't seem to work on my HiSense Chromebook right > now, but maybe that's just an artifact of our board design? I'm pretty > sure I've seen S5-wakes work on other platforms... I doubt that RK808 > is intrinsically incapable of that, it just depends on how you hook it > up.) Good point. The hardware out to be capable of it. >> 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. > > Unfortunately, this doesn't work through S5 if system firmware also > accesses the RTC and transitions GET_TIME on boot (which it does on > Chromebooks). We could fix this for coreboot, but it's probably still > a bad idea to rely on it since Linux should be as firmware-agnostic as > possible. Dang. Who wrote that firmware, anyway? :-P Technically you could still implement this and if firmware happens to read the RTC (and doesn't correct things) then we won't be able to correct things. ...but certainly if you read the old time and then the new time and the old time was < 11/31 and the new time was >= 11/31 you know you need to correct. I'd say that there's a good chance that other firmware (UBoot) doesn't actually read the RTC anyway. Why would it? We only do it for even log, right? >> I'm pretty certain that we need to handle correcting the alarm. >> Setting an alarm for 10 seconds from now and getting the alarm firing >> 1 day and 10 seconds from now seems like a pretty huge problem, at >> least for any system that relies on the RTC alarm a lot. That pretty >> much means that we need some way to identify problematic devices. >> ...so I think if we have no revision register then we should either >> assume all rk808 devices have this problem (and hope and pray that >> Rockchip gives us a way to ID things if they ever add a fix) or come >> up with some other type of solution (probe one time when the clock is >> presumably wrong and store something somewhere in rk808 to indicate >> that we've already probed) > >> Once we have to fix the alarm, handling S3 seems like it will be not >> much more work. > > Agreed, scheduling alarms in the future is also an important point. So > I guess I'll update the patch to fix alarm scheduling and S3 as well, > and we'll just ignore S5 as infeasible?
WARNING: multiple messages have this Message-ID (diff)
From: Doug Anderson <dianders@chromium.org> To: Julius Werner <jwerner@chromium.org> Cc: Chris Zhong <zyw@rock-chips.com>, 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, Alexandre Belloni <alexandre.belloni@free-electrons.com> Subject: [rtc-linux] Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st Date: Mon, 7 Dec 2015 17:17:58 -0800 [thread overview] Message-ID: <CAD=FV=Wx2E+sVOyMuNyzBnkJrzYuG_yoC7b54EApLg7QTu2sxQ@mail.gmail.com> (raw) In-Reply-To: <CAODwPW-zWHgmyHX8svgokEhVsaqyx6zZWwvm+-166aNYcj4z-A@mail.gmail.com> Julius, On Mon, Dec 7, 2015 at 12:28 PM, Julius Werner <jwerner@chromium.org> wrote: >> I was presuming that alarms were never set at power off time unless >> power off happened due to an exceptional case. AKA: normal Linux >> shutdown disables all alarms. > > Hmm... maybe I misunderstand how this works. Are alarms never used to > wake from S5? (It doesn't seem to work on my HiSense Chromebook right > now, but maybe that's just an artifact of our board design? I'm pretty > sure I've seen S5-wakes work on other platforms... I doubt that RK808 > is intrinsically incapable of that, it just depends on how you hook it > up.) Good point. The hardware out to be capable of it. >> 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. > > Unfortunately, this doesn't work through S5 if system firmware also > accesses the RTC and transitions GET_TIME on boot (which it does on > Chromebooks). We could fix this for coreboot, but it's probably still > a bad idea to rely on it since Linux should be as firmware-agnostic as > possible. Dang. Who wrote that firmware, anyway? :-P Technically you could still implement this and if firmware happens to read the RTC (and doesn't correct things) then we won't be able to correct things. ...but certainly if you read the old time and then the new time and the old time was < 11/31 and the new time was >= 11/31 you know you need to correct. I'd say that there's a good chance that other firmware (UBoot) doesn't actually read the RTC anyway. Why would it? We only do it for even log, right? >> I'm pretty certain that we need to handle correcting the alarm. >> Setting an alarm for 10 seconds from now and getting the alarm firing >> 1 day and 10 seconds from now seems like a pretty huge problem, at >> least for any system that relies on the RTC alarm a lot. That pretty >> much means that we need some way to identify problematic devices. >> ...so I think if we have no revision register then we should either >> assume all rk808 devices have this problem (and hope and pray that >> Rockchip gives us a way to ID things if they ever add a fix) or come >> up with some other type of solution (probe one time when the clock is >> presumably wrong and store something somewhere in rk808 to indicate >> that we've already probed) > >> Once we have to fix the alarm, handling S3 seems like it will be not >> much more work. > > Agreed, scheduling alarms in the future is also an important point. So > I guess I'll update the patch to fix alarm scheduling and S3 as well, > and we'll just ignore S5 as infeasible? -- -- 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-08 1:18 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 2015-12-07 3:08 ` [rtc-linux] " 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 [this message] 2015-12-08 1:17 ` 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='CAD=FV=Wx2E+sVOyMuNyzBnkJrzYuG_yoC7b54EApLg7QTu2sxQ@mail.gmail.com' \ --to=dianders@chromium.org \ --cc=a.zummo@towertech.it \ --cc=akpm@linux-foundation.org \ --cc=alexandre.belloni@free-electrons.com \ --cc=heiko@sntech.de \ --cc=jwerner@chromium.org \ --cc=linux-kernel@vger.kernel.org \ --cc=rtc-linux@googlegroups.com \ --cc=sonnyrao@chromium.org \ --cc=zyw@rock-chips.com \ /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.