Messages in this thread |  | | Subject | Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st | | From | Chris Zhong <> | | Date | Mon, 7 Dec 2015 09:33:03 +0800 |
| |
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.
regmap_bulk_read(rk808->regmap, RK808_SECONDS_REG, rtc_data, NUM_TIME_REGS);
<....>
/* Force an update of the shadowed registers right now */ ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG, BIT_RTC_CTRL_REG_RTC_GET_TIME, BIT_RTC_CTRL_REG_RTC_GET_TIME);
regmap_bulk_read(rk808->regmap, RK808_SECONDS_REG, rtc_data, NUM_TIME_REGS);
On 12/06/2015 08:36 AM, Doug Anderson wrote: > Julius, > > On Fri, Dec 4, 2015 at 11:17 PM, Julius Werner <jwerner@chromium.org> wrote: >>> If you set the alarm >>> for Dec 25th and it's currently Oct 31st then you'll have to adjust in >>> the alarm code and you'll really set it for Dec 24th. As per above, >>> we're in S3 (presumably) or have some persistent kernel state so we >>> know to adjust everything when we wake up (even if we wake up for a >>> non-alarm reason). >> How do you deal with the case where you set an alarm in late December, >> but you then power the system on earlier in December by other means? I >> think then you couldn't tell if the fix had already been applied? > 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. If you happened to have an exceptional > shutdown (out of battery?) while an alarm is set then, yes, my > solution fails. Presumably if the RTC keeps state but the system ran > out of battery, you've got two batteries in your system (something > none of the rk808-based Chromebooks have--we back rk808 state up with > the main battery, not a coin cell). > > In Chromebooks you could possibly get a shutdown that Linux didn't > know anything about if you got a forcible reboot (watchdog, crash, or > Refresh-Power) and then you managed to convince the BIOS to shut you > down (you have the dev screen and press power off there). Again, this > seems pretty darn rare. > > >>> You'll still get a failure if you set the alarm and then forcibly go >>> into S5 without software knowledge, then stay in S5 long enough to >>> cross over Nov 31st without seeing it (but somehow keep the RTC >>> state). ...but come on, that seems so incredibly rare! :-P >> I think you could just set it to "November 31st, disabled" at probe >> time (if it isn't already) and keep it like that indefinitely? I think >> as long as you don't need to actually use the alarm, that would work >> fine. > Yup. In ChromeOS we only use the alarm in suspend stress testing, but > I'd believe that anyone using Android on one of these systems would > use the RTC much more. > > We might (?) use the RTC alarm in ChromeOS if we ever support dark > resume etc on rk3288-based devices, right? > > >> Still, with the vast majority of practically existing devices with an >> RK808 almost constantly connected to some network, I'm not sure if a >> huge hack-around is really worth it here. (I guess we could still just >> do the S3 thing which is much less complicated, assuming we can >> guarantee correct identification.) > 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. > > I'm OK with not handling S5, but I think with my proposed scheme we > could also handle it if we wanted. > > > All hacks should be contained in the rk808 driver, which should make > them much less objectionable in general. > > -Doug > > >
|  |