driver: rtc: RV3028 use INT without setting callback, no AIE reset during init

[visuphi]

Is your enhancement proposal related to a problem? Please describe.

this diagram is from the RV3028 datasheet.

To use the INT pin for an alarm, one must set a callback with rtc_alarm_set_callback
which sets the AIE bit to 1, and then set an alarm with rtc_alarm_set_time.

Assuming that the RV3028 is running on backup-voltage and the MCU is off:
When an alarm occurs, the INT pin goes low, which e.g. powers on the MCU.
The MCU boots up, initializes the RV3028 and and performs the following step:

zephyr/drivers/rtc/rtc_rv3028.c

Lines 863 to 867 in 2e23dfd

	/* Disable the alarms */
	err = rv3028_update_reg8(dev,
	RV3028_REG_CONTROL2,
	RV3028_CONTROL2_AIE | RV3028_CONTROL2_UIE,
	0);

During initialization, the AIE bit is reset to 0, disabling INT → INT goes high again.
The callback is executed, and then the AF flag is cleared.

To Reproduce

You'll need a setup where you can run RV3028 and a MCU independently.

1. set the time with rtc_set_time()
2. set a callback with rtc_alarm_set_callback()
3. set an alarm with rtc_alarm_set_time(), e.g. one minute later
4. power off MCU and wait until the alarm time
5. power on MCU again

Describe the solution you'd like

In some cases, it is necessary to keep INT low until the AF flag is cleared manually (e.g. with rtc_alarm_is_pending.)
This is not possible in the current implementation because, during RV3028 initialization, the AIE bit is set to 0, causing INT to go high.
Additionally, the AF flag is immediately cleared in the callback, which must be set if one wants to use INT.

Therefore, i propose the following:

• It should be possible to set an alarm with rtc_alarm_set_time() and still use INT without setting a callback. → The AIE flag should be set when an alarm is configured.
• In my opinion, the AIE bit should not be reset to 0 during initialization (which causes INT to go high again), or this behavior should be configurable via Kconfig.

Describe alternatives you've considered

Additional context

I would like to hear your opinion, depending on the effort I can also do a PR. :)

[github-actions]

Hi @visuphi! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[bjarki-andreasen]

Hi, thanks for bringing this up, definitely something we need to align :)

• It should be possible to set an alarm with rtc_alarm_set_time() and still use INT without setting a callback. → The AIE flag should be set when an alarm is configured.

To mirror integrated RTCs, and keep consistent behavior, it seems reasonable to always enable the interrupt output, given the bus attached RTC has the int-gpios pin connected in the devicetree. Integrated RTCs set the interrupt pending bit, and keep it set, regardless of whether a callback is set, since the interrupt is masked. The same behavior can be achieved for bus attached RTCs by just not configuring the interrupt gpio callback unless the rtc callback is set.

• In my opinion, the AIE bit should not be reset to 0 during initialization (which causes INT to go high again), or this behavior should be configurable via Kconfig.

Integrated RTCs keep their interrupt pending but masked if they caused a wakeup in most cases, in other cases, some "reset cause" register stores that the RTC interrupt caused the wakeup. If the int-gpios is configured, it should not be cleared on init , to produce the same behavior as integrated RTCs. This way, the driver can just check the GPIO state and clear it on rtc_alarm_is_pending(), or cause immediate callback when rtc_alarm_set_callback() is called, just like integrated RTCs.

For bus attached RTCs with no connected interrupt pin, don't clear the alarm set bit in the RTCs regs on init, let it be cleared by rtc_alarm_is_pending() or rtc_alarm_set_callback().

Note: The GPIO routed interrupt on bus attached RTCs usually can indicate more than just the alarm being triggered, it can also be triggered by periodic interrupts, like on each second, or if there are multiple alarms, any of them. So just checking that the pin is not 0 is not enough check the alarm status. registers still need to be fetched to check why the int pin was set.

Suggested clarifications to RTC API header/docs:

• Do not clear alarm pending state on init, pending state is cleared by rtc_alarm_is_pending() or rtc_alarm_set_callback().
• Extend rtc_alarm_is_pending() docs to explicitly state that it can be used to check if an RTCs alarm was triggered while sleeping, potentially causing a wakeup (just because it triggered, it could be another alarm, like a counter or something actually causing the wakeup)

WDYT?