[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191003142150.3d73a9d7@jawa>
Date: Thu, 3 Oct 2019 14:21:50 +0200
From: Lukasz Majewski <lukma@...x.de>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc: Alessandro Zummo <a.zummo@...ertech.it>, linux-rtc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rtc: Add support for century bits to m41t62 (rv4162)
RTC devices
Hi Alexandre,
> Hello,
>
> On 11/09/2019 17:48:03+0200, Lukasz Majewski wrote:
> > This change adds support for 'century bits' on 4162 family of RTC
> > devices (from ST or microcrystal), which allow storing time beyond
> > year 2099.
> >
> > For rv4162 century bits - CB1[7]:CB0[6] are stored in reg6 - 0x6
> > (MONTH): CB1 CB0
> > 0 0 (year 2000 - 2099)
> > 0 1 (year 2100 - 2199)
> > 1 0 (year 2200 - 2299)
> > 1 1 (year 2300 - 2399)
> >
> > The driver has been also adjusted to allow setting time up to year
> > 2399 if the M41T80_FEATURE_CB is set in its DTS/I2C data.
> >
> > There shall be no functional changes for devices not supporting this
> > feature. However, other devices - like m41t80 - have different
> > approaches to handle century information.
> >
>
> This does not work because the RTC doesn't handle leap years on
> century properly. This means that if you do that, then there is no
> guarantee the date will be the correct after 2099. As far as the
> m41t62 and rv4162 are concerned, there is no way to make the century
> bits useful.
The code as is now doesn't allow to setup dates after year 2100.
In my application - I do some tests which depend on setting this time.
>
> See the datasheet:
>
> "During any year which is a multiple of 4, the RV-4162 RTC will
> automatically insert leap day, February 29. Therefore, the
> application software must correct for this during the exception years
> (2100, 2200, etc.) as noted above."
I'm wondering what the phrase "application software" means here?
If it is the userland SW, then we shall at least be able to set 2099 in
this device and then count on software correction.
If the "application software" is the kernel driver - the date
correction shall be done there (maybe some lookup table?).
Personally, I do prefer the first option - this means that with this
patch we can set the time to e.g. 2234 year and then rely on userland
software (or libc) to do the correction.
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@...x.de
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists