All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Steve Twiss <stwiss.opensource@diasemi.com>,
	"linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Support Opensource <Support.Opensource@diasemi.com>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH 1/2] rtc: da9063: set range
Date: Tue, 2 Apr 2019 11:51:15 +0200	[thread overview]
Message-ID: <20190402095115.GW3430@piout.net> (raw)
In-Reply-To: <20190402093359.GB2960@kunai>

On 02/04/2019 11:33:59+0200, Wolfram Sang wrote:
> Hi Alexandre,
> 
> > I had a look at the driver and I guess you have a 9063AD while Steve
> > uses another model.
> > 
> > That explains why you need the uie_unsupported flag. The 9063AD can only
> > do alarms on a minute boundary.
> 
> Bingo! Nice catch. I was on the wrong track because we have an early
> boot quirk handling for the DA on this platform and I was searching
> there for side effects. Makes all sense now. Thanks a lot for your help!
> 
> > Since the move to hr_timer, the uie are done using the classic alarm or
> > they are emulated by the core. This improved the situation for many RTCs
> > that don't have a separate UIE but this made it worse for a few (and
> > this is an example). I have plan to work on this but didn't have the
> > time yet.
> 
> I understand. That explains why my RTC knowledge from a few years ago
> feels so outdated :)
> 
> > I suggest the following patch:
> > 
> > ===
> > 
> > From 37b2ab7d537e76e42bde64cf4b57701b0ed8e8cd Mon Sep 17 00:00:00 2001
> > From: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > Date: Tue, 2 Apr 2019 10:06:46 +0200
> > Subject: [PATCH] rtc: da9063: set uie_unsupported when relevant
> > 
> > The DA9063AD doesn't support alarms on any seconds and its granularity is
> > the minute. Set uie_unsupported in that case.
> > 
> > Reported-by: Wolfram Sang <wsa@the-dreams.de>
> 
> Please use this address:
> 
> Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> 
> > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> 
> And probably Geert wants his "+renesas" address, too:
> 
> Geert Uytterhoeven <geert+renesas@glider.be>
> 
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > ---
> >  drivers/rtc/rtc-da9063.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/rtc/rtc-da9063.c b/drivers/rtc/rtc-da9063.c
> > index 1b792bcea3c7..53e690b0f3a2 100644
> > --- a/drivers/rtc/rtc-da9063.c
> > +++ b/drivers/rtc/rtc-da9063.c
> > @@ -475,6 +475,9 @@ static int da9063_rtc_probe(struct platform_device *pdev)
> >  	da9063_data_to_tm(data, &rtc->alarm_time, rtc);
> >  	rtc->rtc_sync = false;
> >  
> > +	if (config->rtc_data_start != RTC_SEC)
> > +		rtc->rtc_dev->uie_unsupported = 1;
> > +
> 
> I think we should have a comment here, like:
> 
> /* FIXME: Make use of the TICK interrupt once the RTC core supports it */
> 

Well, My plan is to go over all the uie_unsupported users once the
infrastructure is in place but I'll put a comment there.

> So, this helps the UIE test:
> 
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> 
> And I guess we have to live with two of the alarm tests failing because
> of the minute granularity?
> 
> Regards,
> 
>    Wolfram
> 



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

  reply	other threads:[~2019-04-02  9:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-21 10:15 [PATCH 1/2] rtc: da9063: set range Alexandre Belloni
2019-03-21 10:15 ` [PATCH 2/2] rtc: da9063: switch to rtc_time64_to_tm/rtc_tm_to_time64 Alexandre Belloni
2019-03-22 15:28   ` Steve Twiss
2019-04-01  8:43   ` Wolfram Sang
2019-04-01 12:42     ` Steve Twiss
2019-03-22 15:16 ` [PATCH 1/2] rtc: da9063: set range Steve Twiss
2019-04-01  8:41 ` Wolfram Sang
2019-04-01  8:59   ` Geert Uytterhoeven
2019-04-01 12:39     ` Steve Twiss
2019-04-01 12:42       ` Geert Uytterhoeven
2019-04-01 13:00         ` Steve Twiss
2019-04-01 13:21         ` Wolfram Sang
2019-04-01 13:39           ` Geert Uytterhoeven
2019-04-01 15:07             ` Wolfram Sang
2019-04-01 15:16               ` Alexandre Belloni
2019-04-01 15:52                 ` Wolfram Sang
2019-04-01 18:53                   ` Alexandre Belloni
2019-04-01 19:34                     ` Wolfram Sang
2019-04-02  8:53                       ` Alexandre Belloni
2019-04-02  9:33                         ` Wolfram Sang
2019-04-02  9:51                           ` Alexandre Belloni [this message]
2019-04-02 10:33                             ` Steve Twiss
2019-04-02 10:42                               ` Alexandre Belloni
2019-04-02 11:14                                 ` Wolfram Sang
2019-04-02 11:52                                   ` Steve Twiss
2019-04-02  9:37                         ` Steve Twiss
2019-04-02 10:30                           ` Wolfram Sang

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=20190402095115.GW3430@piout.net \
    --to=alexandre.belloni@bootlin.com \
    --cc=Support.Opensource@diasemi.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=stwiss.opensource@diasemi.com \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=wsa@the-dreams.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.