All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jiaxing Hu" <gahing@gahingwoo.com>
Cc: dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
	robh@kernel.org, conor+dt@kernel.org
Subject: Re: [RFC PATCH v5 v5 4/8] pmdomain/rockchip: add optional per-domain power-on settle delay
Date: Wed, 05 Aug 2026 07:19:41 +0000	[thread overview]
Message-ID: <20260805071942.DCC9B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260805063826.95682-5-gahing@gahingwoo.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] On the first power-on from a cold boot, `rockchip_pmu_restore_qos()` incorrectly writes uninitialized zero values to the hardware QoS registers if the domain was powered off by the bootloader.
--

--- Patch [4]: [RFC PATCH v5 v5 4/8] pmdomain/rockchip: add optional per-domain power-on settle delay ---
commit c7d671d6283e8b2b3bf5a4fdce967757abdd8d2f
Author: Jiaxing Hu <gahing@gahingwoo.com>

pmdomain/rockchip: add optional per-domain power-on settle delay

Adds an optional delay_us parameter to rockchip_domain_info to allow the 
RK3576 NPU domains to settle after the idle request is released. This ensures 
the QoS registers answer properly and prevents an async SError on the first 
cold power-on.

> diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rockchip/pm-domains.c
> --- a/drivers/pmdomain/rockchip/pm-domains.c
> +++ b/drivers/pmdomain/rockchip/pm-domains.c

[ ... ]

> @@ -681,6 +684,10 @@ static int rockchip_pd_power(struct rockchip_pm_domain *pd, bool power_on)
>  		if (ret < 0)
>  			goto out;
>  
> +		/* Some domains need to settle before the QoS registers answer. */
> +		if (pd->info->delay_us)
> +			udelay(pd->info->delay_us);
> +
>  		rockchip_pmu_restore_qos(pd);

[Severity: High]
This isn't a bug introduced by this patch, but is it possible that
rockchip_pmu_restore_qos() writes uninitialized zeroes to the hardware
QoS registers on the first power-on?

If a domain is powered off by the bootloader, pm_genpd_init() initializes
it as off, and rockchip_pmu_save_qos() is never called to save the hardware
defaults.

Since qos_save_regs is zero-allocated in rockchip_pm_add_one_domain():

    pd->qos_save_regs[j] = devm_kcalloc(pmu->dev, pd->num_qos,
                                        sizeof(u32), GFP_KERNEL);

When the domain is powered on for the first time by a consumer, this path
is reached and rockchip_pmu_restore_qos() directly writes those zeroes to
the QoS registers, such as QOS_PRIORITY.

Can this cause performance degradation or starvation for IPs in the domain?

>  	}
>  
> @@ -1300,25 +1307,26 @@ static const struct rockchip_domain_info rk3568_pm_domains[] = {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260805063826.95682-1-gahing@gahingwoo.com?part=4

  reply	other threads:[~2026-08-05  7:19 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-05  6:38 [RFC PATCH v5 0/8] accel/rocket: RK3576 NPU (RKNN) enablement Jiaxing Hu
2026-08-05  6:38 ` Jiaxing Hu
2026-08-05  6:38 ` [RFC PATCH v5 v5 1/8] dt-bindings: npu: rockchip: add rockchip, rk3576-rknn-core Jiaxing Hu
2026-08-05  6:38   ` [RFC PATCH v5 v5 1/8] dt-bindings: npu: rockchip: add rockchip,rk3576-rknn-core Jiaxing Hu
2026-08-05  6:38   ` Jiaxing Hu
2026-08-05  6:38 ` [RFC PATCH v5 v5 2/8] dt-bindings: power: rockchip: allow resets in a power domain node Jiaxing Hu
2026-08-05  6:38   ` Jiaxing Hu
2026-08-05  6:38 ` [RFC PATCH v5 v5 3/8] dt-bindings: iommu: rockchip: allow the RK3576 NPU MMU clock set Jiaxing Hu
2026-08-05  6:38   ` Jiaxing Hu
2026-08-05  7:10   ` sashiko-bot
2026-08-05  6:38 ` [RFC PATCH v5 v5 4/8] pmdomain/rockchip: add optional per-domain power-on settle delay Jiaxing Hu
2026-08-05  6:38   ` Jiaxing Hu
2026-08-05  7:19   ` sashiko-bot [this message]
2026-08-05  6:38 ` [RFC PATCH v5 v5 5/8] pmdomain/rockchip: cycle optional power-domain resets on power-on Jiaxing Hu
2026-08-05  6:38   ` Jiaxing Hu
2026-08-05  7:27   ` sashiko-bot
2026-08-05 12:13   ` Philipp Zabel
2026-08-05 12:13     ` Philipp Zabel
2026-08-05  6:38 ` [RFC PATCH v5 v5 6/8] accel/rocket: add RK3576 NPU (RKNN) support Jiaxing Hu
2026-08-05  6:38   ` Jiaxing Hu
2026-08-05  7:39   ` sashiko-bot
2026-08-05 10:34   ` Igor Paunovic
2026-08-05 10:34     ` Igor Paunovic
2026-08-05 12:52   ` Diederik de Haas
2026-08-05 12:52     ` Diederik de Haas
2026-08-05 14:06     ` Igor Paunovic
2026-08-05 14:06       ` Igor Paunovic
2026-08-05 14:07       ` Igor Paunovic
2026-08-05 14:07         ` Igor Paunovic
2026-08-05 14:35         ` Igor Paunovic
2026-08-05 14:35           ` Igor Paunovic
2026-08-05  6:38 ` [RFC PATCH v5 v5 7/8] arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes Jiaxing Hu
2026-08-05  6:38   ` Jiaxing Hu
2026-08-05  7:46   ` sashiko-bot
2026-08-05  6:38 ` [RFC PATCH v5 v5 8/8] arm64: dts: rockchip: rk3576-rock-4d: enable NPU Jiaxing Hu
2026-08-05  6:38   ` Jiaxing Hu
2026-08-05  9:06 ` [RFC PATCH v5 0/8] accel/rocket: RK3576 NPU (RKNN) enablement Igor Paunovic
2026-08-05  9:06   ` Igor Paunovic

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=20260805071942.DCC9B1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gahing@gahingwoo.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.