From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932072AbbLGBdR (ORCPT ); Sun, 6 Dec 2015 20:33:17 -0500 Received: from regular1.263xmail.com ([211.150.99.137]:46357 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754959AbbLGBdP (ORCPT ); Sun, 6 Dec 2015 20:33:15 -0500 X-263anti-spam: KSV:0;BIG:0;ABS:1;DNS:0;ATT:0;SPF:S; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 1 X-SKE-CHECKED: 1 X-ADDR-CHECKED: 0 X-RL-SENDER: zyw@rock-chips.com X-FST-TO: rtc-linux@googlegroups.com X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: zyw@rock-chips.com X-UNIQUE-TAG: X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st To: Doug Anderson , Julius Werner References: <1449107584-3192-1-git-send-email-jwerner@chromium.org> Cc: Andrew Morton , Alessandro Zummo , Sonny Rao , Heiko Stuebner , "linux-kernel@vger.kernel.org" , rtc-linux@googlegroups.com From: Chris Zhong Message-ID: <5664E1CF.8030406@rock-chips.com> Date: Mon, 7 Dec 2015 09:33:03 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 > > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from regular1.263xmail.com (regular1.263xmail.com. [211.150.99.137]) by gmr-mx.google.com with ESMTPS id fg10si3607202pad.0.2015.12.06.17.33.33 for (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 06 Dec 2015 17:33:33 -0800 (PST) Subject: [rtc-linux] Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st To: Doug Anderson , Julius Werner References: <1449107584-3192-1-git-send-email-jwerner@chromium.org> Cc: Andrew Morton , Alessandro Zummo , Sonny Rao , Heiko Stuebner , "linux-kernel@vger.kernel.org" , rtc-linux@googlegroups.com From: Chris Zhong Message-ID: <5664E1CF.8030406@rock-chips.com> Date: Mon, 7 Dec 2015 09:33:03 +0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Reply-To: rtc-linux@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 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 > > > -- -- 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.