Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st

[Chris Zhong <zyw@rock-chips.com>]

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
>
>
>