All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko@sntech.de>
To: tomeu@tomeuvizoso.net, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, joro@8bytes.org, will@kernel.org,
	robin.murphy@arm.com, ulfh@kernel.org, p.zabel@pengutronix.de,
	ogabbay@kernel.org, zhangqing@rock-chips.com,
	Jiaxing Hu <gahing@gahingwoo.com>
Cc: royalnet026@gmail.com, abel.vesa@oss.qualcomm.com,
	sebastian.reichel@collabora.com, sidong.yang@furiosa.ai,
	u.kleine-koenig@baylibre.com, chaoyi.chen@rock-chips.com,
	diederik@cknow-tech.com, alchark@flipper.net,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org, iommu@lists.linux.dev,
	linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Jiaxing Hu <gahing@gahingwoo.com>
Subject: Re: [PATCH v13 09/14] pmdomain: rockchip: add optional per-domain power-on settle delay
Date: Tue, 22 Sep 2026 00:06:12 +0200	[thread overview]
Message-ID: <15844283.tv2OnDr8pf@phil> (raw)
In-Reply-To: <20260915104328.45901-10-gahing@gahingwoo.com>

Hi,

Am Dienstag, 15. September 2026, 12:43:23 Mitteleuropäische Sommerzeit schrieb Jiaxing Hu:
> The RK3576 NPU domains need a short settle time after the idle request is
> released before the registers behind the domain answer. Without it the QoS
> writes that rockchip_pmu_restore_qos() issues land while the domain is
> still coming up, and the NPU throws an async SError on the first cold
> power-on.

are you really really sure, this is the fault of the domain itself?

The regulator also can just need a longer time to bring up the power.
Looking at [0], it seems I actually encountered the same thing back
on the RK3588.

Only difference is, on RK3588 a fan5355-type regulator normally does
provide the npu supply, while on your board it comes from the main pmic.

Can you please try the following:
- set your power-domain regulator to always-on in the DT (so it stays
  on even when the domain gets turned off)
- try to reproduce your SError issue and see if it still appears


And for the other case, look through the pmic datasheet to find the
enable-time values and do something similar for the RK806.


Thanks a lot
Heiko


