From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753571AbbLJS52 (ORCPT ); Thu, 10 Dec 2015 13:57:28 -0500 Received: from mail-wm0-f48.google.com ([74.125.82.48]:33179 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751846AbbLJS5Z (ORCPT ); Thu, 10 Dec 2015 13:57:25 -0500 MIME-Version: 1.0 In-Reply-To: <20151210184119.GL3515@piout.net> References: <1449552115-31256-1-git-send-email-jwerner@chromium.org> <20151210184119.GL3515@piout.net> Date: Thu, 10 Dec 2015 10:57:24 -0800 X-Google-Sender-Auth: 8Ed3X5LQeUHcMP0G7iq8dwTcoQY Message-ID: Subject: Re: [PATCH v2] RTC: RK808: Work around hardware bug on November 31st From: Julius Werner To: Alexandre Belloni Cc: Julius Werner , Doug Anderson , Andrew Morton , Alessandro Zummo , Sonny Rao , Chris Zhong , 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 > I'll try to review and evaluate both solution by the end of the week (no > guarantee though). To summarize, it's a pretty simple trade-off. Do you: a) try to detect every time the RTC deviated from the real-world time and correct it instantly? This can be done most of the time but there are edge cases (when the system is completely powered off while the RTC ticks over Nov 31st) where you cannot detect it. Or, b) just completely let the RTC tick in its own world where every year has an extra day and convert that "calendar" to/from the real-world calendar on every access. This essentially relegates the RTC to a "dumb second counter" and the timestamp in its registers doesn't have any direct connection to the real world time anymore (unless you know the conversion algorithm). This has the nice advantage that it perfectly solves all use cases (time-keeping, accurate alarms, even when shut down or browning out at inopportune times)... the only real disadvantage is that other software (e.g. U-Boot) reading the same RTC must know about this and use the same conversion code to get the correct real-world time from it. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com. [2a00:1450:400c:c09::231]) by gmr-mx.google.com with ESMTPS id b62si4297wmc.0.2015.12.10.10.57.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Dec 2015 10:57:24 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id w144so37306931wmw.0 for ; Thu, 10 Dec 2015 10:57:24 -0800 (PST) MIME-Version: 1.0 Sender: rtc-linux@googlegroups.com In-Reply-To: <20151210184119.GL3515@piout.net> References: <1449552115-31256-1-git-send-email-jwerner@chromium.org> <20151210184119.GL3515@piout.net> Date: Thu, 10 Dec 2015 10:57:24 -0800 Message-ID: Subject: [rtc-linux] Re: [PATCH v2] RTC: RK808: Work around hardware bug on November 31st From: Julius Werner To: Alexandre Belloni Cc: Julius Werner , Doug Anderson , Andrew Morton , Alessandro Zummo , Sonny Rao , Chris Zhong , 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: , > I'll try to review and evaluate both solution by the end of the week (no > guarantee though). To summarize, it's a pretty simple trade-off. Do you: a) try to detect every time the RTC deviated from the real-world time and correct it instantly? This can be done most of the time but there are edge cases (when the system is completely powered off while the RTC ticks over Nov 31st) where you cannot detect it. Or, b) just completely let the RTC tick in its own world where every year has an extra day and convert that "calendar" to/from the real-world calendar on every access. This essentially relegates the RTC to a "dumb second counter" and the timestamp in its registers doesn't have any direct connection to the real world time anymore (unless you know the conversion algorithm). This has the nice advantage that it perfectly solves all use cases (time-keeping, accurate alarms, even when shut down or browning out at inopportune times)... the only real disadvantage is that other software (e.g. U-Boot) reading the same RTC must know about this and use the same conversion code to get the correct real-world time from it. -- -- 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.