Linux Power Management development
 help / color / mirror / Atom feed
From: Jiaxing Hu <gahing@gahingwoo.com>
To: heiko@sntech.de
Cc: chaoyi.chen@rock-chips.com, ulf.hansson@oss.qualcomm.com,
	linux-pm@vger.kernel.org, linux-rockchip@lists.infradead.org
Subject: Re: [PATCH v13 09/14] pmdomain: rockchip: add optional per-domain power-on settle delay
Date: Thu, 24 Sep 2026 21:08:24 +1200	[thread overview]
Message-ID: <20260924090824.38493-1-gahing@gahingwoo.com> (raw)
In-Reply-To: <15844283.tv2OnDr8pf@phil>

Hi Heiko,

Chaoyi has given the mechanism, and I ran your experiment on v13 as
posted, since the SError behind this patch was first seen in June on a
board that held vdd_npu_s0 up with a local regulator-always-on and had
no domain-supply.

Same kernel in every arm (this series, an unrelated dw-hdmi-qp patch,
and a test-only override of the table delay), v13's rock-4d dtb, and for
the last arm that dtb with only regulator-always-on added to vdd_npu_s0:

  delay 15 us, rail follows the domain   536 cold power-ons, clean
  delay 0,     rail follows the domain   SError at the first power-on
  delay 0,     regulator-always-on       SError at the first power-on

Both failures are the same:

  Kernel panic - not syncing: Asynchronous SError Interrupt
   regmap_write+0x58/0x78
   rockchip_pd_power+0x4b4/0x63c
   rockchip_pd_power_on+0x7c/0xd4

In the always-on arm the rail has been enabled since the regulator
registered, so nothing is ramping at that first power-on (1.4 s,
deferred probe), and it still faults. The fault needs only the domain,
as Chaoyi says, and the delay removes it. The enable time is already
described: rk3576-rock-4d.dts gives vdd_npu_s0
regulator-enable-ramp-delay = <400>.

Limits: one boot per failing arm, nothing tried between 0 and 15 us, and
neither failing arm got past its first power-on.

Regards,
Jiaxing

  parent reply	other threads:[~2026-09-24  9:08 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15 10:43 [PATCH v13 00/14] accel/rocket: RK3576 NPU (RKNN) enablement Jiaxing Hu
2026-09-15 10:43 ` [PATCH v13 01/14] accel/rocket: request the core clocks by name Jiaxing Hu
2026-09-15 10:43 ` [PATCH v13 02/14] accel/rocket: take the completion register writes under job_lock Jiaxing Hu
2026-09-15 10:43 ` [PATCH v13 03/14] accel/rocket: wait for a running IRQ handler before resetting a core Jiaxing Hu
2026-09-16 13:28   ` Igor Paunovic
2026-09-15 10:43 ` [PATCH v13 04/14] accel/rocket: let the core suspend after a reset Jiaxing Hu
2026-09-15 10:43 ` [PATCH v13 05/14] accel/rocket: factor the completion tail out of the IRQ handler Jiaxing Hu
2026-09-15 10:43 ` [PATCH v13 06/14] dt-bindings: npu: rockchip: add rockchip,rk3576-rknn-core Jiaxing Hu
2026-09-15 10:43 ` [PATCH v13 07/14] dt-bindings: power: rockchip: allow resets in a power domain node Jiaxing Hu
2026-09-21 21:52   ` Heiko Stuebner
2026-09-15 10:43 ` [PATCH v13 08/14] dt-bindings: iommu: rockchip: describe the RK3576 NPU MMU Jiaxing Hu
2026-09-15 10:43 ` [PATCH v13 09/14] pmdomain: rockchip: add optional per-domain power-on settle delay Jiaxing Hu
2026-09-21 12:41   ` Ulf Hansson
2026-09-21 22:06   ` Heiko Stuebner
2026-09-22  1:28     ` Chaoyi Chen
2026-09-24  9:08     ` Jiaxing Hu [this message]
2026-09-15 10:43 ` [PATCH v13 10/14] pmdomain: rockchip: cycle optional power-domain resets on power-on Jiaxing Hu
2026-09-21 12:43   ` Ulf Hansson
2026-09-23  9:38   ` Philipp Zabel
2026-09-15 10:43 ` [PATCH v13 11/14] accel/rocket: select the per-core clock and reset counts from match data Jiaxing Hu
2026-09-15 10:43 ` [PATCH v13 12/14] accel/rocket: add RK3576 NPU (RKNN) support Jiaxing Hu
2026-09-15 10:43 ` [PATCH v13 13/14] arm64: dts: rockchip: add NPU (RKNN) nodes to rk3576 Jiaxing Hu
2026-09-21 21:51   ` Heiko Stuebner
2026-09-15 10:43 ` [PATCH v13 14/14] arm64: dts: rockchip: enable the NPU on rk3576-rock-4d Jiaxing Hu
2026-09-19  7:32 ` [PATCH v13 00/14] accel/rocket: RK3576 NPU (RKNN) enablement Sidong Yang
2026-09-21 12:46 ` Ulf Hansson
2026-09-24  9:08   ` Jiaxing Hu
2026-09-24 13:48     ` Ulf Hansson

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=20260924090824.38493-1-gahing@gahingwoo.com \
    --to=gahing@gahingwoo.com \
    --cc=chaoyi.chen@rock-chips.com \
    --cc=heiko@sntech.de \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=ulf.hansson@oss.qualcomm.com \
    /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