From: Igor Velkov via B4 Relay <devnull+iav.iav.lv@kernel.org>
To: John Stultz <jstultz@google.com>,
Thomas Gleixner <tglx@kernel.org>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Kevin Hilman <khilman@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>,
Miroslav Lichvar <mlichvar@redhat.com>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
linux-rtc@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org,
Igor Velkov <iav@iav.lv>
Subject: [PATCH RFC 0/3] alarmtimer: Choose the wakeup RTC per sleep state from the device tree
Date: Wed, 04 Nov 2026 05:54:36 +0000 [thread overview]
Message-ID: <20261104-b4-alarmtimer-rtc-priority-v1-0-e996681b8086@iav.lv> (raw)
alarmtimer binds to the first registered RTC that has an alarm and a
wakeup-capable parent and programs it on every suspend. On ODROID-HC4
that RTC is amlogic,meson-vrtc: a register the SoC firmware reads when
the application processors suspend. It wakes the board from deep sleep
only, and only when the firmware handles the alarm; it raises no
interrupt in Linux, so it never wakes the board from s2idle. The board's
pcf8563, whose interrupt line goes to a GPIO, registers later and is
never used.
Which RTC wakes the system depends on the sleep state and on the board's
firmware, so the series lets the board device tree say it per RTC:
- linux,wakeup-states: the sleep states an alarm of this RTC wakes the
system from ("s2idle", "shallow", "deep" as in /sys/power/mem_sleep,
plus "hibernate" and "off"), or "none".
- linux,alarmtimer-priority: a weight to pick among several RTCs that
wake the system from the same state.
alarmtimer keeps each RTC that has an alarm and a wakeup-capable parent,
unless an RTC registered before it, with at least the same priority,
already wakes from every state it lists; each kept RTC gets its own
"alarmtimer" platform device under the RTC. alarmtimer_suspend() picks,
by pm_suspend_target_state, the RTC with the highest priority among
those listing that state, the first registered among equals, and
programs the alarm from that RTC's platform device only. The driver core
suspends a device before its ancestors (dpm_suspend() takes
dpm_prepared_list from the tail, in reverse registration order), so the
chosen RTC and its parent, which drives the hardware, are still awake
when the alarm is programmed.
Without the properties only the first RTC gets a platform device and
alarmtimer programs it on every suspend.
An RTC without linux,wakeup-states is taken to wake the system from
every state, so that adding the property to one RTC, e.g. from an
overlay, does not change how the others are used; a priority on the new
one settles which wins.
Hibernation wakeups (.freeze/.poweroff callbacks) are not part of this
series.
Patch 3 sets linux,wakeup-states on ODROID-HC4: "s2idle" for the
pcf8563 and "deep" for meson-vrtc, so that alarmtimer programs the
pcf8563 for s2idle and meson-vrtc for deep sleep. The patch applies to
the current tree, but the s2idle wakeup also needs the pcf8563
interrupt (GPIOX_5), which a patch under review adds [1].
Tested on ODROID-HC4 with v7.3.1, [1] and a BL301 that handles the vrtc
alarm, waking by a CLOCK_BOOTTIME_ALARM timer, once per state: s2idle
woke on the pcf8563 interrupt, deep sleep on meson-vrtc with the pcf8563
alarm left unset. Without the series the alarm went to meson-vrtc and
the board did not wake from s2idle.
Questions:
- Are "linux,wakeup-states" and "linux,alarmtimer-priority" acceptable
names, or should they be generic (no linux, prefix), given that the
states describe the hardware and the firmware rather than Linux?
- Is the device tree the right place for a capability that depends on
the firmware the board runs? On HC4, meson-vrtc wakes from deep sleep
only with a BL301 that handles its alarm.
The alarm limit of meson-vrtc also depends on the firmware, and the
kernel cannot learn it. Some API is needed to pass this information to
the kernel.
[1] https://lore.kernel.org/r/20261020-hc4-rtc-alarm-irq-v1-1-b2b8c68d54f5@iav.lv
Signed-off-by: Igor Velkov <iav@iav.lv>
---
Igor Velkov (3):
dt-bindings: rtc: Add linux,wakeup-states and linux,alarmtimer-priority
alarmtimer: Choose the wakeup RTC by sleep state and priority
arm64: dts: amlogic: meson-sm1-odroid-hc4: Describe which RTC wakes the board
.../bindings/rtc/amlogic,meson-vrtc.yaml | 3 +
.../devicetree/bindings/rtc/nxp,pcf8563.yaml | 3 +
Documentation/devicetree/bindings/rtc/rtc.yaml | 29 ++++
.../boot/dts/amlogic/meson-sm1-odroid-hc4.dts | 5 +
kernel/time/alarmtimer.c | 157 ++++++++++++++++++---
5 files changed, 180 insertions(+), 17 deletions(-)
---
base-commit: 348f54c435bf3177baa78201952810b255d44b30
change-id: 20261104-b4-alarmtimer-rtc-priority-2e25131a2917
Best regards,
--
Igor Velkov <iav@iav.lv>
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next reply other threads:[~2026-11-04 5:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 5:54 Igor Velkov via B4 Relay [this message]
2026-11-04 5:54 ` [PATCH RFC 1/3] dt-bindings: rtc: Add linux,wakeup-states and linux,alarmtimer-priority Igor Velkov via B4 Relay
2026-11-04 6:06 ` sashiko-bot
2026-11-04 5:54 ` [PATCH RFC 2/3] alarmtimer: Choose the wakeup RTC by sleep state and priority Igor Velkov via B4 Relay
2026-11-04 5:54 ` [PATCH RFC 3/3] arm64: dts: amlogic: meson-sm1-odroid-hc4: Describe which RTC wakes the board Igor Velkov via B4 Relay
2026-11-04 8:50 ` [PATCH RFC 0/3] alarmtimer: Choose the wakeup RTC per sleep state from the device tree Neil Armstrong
2026-11-04 18:38 ` Igor Velkov
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=20261104-b4-alarmtimer-rtc-priority-v1-0-e996681b8086@iav.lv \
--to=devnull+iav.iav.lv@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=iav@iav.lv \
--cc=jbrunet@baylibre.com \
--cc=jstultz@google.com \
--cc=khilman@baylibre.com \
--cc=krzk+dt@kernel.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=mlichvar@redhat.com \
--cc=neil.armstrong@linaro.org \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=tglx@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
all inboxes | Powered by JetHome®