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