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 Content-Length: 1952 Lines: 37 [+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) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/