public inbox for linux-sunxi@lists.linux.dev
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Sasha Levin <sashal@kernel.org>,
	samuel@sholland.org, linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev
Subject: [PATCH AUTOSEL 6.17-6.1] clk: sunxi-ng: sun6i-rtc: Add A523 specifics
Date: Sun, 26 Oct 2025 10:49:16 -0400	[thread overview]
Message-ID: <20251026144958.26750-38-sashal@kernel.org> (raw)
In-Reply-To: <20251026144958.26750-1-sashal@kernel.org>

From: Chen-Yu Tsai <wens@csie.org>

[ Upstream commit 7aa8781f379c32c31bd78f1408a31765b2297c43 ]

The A523's RTC block is backward compatible with the R329's, but it also
has a calibration function for its internal oscillator, which would
allow it to provide a clock rate closer to the desired 32.768 KHz. This
is useful on the Radxa Cubie A5E, which does not have an external 32.768
KHz crystal.

Add new compatible-specific data for it.

Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20250909170947.2221611-1-wens@kernel.org
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES
- `drivers/clk/sunxi-ng/ccu-sun6i-rtc.c:328-346` adds a dedicated
  `sun55i_a523_rtc_ccu_data` entry and wires the
  `"allwinner,sun55i-a523-rtc"` compatible to it, which is already used
  by the SoC DT (`arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi:683`).
  Without this entry the node falls back to the R329 table and leaves
  `have_iosc_calibration` unset, so the SoC never enables its oscillator
  calibration logic.
- The calibration flag drives the guard checks in
  `ccu_iosc_recalc_rate()` and `ccu_iosc_32k_prepare()`
  (`drivers/clk/sunxi-ng/ccu-sun6i-rtc.c:83-178`). With the flag cleared
  the internal 32 kHz path keeps the default ±30 % accuracy
  (`IOSC_ACCURACY`), which is a severe timekeeping bug on boards like
  the Radxa Cubie A5E that ship without an external 32 kHz crystal.
- Once the new match data sets `have_iosc_calibration = true`, the probe
  stores it via `have_iosc_calibration = data->have_iosc_calibration;`
  in `sun6i_rtc_ccu_probe()` (`drivers/clk/sunxi-ng/ccu-
  sun6i-rtc.c:352-360`), letting the prepare hook enable
  `IOSC_CLK_CALI_EN` so the RTC clock actually converges to 32.768 kHz.
  This directly fixes the observed drift.
- Risk is minimal: the change is limited to a new compatible entry that
  reuses the existing R329 parent set and does not alter behaviour for
  any other SoC. All other compatibles keep their prior data, so
  regression surface is effectively isolated to hardware that already
  depends on the new compatible.

 drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
index 0536e880b80fe..f6bfeba009e8e 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
@@ -325,6 +325,13 @@ static const struct sun6i_rtc_match_data sun50i_r329_rtc_ccu_data = {
 	.osc32k_fanout_nparents	= ARRAY_SIZE(sun50i_r329_osc32k_fanout_parents),
 };
 
+static const struct sun6i_rtc_match_data sun55i_a523_rtc_ccu_data = {
+	.have_ext_osc32k	= true,
+	.have_iosc_calibration	= true,
+	.osc32k_fanout_parents	= sun50i_r329_osc32k_fanout_parents,
+	.osc32k_fanout_nparents	= ARRAY_SIZE(sun50i_r329_osc32k_fanout_parents),
+};
+
 static const struct of_device_id sun6i_rtc_ccu_match[] = {
 	{
 		.compatible	= "allwinner,sun50i-h616-rtc",
@@ -334,6 +341,10 @@ static const struct of_device_id sun6i_rtc_ccu_match[] = {
 		.compatible	= "allwinner,sun50i-r329-rtc",
 		.data		= &sun50i_r329_rtc_ccu_data,
 	},
+	{
+		.compatible	= "allwinner,sun55i-a523-rtc",
+		.data		= &sun55i_a523_rtc_ccu_data,
+	},
 	{},
 };
 MODULE_DEVICE_TABLE(of, sun6i_rtc_ccu_match);
-- 
2.51.0


           reply	other threads:[~2025-10-26 14:51 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20251026144958.26750-1-sashal@kernel.org>]

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=20251026144958.26750-38-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=patches@lists.linux.dev \
    --cc=samuel@sholland.org \
    --cc=stable@vger.kernel.org \
    --cc=wens@csie.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