[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8acfb165a492251a08a22a4fa6497a131e8c2609




WARNING: multiple messages have this Message-ID (diff)
From: Heiko Stuebner <heiko@sntech.de>
To: tomeu@tomeuvizoso.net, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, joro@8bytes.org, will@kernel.org,
	robin.murphy@arm.com, ulfh@kernel.org, p.zabel@pengutronix.de,
	ogabbay@kernel.org, zhangqing@rock-chips.com,
	Jiaxing Hu <gahing@gahingwoo.com>
Cc: royalnet026@gmail.com, abel.vesa@oss.qualcomm.com,
	sebastian.reichel@collabora.com, sidong.yang@furiosa.ai,
	u.kleine-koenig@baylibre.com, chaoyi.chen@rock-chips.com,
	diederik@cknow-tech.com, alchark@flipper.net,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org, iommu@lists.linux.dev,
	linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Jiaxing Hu <gahing@gahingwoo.com>
Subject: Re: [PATCH v13 09/14] pmdomain: rockchip: add optional per-domain power-on settle delay
Date: Tue, 22 Sep 2026 00:06:12 +0200	[thread overview]
Message-ID: <15844283.tv2OnDr8pf@phil> (raw)
In-Reply-To: <20260915104328.45901-10-gahing@gahingwoo.com>

Hi,

Am Dienstag, 15. September 2026, 12:43:23 Mitteleuropäische Sommerzeit schrieb Jiaxing Hu:
> The RK3576 NPU domains need a short settle time after the idle request is
> released before the registers behind the domain answer. Without it the QoS
> writes that rockchip_pmu_restore_qos() issues land while the domain is
> still coming up, and the NPU throws an async SError on the first cold
> power-on.

are you really really sure, this is the fault of the domain itself?

The regulator also can just need a longer time to bring up the power.
Looking at [0], it seems I actually encountered the same thing back
on the RK3588.

Only difference is, on RK3588 a fan5355-type regulator normally does
provide the npu supply, while on your board it comes from the main pmic.

Can you please try the following:
- set your power-domain regulator to always-on in the DT (so it stays
  on even when the domain gets turned off)
- try to reproduce your SError issue and see if it still appears


And for the other case, look through the pmic datasheet to find the
enable-time values and do something similar for the RK806.


Thanks a lot
Heiko


[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8acfb165a492251a08a22a4fa6497a131e8c2609




_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  parent reply	other threads:[~2026-09-21 22:06 UTC|newest]

Thread overview: 66+ 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 ` 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   ` 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   ` 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-15 10:43   ` Jiaxing Hu
2026-09-15 10:59   ` sashiko-bot
2026-09-16 13:28   ` Igor Paunovic
2026-09-16 13:28     ` Igor Paunovic
2026-09-19  9:17     ` Jiaxing Hu
2026-09-19  9:17       ` Jiaxing Hu
2026-09-19 10:34       ` Igor Paunovic
2026-09-19 10:34         ` 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   ` Jiaxing Hu
2026-09-15 10:58   ` sashiko-bot
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   ` 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 06/14] dt-bindings: npu: rockchip: add rockchip,rk3576-rknn-core Jiaxing Hu
2026-09-15 10:43   ` 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-15 10:43   ` Jiaxing Hu
2026-09-21 21:52   ` Heiko Stuebner
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   ` 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-15 10:43   ` Jiaxing Hu
2026-09-21 12:41   ` Ulf Hansson
2026-09-21 12:41     ` Ulf Hansson
2026-09-21 22:06   ` Heiko Stuebner [this message]
2026-09-21 22:06     ` Heiko Stuebner
2026-09-22  1:28     ` Chaoyi Chen
2026-09-22  1:28       ` Chaoyi Chen
2026-09-24  9:08     ` Jiaxing Hu
2026-09-24  9:08       ` Jiaxing Hu
2026-09-15 10:43 ` [PATCH v13 10/14] pmdomain: rockchip: cycle optional power-domain resets on power-on Jiaxing Hu
2026-09-15 10:43   ` Jiaxing Hu
2026-09-15 10:56   ` sashiko-bot
2026-09-21 12:43   ` Ulf Hansson
2026-09-21 12:43     ` Ulf Hansson
2026-09-23  9:38   ` Philipp Zabel
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   ` 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   ` Jiaxing Hu
2026-09-15 10:43 ` [PATCH v13 13/14] arm64: dts: rockchip: add NPU (RKNN) nodes to rk3576 Jiaxing Hu
2026-09-15 10:43   ` Jiaxing Hu
2026-09-21 21:51   ` Heiko Stuebner
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-15 10:43   ` Jiaxing Hu
2026-09-19  7:32 ` [PATCH v13 00/14] accel/rocket: RK3576 NPU (RKNN) enablement Sidong Yang
2026-09-19  7:32   ` Sidong Yang
2026-09-19  9:17   ` Jiaxing Hu
2026-09-19  9:17     ` Jiaxing Hu
2026-09-21 12:46 ` Ulf Hansson
2026-09-21 12:46   ` Ulf Hansson
2026-09-24  9:08   ` Jiaxing Hu
2026-09-24  9:08     ` Jiaxing Hu
2026-09-24 13:48     ` Ulf Hansson
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=15844283.tv2OnDr8pf@phil \
    --to=heiko@sntech.de \
    --cc=abel.vesa@oss.qualcomm.com \
    --cc=alchark@flipper.net \
    --cc=chaoyi.chen@rock-chips.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=diederik@cknow-tech.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gahing@gahingwoo.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=ogabbay@kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=royalnet026@gmail.com \
    --cc=sebastian.reichel@collabora.com \
    --cc=sidong.yang@furiosa.ai \
    --cc=tomeu@tomeuvizoso.net \
    --cc=u.kleine-koenig@baylibre.com \
    --cc=ulfh@kernel.org \
    --cc=will@kernel.org \
    --cc=zhangqing@rock-chips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.