From: Igor Paunovic <royalnet026@gmail.com>
To: Heiko Stuebner <heiko@sntech.de>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Cristian Ciocaltea <cristian.ciocaltea@collabora.com>,
Ondrej Jirman <megi@xff.cz>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Igor Paunovic <royalnet026@gmail.com>
Subject: [PATCH v2] arm64: dts: rockchip: fix hym8563 interrupt pin on Orange Pi 5 Plus
Date: Tue, 8 Sep 2026 13:19:08 +0200 [thread overview]
Message-ID: <20260908111908.19371-1-royalnet026@gmail.com> (raw)
The interrupt line of the hym8563 RTC on the Orange Pi 5 Plus is routed
to GPIO0_C6, not GPIO0_B0. The vendor device tree uses RK_PC6 for this
pin; the mainline board file uses RK_PB0, which does not carry the RTC
interrupt on this board.
As a result the alarm interrupt never reaches the SoC, so the RTC alarm
cannot be used as a wakeup source on this board.
This was verified on the board by enabling the alarm interrupt (AIE with
AF already set, so INT# is asserted) and sampling the EXT_PORT register
of all five GPIO banks: GPIO0_C6 is the only pad that follows AIE
(high with AIE=0, low with AIE=1, in two off/on cycles), while GPIO0_B0
stays high and its interrupt counter stays at zero.
Switch the interrupt and its pinctrl entry to GPIO0_C6. The board has an
external pull-up on this open-drain line, so no internal bias is needed.
With this change the alarm interrupt is delivered while the system is
running, and the RTC wakes the SoC out of s2idle.
Fixes: 236d225e1ee7 ("arm64: dts: rockchip: Add board device tree for rk3588-orangepi-5-plus")
Cc: stable@vger.kernel.org
Assisted-by: LLM checkpatch dtbs_check
Signed-off-by: Igor Paunovic <royalnet026@gmail.com>
Reviewed-by: Ondrej Jirman <megi@xff.cz>
---
Changes in v2:
- Drop the internal pull-up: the board schematic already has an external
pull-up on this line (Ondrej Jirman). Only the pin number changes now.
- Reworded the effect paragraphs to state only what was measured; no
functional change.
- Link to v1: https://lore.kernel.org/all/20260906181622.11991-1-royalnet026@gmail.com/
Notes for reviewers (not part of the commit message):
Measured on an Orange Pi 5 Plus. The input levels of all five GPIO banks were
read from their EXT_PORT registers via /dev/mem while toggling the alarm
interrupt enable through /sys/class/rtc/rtc0/wakealarm; GPIO0_C6 was the only
pad that followed it.
The s2idle wakeup was measured with the v1 form of this patch (same pin, but
with the internal pull-up still set): 'PM: Triggering wakeup from IRQ 52'.
With bias-disable, as posted here, I re-checked that the alarm interrupt still
increments the hym8563 interrupt count at the programmed alarm time, with no
spurious interrupts on the level-low line.
Note that on this board the resume itself can still stall later in the USB 2.0
host controllers (a separate issue reported in [1]); with those controllers
unbound the full s2idle cycle completes. It does not affect this fix.
[1] https://lore.kernel.org/all/20260907190000.s2idle-usb2-resume-royalnet026@gmail.com/
arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
index 145986695720..3f2806284754 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
@@ -189,7 +189,7 @@ &hdptxphy1 {
&hym8563 {
interrupt-parent = <&gpio0>;
- interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
+ interrupts = <RK_PC6 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&hym8563_int>;
};
@@ -298,7 +298,7 @@ hdmi1_tx_on_h: hdmi1-tx-on-h {
hym8563 {
hym8563_int: hym8563-int {
- rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
base-commit: 1fc5a74b108fc90951890ec513ac81869f5eaff1
--
2.43.0
reply other threads:[~2026-09-08 11:19 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260908111908.19371-1-royalnet026@gmail.com \
--to=royalnet026@gmail.com \
--cc=conor+dt@kernel.org \
--cc=cristian.ciocaltea@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=megi@xff.cz \
--cc=robh@kernel.org \
--cc=stable@vger.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®