linux-rtc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Jagath Jog J <jagathjog1996@gmail.com>
Cc: a.zummo@towertech.it, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, linux-rtc@vger.kernel.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 2/2] rtc: maxim: Add Maxim max31329 real time clock
Date: Fri, 23 Sep 2022 13:04:06 +0200	[thread overview]
Message-ID: <Yy2SpmCy1ZjC1pMz@mail.local> (raw)
In-Reply-To: <CAM+2EuJsz9NgEskhYapxFg7UrimB3Po97DZGHtBCHTc8+vx_1g@mail.gmail.com>

On 20/09/2022 01:09:37+0530, Jagath Jog J wrote:
>  Hi Alexandre,
> 
> Before sending v3 I have one comment,
> Please see below.
> 
> On Mon, Sep 19, 2022 at 12:18 AM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> >
> > On 17/09/2022 16:09:54+0530, Jagath Jog J wrote:
> > > > This doesn't feel right, doesn't that break start-year?
> > > >
> > > > What is the actual time range supported by this RTC? Shouldn't you set
> > > > the century?
> > >
> > > The time range supported by RTC is 2000 to 2199.
> > > The alarm registers don't have a century bit.
> > > I have tested the alarm for
> > > 2122-09-17T01:22:00
> > > 2142-09-17T01:22:00
> > > 2160-02-29T00:00:00
> > > 2196-02-29T00:00:00 etc
> > >
> > > I will add another condition such that if the century bit
> > > from the time register is not set then configuring the
> > > alarm for the next century is not allowed.
> >
> > The actual check should be for the alarm to not exceed 100 years in the
> > future then. Else, this wouldn't work well with datetime offsetting.
> 
> Sure, I will add this check.
> 
> >
> > > > > +static int max31329_set_time(struct device *dev, struct rtc_time *tm)
> > > > > +{
> > > > > +     struct max31329_data *max31329 = dev_get_drvdata(dev);
> > > > > +     u8 regs[7];
> > > > > +     int ret;
> > > > > +
> > > > > +     ret = max31329_get_osc_status(dev);
> > > > > +     if (ret)
> > > > > +             return ret;
> > > > > +
> > > >
> > > > Checking the oscillator is not needed here but resetting the status is.
> > >
> > > Resetting the device will resets the digital block,
> > > I2C-programmable registers and oscillator also,
> > > The oscillator is taking some time around 80 milli sec
> > > to be back as usual.
> > >
> > > Is it required to reset every time during the time setting?
> > >
> >
> > Not but resetting the osc status is.
> 
> Actually, the STATUS register which contains the Oscillator Stop
> Flag (OSF) bit is a read-only register. If the OSF bit is set, then
> reading the status register will not clear the OSF bit.
> 
> Based on the oscillator disable and enable testing, I observed
> that the OSF bit is getting cleared automatically once the clock
> settles, which is taking around 80msec. The manual resetting
> option is not there for the OSC status bit.
> 
> Can I set the time without resetting the OSC status?
> 

Sure but then it is not even useful to ever test OSF because we just
don't care if it fails while we are running, the most important info is
whether it fails when Linux is not running.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

      reply	other threads:[~2022-09-23 11:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-12 19:07 [PATCH v2 0/2] rtc: maxim: add support for Maxim max31329 RTC Jagath Jog J
2022-09-12 19:07 ` [PATCH v2 1/2] dt-bindings: rtc: add Maxim max31329 rtc device tree bindings Jagath Jog J
2022-09-12 19:07 ` [PATCH v2 2/2] rtc: maxim: Add Maxim max31329 real time clock Jagath Jog J
2022-09-14 11:55   ` Alexandre Belloni
2022-09-17 10:39     ` Jagath Jog J
2022-09-18 18:48       ` Alexandre Belloni
2022-09-19 19:39         ` Jagath Jog J
2022-09-23 11:04           ` Alexandre Belloni [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yy2SpmCy1ZjC1pMz@mail.local \
    --to=alexandre.belloni@bootlin.com \
    --cc=a.zummo@towertech.it \
    --cc=devicetree@vger.kernel.org \
    --cc=jagathjog1996@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).