From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 87555C88E45 for ; Sat, 12 Sep 2026 06:53:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=1lNSWsa5yKt3sKsY0XAA4yLdaLfJ52HIF6FqGgDi9dk=; b=cDCHZvIO6fd2Mn 8h/r+3+25Nyv+FSPSL6CWALoTz2SHaodnf2aG2Whtap4XnJ3PBqJYvQNKyXz+LTnxO7qOYvhaDn4k u/PNWkzxr4Hw/rfhbs60mj5qzQTDzMqZNbksx39KaoMvyFKlWP2ZUds/+iynG49zEYLe0AF9Y42QZ MU/r2QqIoqb3LQhD0tJEHlij6BtQGXuJAyGfyAoQIeuT83+VOQm/fJ+1xPVaTo2Pu+ufmqGYxFM/t aeOZnp3fC6b+p5Ydd177vIQ/EDoyEeikiVLrqXCqfMv7SsP5PvArkxwwmBOx5O567wGRKcTI0SXRn ZR3QPIqG7xw1SztThXug==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x5Hbs-00000000c5y-0uZj; Sat, 12 Sep 2026 06:53:12 +0000 Received: from fout-b5-smtp.messagingengine.com ([202.12.124.148]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1x5Hbj-00000000bzX-1QAs; Sat, 12 Sep 2026 06:53:10 +0000 Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfout.stl.internal (Postfix) with ESMTP id 0165F1D00072; Sat, 12 Sep 2026 02:53:01 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Sat, 12 Sep 2026 02:53:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gahingwoo.com; h=cc:cc:content-transfer-encoding:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm2; t=1789195981; x= 1789282381; bh=e9LoMMVEroZGsuUE/y7jMO1McFxznbr3sDdiQfN22eo=; b=R qExlXUM0deJ7/whYA3v1mduBHnBnEKBhXEpoMY+nESYmYxRPLg3A622mwXnH+pbM eJMwN7zBUwSjlwW4olMB5hgIMlDIB1XdNiLvkZpmrhDmji+BTgGMQHCYmN6Elgjg O6/npKmBZP+VwuzHIBQPjSs6lLfwlordqOYr1Thu3+6mOkJ1lL0Sae4+JVa1kbbe tu7VBUfKmipw2aW8d8CsZ4+ku/ITAQLzlsKUAeWDLaftp5Q0tSIuvMHLqSTwVDhq be88nAyGoN06t0pUUiOOHrCEef1Ckd7umNa+rZNdDsSvlxUPZrE8PAQ9c4elow1I goE997VP64ZiOZM2UcGJw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1789195981; x=1789282381; bh=e 9LoMMVEroZGsuUE/y7jMO1McFxznbr3sDdiQfN22eo=; b=ZGf/yffUt5d225bK6 VNpRPHUFrBJqi9443RAVjPhBXrAAVZ13bSaAhMOz8NzLmy4R3iaQZ5R17faZDhL8 AG9WMxa9D2GseGknfkiEagFH6miO+wyIe7GYzDxZPM8AKA3FugXgj98R3eMkM9Lr Uw9MXS2QRlk4CS+XBYB/PSSzGIEZ2PNdiZ6vev1DxBf1THRoF4BY+nIZATLWx+P9 XiqVyczIVwpk4QHMD1RdZFQ5LsXK3TzqWM/9y0e2klWLkBO9x2ci/AQHHilB3nWD Xifn10Ng+o8TOMylEU4hBWCmOFnUz7QRRf2gDf9iyZNnCbRyFtADX5J78npe1xJj J34Zw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFWRe4FupnosV8kB1g6tNV76p6jywVrK0lcdqghhiQv/JHzElhv6b9tuqq+aCOLTS EmoFZAtvHzX5d9oQIr0J9Ha3BwGzdA3zpPU3H3YNHnAt/uad4hE/RhjgAgWIAwYn/Jhsox kSjja0/P5LO3n/qCpTlMjacpEbiJsr25Qz08lRqXdqFPuHljo+J9/XW71P/mKHyE4e8EuB SPTMsPmhqyOmbMtQUpJiSbig7TMVVj0Zv/9fE9y6HOUn0XwsjMX9WNsc0M6IEwHRKcBkea uw6ElX4ffC60dLVplCV5rfWQZ5xjClO3fTMZyxWN6JpcDVAycskmADuyvJ1IzcEA0uX7BT n08quT6Ro0ZptaZQMwqf0fhtjT0O4xARVxZtP6z8fTCeRL3WWRh7g/lpa5tNJ4USa5/K0b jKbQXhkmfffFlFi8vbdY+fkqZulW7qvXuPiFqUjFwb7605LDsyWRwXaQFJvZYDcru4yWyJ t9Ks4W6o3606U8p5jE/SYBDjDe3IfybtKXUPVmQ5d/6QhhE88RRtN+LczQVQsb6qJyqC/j GB/QYFzNdCQCJiePnWx55REtfh/vjhoGk9K3Cs4qY/bZHFVMtMrPsQ4EhR5ZyxjzlSAy8F ja8aP7NGvp0bqjsKrOAfboMFkP4PpPtOPHyTCjPsG1P4R1wD+hSHzlpJEYbQ X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Sep 2026 02:52:53 -0400 (EDT) From: Jiaxing Hu To: tomeu@tomeuvizoso.net, heiko@sntech.de, 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 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 Subject: [PATCH v12 10/14] pmdomain: rockchip: cycle optional power-domain resets on power-on Date: Sat, 12 Sep 2026 18:50:49 +1200 Message-ID: <20260912065053.1519165-11-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260912065053.1519165-1-gahing@gahingwoo.com> References: <20260912065053.1519165-1-gahing@gahingwoo.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260911_235303_477121_ACF45C83 X-CRM114-Status: GOOD ( 19.12 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org Some Rockchip domains come out of power-on with their bus interface in an undefined state. On the RK3576 NPU this shows up as a hang on the first register access after the domain is switched on, and pulsing the domain's resets at this point clears it. Take the domain node's resets if it has any, and pulse them between releasing idle and restoring QoS. The resets are optional, so domains that do not list any are unaffected. The cycle goes before the settle delay 9/14 adds, not after it. A domain that asks for both is asking to settle before the QoS registers answer, and a reset deasserted after the delay would leave nothing between the deassert and rockchip_pmu_restore_qos(). On RK3576 PD_NPU0 and PD_NPU1 ask for both, and the reset they cycle is SRST_A_RKNN0/1_BIU, the bus interface those QoS writes go through. It only runs when the domain actually changes state: rockchip_pd_power() returns early when the hardware already reads the state being asked for. A bootloader that leaves the NPU powered would therefore skip both this and the delay, which is why 9/14 gives RK3576_PD_NPU need_regulator and forces the domain off at probe. No in-tree DTS puts resets in a power-domain node today, so every other Rockchip SoC takes the optional get's NULL and is unchanged. Signed-off-by: Jiaxing Hu Reviewed-by: Abel Vesa --- drivers/pmdomain/rockchip/pm-domains.c | 27 ++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rockchip/pm-domains.c index 39988efd8..6cc8d6efd 100644 --- a/drivers/pmdomain/rockchip/pm-domains.c +++ b/drivers/pmdomain/rockchip/pm-domains.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include #include @@ -103,6 +104,7 @@ struct rockchip_pm_domain { struct clk_bulk_data *clks; struct device_node *node; struct regulator *supply; + struct reset_control *resets; }; struct rockchip_pmu { @@ -688,6 +690,21 @@ static int rockchip_pd_power(struct rockchip_pm_domain *pd, bool power_on) if (ret < 0) goto out; + /* + * Optional: some domains need their resets cycled once power + * is on. This goes BEFORE the settle delay, not after: a + * domain that asks for both is asking to settle before the + * QoS registers answer, and a reset deasserted after the + * delay would leave nothing between it and the QoS writes. + * On RK3576 the reset being cycled is the NPU core's bus + * interface, which is what those writes go through. + */ + if (pd->resets) { + reset_control_assert(pd->resets); + usleep_range(10, 20); + reset_control_deassert(pd->resets); + } + /* Some domains need to settle before the QoS registers answer. */ if (pd->info->delay_us) udelay(pd->info->delay_us); @@ -861,6 +878,14 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, if (error) goto err_put_clocks; + pd->resets = of_reset_control_array_get_optional_exclusive(node); + if (IS_ERR(pd->resets)) { + error = dev_err_probe(pmu->dev, PTR_ERR(pd->resets), + "%pOFn: failed to get resets\n", node); + pd->resets = NULL; + goto err_unprepare_clocks; + } + pd->num_qos = of_count_phandle_with_args(node, "pm_qos", NULL); @@ -931,6 +956,7 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, clk_bulk_unprepare(pd->num_clks, pd->clks); err_put_clocks: clk_bulk_put(pd->num_clks, pd->clks); + reset_control_put(pd->resets); return error; } @@ -949,6 +975,7 @@ static void rockchip_pm_remove_one_domain(struct rockchip_pm_domain *pd) clk_bulk_unprepare(pd->num_clks, pd->clks); clk_bulk_put(pd->num_clks, pd->clks); + reset_control_put(pd->resets); /* protect the zeroing of pm->num_clks */ mutex_lock(&pd->pmu->mutex); -- 2.43.0 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip