Re: [RFC PATCH v5 v5 4/8] pmdomain/rockchip: add optional per-domain power-on settle delay

[email protected] Wed, 05 Aug 2026 07:19:41 +0000
Newsgroups gmane.linux.drivers.devicetree,gmane.comp.video.dri.devel
Message-ID <[email protected]>
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 <[email protected]>

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-SYz5u2A9JnigSpxsJD1C4w@public.gmane.org?part=4