From: Neil Armstrong <neil.armstrong@linaro.org>
To: iav@iav.lv, 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>,
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
Subject: Re: [PATCH RFC 0/3] alarmtimer: Choose the wakeup RTC per sleep state from the device tree
Date: Wed, 4 Nov 2026 09:50:49 +0100 [thread overview]
Message-ID: <399668f0-e97a-438e-b761-1ea6c18d904b@linaro.org> (raw)
In-Reply-To: <20261104-b4-alarmtimer-rtc-priority-v1-0-e996681b8086@iav.lv>
On 11/4/26 06:54, Igor Velkov via B4 Relay wrote:
> 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.
This sounds bulky, perhaps it would be much simpler if we just added
all the available RTCs which has RTC_FEATURE_ALARM and can wakeup ?
Just switch from 1 single to multiple RTCs in a linked list and you're
done, no DT & bindings changes.
Neil
>
> 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,
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
prev parent reply other threads:[~2026-11-04 8:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 5:54 Igor Velkov via B4 Relay
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 ` Neil Armstrong [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=399668f0-e97a-438e-b761-1ea6c18d904b@linaro.org \
--to=neil.armstrong@linaro.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=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®