From: Lucas Tanure <tanure@linux.com>
To: Neil Armstrong <neil.armstrong@linaro.org>,
Kevin Hilman <khilman@baylibre.com>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Stephen Boyd <sboyd@kernel.org>
Cc: Jian Hu <jian.hu@amlogic.com>,
Ronald Claveau <linux-kernel-dev@aliel.fr>,
Brian Masney <bmasney@redhat.com>,
Chuan Liu <chuan.liu@amlogic.com>,
linux-arm-kernel@lists.infradead.org,
linux-amlogic@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org
Subject: [PATCH 0/4] arm64: amlogic: t7: describe the VIM4 supplies and keep the fabric clocks running
Date: Sat, 29 Aug 2026 10:47:54 +0100 [thread overview]
Message-ID: <20260829094758.23248-1-tanure@linux.com> (raw)
The Khadas VIM4 has needed clk_ignore_unused to boot reliably. Without it
the board hangs at random, loses storage and corrupts memory, and the
failures move around from boot to boot.
Six of the SoC's PWM outputs drive the board's voltage regulators: the
always-on domain, both CPU clusters, the GPU, the NPU and the DRAM. None
of them were described, so Linux saw the outputs as unused and switched
them off about a second into boot. The regulators then drifted away from
the levels the bootloader had set, which is where the corruption and the
random hangs came from.
Thanks to Chuan Liu from Amlogic for helping me indetify which clocks are
critical.
Separately, four clocks feed the bus that carries data between the
peripherals and memory. Nothing claims those either, and switching them
off leaves any device that starts a transfer afterwards stuck. The SD
card comes up about two seconds into boot, so it was the visible victim.
Two of the patches are pin group fixes. The description named groups that
do not exist in the pinctrl driver, so anything referencing them refused
to probe. That is what the supplies patch needs in order to work, and it
had a second effect worth mentioning: the failing probe left one device
unbound, which kept the clock controller's sync_state() deferred forever
and quietly stopped every peripheral clock from ever being switched off.
The board looked healthy for entirely the wrong reason.
Tested on a VIM4 booting from SD with no clk_ignore_unused: 74 clocks are
still switched off, but the card enumerates and the root filesystem mounts
and memtest runs clean over 512 MiB.
Thread about these issues in Vim4:
https://lore.kernel.org/linux-clk/3930906f-783b-4d72-9260-ba25cc8081cb@linux.com/
Lucas Tanure (4):
clk: meson: t7: keep the memory fabric clocks running
arm64: dts: amlogic: t7: fix the pin groups of two PWM outputs
arm64: dts: amlogic: t7: khadas-vim4: add the PWM-driven supplies
arm64: dts: amlogic: t7: fix the pin groups of the vsync PWM
.../amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 110 +++++++++++++++++-
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 44 ++++++-
drivers/clk/meson/t7-peripherals.c | 13 ++-
3 files changed, 156 insertions(+), 11 deletions(-)
--
2.55.0
next reply other threads:[~2026-08-29 9:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-29 9:47 Lucas Tanure [this message]
2026-08-29 9:47 ` [PATCH 1/4] clk: meson: t7: keep the memory " Lucas Tanure
2026-08-29 9:47 ` [PATCH 2/4] arm64: dts: amlogic: t7: fix the pin groups of two PWM outputs Lucas Tanure
2026-08-30 13:06 ` Neil Armstrong
2026-08-29 9:47 ` [PATCH 3/4] arm64: dts: amlogic: t7: khadas-vim4: add the PWM-driven supplies Lucas Tanure
2026-08-30 13:01 ` Neil Armstrong
2026-08-29 9:47 ` [PATCH 4/4] arm64: dts: amlogic: t7: fix the pin groups of the vsync PWM Lucas Tanure
2026-08-30 13:02 ` Neil Armstrong
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=20260829094758.23248-1-tanure@linux.com \
--to=tanure@linux.com \
--cc=bmasney@redhat.com \
--cc=chuan.liu@amlogic.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jbrunet@baylibre.com \
--cc=jian.hu@amlogic.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-clk@vger.kernel.org \
--cc=linux-kernel-dev@aliel.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=neil.armstrong@linaro.org \
--cc=robh@kernel.org \
--cc=sboyd@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®