linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
>
>
>



  reply	other threads:[~2015-12-07  3:08 UTC|newest]

Thread overview: 31+ 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 14:42 ` [rtc-linux] " Alexandre Belloni
2015-12-03 16:53   ` Julius Werner
2015-12-04 23:50 ` Doug Anderson
2015-12-05  0:25   ` Julius Werner
2015-12-05  0:58     ` Doug Anderson
2015-12-05  1:54       ` Julius Werner
2015-12-05  4:02         ` Doug Anderson
2015-12-05  4:53           ` Doug Anderson
2015-12-05  7:17             ` Julius Werner
2015-12-06  0:36               ` Doug Anderson
2015-12-07  1:33                 ` Chris Zhong
2015-12-07  2:50                   ` Doug Anderson
2015-12-07  2:52                     ` Doug Anderson
2015-12-07  3:08                       ` Chris Zhong [this message]
2015-12-07 20:28                         ` Julius Werner
2015-12-07 22:40                           ` Julius Werner
2015-12-08  1:17                           ` Doug Anderson
2015-12-08  1:41                             ` Julius Werner
2015-12-08  5:19                               ` Julius Werner
2015-12-08  5:21                                 ` [PATCH v2] " Julius Werner
2015-12-09  5:44                                   ` Doug Anderson
2015-12-09 21:32                                     ` Julius Werner
2015-12-10 18:41                                       ` Alexandre Belloni
2015-12-10 18:57                                         ` Julius Werner
2015-12-15 23:02                                           ` [PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation " Julius Werner
2015-12-15 23:14                                             ` Julius Werner
2015-12-19  0:25                                               ` Doug Anderson
2015-12-19  0:31                                                 ` Julius Werner
2015-12-19  0:26                                             ` Doug Anderson
2015-12-21  8:16                                             ` 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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).