Q: use 1s irqs to overcome alarm minute granularity?

Q: use 1s irqs to overcome alarm minute granularity?

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

Hi,

so alarms of the Renesas RZ-N1 RTC can only have one-minute-granularity.
However, it does have a one-second-interrupt. Has it been tried already
for some driver to use such an interrupt to emulate second-granularity
of the alarm? My searches did not yield results so far.

So the idea is, of course, to the let the alarm fire on the minutes.
Then, enable the second-update irqs until reading the seconds matches
the requested seconds of the alarm.

It would not only gain us a better resolution for alarms, but also
allows for enabling UIE.

I get it that handling the different interrupts may get tricky if e.g.
there is a change in the timerqueue while something has already been
setup or so. I need to research this, I have currently no idea how this
is handled at all.

But while doing so, I wanted to ask if there are already opinions if
this approach is feasible or not. I can't imagine that I am the first
one to try it, so there probably are experiences out there?

Thanks and happy hacking,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: Q: use 1s irqs to overcome alarm minute granularity?

[Biju Das]

+ Claudiu, Looks RZ/G3S RTC can handle it.
● 
Periodic interrupt (PRD)
? 2 seconds, 1 second, 1/2 second, 1/4 second, 1/8 second, 1/16 second, 1/32

Cheers,
Biju

> -----Original Message-----
> From: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Sent: 25 February 2025 10:19
> To: linux-rtc@vger.kernel.org; Alexandre Belloni <alexandre.belloni@bootlin.com>
> Cc: linux-renesas-soc@vger.kernel.org; Miquel Raynal <miquel.raynal@bootlin.com>
> Subject: Q: use 1s irqs to overcome alarm minute granularity?
> 
> Hi,
> 
> so alarms of the Renesas RZ-N1 RTC can only have one-minute-granularity.
> However, it does have a one-second-interrupt. Has it been tried already for some driver to use such an
> interrupt to emulate second-granularity of the alarm? My searches did not yield results so far.
> 
> So the idea is, of course, to the let the alarm fire on the minutes.
> Then, enable the second-update irqs until reading the seconds matches the requested seconds of the
> alarm.
> 
> It would not only gain us a better resolution for alarms, but also allows for enabling UIE.
> 
> I get it that handling the different interrupts may get tricky if e.g.
> there is a change in the timerqueue while something has already been setup or so. I need to research
> this, I have currently no idea how this is handled at all.
> 
> But while doing so, I wanted to ask if there are already opinions if this approach is feasible or not.
> I can't imagine that I am the first one to try it, so there probably are experiences out there?
> 
> Thanks and happy hacking,
> 
>    Wolfram

Re: Q: use 1s irqs to overcome alarm minute granularity?

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

On Tue, Feb 25, 2025 at 10:24:32AM +0000, Biju Das wrote:
> + Claudiu, Looks RZ/G3S RTC can handle it.
> ● 
> Periodic interrupt (PRD)
> ? 2 seconds, 1 second, 1/2 second, 1/4 second, 1/8 second, 1/16 second, 1/32

This driver does not have that problem, because the alarms support
seconds right away:

408                 writeb(RTCA3_AR_ENB | bin2bcd(tm->tm_sec), priv->base + RTCA3_RSECAR);


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Q: use 1s irqs to overcome alarm minute granularity?

[Alexandre Belloni]

Hi,

On 25/02/2025 11:19:01+0100, Wolfram Sang wrote:
> so alarms of the Renesas RZ-N1 RTC can only have one-minute-granularity.
> However, it does have a one-second-interrupt. Has it been tried already
> for some driver to use such an interrupt to emulate second-granularity
> of the alarm? My searches did not yield results so far.
> 
> So the idea is, of course, to the let the alarm fire on the minutes.
> Then, enable the second-update irqs until reading the seconds matches
> the requested seconds of the alarm.

I'd say this is probably useless because you will already be awake
anyway so I don't see the clear benefit.

> 
> It would not only gain us a better resolution for alarms, but also
> allows for enabling UIE.

This is already something you can do. I admit this has become super
convoluted since Jon switched UIEs to be handled using the alarm
interrupt...


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

Re: Q: use 1s irqs to overcome alarm minute granularity?

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]


> > It would not only gain us a better resolution for alarms, but also
> > allows for enabling UIE.
> 
> This is already something you can do. I admit this has become super
> convoluted since Jon switched UIEs to be handled using the alarm
> interrupt...

How can I enable UIE with alarms which do not support
one-second-resolution? I found that most, if not all, drivers which have
RTC_FEATURE_ALARM_RES_MINUTE or RTC_FEATURE_ALARM_RES_2S set, they all
disable RTC_FEATURE_UPDATE_INTERRUPT. Which makes sense to me when I
look at the UIE-via-alarms code in the RTC core. But, yes, it is
convoluted, so maybe I am missing something?

Thanks for your fast reply!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]