From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756402AbbLGWkm (ORCPT ); Mon, 7 Dec 2015 17:40:42 -0500 Received: from mail-wm0-f45.google.com ([74.125.82.45]:33073 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756112AbbLGWki (ORCPT ); Mon, 7 Dec 2015 17:40:38 -0500 MIME-Version: 1.0 In-Reply-To: References: <1449107584-3192-1-git-send-email-jwerner@chromium.org> <5664E1CF.8030406@rock-chips.com> <5664F837.607@rock-chips.com> Date: Mon, 7 Dec 2015 14:40:36 -0800 X-Google-Sender-Auth: bnzVstU8outNRdMyp_OwGzHF24Y Message-ID: Subject: Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st From: Julius Werner To: Julius Werner Cc: Chris Zhong , Doug Anderson , Alexandre Belloni , Andrew Morton , Alessandro Zummo , Sonny Rao , Heiko Stuebner , "linux-kernel@vger.kernel.org" , rtc-linux@googlegroups.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [+Alexandre... sorry, didn't notice that you somehow fell off the thread again, but I presume you get rtc-linux anyway] > Agreed, scheduling alarms in the future is also an important point. So > I guess I'll update the patch to fix alarm scheduling and S3 as well, > and we'll just ignore S5 as infeasible? Found another edge case trying to implement this: if you set an alarm on Nov 25th for Dec 5th, the code will have to adjust it to Dec 4th to account for the extra day. But if you then power off (or brownout) to S5 and don't power it on again until December, you have no way of knowing whether the already set alarm timestamp is on the Rockchip or the Gregorian calendar. You may or may not sync your current time back through an external source, but you have no way of knowing what you should do with the alarm. Other than that my current idea is roughly: - if the current time gets written, always assume the new date is correct - store a "last known timestamp" in memory on boot and on every write - if the current time gets read, adjust it forward by the amount of Nov 31sts since the stored timestamp (this adjustment itself constitutes a write) - if an alarm is written, adjust the timestamp written to hardware backward by the amount of Nov 31sts between the stored timestamp and the alarm time - if an alarm is read, adjust the returned result forward by the amount of Nov 31sts between the stored timestamp and the alarm time - if the current time gets written, read the alarm time before the write and write it back afterwards (the last known timestamp will change as a result of writing the current time, meaning the newly written hardware alarm time may be different from the old one) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com. [2a00:1450:400c:c09::230]) by gmr-mx.google.com with ESMTPS id 204si853745wmx.1.2015.12.07.14.40.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Dec 2015 14:40:36 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id w144so6810653wmw.0 for ; Mon, 07 Dec 2015 14:40:36 -0800 (PST) MIME-Version: 1.0 Sender: rtc-linux@googlegroups.com In-Reply-To: References: <1449107584-3192-1-git-send-email-jwerner@chromium.org> <5664E1CF.8030406@rock-chips.com> <5664F837.607@rock-chips.com> Date: Mon, 7 Dec 2015 14:40:36 -0800 Message-ID: Subject: [rtc-linux] Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st From: Julius Werner To: Julius Werner Cc: Chris Zhong , Doug Anderson , Alexandre Belloni , Andrew Morton , Alessandro Zummo , Sonny Rao , Heiko Stuebner , "linux-kernel@vger.kernel.org" , rtc-linux@googlegroups.com Content-Type: text/plain; charset=UTF-8 Reply-To: rtc-linux@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , [+Alexandre... sorry, didn't notice that you somehow fell off the thread again, but I presume you get rtc-linux anyway] > Agreed, scheduling alarms in the future is also an important point. So > I guess I'll update the patch to fix alarm scheduling and S3 as well, > and we'll just ignore S5 as infeasible? Found another edge case trying to implement this: if you set an alarm on Nov 25th for Dec 5th, the code will have to adjust it to Dec 4th to account for the extra day. But if you then power off (or brownout) to S5 and don't power it on again until December, you have no way of knowing whether the already set alarm timestamp is on the Rockchip or the Gregorian calendar. You may or may not sync your current time back through an external source, but you have no way of knowing what you should do with the alarm. Other than that my current idea is roughly: - if the current time gets written, always assume the new date is correct - store a "last known timestamp" in memory on boot and on every write - if the current time gets read, adjust it forward by the amount of Nov 31sts since the stored timestamp (this adjustment itself constitutes a write) - if an alarm is written, adjust the timestamp written to hardware backward by the amount of Nov 31sts between the stored timestamp and the alarm time - if an alarm is read, adjust the returned result forward by the amount of Nov 31sts between the stored timestamp and the alarm time - if the current time gets written, read the alarm time before the write and write it back afterwards (the last known timestamp will change as a result of writing the current time, meaning the newly written hardware alarm time may be different from the old one) -- -- 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.