All of lore.kernel.org
 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
>
>
>



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.

  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: link
Be 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.