From nobody Fri Sep 25 13:16:57 2026 Received: from fhigh-b3-smtp.messagingengine.com (fhigh-b3-smtp.messagingengine.com [202.12.124.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A218E3603EB; Sat, 12 Sep 2026 06:51:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.154 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195880; cv=none; b=scAv5z4R4Yh1p4taZOzn7HqSIRG06EQaq1XEcC8bpyteejZXdzyx13AbhFmnH0+LgZO3QFZLSZSKT/xo3RdgeWkj72a0FKC/Bi3cH9O5WPiyJqAAZYoMLushEo1ScGh24flGvc5sVgDViEQlx/YgazU9g42fw5MeYQQOQc5bvDI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195880; c=relaxed/simple; bh=NzFBEuKw+edBTPRDPqk05HVymcwE1+Hsrc/T5KLMj4k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QIPD8JAlRy+nXOtpBYaXrrU3BncjYXVqvWer/wHQXZR8x+NbNujlkcVNY5AajpemBfyn4npI7MNpyZORaDLUEwSBjnpA9WQp0D/OZi75RrwgWFZOy3HsXWsA96LQYBGbstFxBXCBQxfkaHzRAVi/JoxlnzN8Jz7+tf/S9WtvE1Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com; spf=pass smtp.mailfrom=gahingwoo.com; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b=plxZdsK2; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=C6SAYQ4G; arc=none smtp.client-ip=202.12.124.154 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b="plxZdsK2"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="C6SAYQ4G" Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.stl.internal (Postfix) with ESMTP id 5B35E7A00D2; Sat, 12 Sep 2026 02:51:17 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Sat, 12 Sep 2026 02:51:18 -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=1789195877; x= 1789282277; bh=bhEwuQXKYWMYM7UfAE9zXDC7PfmHACUKFcOafx5HkO8=; b=p lxZdsK2iSvV5FW1MdCY6tEokp983VtNTVCeChB06QUL7IURbDbPjIl/ACiDyyzdH hEu5cy9aDujp7G5km1DNBFvlzAgpBLsP6BBcYJvYpboPZp+bzayOUbz9cqldaWDH kcP63TVItmRMzorcPzd2vOBSwftv6krxdeYhY7rt6mAMMYips+IozOGhT0lFpY0A j/5sYzCn1pzyRZUmmJKs+SfXMXPssTORqPc3rtYs9MiVqS02/S8vZC6c/LQjwTm8 NovqQgpdQLn1vx63+Cv4sU5ZZhVaJdfYxCWMNzrnEy7oKiUAy8lI1cI1/zJaHaHd ormn/ieXnm1dUpl9v2tYA== 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=1789195877; x=1789282277; bh=b hEwuQXKYWMYM7UfAE9zXDC7PfmHACUKFcOafx5HkO8=; b=C6SAYQ4GT8ChY1FVu 3xVvaqjQpCK1Iv2Jg4BG5D/d+DKnHpuDaMn9xEsCiNquww3OjaDiWYKXeOz+jLZa qcWYID63FsjiN26rV6tKT8de4ssm+wbN5BcuCAQZ4gGYeJ8V7uttv5vxhk39If/6 ubPY6CNPM1wZHTxlvUDn0i80xZJ+XdhrJsAyoEjZIKB/VkXnBi5Gp7H+3eo2Ikxv tjFe2i+YEzhuGb35kXtCgyR9rhTQCkLOZsdigicQ7GGKRQG94t6c9eZeX76zYc8V j0UmoRALtZ/yy1espElBfLFO+y1PzRnHLp4l5ANoiHgdWEfrHU1CetyYao+vPrLj 2mzEA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEPb8qUI/Bch63DUv9Os4CRaZnJidcR38w4lyHY6iaGmzqubjANrD0SeN/gjpgWtD 9JpSgLNav7upxo5UY8BD+gTgneuYvtjdT7xUeoI37l3u3ANYgfWTUMIQPTBe+0FGjKZ893 EmiED4E9ABLDGP636x+3BNPL+06gHQG63VHM2tKDilhH/OyX7+TagruxeFKd93pQCYj32B BeiQF2P6k05N47Few9BlXMbV3J128+kb4hnRL4hf+Yoc0wDQXXqOQeonbIg1B1tOCqO85x XB7Y9LiCcE2oZkETEXdiacCDRMuKmK7OMtWiJEvsJa8P7QUcJM2B6xHrJPAU/2XBsLk7LU MpW+EDDQJ2Ssp/huf9O4ilhDarGGDooD/tPvjmxA3kV4YuBLbU0NgpsKcM2c3FTAKYnEg0 jq5IGrTkmY47BXIoNJPhqR+oduqMGcqhz9nGiw6JhE/5cQUuLXQYPDV/lhGTFsq01TSQ0+ D0Rd5roncpHx5JToGc+FO/+IyrU4ThcP5qdZL0/9k0YZQesYtIDta4uUVindQa19N+8vMU ghKOp7XxGNAE2QzZbXQ1G24VOw7zkmCgza6Abzr7xYJij1+jA8wedKIl3szVqlWrKvTM9O LxBTeYBqYWt04zJFlH8p53hyWTHycR1oaZ9Cn2KNybLme2DHZyJfL52F+mzg X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Sep 2026 02:51:08 -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 01/14] accel/rocket: request the core clocks by name Date: Sat, 12 Sep 2026 18:50:40 +1200 Message-ID: <20260912065053.1519165-2-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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Igor Paunovic rocket_core_init() hands core->clks to devm_clk_bulk_get() without ever setting the .id members. The rocket_core array is allocated with devm_kcalloc() in rocket_device_init(), and rocket_probe() only fills in .rdev, .dev and .index, so all four clk_bulk_data entries are requested with a NULL con_id (unlike core->resets, whose ids are set a few lines above). clk_get(dev, NULL) ends up in of_clk_get_hw(np, 0, NULL), and of_parse_clkspec() only consults "clock-names" when a name was passed, so the index stays 0 for all four entries. Every entry therefore ends up holding a handle to the *first* clock of the DT "clocks" property, i.e. ACLK_NPUn. Nothing fails: probe succeeds and the driver believes it owns four different clocks. The consequence is that rocket_device_runtime_resume() prepares and enables the AXI clock four times, while hclk, pclk and - most importantly - the NPU compute clock ("npu", SCMI_CLK_NPU on RK3588) are never prepared or enabled by this driver at all. The NPU still works only because the Rockchip power-domain driver sets GENPD_FLAG_PM_CLK and its attach_dev() callback walks the device node with of_clk_get() and adds every clock to the pm_clk list, so genpd happens to keep the remaining clocks running. The bug is therefore latent today, but it means the driver holds no reference to the clock that actually feeds the NPU, which stands in the way of any future frequency scaling (OPP/devfreq) work. Found on an Orange Pi 5 Plus (RK3588) by reading the live clock tree: /sys/kernel/debug/clk/clk_summary shows four "fdab0000.npu" consumer handles on aclk_npu0 (and likewise on aclk_npu1/aclk_npu2 for the other two cores), while hclk_npu0, pclk_npu_root and scmi_clk_npu have no "fdab0000.npu" consumer at all - their only consumers are the "npu@fdab0000" handles created by the power-domain driver via of_clk_get(). Set the ids explicitly, in the order mandated by the binding (Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml): aclk, hclk, npu, pclk. After the change the driver holds one handle per distinct clock and clk_bulk_prepare_enable() covers all four. Note that this is a user-visible tightening for out-of-tree DTs: the old NULL-id requests resolved by index and succeeded no matter what "clock-names" contained, while the named requests fail probe with -ENOENT when one of the four names is missing. That is the right outcome for in-tree users - the binding requires exactly these four clock-names and rk3588-base.dtsi carries them on all three cores - but a DT that relied on the permissive lookup goes from silently running on the wrong clock handles to not probing at all, so record the change here where git log will find it. Fixes: ed98261b4168 ("accel/rocket: Add a new driver for Rockchip's NPU") Signed-off-by: Igor Paunovic Tested-by: Sidong Yang Tested-by: Diederik de Haas # NanoPC-T6 LTS, Nan= oPC-T6 Plus Reviewed-by: Sebastian Reichel Reviewed-by: Jiaxing Hu Signed-off-by: Jiaxing Hu Tested-by lines stand as he sent them. --- drivers/accel/rocket/rocket_core.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/accel/rocket/rocket_core.c b/drivers/accel/rocket/rock= et_core.c index b3b2fa9ba..5dd260bac 100644 --- a/drivers/accel/rocket/rocket_core.c +++ b/drivers/accel/rocket/rocket_core.c @@ -28,6 +28,10 @@ int rocket_core_init(struct rocket_core *core) if (err) return dev_err_probe(dev, err, "failed to get resets for core %d\n", cor= e->index); =20 + core->clks[0].id =3D "aclk"; + core->clks[1].id =3D "hclk"; + core->clks[2].id =3D "npu"; + core->clks[3].id =3D "pclk"; err =3D devm_clk_bulk_get(dev, ARRAY_SIZE(core->clks), core->clks); if (err) return dev_err_probe(dev, err, "failed to get clocks for core %d\n", cor= e->index); --=20 2.43.0 From nobody Fri Sep 25 13:16:57 2026 Received: from fout-b5-smtp.messagingengine.com (fout-b5-smtp.messagingengine.com [202.12.124.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2975D2FFF8D; Sat, 12 Sep 2026 06:51:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.148 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195891; cv=none; b=eMCKN5S+UL3ZbTvx6ImXSSpkJTH/1PIjZkmk0NlsoaqTNmaOeax+o6kA6D0eH3C5Gw+qq5iVVAc6DQA/EWuEv9QyAYLo7c6ZW6+fMej+WlcRhSkNa91febxCFCmx2utTnufLFOCPHf9AQzn2zIzZL98FZmJrF9f0OR2NU7edTDM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195891; c=relaxed/simple; bh=UQlOTZqVGNQ7grjM0lKayb8u7Z95Xocjl3oDH1Jwl4w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ri9Et7OrfPxl4FcruC/fL3prjadsUi3fr5BVrmG92ABC9lSDJDz4KKWsW/k680A+is2RR54G11CsSucifv351I/DdAuF9tKdLxkI15Xj18/ZXaZWw61Zb20Z0ENz5qfm9wI3wCk31WYldeywwhezjkYfY5F0nN/1eZwE+gUreuA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com; spf=pass smtp.mailfrom=gahingwoo.com; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b=SS3g8BQi; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=lQVrHRKb; arc=none smtp.client-ip=202.12.124.148 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b="SS3g8BQi"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="lQVrHRKb" Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfout.stl.internal (Postfix) with ESMTP id A17EB1D000AB; Sat, 12 Sep 2026 02:51:28 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Sat, 12 Sep 2026 02:51:29 -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=1789195888; x= 1789282288; bh=+AhFYA6kLyf5iGfmp128Qz+6Bq5cxqtA7vBGMdZdKi0=; b=S S3g8BQiNN0rjjrIU54x4c/RdkvrZdaZCBjtn7FuXi9mN55OGrkmIUOG5qU8OQ84k aHk/wp03TJRjlkNR0Mz00ndiYrO7qYZ2sZRcKR/CzXt5TV01VNvUwINTmpmIpDJD 29M/oTOgAdmposqg5pSWivjCI2RLPO3h+Ma9cDnVp+1cDka9v2rz75YQEYh83jzx ZXv9Saa04DV0xK0UpCOncPUYmBwcfhN7Ua0Rn4NjBFWroMTxp2VvnN3/ouzeQiv7 UN0FaAm2vNwn2MX18qLvkSNKnX5ZoPPzdDSXs7p/hQ3a4SfBobR+sOfc4wVeolt3 B1IGMpweTDzcCxLG7wj+A== 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=1789195888; x=1789282288; bh=+ AhFYA6kLyf5iGfmp128Qz+6Bq5cxqtA7vBGMdZdKi0=; b=lQVrHRKbGFVBaB6sw QsSyNVsIsYzGxpKguVjNE0nfR0P/82W05fDOhvtaLOwnpwE3TfChYosR6HYsqMA9 10OvWJRfgDGWsX+21SUQbq+52F/Wt1FcttGZo4FSA1Xy2l3Stv7Pua3MNYNs112I +ZtJSOa4NVofltkm1aIgaP6h6mNxJKskgEY7QSbB9eKQHI9hAS873c9BxkoKIikR Vo2cK/SHOIa4AgIJZj6ClOrpnBK/neVeYR7dgC2LY9OpgHZaIuTXeKGcdbY0D2Oq /sTNKqk2M8KSpqwvAzT8QoPtLe+Dy0/WT3+YGyHsXuejPMNu5w2U23o6penpYTPT KZLLA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEPb8qUI/Bch63DUv9Os4CRaZnJidcR38w4lyHY6iaGmzqubjANrD0SeN/gjpgWtD 9JpSgLNav7upxo5UY8BD+gTgneuYvtjdT7xUeoI37l3u3ANYgfWTUMIQPTBe+0FGjKZ893 EmiED4E9ABLDGP636x+3BNPL+06gHQG63VHM2tKDilhH/OyX7+TagruxeFKd93pQCYj32B BeiQF2P6k05N47Few9BlXMbV3J128+kb4hnRL4hf+Yoc0wDQXXqOQeonbIg1B1tOCqO85x XB7Y9LiCcE2oZkETEXdiacCDRMuKmK7OMtWiJEvsJa8P7QUcJM2B6xHrJPAU/2XBsLk7Rn nXZIEnpaOlhztllKAJmqmyh+1BzljzZIYJQP5kN4jjFJ3Wnbb9ZZ9+lsz43QONrs8SEMNK dqquehyN6IR5n4z86mAQdmMwp3CrMNrObcmpB6CFpGoQKMrVChoD4wFm11vKu+UF3D+eSq BZt1aLtJGUtzGOmm274iehc4Fq2KDfFcOfW53cYwTlzHHbyu88MzWVNr9EL8O9rKD7De8h y7aiIQrqqL+9FZd32fImranh3a9ruoVVx5fkLYYuZiSDNlwQ++jk+6PYesvKTQUsfYxODc wAFypyEme26SBcNkNMr5/S34wi4eYq1LHbkpMMPymMMur/0hOcyog4gQmjRw X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Sep 2026 02:51:20 -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 02/14] accel/rocket: take the completion register writes under job_lock Date: Sat, 12 Sep 2026 18:50:41 +1200 Message-ID: <20260912065053.1519165-3-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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" rocket_job_handle_irq() writes OPERATION_ENABLE and INTERRUPT_CLEAR before taking job_lock, while rocket_job_hw_submit() writes OPERATION_ENABLE from inside it. The two can therefore race: a completion being handled on one core can write its zero after a submit on the same core has written its one, and stop a task that has only just started. Nothing in tree hits this often, because the interrupt is the only completion path and it does not overlap its own submit, but the ordering is wrong on its own terms. To be exact about what the lock does and does not buy: a mutex gives mutual exclusion, not ordering, so it does not by itself stop a zero from landing after a one. What keeps the ordinary path safe is that the handler signals the job's done fence before the scheduler can issue the next one. The reason the writes belong inside the guard is that stopping the block and deciding what to start next have to be one step, which they were not. Move both writes inside the existing scoped_guard() rather than adding a second critical section, so stopping the block and deciding what to start next are one atomic step. Fixes: 0810d5ad88a1 ("accel/rocket: Add job submission IOCTL") Signed-off-by: Jiaxing Hu Tested-by: Igor Paunovic # RK3588, three cores Tested-by lines stand as he sent them. --- drivers/accel/rocket/rocket_job.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/accel/rocket/rocket_job.c b/drivers/accel/rocket/rocke= t_job.c index f40435505..575945015 100644 --- a/drivers/accel/rocket/rocket_job.c +++ b/drivers/accel/rocket/rocket_job.c @@ -345,10 +345,15 @@ static void rocket_job_handle_irq(struct rocket_core = *core) { pm_runtime_mark_last_busy(core->dev); =20 - rocket_pc_writel(core, OPERATION_ENABLE, 0x0); - rocket_pc_writel(core, INTERRUPT_CLEAR, 0x1ffff); + scoped_guard(mutex, &core->job_lock) { + /* + * Stopping the block belongs under the lock. hw_submit() writes + * OPERATION_ENABLE too, and outside the lock this zero can land + * after that one and stop a task that has only just started. + */ + rocket_pc_writel(core, OPERATION_ENABLE, 0x0); + rocket_pc_writel(core, INTERRUPT_CLEAR, 0x1ffff); =20 - scoped_guard(mutex, &core->job_lock) if (core->in_flight_job) { if (core->in_flight_job->next_task_idx < core->in_flight_job->task_coun= t) { rocket_job_hw_submit(core, core->in_flight_job); @@ -360,6 +365,7 @@ static void rocket_job_handle_irq(struct rocket_core *c= ore) pm_runtime_put_autosuspend(core->dev); core->in_flight_job =3D NULL; } + } } =20 static void --=20 2.43.0 From nobody Fri Sep 25 13:16:57 2026 Received: from fhigh-b3-smtp.messagingengine.com (fhigh-b3-smtp.messagingengine.com [202.12.124.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6123137417B; Sat, 12 Sep 2026 06:51:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.154 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195904; cv=none; b=ZaZAwQui12Uxyb71NtJMZWUFEzyfc5DygyTJNrPDWbXNZzBVmHQbrMRbw/2dKX6EDXzaqs5w0YsVQjgaG1HC16/mvNeoHlHsIqYmkc28oOo2syk9LjuGR2RS2KuYtnqiutjDSMHF6svM3E2g0JOOdoPmXVpvfh5thwJ9rtaXYOs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195904; c=relaxed/simple; bh=i5DiVlINgwnNhtS3vi9Pt2BdawjxGHAj3w84ic0jIXg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Bi39I6+AjZPZomQAYQymdXt40hUr0M24c3Z1gxSkqhJVLY35YhSCmnpIXJrhuwQAJ08q151BSvDtkBBa4Gy/4WyeUbFwV2BPu9RTnjCDXKG//jZteucUPXzRuIPgW9Wh5RgeAPahsKKW8wbRJQXToqyXA+6ajV+saxsbHvKtXTc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com; spf=pass smtp.mailfrom=gahingwoo.com; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b=Yndc+8yt; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=v0/m8Ix9; arc=none smtp.client-ip=202.12.124.154 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b="Yndc+8yt"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="v0/m8Ix9" Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfhigh.stl.internal (Postfix) with ESMTP id 06CED7A009B; Sat, 12 Sep 2026 02:51:41 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Sat, 12 Sep 2026 02:51:41 -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=1789195900; x= 1789282300; bh=dy/rZbJ8lujt892CZ6J3W3qCbtMy0BQKpDj3DzkhqMM=; b=Y ndc+8ytc9phVCsDpEJ5d1VIL8FnnEKgeFb0OifEaYmXrE+XpzOuvI0qogp3vXL3X w13tCTLBUN8+JHujZpmvwveKg8l4H1BDvPaQwjNXsVsx2WB1AMA330pd/HmYi5Dg nHGOTyIeHWwr7hb01iUXjzOlM1svQ9UUMB4dJXvT2XX9xuBgZaVRlj/dICANZbwp DD6t0FVJNLu6CowuIkIrWOxm9xU0BcKfqonVbqBdJKTaC7sU2jJIpcMeKc8QccGm HDNlzYXlNjxIaYyxoR4e7ipu6EH87bTA6n65iY+LbD695R6Z/PkH33ew06+AYK+T Tw2onIOOLy46HG+Pgn2Jw== 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=1789195900; x=1789282300; bh=d y/rZbJ8lujt892CZ6J3W3qCbtMy0BQKpDj3DzkhqMM=; b=v0/m8Ix9gyOqyS9Fl YBUfUL77Gd+87V/1v6dNXl7Qkr4/wKJSH8CPAhECqhNKyVNIjDnwblJ1FPGSYrtX eiIdZy6+aWD14iy+r2ONoaDM7D029QKsBVCy0gJitiXtBYsfokQt2ClHVYQ8SuqO /pbSNZgzyI7JaMHJzRGcwijKstIbI5sGwfwKu9tVtqb0gIXW5pFZiVe7N034ObIc F9ODJ2JHc20f1DvPirN/tLlW8ST6JTph7NTsJQPq2kX5YO6RY1IeC4FCZMh5GcnT 7sP4TUrSMAdfqX/QNJMHZJTtJlhR3gj7BGqD9cyNrq0GWuVviMXaJO6TBcVdigMC cu5bw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTE+xqYf+UNK3n3/SIVs5BMAkLL9SxSoeEa4aB1fL6sr5qoef0WXj/1D7lk0loNQgA 4wrb8ygN/2xkG75l4y4Fs8h3bchGJPI+qo1AnRPcGZkXLwTgZeTSmelpSlfpC1UBJUBigI 1uFUwuHYg71uhjWBx+7gOB0wn6akkmIMJLFlo26eFvuPPeo/6Kal04PCqlAm2Qq1tO2Cfv o3w83T+/2Kx2uyay0A4QdFPpF8s9PMsVXY0xB+GdGF9iMqqNE7jnJG1ikE4FT0u5FbUTpq 2eYTgupwj7OYcoX2KuqqrFT2VA0jtIcYybDBTRddmCPQ7BA12Wvv4mvQuWCvRqXsZSSFTA CJonMka8MMkBSjNQSjLHwBZeQ1p+OUy6IaRFfV23oAjaU2/SOWWLib+hJI2hn6vfeyG+LM Nt2RyX6L7vfu+pyDUASDDnfn/DUzUlroYPKJtlgqfXSkTQ7mO8NOPJCkyK18EJLXkMWKzp l0gMxDlR5lbQUEq4SBJTTpCecJHPO5CdKVez3Hgs2YYyEMVq9qectO2kJzaJKa0T8zDw3F T5hxc9NpyBQf8H1DyFF5zB7kG+RmNomJAkg8AtVD4/YsLUgAV+YEmhRoNNohbf8mo13fgm f1yCBXJ6aYqfXkimGFGvgFh/MHrEZxue9ARckpm4DNOcDAguzsbpurteQG3A X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Sep 2026 02:51:31 -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 03/14] accel/rocket: wait for a running IRQ handler before resetting a core Date: Sat, 12 Sep 2026 18:50:42 +1200 Message-ID: <20260912065053.1519165-4-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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" rocket_reset() calls drm_sched_stop(), which stops the scheduler and returns. It does not wait for a threaded handler that is already running, so the comment that follows, "Remaining interrupts have been handled", states an assumption rather than something the code arranges. Call synchronize_irq(core->irq) after drm_sched_stop() and reword the comment to say what holds afterwards. It has to go before the scoped_guard(mutex, &core->job_lock) rather than inside it. rocket_job_handle_irq() takes job_lock, so waiting for the handler while holding that lock would be waiting for a handler that is waiting for us. Nothing is held at that point: drm_sched_job_timedout() drops job_list_lock before calling ->timedout_job(), and the only live caller, rocket_job_timedout(), runs in process context, so sleeping there is allowed. This does not stop a handler that has already read in_flight_job from finishing its work on the job the reset is about to drop. That window needs the check and the register writes to be one step under the lock, which is what the previous patch does; the two are complementary. Mask the block before the sync as well. INTERRUPT_MASK is armed by hw_submit() on every submit and cleared only by the hardirq, so on an ordinary timeout it is still live and a completion can arrive after synchronize_irq() returns. Nothing is lost by clearing it, since the next submit arms it again. That write is the first register access this function has ever made, and it is guarded, because the function holds no runtime PM reference of its own. The only reference in the window belongs to in_flight_job, and the completion path can have put it and cleared the pointer before the timeout worker arrives: drm_sched_stop() sits in between and can block on cancel_work_sync() and on a dma_fence_wait(), and it subtracts every pending job's credits, so rocket_job_is_idle() is true and rocket_device_runtime_suspend() will not refuse. With the autosuspend delay elapsed the clocks are off and both NPU domains are down. A register access in that state takes an async SError on this hardware, which is the failure two later patches in this series describe from the power-on side. pm_runtime_get_if_active() resumes nothing and allocates nothing; if the core is already down there is no live interrupt to mask and the following synchronize_irq() is all that is needed. Only a POSITIVE answer says the device is active, and that distinction is not cosmetic: the helper tests power.disable_depth before power.runtime_status, so -EINVAL masks a suspended device rather than excluding one. pm_runtime_force_suspend(), which is this driver's own system sleep callback, disables runtime PM first and turns the clocks off second; rocket_core_fini() suspends the core and disables before cancelling the timeout worker. Both offer -EINVAL with the domain down, which is the SError this patch exists to avoid causing. The mask is written with a clear of the raw status, paired the way the completion path writes them. Masking alone leaves the DPU bit latched until rocket_core_reset(), and the hardirq decides on raw status alone, so a fault from the IOMMU sharing this core's line would wake the thread again and the guarantee this patch is about would stop holding partway through the function. Igor Paunovic asked the general form of this on v8 -- whether rocket_reset() should hold a reference -- and it was deferred then because nothing in the path touched a register. This patch is what makes it matter. The deadlock this placement avoids would not have been reported. The wait is on desc->wait_for_threads rather than on a lock, so lockdep does not model it and it would have hung silently. Igor also ran a differential on RK3588 with this patch and the previous one removed together, so what it shows bounds the pair rather than either one of them. On 19 August, 45 induced resets across both arms: no manifestation, oracle 48/48 throughout. On 25 August, the same protocol on v9 as posted, one of five runs on the arm without the two patches returned all 48 output channels at 0x80 from an inference that reported success, with nothing in dmesg, in lockdep or on the serial console, out of 102 resets across nine runs. His own bound on it is the right one: one event in 53 differential resets against zero in 49 with the patches, timing-dependent, and his protocol cannot tell a genuinely hung block from a lost completion. It bounds; it does not prove. Link: https://lore.kernel.org/all/20260819073530.6087-1-royalnet026@gmail.c= om/ Link: https://lore.kernel.org/all/CAEWPSH5mxTbUkNouxm6yecMZYvDowquhvYvhaXQ8= HoMtHD5U1g@mail.gmail.com/ Suggested-by: Igor Paunovic Signed-off-by: Jiaxing Hu Tested-by: Igor Paunovic # RK3588, three cores, ind= uced reset, differential base, JOB_TIMEOUT_MS=3D2 Tested-by lines on 2/14, 3/14 and 4/14 stand for that and only that. Tested-by lines stand as he sent them. --- drivers/accel/rocket/rocket_job.c | 49 +++++++++++++++++++++++++++++-- 1 file changed, 46 insertions(+), 3 deletions(-) diff --git a/drivers/accel/rocket/rocket_job.c b/drivers/accel/rocket/rocke= t_job.c index 575945015..0be8db391 100644 --- a/drivers/accel/rocket/rocket_job.c +++ b/drivers/accel/rocket/rocket_job.c @@ -377,9 +377,52 @@ rocket_reset(struct rocket_core *core, struct drm_sche= d_job *bad) drm_sched_stop(&core->sched, bad); =20 /* - * Remaining interrupts have been handled, but we might still have - * stuck jobs. Let's make sure the PM counters stay balanced by - * manually calling pm_runtime_put_noidle(). + * Mask the block before waiting. hw_submit() arms INTERRUPT_MASK on + * every submit and only the hardirq clears it, so on an ordinary + * timeout it is still live and a completion can arrive after the sync + * returns. The next submit re-arms it, so nothing is lost here. + * + * Only when the device is already awake, though. This function holds no + * runtime PM reference of its own: the only one in the window belongs to + * in_flight_job, and the completion path may have put it and cleared the + * pointer before the timeout worker got here. drm_sched_stop() above can + * block for a long time, and it drops every pending job's credits, so + * rocket_job_is_idle() is true and nothing keeps the core resumed. On + * this hardware a register access with the domain down takes an async + * SError, so a reset must not be the thing that causes one. + * + * Only a positive answer will do. pm_runtime_get_if_active() tests + * power.disable_depth before power.runtime_status, so -EINVAL MASKS a + * suspended device rather than excluding one: pm_runtime_force_suspend(), + * which is this driver's own system suspend callback, disables runtime PM + * first and turns the clocks off second, and rocket_core_fini() suspends + * the core and disables before it cancels the timeout worker. Both leave + * the domain down with -EINVAL on offer. + * + * Clear the raw status along with the mask, the way the completion path + * does. Masking alone leaves the DPU bit latched until + * rocket_core_reset(), and the hardirq decides on raw status alone, so a + * fault from the IOMMU that shares this line would wake the thread again + * and what the comment below asserts would stop being true. + */ + if (pm_runtime_get_if_active(core->dev) > 0) { + rocket_pc_writel(core, INTERRUPT_MASK, 0x0); + rocket_pc_writel(core, INTERRUPT_CLEAR, 0x1ffff); + pm_runtime_put_autosuspend(core->dev); + } + + /* + * drm_sched_stop() returns without waiting for a threaded handler that + * is already running, so wait for one here. This has to stay outside + * job_lock: the handler takes that lock, so waiting for it while + * holding it would deadlock instead of fencing anything. + */ + synchronize_irq(core->irq); + + /* + * No handler is running now, but we might still have stuck jobs. Let's + * make sure the PM counters stay balanced by manually calling + * pm_runtime_put_noidle(). */ scoped_guard(mutex, &core->job_lock) { if (core->in_flight_job) --=20 2.43.0 From nobody Fri Sep 25 13:16:57 2026 Received: from fhigh-b3-smtp.messagingengine.com (fhigh-b3-smtp.messagingengine.com [202.12.124.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF84A3624BC; Sat, 12 Sep 2026 06:51:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.154 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195915; cv=none; b=F3/f+aNJPoz1uh9TGF0djkGAbu7rHImzTQ8bVK/tvby7FJFjae671IbeAhOtUmpKknBKYgRFSdDHxRJfPhvr9vU68OzVTHLXwPsfvNWnCEcU8caB8duKyqUUI+J/r94qLVwv99klqq/tjLwNR3C5tPT5b0YZuIpLzXC3jJwIQiM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195915; c=relaxed/simple; bh=M4xh6eMrXGc2J2BIeRBFM91FP/hXrXSLQUopRAscVHI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sx9NOwSYCJ+XFo51kmUwBBoiKWvS1E0upOz6t7BPUU3HSTZxs6zfLHD2kPGjdYEG1wlloJPBqYmzwzlvuM7I7O/EPUzsJkS4WAF4ClPdkr1dL7AE7KVjldehl5TeQ3qyrLDlWuFJb443ouB2DbS7F5ZRJSxzACRzyFVRN68z1Kc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com; spf=pass smtp.mailfrom=gahingwoo.com; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b=KSQh1D94; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=dAu0IZl2; arc=none smtp.client-ip=202.12.124.154 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b="KSQh1D94"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="dAu0IZl2" Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfhigh.stl.internal (Postfix) with ESMTP id 916127A009B; Sat, 12 Sep 2026 02:51:52 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-12.internal (MEProxy); Sat, 12 Sep 2026 02:51:53 -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=1789195912; x= 1789282312; bh=2VGPOrJwM/1fzfaIuhVbGccUSYx13ajg4aSt3q/c7/Q=; b=K SQh1D94RCi6AoYKPYgM+SGXKw8NgAbMNnUuYeZPAVclCHy8y6xSjLcwOVOXoooM2 zSidZ36PfZnJioXtT+HJRSROjEMYOfQ+2JdJtq0EobKrG/D3eNCeU7G+XMgp4LcC BubSqGlxthYsp2CQmMfnJGqJQkZOaWPhYajiTjDH+G9d0CoOQAhuL6/l6vW5ToSw BVNf4b9yxnIMXlhPAZLGMZNxvb4b08x8Z1wQStiS6HmoOUAoLN83HRrRGdwIvNq1 DxrZvMGiHqFc1LFx4MwtvgueWwVgR2PvzeaQLRUidcUnI27umdkQ9TInuahKi75s j41IkgNkDwBtp39pK3bQA== 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=1789195912; x=1789282312; bh=2 VGPOrJwM/1fzfaIuhVbGccUSYx13ajg4aSt3q/c7/Q=; b=dAu0IZl2TfpoMJ6bT SVrGHV6QJVgy2Tyyot/L16AgXtzamldXGP9uEdXFe6r1tYGKiVs/SOMF2MAdXpLW HmHuSJiHSQ7GhfUnLJ7QJd9hb56ZDAkt4Pkc3AeoX5nCg/BplHvpcAso0w51mM5s A5hSd3J0NGojyiT8dViTg1ziqJ2Xa3CWWXyYnrLzzrbyr8c39qFjh3HimZq9+lMn rIb3c4v0k3FRhOZikIr4LnxuHZWI+zJXyan5riUaxN76QYabOjMKmy2meXVuOA+j T2760+CXz13LCds3aBlBQAjndnU/XwN1QK37QnHMvbyUrzaxbcTMnFeSb+wp8Jsv vw59g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTE+xqYf+UNK3n3/SIVs5BMAkLL9SxSoeEa4aB1fL6sr5qoef0WXj/1D7lk0loNQgA 4wrb8ygN/2xkG75l4y4Fs8h3bchGJPI+qo1AnRPcGZkXLwTgZeTSmelpSlfpC1UBJUBigI 1uFUwuHYg71uhjWBx+7gOB0wn6akkmIMJLFlo26eFvuPPeo/6Kal04PCqlAm2Qq1tO2Cfv o3w83T+/2Kx2uyay0A4QdFPpF8s9PMsVXY0xB+GdGF9iMqqNE7jnJG1ikE4FT0u5FbUTpq 2eYTgupwj7OYcoX2KuqqrFT2VA0jtIcYybDBTRddmCPQ7BA12Wvv4mvQuWCvRqXsZSSFtR Thh8Nm31j5n/ZrvrcB/CaqN2b+T77rkWnP2lBeJyLWYqXzXEfgoeeidlKdM+gMT4DS8in5 KxMWJEqW98g6qcFb78ZexlzMtorQJ1IMcHng1m874D6AfZjlylNXJ3sH2QWYt+DKUhb6GH 71iUa8DPzWdKGcDe28NevzHsKGYIzbWKTJqqVW7dIzXnHPll6xlGl1cJczBFuFcl11xVBB O92CEFAbZsI0UN6bVoeXAd1hZwd4Kb7pYQA7kEM0NnojzUS6e0dp4rlLZ2xoDMBOpN5BnN lvUEGnnZhBRv5ZBSE/N7QhYQ+hqVhYOFZ1mirjIAltdb3v7ZWHQt742h57Rw X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Sep 2026 02:51:44 -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 04/14] accel/rocket: let the core suspend after a reset Date: Sat, 12 Sep 2026 18:50:43 +1200 Message-ID: <20260912065053.1519165-5-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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" rocket_reset() drops the in-flight job's runtime PM reference with pm_runtime_put_noidle(), a bare decrement that requests nothing. The core is left at usage_count 0 but still runtime-active with no idle request pending, so it does not suspend until something else asks, and on a platform whose power domain does work on power-on that work never happens. On RK3576 that work is a bus interface reset the domain cycles when it comes up. Without it the NPU's IOMMU stops answering, and the job after a timeout returns a surface of the output zero point with rk_iommu reporting that MMU_DTE_ADDR is not functioning. Measured on a ROCK 4D in one boot, three runs, one variable between them. With the bare put the core reads runtime-active with its rail still up after the reset, the IOMMU reports the failure on the next attach and the inference returns 0 of 128 channels. With the reference put back through pm_runtime_put_autosuspend() the core reads suspended with the rail down, there is no IOMMU message, and the same inference returns 128 of 128. A third run repeating the first failed the same way. It also matches the put in the completion path a few lines away, so the reset path no longer leaves the device in a state the rest of the driver never produces. The remaining put, on the error path in rocket_job_run(), is a plain pm_runtime_put() and is left alone here: it unwinds a pm_runtime_resume_and_get() that never reached the hardware, and changing it belongs in its own patch. Igor Paunovic ran the differential on RK3588: 45 induced resets across three cores, with and without the two preceding patches, and the domain dropped every single time with no MMU message on either kernel. So this is not rocket-wide. His conditions cross a healthy block with a lowered timeout rather than a hung one, which he was careful to say his protocol cannot settle, but it is what scopes the change to RK3576. Link: https://lore.kernel.org/all/20260819073530.6087-1-royalnet026@gmail.c= om/ Fixes: 0810d5ad88a1 ("accel/rocket: Add job submission IOCTL") Signed-off-by: Jiaxing Hu Tested-by: Igor Paunovic # RK3588, three cores, ind= uced reset, JOB_TIMEOUT_MS=3D2 Tested-by lines stand as he sent them. --- drivers/accel/rocket/rocket_job.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/accel/rocket/rocket_job.c b/drivers/accel/rocket/rocke= t_job.c index 0be8db391..b588049aa 100644 --- a/drivers/accel/rocket/rocket_job.c +++ b/drivers/accel/rocket/rocket_job.c @@ -421,12 +421,12 @@ rocket_reset(struct rocket_core *core, struct drm_sch= ed_job *bad) =20 /* * No handler is running now, but we might still have stuck jobs. Let's - * make sure the PM counters stay balanced by manually calling - * pm_runtime_put_noidle(). + * make sure the PM counters stay balanced by putting the reference the + * job took, and request idle while doing it so the core can suspend. */ scoped_guard(mutex, &core->job_lock) { if (core->in_flight_job) - pm_runtime_put_noidle(core->dev); + pm_runtime_put_autosuspend(core->dev); =20 iommu_detach_group(NULL, core->iommu_group); =20 --=20 2.43.0 From nobody Fri Sep 25 13:16:57 2026 Received: from fhigh-b3-smtp.messagingengine.com (fhigh-b3-smtp.messagingengine.com [202.12.124.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 195F732E128; Sat, 12 Sep 2026 06:52:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.154 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195926; cv=none; b=jIEDDaRl0YugbcQS2LFFoOVZO+MmhGDya1u2hCB96W9Ry3FD+Ph/dm41FjJNr5tzd1LU3l8iliuAsobH6QUc1bd/a2utrWyzttieBs52EJpCygbMFi0Mdj2MlWDLmUTWLg2lWTf3kPLSN2UAHIRuHbCZals2sIQrCHRQx1jytg8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195926; c=relaxed/simple; bh=88FHouxIOTWiZNLtZ4sd/VrxWbIV+81Cr7r/eb3f00E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iNhtTyYwKk9sdjtho0Mmj/zLGyZg3y9oA+XlgXYyrNQptu4dBr4SkMix/+IWrhJL/qdF7YaTab4bWkoR5UkgK2E75rwvtJZsE7FGv3T4EzOFHaD8M8QAEflxKg/yZyDb39Prs+5AQjp+O95ny0TN/RiUVPAQ68AE/iS7yicggWE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com; spf=pass smtp.mailfrom=gahingwoo.com; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b=FXo259Pq; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=FpanS+M5; arc=none smtp.client-ip=202.12.124.154 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b="FXo259Pq"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="FpanS+M5" Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfhigh.stl.internal (Postfix) with ESMTP id A74EB7A00B7; Sat, 12 Sep 2026 02:52:03 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-12.internal (MEProxy); Sat, 12 Sep 2026 02:52:04 -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=1789195923; x= 1789282323; bh=n+cF16GIsW3+Z+8TyLHOWAsOJUvCToUrYBZTcA3LkCA=; b=F Xo259Pq3DOA4x3VIPhi8BbnQr+VExgyOUnYSqPO8gjk4Am9uxRL+9HcAH5U/62Bo qnjfNoDKXOrrH+8QGfFZ2+JOGCV8LGQ3BHSO/FMOMogGNkUOZ+jbDPPlIyzWBVu/ SUJ8b/HNb9EroZqjxo6qzruzRr1+XduEs0/aZfrSH8P5lIC9gPGXa+bH42+DBjvx m4wGvHfVIRR3Kqq+dCJI2NUV7Ih9QaQNZsLa6AG6jk7uL78U+FDX2uMs6Cv7D3nT 4szE7NSFwUFeslRwccq9DKqZ3wUWrAZYjKd0OvHHEZ9ecOMw6Y6wlyWa15wau3iQ wk9G63fzmo3bX4FVevNjw== 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=1789195923; x=1789282323; bh=n +cF16GIsW3+Z+8TyLHOWAsOJUvCToUrYBZTcA3LkCA=; b=FpanS+M5tk0sSrrAb aVDJMkYZWmyHpucd5m77w1kOM5375ZidMiwi/Q5vwWgmysBMarFlARmd44QsTgKs mVDgEDP9lUgZ1H2yAy7IyB2EyYXWFw0cqX10OOohMmOU0LzoADpjNBzIKaqRjxyR vikHOLrKEdBe7TeCHLKRqf15Ma4faQLzmCqOfVXniOWysIjIZKuuFRNj3AUpiOHn 31vmvzKUjgxM2TkumkEnW8EyCT9n3Z6SZieHzqx6K2lDE693i2XCIq3rlRuMXfT4 YCcU+Hp9PMIKu4B0Q+jqOFTNkUkAthUGU2x06RQCHEQAtwiaDYy9Z0ZMNPcizicE XAX+Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEPb8qUI/Bch63DUv9Os4CRaZnJidcR38w4lyHY6iaGmzqubjANrD0SeN/gjpgWtD 9JpSgLNav7upxo5UY8BD+gTgneuYvtjdT7xUeoI37l3u3ANYgfWTUMIQPTBe+0FGjKZ893 EmiED4E9ABLDGP636x+3BNPL+06gHQG63VHM2tKDilhH/OyX7+TagruxeFKd93pQCYj32B BeiQF2P6k05N47Few9BlXMbV3J128+kb4hnRL4hf+Yoc0wDQXXqOQeonbIg1B1tOCqO85x XB7Y9LiCcE2oZkETEXdiacCDRMuKmK7OMtWiJEvsJa8P7QUcJM2B6xHrJPAU/2XBsLk7hb LW4LfTP7Zdkq68MwmwIaACDlM3y/lZUL4DyZDST0DO8C87Su9xOuC/r8LQ3Vc/3/7AgZ4N VCp2yv52tLJGGeWpYdy2RpAgRnsLkQOqhcB5cXy7kWhc74WBf4rjUpq38oYydmvpLMBN+y b5rCet9H1T8s3lIo9Paeh90N+C6CbMXxDlyp045H6EHzElqY1eMF1IJ8OKmk3mq8kMNr/A e4atOiYHYAbFJR65q2DiLgk5tSwSsxvbT3w68wEQvviJa7cIXCcdKtBAA3X4jMmpgnmDG7 CIZiHw235OvMylowJfGGVTs6GIj4gvZu4zrDL4X3f3A0JNo7mR+bbxjnRMQg X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Sep 2026 02:51:55 -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 05/14] accel/rocket: factor the completion tail out of the IRQ handler Date: Sat, 12 Sep 2026 18:50:44 +1200 Message-ID: <20260912065053.1519165-6-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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" rocket_job_handle_irq() stops the block and then either starts the job's next task or retires the job. The second half is a step of its own and reads better with a name, now that taking the register writes under job_lock has moved it a level deeper inside the scoped guard. Move it to rocket_job_next_locked(). The early return that used to leave the handler now leaves the helper, which is the same thing here: the scoped guard drops job_lock either way and nothing follows it. Doing it as its own patch keeps the locking fix at the head of the series minimal, so a bisect that stops before this one gets that fix and nothing else. There is one caller, and no functional change. Signed-off-by: Jiaxing Hu Reviewed-by: Igor Paunovic Tested-by lines stand as he sent them. --- drivers/accel/rocket/rocket_job.c | 31 ++++++++++++++++++++----------- 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/drivers/accel/rocket/rocket_job.c b/drivers/accel/rocket/rocke= t_job.c index b588049aa..8cffe93f6 100644 --- a/drivers/accel/rocket/rocket_job.c +++ b/drivers/accel/rocket/rocket_job.c @@ -341,6 +341,25 @@ static struct dma_fence *rocket_job_run(struct drm_sch= ed_job *sched_job) return ERR_PTR(ret); } =20 +/* Start the job's next task, or retire it. Caller holds job_lock. */ +static void rocket_job_next_locked(struct rocket_core *core) +{ + lockdep_assert_held(&core->job_lock); + + if (!core->in_flight_job) + return; + + if (core->in_flight_job->next_task_idx < core->in_flight_job->task_count)= { + rocket_job_hw_submit(core, core->in_flight_job); + return; + } + + iommu_detach_group(NULL, iommu_group_get(core->dev)); + dma_fence_signal(core->in_flight_job->done_fence); + pm_runtime_put_autosuspend(core->dev); + core->in_flight_job =3D NULL; +} + static void rocket_job_handle_irq(struct rocket_core *core) { pm_runtime_mark_last_busy(core->dev); @@ -354,17 +373,7 @@ static void rocket_job_handle_irq(struct rocket_core *= core) rocket_pc_writel(core, OPERATION_ENABLE, 0x0); rocket_pc_writel(core, INTERRUPT_CLEAR, 0x1ffff); =20 - if (core->in_flight_job) { - if (core->in_flight_job->next_task_idx < core->in_flight_job->task_coun= t) { - rocket_job_hw_submit(core, core->in_flight_job); - return; - } - - iommu_detach_group(NULL, iommu_group_get(core->dev)); - dma_fence_signal(core->in_flight_job->done_fence); - pm_runtime_put_autosuspend(core->dev); - core->in_flight_job =3D NULL; - } + rocket_job_next_locked(core); } } =20 --=20 2.43.0 From nobody Fri Sep 25 13:16:57 2026 Received: from fhigh-b3-smtp.messagingengine.com (fhigh-b3-smtp.messagingengine.com [202.12.124.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B1B3E3624BC; Sat, 12 Sep 2026 06:52:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.154 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195938; cv=none; b=VR4lXrvfGHV12c/gqUHM+azyGna4oflodpYdQRWYqwWbEffgaZXWjyKBEzfWJG8xNPDREltAkOYPSXNMSVGJzyJKIZeRAqGugBH7QMbXRmLR2/MvfLmSkTFC6ChrAxo1LBDlT0PGO+c1MfQuHE9BE/pOyKEtYRrD3YZJ7k9mn+o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195938; c=relaxed/simple; bh=k+gwYS+NobpdAIM3dOhrv68WcBmgsiY15gPhhplWBQ0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=keNBGkT3iLyp9WYO1x63bw+kDgkN9nNcGOlmtZipw9rFaXAKx9W56UGLbPFJOWKnyqZ8b/GGCiuEBctcQzgzVPvJfJaKUBgQsA2ktOoiBlju8jTY0VnGfZu38FohI5j1B8ftDdeBM5ETCYd4M/ppBh+4/nSNzNhux1aDnVxZfbQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com; spf=pass smtp.mailfrom=gahingwoo.com; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b=MlDUgksS; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=jV2N3I12; arc=none smtp.client-ip=202.12.124.154 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b="MlDUgksS"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="jV2N3I12" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.stl.internal (Postfix) with ESMTP id 562A17A00B3; Sat, 12 Sep 2026 02:52:15 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Sat, 12 Sep 2026 02:52:16 -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=1789195935; x= 1789282335; bh=muWc6YiNsdF4ep6300eTVDZM5wKjxIUffmssTrDfe8A=; b=M lDUgksSQfhwS1SeQvwtids85hOo30/RVE2g38RcQk1smF6hDGLDbCsc1f71Tvcpz wxiYCzBpUmTBqlwOYF8NJCwVtFGasMU3276L6UeGp6PM9bxBLXHW0WZs3PHdYWsV dK2fnVw1tpwZv7VlzL7EhtnR7HufLxSo+d/nHAbUIjC/7Opnl+NWxCCNI6iKoKTM PTRS0jRSuQESZMgAv7e+ocWhFCpxReDXBsL2PgV9M6Jo/2MFsZGwnACUwNKCXTCT V9jRjhZIgjmr43Frgc3GlHiKnGpEAaUsODwxoC/sSRH1djtJeJLJctp8T0AEjJcy jBnwcVerbTcZCIEkCZBpg== 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=1789195935; x=1789282335; bh=m uWc6YiNsdF4ep6300eTVDZM5wKjxIUffmssTrDfe8A=; b=jV2N3I12yNcTXbgLR KLb5PuuO9oIe9dHPRiT/GK5E9ItAIlJ762VBy6ssV29pbhlIlXRgBP8jnYMQC/+H MuVulvspRb+ebqrvdyMwdhCinT3aB9Nxnulq3/crKwm4DmY46FphUSJ1q9XYDmdZ 4DsPR6zg/eX7td63tJbmYspU7J0L9k4MpwVYEo16S3y0M2iVztmrBj0onLXf+dxV qBxpqYAeiyh9NEO7Vo7r5Q1F+ZjaI7BbN7+XZoupqTDYOaIhrYe75tNHdHDrjz5w NHk2527EJ1tIILLyJv+n5tlm3pGJ8d/wSvQwzwymdAU0RJ/PzRBx4J9QLv1PWuOP qNjkQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGcFzQLfCTns7TE5rL/P1eVKE8QA21beBwBFkyY9YTeXq4RsTqFTQqy8xwPCXflst Bzb2WN8+Z9wMsDPevozKXmCdfbpB7u35gxPBdZcE1OggzV+SpuJLXHq2biTYWRbmSZxKVK SGSCjqFmU7DVBX5xWAgirxAFKhQFJBsPmOT+6pwgRseCRI2yQSz8RIt35R9bMFoCkvmZR+ 9iAYcTwRUMbNeagNJ0dRavH1kOhxbKzZutjdkaXg936crjsT5yruCxuJ1iD3z1iXsOeTBA gQ1aPtegLyhOeojTrex/RjcmOrlktpryCA6Bl5bNjcl7LPMImDh/uFZbWCql0nAGPJnZbK oQHC/jR9dUxKwsQi6AKcF70kVGGtKznY5nSXpDvT9POZfour6tAk2kgygeQlwKj0O/CqPr 78GTdtZo1hF36ItD+CVCz+LxtCwM0UU4yeoiYyR8u+xBJgEWPOunUU0fLzkMj7QRZnjWB9 q7A2FHda5iMpedjOO3DEaqKAg6As6j65P6ku7eH/tjgBn7XBis06vWyeawovxQ72GnmEzh A15fgczvJqy+8A1g6mkvdSWaK0hVxjzJCwDRXmNZHwHV+K6hRRHE+KcGftyqNqaJZLwZ9y b89p/PEushz/MD0vT6rEKyLHiE3yA+z+XNUGQTpBOLCxJ5F2OvCItxOPz1bQ X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Sep 2026 02:52:06 -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 , Krzysztof Kozlowski Subject: [PATCH v12 06/14] dt-bindings: npu: rockchip: add rockchip,rk3576-rknn-core Date: Sat, 12 Sep 2026 18:50:45 +1200 Message-ID: <20260912065053.1519165-7-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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The RK3576 NPU has two cores of the same RKNN block the RK3588 binding already describes, but it wires them up differently: two extra CBUF clocks, two power domains per core, and a single reset instead of two. It also has no NPU SRAM supply. Widen the property ranges to cover both, then pin each SoC back to its own shape in allOf so nothing loosens for RK3588, and keep sram-supply required for rockchip,rk3588-rknn-core only. Signed-off-by: Jiaxing Hu Reviewed-by: Krzysztof Kozlowski Tested-by lines stand as he sent them. --- .../npu/rockchip,rk3588-rknn-core.yaml | 47 +++++++++++++++++-- 1 file changed, 44 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-cor= e.yaml b/Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.ya= ml index caca2a490..3b611b64c 100644 --- a/Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml +++ b/Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml @@ -21,6 +21,7 @@ properties: =20 compatible: enum: + - rockchip,rk3576-rknn-core - rockchip,rk3588-rknn-core =20 reg: @@ -33,14 +34,18 @@ properties: - const: core # Main NPU core processing unit registers =20 clocks: - maxItems: 4 + minItems: 4 + maxItems: 6 =20 clock-names: + minItems: 4 items: - const: aclk - const: hclk - const: npu - const: pclk + - const: aclk_cbuf + - const: hclk_cbuf =20 interrupts: maxItems: 1 @@ -51,12 +56,15 @@ properties: npu-supply: true =20 power-domains: - maxItems: 1 + minItems: 1 + maxItems: 2 =20 resets: + minItems: 1 maxItems: 2 =20 reset-names: + minItems: 1 items: - const: srst_a - const: srst_h @@ -75,7 +83,40 @@ required: - resets - reset-names - npu-supply - - sram-supply + +allOf: + - if: + properties: + compatible: + contains: + const: rockchip,rk3588-rknn-core + then: + properties: + clocks: + maxItems: 4 + clock-names: + maxItems: 4 + power-domains: + maxItems: 1 + resets: + minItems: 2 + reset-names: + minItems: 2 + required: + - sram-supply + else: + properties: + clocks: + minItems: 6 + clock-names: + minItems: 6 + power-domains: + minItems: 2 + resets: + maxItems: 1 + reset-names: + maxItems: 1 + sram-supply: false =20 additionalProperties: false =20 --=20 2.43.0 From nobody Fri Sep 25 13:16:57 2026 Received: from fhigh-b3-smtp.messagingengine.com (fhigh-b3-smtp.messagingengine.com [202.12.124.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4350B3624BC; Sat, 12 Sep 2026 06:52:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.154 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195949; cv=none; b=U71FjgiUCFekwvGaOcXVMa7s5NTyiZmjMxEqxuetYfgp1KExL1vSLtCxIVsa2VPvUgi4ZSVaJEfDLw3iVXmbuW+GP/KXzNx1oRkTJi/BtCG3KApBUT+fUaelJc+G7SCqI/GX5nbMtIujbp3TANXG3YUoj3PoRfJzBlAkpz2k0yQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195949; c=relaxed/simple; bh=dNAZ2fcLPxuDRucYqOpUmntaART7AfrXkvG+7ZnZ/ck=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Y+yyPYVzJNquUpJBd3e2eBaqxp8u/nqMmt+ABmLneclHzVh76wac7nYgGb7L8LSqevrVNy1pb+5wrXqXncEGgY+vGbFMIpZ2fIdlgAf1TVf6HShPErLPitMG4U4jISIESOejs34yMaqAuwDWeny4EqNnGh+vy18tkrTZEmfZ2kA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com; spf=pass smtp.mailfrom=gahingwoo.com; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b=WOeEfcpF; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=kUmk15fQ; arc=none smtp.client-ip=202.12.124.154 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b="WOeEfcpF"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="kUmk15fQ" Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.stl.internal (Postfix) with ESMTP id 0B4207A009B; Sat, 12 Sep 2026 02:52:27 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Sat, 12 Sep 2026 02:52:27 -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=1789195946; x= 1789282346; bh=2mKKiQO9zpo513ebYoXsjxDsShdmIQsmiSfHdP5Kuwk=; b=W OeEfcpF2CserbKBFBqwfGzoEVFzmFwt6Xee+pVLHWhHJy2p83GBI4113eRlu/AkB eOqn7tl79HBnf/svoO+LKD1lDw20C1SEZfyBn8EcuIi260cn1c4zIdMPpsFIobxK aMZyhOgRfMxb+qmoTugxZ3xmsRwHYwb/IoXo7kWhN2fqct+2WgPKwbvZCGj0l+Dc xNvOZV/chGFTFvhZ2iDS2Yt5vCkDfRQ6Ys5d8OuS3/fJVXHPsZ+7HLzeL9vhz3i3 NEFEy1ofsfW99qzO4s0U30HA4We6BBBniFF2eml/suTc3+z4oLW0y0oMPqsOEBOF ifYDRLCH6LiHj30nqrUCQ== 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=1789195946; x=1789282346; bh=2 mKKiQO9zpo513ebYoXsjxDsShdmIQsmiSfHdP5Kuwk=; b=kUmk15fQ444zlWr7O 6iUTtv7WXpcUaCfqExLOJqtwB7+ONzzFYC8SDNhlDK5n0euAXC4v4fpfgggNyc5d A+FZqlYZy3MTJjE6CN0fQ9bMafPrRGazi82IjFamzINSqUwavLRoeyLUJ/vVfV+7 Z8FlkD8Hcy6EfVksMiqU2H4TP+l6nJPJfgPuYRD7Km7PrB0DFQQ4Ap2Bqqk09gaD f8Eo3RLv+3SpV0PptFc1Tut83BgfT1swJ+ubE9gB+AAaEIkoavWG9d2PNVpqXz+W lmiu96ODDqK42TrhB+6ZlBBEOh6pF4M+WaB2cmkJ3F5Abxzvs3ojOaRDaLEwDMQ0 PE5rQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEu1UivQs0afaRwUSouQVT9fA+dkflD6xboTnJ8/VAbYbVKvUN4MK/f41UbmxFFxr Ze/lAcGl5aaDrgNdh5RizAYp6gZ1Fmr3KCjz7zHDD4cOn39vzVmTzK5WxaodNDQGOkfvgV TdFpznrAgjbTayTTszyCWlN72zMOkFQpdze8A+hMde794s2VEYQ8toT2zFE5mRrYgzN6+t tk2rE/tKTqe3b+QIO1iV7bQxdgYWyGe9yctTl5iCm6FOwVGrXz7LH6jTkXm+ksK0e2c6Ew aHyzLoG7vkGqykDqvyMzIEE3oCVwgpZfOgFBq2VtY2d5nhXH0wGpaJHM0aFW6G+GK5/an7 ABdJM2mkn8coI7hbY5QaeQJJcbb6abS31gkUBP1Df2UTH5O+bK+tcVlG34lPX6IM9EMARG qdkIZ/9s4Ena7Mxqnq9A7v9P8MhDgn8OqlJPoM5mR7gboWWNSVsxjsFHptXLEPpI8M5Axs aaxkL/GEs9YLYxT1kddzJd/13YSn6bvWjjINzPidBffWTVXf+YFnptR8pGDNakp4CANzRA 2YnuMmaInjfz6OhZPl4fCEMBKy+oGx5X70msLejX3SzJATH98c0imNiGID2a3y0SJYjA88 FaMNspF4xqoPbZSrmYmgO9jvvuEdRbobE/K4SyMnFrUpMoy7dAcZw1IWJ16A X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Sep 2026 02:52:18 -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 , Conor Dooley Subject: [PATCH v12 07/14] dt-bindings: power: rockchip: allow resets in a power domain node Date: Sat, 12 Sep 2026 18:50:46 +1200 Message-ID: <20260912065053.1519165-8-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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Some domains do not come up in a usable state on their own and need their resets cycled once power is on. The RK3576 NPU domains are one case: without it the first access after power-on takes an async SError. Signed-off-by: Jiaxing Hu Acked-by: Conor Dooley Tested-by lines stand as he sent them. --- .../bindings/power/rockchip,power-controller.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/power/rockchip,power-control= ler.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controlle= r.yaml index b41db576f..83741f048 100644 --- a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml +++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml @@ -136,6 +136,13 @@ $defs: A number of phandles to clocks that need to be enabled while power domain switches state. =20 + resets: + maxItems: 1 + description: + A phandle to a reset that needs to be cycled once the power doma= in has + been switched on, for domains whose logic does not come up in a = usable + state by itself. + domain-supply: description: domain regulator supply. =20 @@ -216,6 +223,7 @@ examples: reg =3D ; clocks =3D <&cru ACLK_IEP>, <&cru HCLK_IEP>; + resets =3D <&cru SRST_A_IEP>; pm_qos =3D <&qos_iep>; #power-domain-cells =3D <0>; }; --=20 2.43.0 From nobody Fri Sep 25 13:16:57 2026 Received: from fout-b5-smtp.messagingengine.com (fout-b5-smtp.messagingengine.com [202.12.124.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4E61E37757A; Sat, 12 Sep 2026 06:52:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.148 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195961; cv=none; b=byj59rA5Cllzo/T+hUz+rXUxT20kiOCusJAqBqI2x4UOo+Th0uxeQX43zwyc6tl6O2dBKCwuTauVLoSBq0WanUeCiDM9s7LO0h2R//N3GdalFtPiCZq8+V3Q7wtQbSYfM/XaMfmF9bLZUhMkoSDvxlHMyAtaRLjvrjDAZOrgXDY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195961; c=relaxed/simple; bh=t8745wRWNkKuyuDHBQoZFLJWeOid9g1cW7YEvJI2P74=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KflzCn/mVBQjKI9TZR2WX7q+YfRhJ0jjSbfCMGYJj5Y9y5ghtrmi1JVCi3hmojwnx9+EfmUPbL7q+WjcXCrKmBIUPWd2RDVuD5QL7domiE39Y5duZtZXgRhRaIZRrcrUBqkqDcb4fS2YaMBqcZcknvgXhOOyMcfYNMubICIN90I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com; spf=pass smtp.mailfrom=gahingwoo.com; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b=aoq0qVOD; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=H/vijw4k; arc=none smtp.client-ip=202.12.124.148 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b="aoq0qVOD"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="H/vijw4k" Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfout.stl.internal (Postfix) with ESMTP id B8D951D0009D; Sat, 12 Sep 2026 02:52:38 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Sat, 12 Sep 2026 02:52:39 -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=1789195958; x= 1789282358; bh=EM0swreY1zyIAIB6E9vTAuQx73Txv82P4kLUWclFi0w=; b=a oq0qVODpppXKnPRakSL5E6z54rIYx4vH9BACdB7jMkMe9HbOxUYFUEVT8VZH6mfh CWmJLMQsJbMATTWzb29O63Eg1JQ9CCSrqPe4oFPJL5YWGNGbGVLraQmQjPVHLasL dpS0qnd/CGe8Cz+xVsHqEcXRpqIWOE3/ZolRMrChlWGGWsD8his0p5Y3PbvpYLPz xH/+EkHk5P3xFkK3naJUDu3MRlQLoQDul6LB31LkPlZU1UaXG6U3Ds9lrdh6ylz3 /1LzvioFmF3thYu+BIZ/MjwZMjm9Cn9aK+IfTN2C+l3EyLkqVtht5b4dYYB0R0ic 1eXis/56g82MPQJLsBc/A== 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=1789195958; x=1789282358; bh=E M0swreY1zyIAIB6E9vTAuQx73Txv82P4kLUWclFi0w=; b=H/vijw4kICc2fVZlB yJKypO0KFUUji0jL4rjBWUM9sjnePPp4ktyF5Toxgwh4BIgl7AYM31K4qab3De1A E9l7x3SQ4VomBoYrMq5UE7w4qp+ZEJOqvfCZl7J99/HnIGJAn/pgpUHh0nC881lV 4CDWaZS70dzUv14KByoH9bigftxeHRcIfRjVOS+aizD0q8RPueg/U7NbBO6L2PNE INknbFY8TklEZz2R9pHzaT2nOQ9Ek1kPxuFiVDu4GewRWED7rtUMMVEOF74jFlff Do12qUYK0PTlnfG3BLUcnQp7spinIpzH50dWdmINK6MOeWYnm2nuSKcHgaBHEfAg aV3sg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGcFzQLfCTns7TE5rL/P1eVKE8QA21beBwBFkyY9YTeXq4RsTqFTQqy8xwPCXflst Bzb2WN8+Z9wMsDPevozKXmCdfbpB7u35gxPBdZcE1OggzV+SpuJLXHq2biTYWRbmSZxKVK SGSCjqFmU7DVBX5xWAgirxAFKhQFJBsPmOT+6pwgRseCRI2yQSz8RIt35R9bMFoCkvmZR+ 9iAYcTwRUMbNeagNJ0dRavH1kOhxbKzZutjdkaXg936crjsT5yruCxuJ1iD3z1iXsOeTBA gQ1aPtegLyhOeojTrex/RjcmOrlktpryCA6Bl5bNjcl7LPMImDh/uFZbWCql0nAGPJnZaS zdKKvXa9SA/dGvws1TOyEh4ZUXZwlBjLII62HKVkwVWgeGVwaFrXrqpY9VMxugXm0tfJ3/ a1Hu10SVG6l8yxaYgppfYRNzLZB1Zu4LV7oBec8+/THRnRnkSSUDpzp08N2EXsaGtTgH3o 4MqKgHXLt4qQ0s7ONoZ1jieJ56CXHsqa2vkw35koiK6l+a1GFV3bwjREl0CKNQ2xNU5svW /5VzqqwQwZpMq6rwcTQKwc5oSwhb5stX3oyKZ8boDg1Qlr9UJznRmjCM8KFAEKj6i/sQU0 h3v4gaK3+wYc/UUM1XeyKLDSvqnAhZtGhq/pLutoaM3/FuO3/FNT/6FIMvbw X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Sep 2026 02:52:30 -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 , Conor Dooley Subject: [PATCH v12 08/14] dt-bindings: iommu: rockchip: describe the RK3576 NPU MMU Date: Sat, 12 Sep 2026 18:50:47 +1200 Message-ID: <20260912065053.1519165-9-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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The RK3576 NPU MMUs are rk3568-iommu compatible but take five clocks where every other Rockchip MMU takes two, the extra three being the compute clock and the two convolution buffer clocks. Give them a compatible of their own and pin both sides with an allOf, so that an rk3568-iommu cannot carry five clocks and an NPU MMU cannot carry two. Describing the extra clocks as belonging to one SoC without saying so in the schema, which is what a comment on a description does, leaves both of those spellings valid. Signed-off-by: Jiaxing Hu Acked-by: Conor Dooley Tested-by lines stand as he sent them. --- .../bindings/iommu/rockchip,iommu.yaml | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/= Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml index 6ce41d11f..83d7e7c8e 100644 --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml @@ -26,6 +26,7 @@ properties: - items: - enum: - rockchip,rk3576-iommu + - rockchip,rk3576-npu-iommu - rockchip,rk3588-iommu - const: rockchip,rk3568-iommu =20 @@ -42,14 +43,22 @@ properties: minItems: 1 =20 clocks: + minItems: 2 items: - description: Core clock - description: Interface clock + - description: Compute clock + - description: Convolution buffer core clock + - description: Convolution buffer interface clock =20 clock-names: + minItems: 2 items: - const: aclk - const: iface + - const: npu + - const: aclk_cbuf + - const: hclk_cbuf =20 "#iommu-cells": const: 0 @@ -72,6 +81,25 @@ required: - clock-names - "#iommu-cells" =20 +allOf: + - if: + properties: + compatible: + contains: + const: rockchip,rk3576-npu-iommu + then: + properties: + clocks: + minItems: 5 + clock-names: + minItems: 5 + else: + properties: + clocks: + maxItems: 2 + clock-names: + maxItems: 2 + additionalProperties: false =20 examples: --=20 2.43.0 From nobody Fri Sep 25 13:16:57 2026 Received: from fout-b5-smtp.messagingengine.com (fout-b5-smtp.messagingengine.com [202.12.124.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 80C4527456; Sat, 12 Sep 2026 06:52:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.148 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195973; cv=none; b=p+Jfi8M2s0WeQ8Fs49SHOaMv3v+YBx1SCXlPMriwOzLhmokxFE19cLf4LuNU9y85bdG7uMp8/OEiK9NIEAxA488QsZW9KjNRc5yTMGM/5gZdAP7yh5iRlZm5TXDcn7i8xzhhIXWfxXxPxrH47XloP+PtAb0W6D0CSyNujnKc0RA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195973; c=relaxed/simple; bh=Ip+HAn15yti1nPjwxni+RXd5Yp0M1mStlI9ymrZeDxo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Kj0QG4z0Jm/mIalwR3XZQrVdP7aiohiIW2X/zLhlqe9J0vpIrB+mDeXFmeJXUlIGoN3YredOR9TPeU65K/1xMjfRkU5z0SF2muIlr7ZartS9WmyZO3m4WofEg0hWCFST3GloRqF38DscuiSeKrsydokx56+9KLIsB8c34xgCskE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com; spf=pass smtp.mailfrom=gahingwoo.com; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b=JMc0BXmo; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=w39PNcOM; arc=none smtp.client-ip=202.12.124.148 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b="JMc0BXmo"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="w39PNcOM" Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfout.stl.internal (Postfix) with ESMTP id 583911D000A6; Sat, 12 Sep 2026 02:52:50 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Sat, 12 Sep 2026 02:52:51 -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=1789195970; x= 1789282370; bh=oROQQwI1ZEPMURf5LYEkLF9C7dmz97iY/nn6Kfld3rw=; b=J Mc0BXmo8Dh1o1wFFoq9yZhp7j2Wg70Bo7gDL5R4D1psC9g/tFE322PXymXY/tbO9 tFl+cY0t11dxsuIyJkC69TXeHGY6X54MzIYGKNyM44qp1c1o3PHcJHntz2K6mIK5 uCK/DfbnphCoH2nahikAAV7wmzedjfEN9x6b/nDO3KvkGv68F9F/1f1rqZwU4aqX D3GYmQ8ubHl0cistKbT02t4d4i+b5Yt/uqCFOgJj51yvbSD5IP49j4nz36ImRDsD +hMnvTK+ZBVWPSopCOa95S+z1E0/wsBV4vBBOV03YHqiSUZzKiAqp8hSWARXzBeS +2ytuezPlC2RvnhUTgssw== 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=1789195970; x=1789282370; bh=o ROQQwI1ZEPMURf5LYEkLF9C7dmz97iY/nn6Kfld3rw=; b=w39PNcOMJfJwGpSnr moGcbbAz9mCXWgKNJOe5P0KbL0XQ5i2eTdCcGBNj5APcyNIw58qRcXAyUQjYQLa0 H+ubfkKUYOhTXq79WPBvgkR/m8IWtvv/0VbfT4tsL6F909L1sGbhBd+ZpBo4spBw 9IpVaPra0+Z3qahHuC3hbBEsrtLPCIxYo86aUjITv5mSm5zEZUUg67c+oYWrOMRt FxFMFdZKfRtIb6Ze9WVpuSLoKt1kEQEe1bplgv5K5TtNds6ChqsXgtMcttH3p/YW DGnkiz0fJZ2tjdjQuqy62bsM+wkWOUPl6UYlbXM0mmqoc8swzoLPt/UHnnyw/KL1 e97mA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEPb8qUI/Bch63DUv9Os4CRaZnJidcR38w4lyHY6iaGmzqubjANrD0SeN/gjpgWtD 9JpSgLNav7upxo5UY8BD+gTgneuYvtjdT7xUeoI37l3u3ANYgfWTUMIQPTBe+0FGjKZ893 EmiED4E9ABLDGP636x+3BNPL+06gHQG63VHM2tKDilhH/OyX7+TagruxeFKd93pQCYj32B BeiQF2P6k05N47Few9BlXMbV3J128+kb4hnRL4hf+Yoc0wDQXXqOQeonbIg1B1tOCqO85x XB7Y9LiCcE2oZkETEXdiacCDRMuKmK7OMtWiJEvsJa8P7QUcJM2B6xHrJPAU/2XBsLk7FZ 6sVIXXcKDphN5LuDLtX8b1mSKoE0f9mieUZDWnAt55vnTjACKg7JLL7uJ7zRIx0AgPt5xj cvh4wv5qIvNKo1Jk2P+qiUcHLYGdYzhW0kRsWCOddHGRqTz+TRVtk2W3rCi8eCNAFIIl/W +YvWHfRkpjTuQ3Efye2lJBquJyC/yXPknuBB4rHppSM0iY6Fc3DrgPSeWFcBMcUjpgyUr3 c9yxF+p64IIZeKdqR5BAFI3slcO9UvRWbCJcWI0QZtoowDTeE+fv2gFmD0gI022wni9mXa +h3X2FeSy7U84H6nBMNNOifEQ+2o019ojFynAz72xjYCblJgsYJtJQizEX5w X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Sep 2026 02:52:41 -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 09/14] pmdomain: rockchip: add optional per-domain power-on settle delay Date: Sat, 12 Sep 2026 18:50:48 +1200 Message-ID: <20260912065053.1519165-10-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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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. Give rockchip_domain_info an optional delay_us and wait for it between releasing idle and restoring QoS. Rename DOMAIN_M_O_R_G to DOMAIN_M_O_R_G_W, since the suffixes name the fields the macro sets and this one now also carries a wakeup delay; RK3576 is its only user, so the old spelling is not kept around. While the macro is being rewritten, give it the regulator argument that DOMAIN_M_O_R and DOMAIN_M_R already take. Without .need_regulator set, rockchip_pd_regulator_enable() returns early for every RK3576 domain, so a domain-supply in the device tree is never looked up and never enabled. Add a DOMAIN_RK3576_R spelling that passes true and use it for RK3576_PD_NPU, which is the one RK3576 domain with a rail of its own; every other domain passes false and is unchanged. Two things beyond the delay, both worth saying out loud because neither is what the subject describes. RK3576_PD_NPU also gets need_regulator here, which makes rockchip_pm_add_one_domain() call rockchip_pd_power(pd, false) at probe on all thirteen in-tree rk3576 boards. Twelve of them describe no domain-supply, so the first power-on takes a dummy regulator and a dev_warn rather than failing. It is deliberate, and it is what the delay is for: without the domain being forced off at probe, a bootloader that leaves the NPU powered means ->power_on is never called and neither the delay nor 10/14's reset pulse ever runs. If that is too much for one patch, say so and it splits. Signed-off-by: Jiaxing Hu Reviewed-by: Abel Vesa Tested-by lines stand as he sent them. --- drivers/pmdomain/rockchip/pm-domains.c | 56 ++++++++++++++++---------- 1 file changed, 34 insertions(+), 22 deletions(-) diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rock= chip/pm-domains.c index ba66ae719..39988efd8 100644 --- a/drivers/pmdomain/rockchip/pm-domains.c +++ b/drivers/pmdomain/rockchip/pm-domains.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -59,6 +60,7 @@ struct rockchip_domain_info { u32 pwr_offset; u32 mem_offset; u32 req_offset; + u32 delay_us; }; =20 struct rockchip_pmu_info { @@ -185,7 +187,7 @@ struct rockchip_pmu { .need_regulator =3D regulator, \ } =20 -#define DOMAIN_M_O_R_G(_name, p_offset, pwr, status, m_offset, m_status, r= _status, r_offset, req, idle, ack, g_mask, wakeup) \ +#define DOMAIN_M_O_R_G_W(_name, p_offset, pwr, status, m_offset, m_status,= r_status, r_offset, req, idle, ack, g_mask, delay, wakeup, regulator) \ { \ .name =3D _name, \ .pwr_offset =3D p_offset, \ @@ -200,8 +202,10 @@ struct rockchip_pmu { .req_mask =3D (req), \ .idle_mask =3D (idle), \ .clk_ungate_mask =3D (g_mask), \ + .delay_us =3D (delay), \ .ack_mask =3D (ack), \ .active_wakeup =3D wakeup, \ + .need_regulator =3D regulator, \ } =20 #define DOMAIN_M_R(_name, pwr, status, req, idle, ack, wakeup, regulator) \ @@ -258,8 +262,11 @@ struct rockchip_pmu { #define DOMAIN_RK3568(name, pwr, req, wakeup, regulator) \ DOMAIN_M_R(name, pwr, pwr, req, req, req, wakeup, regulator) =20 -#define DOMAIN_RK3576(name, p_offset, pwr, status, r_status, r_offset, req= , idle, g_mask, wakeup) \ - DOMAIN_M_O_R_G(name, p_offset, pwr, status, 0, r_status, r_status, r_offs= et, req, idle, idle, g_mask, wakeup) +#define DOMAIN_RK3576(name, p_offset, pwr, status, r_status, r_offset, req= , idle, g_mask, delay, wakeup) \ + DOMAIN_M_O_R_G_W(name, p_offset, pwr, status, 0, r_status, r_status, r_of= fset, req, idle, idle, g_mask, delay, wakeup, false) + +#define DOMAIN_RK3576_R(name, p_offset, pwr, status, r_status, r_offset, r= eq, idle, g_mask, delay, wakeup) \ + DOMAIN_M_O_R_G_W(name, p_offset, pwr, status, 0, r_status, r_status, r_of= fset, req, idle, idle, g_mask, delay, wakeup, true) =20 /* * Dynamic Memory Controller may need to coordinate with us -- see @@ -681,6 +688,10 @@ static int rockchip_pd_power(struct rockchip_pm_domain= *pd, bool power_on) if (ret < 0) goto out; =20 + /* 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); } =20 @@ -1300,25 +1311,26 @@ static const struct rockchip_domain_info rk3568_pm_= domains[] =3D { }; =20 static const struct rockchip_domain_info rk3576_pm_domains[] =3D { - [RK3576_PD_NPU] =3D DOMAIN_RK3576("npu", 0x0, BIT(0), BIT(0), 0, = 0x0, 0, 0, 0, false), - [RK3576_PD_NVM] =3D DOMAIN_RK3576("nvm", 0x0, BIT(6), 0, BIT(6)= , 0x4, BIT(2), BIT(18), BIT(2), false), - [RK3576_PD_SDGMAC] =3D DOMAIN_RK3576("sdgmac", 0x0, BIT(7), 0, BIT(= 7), 0x4, BIT(1), BIT(17), 0x6, false), - [RK3576_PD_AUDIO] =3D DOMAIN_RK3576("audio", 0x0, BIT(8), 0, BIT(8= ), 0x4, BIT(0), BIT(16), BIT(0), false), - [RK3576_PD_PHP] =3D DOMAIN_RK3576("php", 0x0, BIT(9), 0, BIT(9)= , 0x0, BIT(15), BIT(15), BIT(15), false), - [RK3576_PD_SUBPHP] =3D DOMAIN_RK3576("subphp", 0x0, BIT(10), 0, BIT(= 10), 0x0, 0, 0, 0, false), - [RK3576_PD_VOP] =3D DOMAIN_RK3576("vop", 0x0, BIT(11), 0, BIT(11= ), 0x0, 0x6000, 0x6000, 0x6000, false), - [RK3576_PD_VO1] =3D DOMAIN_RK3576("vo1", 0x0, BIT(14), 0, BIT(14= ), 0x0, BIT(12), BIT(12), 0x7000, false), - [RK3576_PD_VO0] =3D DOMAIN_RK3576("vo0", 0x0, BIT(15), 0, BIT(15= ), 0x0, BIT(11), BIT(11), 0x6800, false), - [RK3576_PD_USB] =3D DOMAIN_RK3576("usb", 0x4, BIT(0), 0, BIT(16= ), 0x0, BIT(10), BIT(10), 0x6400, true), - [RK3576_PD_VI] =3D DOMAIN_RK3576("vi", 0x4, BIT(1), 0, BIT(17)= , 0x0, BIT(9), BIT(9), BIT(9), false), - [RK3576_PD_VEPU0] =3D DOMAIN_RK3576("vepu0", 0x4, BIT(2), 0, BIT(1= 8), 0x0, BIT(7), BIT(7), 0x280, false), - [RK3576_PD_VEPU1] =3D DOMAIN_RK3576("vepu1", 0x4, BIT(3), 0, BIT(1= 9), 0x0, BIT(8), BIT(8), BIT(8), false), - [RK3576_PD_VDEC] =3D DOMAIN_RK3576("vdec", 0x4, BIT(4), 0, BIT(20= ), 0x0, BIT(6), BIT(6), BIT(6), false), - [RK3576_PD_VPU] =3D DOMAIN_RK3576("vpu", 0x4, BIT(5), 0, BIT(21= ), 0x0, BIT(5), BIT(5), BIT(5), false), - [RK3576_PD_NPUTOP] =3D DOMAIN_RK3576("nputop", 0x4, BIT(6), 0, BIT(= 22), 0x0, 0x18, 0x18, 0x18, false), - [RK3576_PD_NPU0] =3D DOMAIN_RK3576("npu0", 0x4, BIT(7), 0, BIT(23= ), 0x0, BIT(1), BIT(1), 0x1a, false), - [RK3576_PD_NPU1] =3D DOMAIN_RK3576("npu1", 0x4, BIT(8), 0, BIT(24= ), 0x0, BIT(2), BIT(2), 0x1c, false), - [RK3576_PD_GPU] =3D DOMAIN_RK3576("gpu", 0x4, BIT(9), 0, BIT(25= ), 0x0, BIT(0), BIT(0), BIT(0), false), + /* name p_offset pwr s= tatus r_status r_offset req idle g_mask delay wakeup */ + [RK3576_PD_NPU] =3D DOMAIN_RK3576_R("npu", 0x0, BIT(0), BIT(0), 0, = 0x0, 0, 0, 0, 0, false), + [RK3576_PD_NVM] =3D DOMAIN_RK3576("nvm", 0x0, BIT(6), 0, BIT(6)= , 0x4, BIT(2), BIT(18), BIT(2), 0, false), + [RK3576_PD_SDGMAC] =3D DOMAIN_RK3576("sdgmac", 0x0, BIT(7), 0, BIT(= 7), 0x4, BIT(1), BIT(17), 0x6, 0, false), + [RK3576_PD_AUDIO] =3D DOMAIN_RK3576("audio", 0x0, BIT(8), 0, BIT(8= ), 0x4, BIT(0), BIT(16), BIT(0), 0, false), + [RK3576_PD_PHP] =3D DOMAIN_RK3576("php", 0x0, BIT(9), 0, BIT(9)= , 0x0, BIT(15), BIT(15), BIT(15), 0, false), + [RK3576_PD_SUBPHP] =3D DOMAIN_RK3576("subphp", 0x0, BIT(10), 0, BIT(= 10), 0x0, 0, 0, 0, 0, false), + [RK3576_PD_VOP] =3D DOMAIN_RK3576("vop", 0x0, BIT(11), 0, BIT(11= ), 0x0, 0x6000, 0x6000, 0x6000, 0, false), + [RK3576_PD_VO1] =3D DOMAIN_RK3576("vo1", 0x0, BIT(14), 0, BIT(14= ), 0x0, BIT(12), BIT(12), 0x7000, 0, false), + [RK3576_PD_VO0] =3D DOMAIN_RK3576("vo0", 0x0, BIT(15), 0, BIT(15= ), 0x0, BIT(11), BIT(11), 0x6800, 0, false), + [RK3576_PD_USB] =3D DOMAIN_RK3576("usb", 0x4, BIT(0), 0, BIT(16= ), 0x0, BIT(10), BIT(10), 0x6400, 0, true), + [RK3576_PD_VI] =3D DOMAIN_RK3576("vi", 0x4, BIT(1), 0, BIT(17)= , 0x0, BIT(9), BIT(9), BIT(9), 0, false), + [RK3576_PD_VEPU0] =3D DOMAIN_RK3576("vepu0", 0x4, BIT(2), 0, BIT(1= 8), 0x0, BIT(7), BIT(7), 0x280, 0, false), + [RK3576_PD_VEPU1] =3D DOMAIN_RK3576("vepu1", 0x4, BIT(3), 0, BIT(1= 9), 0x0, BIT(8), BIT(8), BIT(8), 0, false), + [RK3576_PD_VDEC] =3D DOMAIN_RK3576("vdec", 0x4, BIT(4), 0, BIT(20= ), 0x0, BIT(6), BIT(6), BIT(6), 0, false), + [RK3576_PD_VPU] =3D DOMAIN_RK3576("vpu", 0x4, BIT(5), 0, BIT(21= ), 0x0, BIT(5), BIT(5), BIT(5), 0, false), + [RK3576_PD_NPUTOP] =3D DOMAIN_RK3576("nputop", 0x4, BIT(6), 0, BIT(= 22), 0x0, 0x18, 0x18, 0x18, 15, false), + [RK3576_PD_NPU0] =3D DOMAIN_RK3576("npu0", 0x4, BIT(7), 0, BIT(23= ), 0x0, BIT(1), BIT(1), 0x1a, 15, false), + [RK3576_PD_NPU1] =3D DOMAIN_RK3576("npu1", 0x4, BIT(8), 0, BIT(24= ), 0x0, BIT(2), BIT(2), 0x1c, 15, false), + [RK3576_PD_GPU] =3D DOMAIN_RK3576("gpu", 0x4, BIT(9), 0, BIT(25= ), 0x0, BIT(0), BIT(0), BIT(0), 0, false), }; =20 static const struct rockchip_domain_info rk3588_pm_domains[] =3D { --=20 2.43.0 From nobody Fri Sep 25 13:16:57 2026 Received: from fout-b5-smtp.messagingengine.com (fout-b5-smtp.messagingengine.com [202.12.124.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3BBEC379ED2; Sat, 12 Sep 2026 06:53:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.148 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195984; cv=none; b=i2mEBQpc1JWiKFzAH8EXrxJEslwJ5PFB/vNx9wvKFZq0GjH+rNrQBx/ACG69eXHcB8izRwXRsoDZZVf4UMzzgWYWjkkqrbd1O5W2Yoa9shenFmXwIUfblt9jP27twKlmfftK54nNo0L0glWPw+8VI2997TI8LcVrVwZEASGsEgM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195984; c=relaxed/simple; bh=XkKS64ilmfTZbzrK5Po4eJtI/KFUDUj/aHDPQvHk5fg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YI5LmplX3HkNkGFwjPJaIrWGUnX/XHNH24uvrna87fiY96MC9VnLaaSbyyM/F4M0jzhgAFVw0H9CHJrZ3juMs81qL2+UALE93tRrnCWl0PqiKluBq3VuAzeOHvw3XAXBDJMhwzYXtMO+Cr7pkDTGIOMvQAVwnR/Xh0cNV6NIKlo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com; spf=pass smtp.mailfrom=gahingwoo.com; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b=RqExlXUM; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=ZGf/yffU; arc=none smtp.client-ip=202.12.124.148 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b="RqExlXUM"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="ZGf/yffU" 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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 Tested-by lines stand as he sent them. --- drivers/pmdomain/rockchip/pm-domains.c | 27 ++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rock= chip/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; }; =20 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; =20 + /* + * 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; =20 + pd->resets =3D of_reset_control_array_get_optional_exclusive(node); + if (IS_ERR(pd->resets)) { + error =3D dev_err_probe(pmu->dev, PTR_ERR(pd->resets), + "%pOFn: failed to get resets\n", node); + pd->resets =3D NULL; + goto err_unprepare_clocks; + } + pd->num_qos =3D of_count_phandle_with_args(node, "pm_qos", NULL); =20 @@ -931,6 +956,7 @@ static int rockchip_pm_add_one_domain(struct rockchip_p= mu *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; } =20 @@ -949,6 +975,7 @@ static void rockchip_pm_remove_one_domain(struct rockch= ip_pm_domain *pd) =20 clk_bulk_unprepare(pd->num_clks, pd->clks); clk_bulk_put(pd->num_clks, pd->clks); + reset_control_put(pd->resets); =20 /* protect the zeroing of pm->num_clks */ mutex_lock(&pd->pmu->mutex); --=20 2.43.0 From nobody Fri Sep 25 13:16:57 2026 Received: from fhigh-b3-smtp.messagingengine.com (fhigh-b3-smtp.messagingengine.com [202.12.124.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 306393624BC; Sat, 12 Sep 2026 06:53:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.154 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195996; cv=none; b=WMKtGC/oaRMxVPoJkaTpL+zzf9L/tm6CoU5KLCe/vYP8M08OyJ1xeO6KD2R3CFG7ZvD1nFFDSw0sUXJc0mGyeLx5gTHEq61gOaFsaMfuKRv6RIjxXXIdtDxZ6xtGY86iPtnNrCmhxKLQt7FD8VRGeU4zkAE29x1SFxdkSpV+BqY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789195996; c=relaxed/simple; bh=IE3xWBXDo6VtwItgviJPad/JRbM0VHzIDuwI7KgwfBc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=L2PPlhlkRJnlJpVVDa31icL+fqIFe3asOZaAiRi/Now5MvbzA2WqpKD+WJLzNkj9pdbH1xQP2eRd22XlsAH6deP57jD1XQgAhAVucwawDBOw2xHF3B2PGBNmybYVOLYd0VkGn4E98J2ZC1NsRZajTmviMYbAkkJ8mrPJRzlbtWE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com; spf=pass smtp.mailfrom=gahingwoo.com; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b=gvHSvQ3r; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=df0iVg3T; arc=none smtp.client-ip=202.12.124.154 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b="gvHSvQ3r"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="df0iVg3T" Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfhigh.stl.internal (Postfix) with ESMTP id E6EE67A00BD; Sat, 12 Sep 2026 02:53:13 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Sat, 12 Sep 2026 02:53:14 -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=1789195993; x= 1789282393; bh=eIbu+FRnuIaeFrU8yxIF1UYO5RWNoHkH+v38kjzzSXI=; b=g vHSvQ3r7v+l+egfUn2U8wl6Wppp4psnh5oINunj7Q5KZhxnHBA9zqm5WhrnXsm+O Uvxcs/Gm9k4z7+MbVzuroF1U+JHLcdF8ps4OnhkpYqcT/Tq/dkfrHqWRiXNkDQ3M VEA3EhlNcRQXk8CQ4PDV4OCzBlqwmsPGKWCvN1R51eiIh0Cvrp3mlT7cj+bU5r4N uC7IiHsAcHnHmrtohE77ke3iiIxHrd+QpC+gB5iHXwaa6fjFTtatXvhjnENouH61 TzHqQcQOepRBMqh0hcc5llzqCawp05l28Zm56tlsJ/nOfW8i3yYLud2hsE7WxgDA 9sg4ejDf3+fsrD/k/2fBQ== 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=1789195993; x=1789282393; bh=e Ibu+FRnuIaeFrU8yxIF1UYO5RWNoHkH+v38kjzzSXI=; b=df0iVg3THyYOPUXLv NybtfFnHYTLq+J9Un3Y98qNGYM9N5V59zzHgvjQy9FX0MU400iMADCOsP+CIL8Yz FfunFelSynqP7xJr9pdw1+3YrMRibSdMA4+C1U6yPOW5g8f3fFXClGOiFrG73WEA GrjZ5ed2iGt2dGqPBLRirMjlPi9PbHryYXTF4piIPL615gniFZ7eFR4uGQEdBCuL HMm3v7GLDEZwr+DcN66cBL/gVVu1ALCzHzIKNYt1oPttpZ/k4RtqQiyvo0f7ZKwB 75GKqo+lZwgjsKW3CuTZ3kz04VRsB0FL5f3YDrkQQwtHP/KurEsbTu42fdJNJjYf HlSDA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFADPy43ymxNR6XHAVFKRdNY4DpcYEBRSwa13JqCTHbL9NsQVfP9qCQ5TTmagE5kF RB532MExwgRSB4dKHz35IjH9JqP654WzyiSX+TI/62Bro3K5rJ+mWZ18Sxxo6D9XJjUSyu Eob4bmEwP/sHC/KMD1YX4DKomTq3nqtMsAoZtW6mHz74Bj+8J2iIqiPYSwY0Lln911wUXn 2LrOxQMwefzQS/S4posukY87oskKCBLl/4tkcieL5kkqVMlf97XBcvzTaPE3LqTgGgxCyb hCopDHT7yawVnq3UuO8HWKojJnhhQiPlPVXjr7c5M9JZoLkZ/wGQ5AHB8kIddJPmNXv6gr 4JsLzQZ8k2buCdwUXlSYtbl60UffPpcbB97xVkQv584B2n2hLCITvNjlA1Q/w3uuGHwiWf Ld7sHQDXQ3OHWIY8m3yUM2kJeVXqrexmLjHwajNdYH17yzMeyVQnAXeMscjyt5MlgWsvdr KX8HQVKUIfUlXTjZODeJJ2m2u34g5/stV9s8COxid7d2hSipcs8fKavPY2ZpgwERxrINKX h3QjLIK8kdeRjXXmLjm51ThFK/2WoLlKOvCXB3ZTI6/3FZNXkKn29hx+BBL9PeLWMwyNXA f+kBwUEl+RlNgZOwDE/5yzvaITD0sugxVcVv4nmI2ueODnj7JhMkoeh+p/Cw X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Sep 2026 02:53:05 -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 11/14] accel/rocket: select the per-core clock and reset counts from match data Date: Sat, 12 Sep 2026 18:50:50 +1200 Message-ID: <20260912065053.1519165-12-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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The RK3576 carries the same RKNN block with a different set of clocks and resets, so the counts cannot stay compile-time constants. Add a soc_data struct to the of_device_id match data and take the bulk counts from it. RK3588 keeps four clocks and two resets, so nothing changes for it, and the arrays keep their present sizes: the SoC that needs a longer one grows it in the patch that adds the names. rocket_core_reset() is switched over as well. It is the same array, and leaving it on ARRAY_SIZE() would walk entries that were never acquired once a SoC asks for fewer. soc is checked at the top of rocket_probe(), before anything is allocated and before the per-core fields are stored. of_device_get_match_data() returns NULL for a device that bound by name rather than by compatible, and such a device has no of_node, so it was never counted by the walk of matching nodes that sizes rdev->cores[]. Storing into that array first and checking afterwards would be writing past the end under the check's own premise, and returning from there is the one error path in this function that would skip the unwind the path below it does. Signed-off-by: Jiaxing Hu Tested-by lines stand as he sent them. --- drivers/accel/rocket/rocket_core.c | 8 ++++---- drivers/accel/rocket/rocket_core.h | 7 +++++++ drivers/accel/rocket/rocket_drv.c | 26 +++++++++++++++++++++++--- 3 files changed, 34 insertions(+), 7 deletions(-) diff --git a/drivers/accel/rocket/rocket_core.c b/drivers/accel/rocket/rock= et_core.c index 5dd260bac..b202d1581 100644 --- a/drivers/accel/rocket/rocket_core.c +++ b/drivers/accel/rocket/rocket_core.c @@ -23,7 +23,7 @@ int rocket_core_init(struct rocket_core *core) =20 core->resets[0].id =3D "srst_a"; core->resets[1].id =3D "srst_h"; - err =3D devm_reset_control_bulk_get_exclusive(&pdev->dev, ARRAY_SIZE(core= ->resets), + err =3D devm_reset_control_bulk_get_exclusive(&pdev->dev, core->soc->num_= resets, core->resets); if (err) return dev_err_probe(dev, err, "failed to get resets for core %d\n", cor= e->index); @@ -32,7 +32,7 @@ int rocket_core_init(struct rocket_core *core) core->clks[1].id =3D "hclk"; core->clks[2].id =3D "npu"; core->clks[3].id =3D "pclk"; - err =3D devm_clk_bulk_get(dev, ARRAY_SIZE(core->clks), core->clks); + err =3D devm_clk_bulk_get(dev, core->soc->num_clks, core->clks); if (err) return dev_err_probe(dev, err, "failed to get clocks for core %d\n", cor= e->index); =20 @@ -109,9 +109,9 @@ void rocket_core_fini(struct rocket_core *core) =20 void rocket_core_reset(struct rocket_core *core) { - reset_control_bulk_assert(ARRAY_SIZE(core->resets), core->resets); + reset_control_bulk_assert(core->soc->num_resets, core->resets); =20 udelay(10); =20 - reset_control_bulk_deassert(ARRAY_SIZE(core->resets), core->resets); + reset_control_bulk_deassert(core->soc->num_resets, core->resets); } diff --git a/drivers/accel/rocket/rocket_core.h b/drivers/accel/rocket/rock= et_core.h index f6d738285..ba74c5339 100644 --- a/drivers/accel/rocket/rocket_core.h +++ b/drivers/accel/rocket/rocket_core.h @@ -27,9 +27,16 @@ #define rocket_core_writel(core, reg, value) \ writel(value, (core)->core_iomem + (REG_CORE_##reg) - REG_CORE_S_STATUS) =20 +/* Per-SoC differences, selected by the of_device_id match data. */ +struct rocket_soc_data { + unsigned int num_clks; /* clk_bulk count */ + unsigned int num_resets; /* reset_bulk count */ +}; + struct rocket_core { struct device *dev; struct rocket_device *rdev; + const struct rocket_soc_data *soc; unsigned int index; =20 int irq; diff --git a/drivers/accel/rocket/rocket_drv.c b/drivers/accel/rocket/rocke= t_drv.c index 8bbbce594..7ed64c131 100644 --- a/drivers/accel/rocket/rocket_drv.c +++ b/drivers/accel/rocket/rocket_drv.c @@ -159,8 +159,22 @@ static const struct drm_driver rocket_drm_driver =3D { =20 static int rocket_probe(struct platform_device *pdev) { + const struct rocket_soc_data *soc =3D of_device_get_match_data(&pdev->dev= ); int ret; =20 + /* + * soc is dereferenced without a check by every one of its users, and + * rocket_core_init() below is the first of them. A device that bound + * by name rather than by compatible has no match data, so fail before + * anything is allocated rather than at the first dereference: the + * number of cores comes from a walk of matching DT nodes, and a device + * with no of_node was never counted by it. + */ + if (!soc) { + dev_err(&pdev->dev, "no match data for this device\n"); + return -ENODEV; + } + if (rdev =3D=3D NULL) { /* First core probing, initialize DRM device. */ rdev =3D rocket_device_init(drm_dev, &rocket_drm_driver); @@ -176,6 +190,7 @@ static int rocket_probe(struct platform_device *pdev) =20 rdev->cores[core].rdev =3D rdev; rdev->cores[core].dev =3D &pdev->dev; + rdev->cores[core].soc =3D soc; rdev->cores[core].index =3D core; =20 rdev->num_cores++; @@ -213,8 +228,13 @@ static void rocket_remove(struct platform_device *pdev) } } =20 +static const struct rocket_soc_data rk3588_soc_data =3D { + .num_clks =3D 4, + .num_resets =3D 2, +}; + static const struct of_device_id dt_match[] =3D { - { .compatible =3D "rockchip,rk3588-rknn-core" }, + { .compatible =3D "rockchip,rk3588-rknn-core", .data =3D &rk3588_soc_data= }, {} }; MODULE_DEVICE_TABLE(of, dt_match); @@ -240,7 +260,7 @@ static int rocket_device_runtime_resume(struct device *= dev) if (core < 0) return -ENODEV; =20 - err =3D clk_bulk_prepare_enable(ARRAY_SIZE(rdev->cores[core].clks), rdev-= >cores[core].clks); + err =3D clk_bulk_prepare_enable(rdev->cores[core].soc->num_clks, rdev->co= res[core].clks); if (err) { dev_err(dev, "failed to enable (%d) clocks for core %d\n", err, core); return err; @@ -260,7 +280,7 @@ static int rocket_device_runtime_suspend(struct device = *dev) if (!rocket_job_is_idle(&rdev->cores[core])) return -EBUSY; =20 - clk_bulk_disable_unprepare(ARRAY_SIZE(rdev->cores[core].clks), rdev->core= s[core].clks); + clk_bulk_disable_unprepare(rdev->cores[core].soc->num_clks, rdev->cores[c= ore].clks); =20 return 0; } --=20 2.43.0 From nobody Fri Sep 25 13:16:57 2026 Received: from fhigh-b3-smtp.messagingengine.com (fhigh-b3-smtp.messagingengine.com [202.12.124.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 92BB027456; Sat, 12 Sep 2026 06:53:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.154 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789196009; cv=none; b=btoK0BYGhZU8ZwW39RhJ4Cw5e4fgGMQmqkK52UMnU3q7Tmqofa6g/waQThpCGPO4MHsdV2h44m/NxJ++/XIBMEWcPcfhkwUlmSL7dn/kXL6qYqh/DiElJL3M4dOjDVh5/+78Ej8CRm9RPyMgUmWSwGXpg7wFvQhtnHMS9xIImIQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789196009; c=relaxed/simple; bh=SU5r2mgDngoCkXL1E/TLAvg+G1+4T4A4HFtGHcd7EHQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=U+wkSlIW8JJ2THdQ8l4+6mli3RxbHPVzBczACG9A8b+hU0mrRgnvU7DMwrdadyFdJCZphmu9lLtCAl0n4AP4dW30Om3F6O3taOeI2UMz+FxozBqgSzBuOQv3PbzSyfK7gT73fawNoizOFr2gEfj46EQ/uTSuI6g4BqDFOAVrGmI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com; spf=pass smtp.mailfrom=gahingwoo.com; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b=o3Yy2zjQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=rk+Des1k; arc=none smtp.client-ip=202.12.124.154 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b="o3Yy2zjQ"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="rk+Des1k" Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.stl.internal (Postfix) with ESMTP id 37E187A00B7; Sat, 12 Sep 2026 02:53:26 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Sat, 12 Sep 2026 02:53:26 -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=1789196006; x= 1789282406; bh=YKZPBXw+xdtM1qi3e13LXX3HE+2vzSoSJwaoX0SpJ3s=; b=o 3Yy2zjQwQ1JMI0pHy0VTovPTubcJRoI6Ryz+wcRYd0St8CaGCdlMB3+L74YS2osB igDSsUyeZrTtC9GUdJav/zNYyoVJQkLZqLZoawatu3Oekdgxqxqurgdnz+bZ1D5Z Yl8PQPOAZFvitROItahyRTKH8bAQ7lCCpNBB4s3JQJ1fn0/pz8wCXOt8XtlLZJWP wd6V7qzZJp4pouUNIh2rpdJBQ5+CLRjdcz2Nsi/WMzDdHSl3VA6i19G2yH1tB83a WIjl7Dhgc9Aa1asFCie9ls6FGU13XtL276rV+55FdrO5vDTCYmPWlGe1XDEONU3u dr153FcNC/PKUqmkxRE/Q== 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=1789196006; x=1789282406; bh=Y KZPBXw+xdtM1qi3e13LXX3HE+2vzSoSJwaoX0SpJ3s=; b=rk+Des1khWC1dclUn GV1O6psqYPo6h2ekU3+xv5sWfwrgO2SguulTwkgIANUC3+VKu/gYPxGuu7wI0Mp3 dBBVDiQxg7mHcFvM8rPvq+IU+fcYLSWPe1vpLnqpWcKhwDoxW4cAKRZ/Tv/TVbSh dHyPkcB/FULjpIkgdyKDkqUujo0+4Rzl0abU31Ia60CN52KSoELHwycfobDVPVBy GL+gjVkNzvxwxO6gttYFjKTJgt3aRjMJ/2ZzGkBicarSyWlcKGke3ZKsHu8yjUmz EjZvencn0GX4skgtv0vgyJhNH1Gyl0j3WZzXNN0qwFQnvmog5vZb/TFF+J5BpTku h/hGQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGVdccJ1gJMsqn3dH5DfQJDUoT974JEec4+O/M/3zUCePWBB3mYzj2y1w7M97x2AZ MZwtNnmr4VHmOPtxdsT1Ko1DgahOTDpqDIZCaHZJoSy5dE4J01lmj06c3Sc0Hwew3SgLhs ZKTdq0M+5JpRju0U6zuB39CPpRGTTWPN8aJ4xI2KqHNCfsRWI2rvFACjPNv6juIum/MN9G GhEkGmcF8C90sZVzEajYsclIsqm1C/+nlTq9yLNLmx0A9G0tnlAXgoHDAnOHgrWDCyD7Uv +GJ0Q9X91kPI/Ps8JuOxwpYgMTDMovsoNW6MCulQnDOY+OnX2XSjZTgt12AkOSJ/RtIXtS M/M3kKBjr1DC8AMXhfXRpAokUdYKkSJsAUxC5WLI1kKvZeB3Ebu4MCHL1IiZEkJRLykQ5u S25TMmY2Xu2Se/amBQcWSuSSqDrsFUQmJu/TB8Dzs/4ASNUxGq3ZqGmiC+ApVKZNgu07SX aEgbjTvWdtqsI5v/OtCzl+JfnoigewgT0KuPlmZVF62CumI4aOqYif/ljv4XXUGbv3Itbf Nd6Akt1vopPjQG28DEpYcKERalnfZCy9ZjN1uABKFPdZfqkfEG3rOJK+lfm4x6APdLsq2H 4eXleNvP2cyx2ll98fRBlqOjEQC4wgFxHiaHtJDT3wznIbDV/l+Ih1rQLM0g X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Sep 2026 02:53:17 -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 12/14] accel/rocket: add RK3576 NPU (RKNN) support Date: Sat, 12 Sep 2026 18:50:51 +1200 Message-ID: <20260912065053.1519165-13-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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The RK3576 has two cores of the same RKNN block and a few platform differences: - the CBUF (convolution buffer) has its own clock domain, so the core needs six clocks rather than four; - there is no per-core hclk reset. The CRU has SRST_A_RKNN0 and SRST_A_RKNN1 but no SRST_H_RKNN0 or SRST_H_RKNN1, so a core takes one reset where RK3588 takes two; - the NPU spans two power domains, and a device with more than one is skipped by the driver-core single-domain auto-attach, so the list has to be attached explicitly; - PC_TASK_CON packs the task number with sixteen bits rather than twelve, moving the two controls above it up by four and adding a third. That last one is the reason this series has been reporting, since v3, that the block accepts exactly one task per reset. rocket_registers.h is generated from the RK3588 description, so writing it unchanged to an RK3576 asks for task_number 0x7001, which is 28673 tasks, and puts TASK_COUNT_CLEAR inside the sixteen-bit task number, where it inflates the count rather than clearing it. The counter is then only ever cleared by a reset. The layout was confirmed by Chaoyi Chen of Rockchip, including the third control at BIT(18), task_last_layer_clear, which belongs on every submit alongside the count clear: https://lore.kernel.org/all/4f300b78-d96d-4d98-8819-dc292b0c9b97@rock-chi= ps.com/ With that written correctly a job of several tasks runs to completion, the completion interrupt arrives, and /proc/interrupts counts up. A convolution submitted three times with three different inputs is byte exact against the CPU reference each time, with no reset in between and with nothing retiring the job but the interrupt. Counting the cores now walks the driver's own match table instead of a second, hand-kept list of compatibles. The array sized from that count is indexed by every core that goes on to probe, so the two lists cannot be allowed to disagree. All of it hangs off the soc_data added earlier, so the RK3588 path keeps its existing counts and behaviour. The match table moves to rocket_drv.h so rocket_device.c can walk it with for_each_matching_node() rather than repeating a for_each_compatible_node() loop per SoC, which also keeps num_cores in step with the table that sizes the array it counts into. The declaration needs struct of_device_id, taken from rather than , which carries every subsystem's tables with it. Signed-off-by: Jiaxing Hu Tested-by lines stand as he sent them. --- drivers/accel/rocket/rocket_core.c | 20 ++++++++++++++ drivers/accel/rocket/rocket_core.h | 8 +++--- drivers/accel/rocket/rocket_device.c | 7 ++++- drivers/accel/rocket/rocket_drv.c | 16 +++++++++--- drivers/accel/rocket/rocket_drv.h | 2 ++ drivers/accel/rocket/rocket_job.c | 39 +++++++++++++++++++++++++--- 6 files changed, 81 insertions(+), 11 deletions(-) diff --git a/drivers/accel/rocket/rocket_core.c b/drivers/accel/rocket/rock= et_core.c index b202d1581..91f690176 100644 --- a/drivers/accel/rocket/rocket_core.c +++ b/drivers/accel/rocket/rocket_core.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include =20 @@ -21,6 +22,7 @@ int rocket_core_init(struct rocket_core *core) u32 version; int err =3D 0; =20 + /* RK3576 has no per-core hclk reset, so it takes srst_a alone. */ core->resets[0].id =3D "srst_a"; core->resets[1].id =3D "srst_h"; err =3D devm_reset_control_bulk_get_exclusive(&pdev->dev, core->soc->num_= resets, @@ -32,6 +34,9 @@ int rocket_core_init(struct rocket_core *core) core->clks[1].id =3D "hclk"; core->clks[2].id =3D "npu"; core->clks[3].id =3D "pclk"; + /* RK3576 clocks the CBUF separately; the compute path stalls without the= se. */ + core->clks[4].id =3D "aclk_cbuf"; + core->clks[5].id =3D "hclk_cbuf"; err =3D devm_clk_bulk_get(dev, core->soc->num_clks, core->clks); if (err) return dev_err_probe(dev, err, "failed to get clocks for core %d\n", cor= e->index); @@ -60,6 +65,21 @@ int rocket_core_init(struct rocket_core *core) if (err) return err; =20 + /* + * RK3576 spans two power domains, and a multi-domain device is skipped + * by the driver-core single-domain auto-attach, so attach the list here. + * This goes before the first thing that would have to be unwound, so a + * failure can simply return. + */ + if (core->soc->multi_power_domain) { + struct dev_pm_domain_list *pd_list; + + err =3D devm_pm_domain_attach_list(dev, NULL, &pd_list); + if (err < 0) + return dev_err_probe(dev, err, + "failed to attach NPU power domains\n"); + } + core->iommu_group =3D iommu_group_get(dev); =20 err =3D rocket_job_init(core); diff --git a/drivers/accel/rocket/rocket_core.h b/drivers/accel/rocket/rock= et_core.h index ba74c5339..8c8d1f453 100644 --- a/drivers/accel/rocket/rocket_core.h +++ b/drivers/accel/rocket/rocket_core.h @@ -29,8 +29,10 @@ =20 /* Per-SoC differences, selected by the of_device_id match data. */ struct rocket_soc_data { - unsigned int num_clks; /* clk_bulk count */ - unsigned int num_resets; /* reset_bulk count */ + unsigned int num_clks; /* clk_bulk count: 4 base, 6 with CBUF */ + unsigned int num_resets; /* reset_bulk count: 2 base, 1 on RK3576 */ + bool multi_power_domain; /* device spans more than one PM domain */ + bool task_con_16bit; /* PC_TASK_CON uses the 16-bit task number */ }; =20 struct rocket_core { @@ -43,7 +45,7 @@ struct rocket_core { void __iomem *pc_iomem; void __iomem *cna_iomem; void __iomem *core_iomem; - struct clk_bulk_data clks[4]; + struct clk_bulk_data clks[6]; struct reset_control_bulk_data resets[2]; =20 struct iommu_group *iommu_group; diff --git a/drivers/accel/rocket/rocket_device.c b/drivers/accel/rocket/ro= cket_device.c index 46e6ee1e7..923add5bd 100644 --- a/drivers/accel/rocket/rocket_device.c +++ b/drivers/accel/rocket/rocket_device.c @@ -9,6 +9,7 @@ #include =20 #include "rocket_device.h" +#include "rocket_drv.h" =20 struct rocket_device *rocket_device_init(struct platform_device *pdev, const struct drm_driver *rocket_drm_driver) @@ -27,7 +28,11 @@ struct rocket_device *rocket_device_init(struct platform= _device *pdev, ddev =3D &rdev->ddev; dev_set_drvdata(dev, rdev); =20 - for_each_compatible_node(core_node, NULL, "rockchip,rk3588-rknn-core") + /* + * Count over the same match table the platform driver binds with, so + * that a core added there is counted here without a second edit. + */ + for_each_matching_node(core_node, rocket_dt_match) if (of_device_is_available(core_node)) num_cores++; =20 diff --git a/drivers/accel/rocket/rocket_drv.c b/drivers/accel/rocket/rocke= t_drv.c index 7ed64c131..f387b4656 100644 --- a/drivers/accel/rocket/rocket_drv.c +++ b/drivers/accel/rocket/rocket_drv.c @@ -231,13 +231,23 @@ static void rocket_remove(struct platform_device *pde= v) static const struct rocket_soc_data rk3588_soc_data =3D { .num_clks =3D 4, .num_resets =3D 2, + .multi_power_domain =3D false, + .task_con_16bit =3D false, }; =20 -static const struct of_device_id dt_match[] =3D { +static const struct rocket_soc_data rk3576_soc_data =3D { + .num_clks =3D 6, + .num_resets =3D 1, + .multi_power_domain =3D true, + .task_con_16bit =3D true, +}; + +const struct of_device_id rocket_dt_match[] =3D { { .compatible =3D "rockchip,rk3588-rknn-core", .data =3D &rk3588_soc_data= }, + { .compatible =3D "rockchip,rk3576-rknn-core", .data =3D &rk3576_soc_data= }, {} }; -MODULE_DEVICE_TABLE(of, dt_match); +MODULE_DEVICE_TABLE(of, rocket_dt_match); =20 static int find_core_for_dev(struct device *dev) { @@ -296,7 +306,7 @@ static struct platform_driver rocket_driver =3D { .driver =3D { .name =3D "rocket", .pm =3D pm_ptr(&rocket_pm_ops), - .of_match_table =3D dt_match, + .of_match_table =3D rocket_dt_match, }, }; =20 diff --git a/drivers/accel/rocket/rocket_drv.h b/drivers/accel/rocket/rocke= t_drv.h index 2c673bb99..0cd692a66 100644 --- a/drivers/accel/rocket/rocket_drv.h +++ b/drivers/accel/rocket/rocket_drv.h @@ -6,10 +6,12 @@ =20 #include #include +#include =20 #include "rocket_device.h" =20 extern const struct dev_pm_ops rocket_pm_ops; +extern const struct of_device_id rocket_dt_match[]; =20 struct rocket_iommu_domain { struct iommu_domain *domain; diff --git a/drivers/accel/rocket/rocket_job.c b/drivers/accel/rocket/rocke= t_job.c index 8cffe93f6..c5396c62d 100644 --- a/drivers/accel/rocket/rocket_job.c +++ b/drivers/accel/rocket/rocket_job.c @@ -21,6 +21,30 @@ =20 #define JOB_TIMEOUT_MS 500 =20 +/* + * PC_TASK_CON packs the task number with control bits above it, and neith= er + * the width of the number nor the count of the controls is the same on ev= ery + * SoC. rocket_registers.h is generated from the RK3588 description, where= the + * task number is twelve bits and there are two: + * + * RK3588 BIT[11:0] task_number, BIT[12] pp_en, BIT[13] count_clear + * RK3576 BIT[15:0] task_number, BIT[16] pp_en, BIT[17] count_clear, + * BIT[18] last_layer_clear + * + * The RK3576 layout was confirmed by Chaoyi Chen of Rockchip: + * https://lore.kernel.org/all/4f300b78-d96d-4d98-8819-dc292b0c9b97@rock-c= hips.com/ + * + * Writing the RK3588 layout to an RK3576 therefore asks for task_number + * 0x7001, that is 28673 tasks, and lands the count clear on a bit that do= es + * nothing. The task counter is then only ever cleared by a reset, which is + * exactly the "one task per reset" behaviour this series has been reporti= ng + * since v3. + */ +#define RK3576_PC_TASK_CON_TASK_NUMBER(n) ((n) & 0xffff) +#define RK3576_PC_TASK_CON_PP_EN BIT(16) +#define RK3576_PC_TASK_CON_COUNT_CLEAR BIT(17) +#define RK3576_PC_TASK_CON_LAST_LAYER_CLEAR BIT(18) + static struct rocket_job * to_rocket_job(struct drm_sched_job *sched_job) { @@ -142,10 +166,17 @@ static void rocket_job_hw_submit(struct rocket_core *= core, struct rocket_job *jo rocket_pc_writel(core, INTERRUPT_MASK, PC_INTERRUPT_MASK_DPU_0 | PC_INTER= RUPT_MASK_DPU_1); rocket_pc_writel(core, INTERRUPT_CLEAR, PC_INTERRUPT_CLEAR_DPU_0 | PC_INT= ERRUPT_CLEAR_DPU_1); =20 - rocket_pc_writel(core, TASK_CON, PC_TASK_CON_RESERVED_0(1) | - PC_TASK_CON_TASK_COUNT_CLEAR(1) | - PC_TASK_CON_TASK_NUMBER(1) | - PC_TASK_CON_TASK_PP_EN(1)); + if (core->soc->task_con_16bit) + rocket_pc_writel(core, TASK_CON, + RK3576_PC_TASK_CON_LAST_LAYER_CLEAR | + RK3576_PC_TASK_CON_COUNT_CLEAR | + RK3576_PC_TASK_CON_PP_EN | + RK3576_PC_TASK_CON_TASK_NUMBER(1)); + else + rocket_pc_writel(core, TASK_CON, PC_TASK_CON_RESERVED_0(1) | + PC_TASK_CON_TASK_COUNT_CLEAR(1) | + PC_TASK_CON_TASK_NUMBER(1) | + PC_TASK_CON_TASK_PP_EN(1)); =20 rocket_pc_writel(core, TASK_DMA_BASE_ADDR, PC_TASK_DMA_BASE_ADDR_DMA_BASE= _ADDR(0x0)); =20 --=20 2.43.0 From nobody Fri Sep 25 13:16:57 2026 Received: from fout-b5-smtp.messagingengine.com (fout-b5-smtp.messagingengine.com [202.12.124.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 45C9737757A; Sat, 12 Sep 2026 06:53:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.148 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789196020; cv=none; b=mF5QxzGFKAZotN01RgNtPe3S/XVYY12oQjaBKRgD5K+Arfb1A4vvFWzvyGNF9Lp7AJcvNh/7rPtoPU6f9uezBGAZRQyMXDoRI9pOYaNMfT+aeCWJe7b1fzLmMPJgV+shiCOKZWiMVN0v+gftoZ5cYdSvEp3kE4FFch9leZq0qjA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789196020; c=relaxed/simple; bh=H6kg6W5KJ8QXgz8YLb6qNBmV77ftxTZZb7S2KPSFr5k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=I+ajRj3SApede50rbjfcMs6DfiBafeTHQOEXmeYpiGlN7oyOxOB1Sfz6HYZaYG4YC5a7HOYshnJWpknrWFkJ0Vxm2ambJS+IbnlwUnHcKFU+MlmtuBq+0FEWMe4g5+g/maHucfDlQL26iMmajJ0VyYt7dolGH8Sp13ogmYUMbAE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com; spf=pass smtp.mailfrom=gahingwoo.com; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b=Fv9DPVFQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=CW7Sibs8; arc=none smtp.client-ip=202.12.124.148 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b="Fv9DPVFQ"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="CW7Sibs8" Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfout.stl.internal (Postfix) with ESMTP id AB8A01D00072; Sat, 12 Sep 2026 02:53:37 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Sat, 12 Sep 2026 02:53:38 -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=1789196017; x= 1789282417; bh=29kuZTOL34ZYrLuE3glr7QdIb7w/z7TETbxd0s1r3s4=; b=F v9DPVFQRNtxHaEWJMx1F1K9kBEsuVh6czXmO5N7fJet2UXqFKeWmRGQmeAG7IBO+ KzUXsZP8bSQnQC/HV9m/hDjjjWu0kkOn3ha31tKIQ8VSW1piRSZJlf2tYt4XZ7H1 x3VDFJLH7m+3QSolmClVloS3II7UyTwxdvH7c8ewsPVtn33yXG4y0JRVSipZQPNO qbRW/v7YlpYUgECsZneKfArFCG6KZLLR5YZzMzBPhX0zmn9BAtB+1SI5iv2HgbOa EsFSfbioccxbO6lsNe0f41kqj6nw0ihXIhOPw8yAaHY6KV9h0LdcEEOAEmnyeJOu +OzZC3F89SJJH21IebmJQ== 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=1789196017; x=1789282417; bh=2 9kuZTOL34ZYrLuE3glr7QdIb7w/z7TETbxd0s1r3s4=; b=CW7Sibs8Nl6o7kNFT hLLBtN3ACmk9BWxRULQknYmX58qkR/CXyDUbh1LprOGy/cI2tXP6gE10jP6u3eBR B9z8A42Z8WZ4YG2vS8r6BjzU6Vf6h0ZTlsCapFegZILF3nQML46kFkERB8+eI2cz qrlFPgK6ShgKpOqzxtO1QHcZG8wSApEL/phx67ifs8OgkmkWQ3oinwVB8koJdyfI ZWyoxU8JU6/pOlrP21b0D1C3Gt1mz9tl2WshmLv7NCMm4JD1FCz1gqnO6K2+sz2y zhxb210trNL+B1jp3muH+DyQP2zjdSYLkgbxMyk672FEv88yFlankE22LSxv7LEo lpUmA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFdeou/rbPZ0VyQgVeeN0Gr5FPjkDs1WcHQqmznz4822R6kIGkA6M2j2vL65U0LHa hJMTpzNtpSPndker32EDj/av1OoTrFZCOL+/rpWrbqdHOV0wxVplOupufhBfTl2nkuCDeo WutOwNfhVelqRAGrUIW6Tr5x4cT+rccYeXK0sVaQXwT64DJXiZ/8JVDkwt5IzZDuPG1YG2 3O2o3Ta2PYQVpvHs2Pp1mAygVSjtkvNJP2cZEhnK/mNXtSJIqwU6EpEGiWseBWMNb/qZaR 5jk99FyCnnmWy6VyY4rt8MvFdKYOBQ+jg7yaVaZMXhvnhbfzgIWf0uQyPIgzQrlr0ZskBY NAp4y/yg4bd+gAMw4sJqBCu7I5gQc8s9jjHJG+AvOlT+FhPFkBTrqXomTr0De7kqvkU6Yg MkzHC6m6eCQRBqqL8X0LKVtDrlaFURsmIMugUJ+8AurJwGjthDKJy1KEHKWC3TQoZLlBeg fH3bRTABWEgFou1rKvr+zwsPGjCjmFWGB+tk8MfUa+1lqeQLoEl/Wq4OyCXoVnLwdpU5or fQ4fFd+xU3REj1c0A1As+XeLp4ah9RZKIXxsPrdE9/5i4IWmeW/1Cazm8c++ybIbgey7Bn kp6n3/O4nPF5ak4VdoNHrkAmZkaE2N65cONEk0EStetrio/Lpt3ZJI/paJxw X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Sep 2026 02:53:29 -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 13/14] arm64: dts: rockchip: add NPU (RKNN) nodes to rk3576 Date: Sat, 12 Sep 2026 18:50:52 +1200 Message-ID: <20260912065053.1519165-14-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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Add the two RKNN cores and their IOMMUs. Both cores are disabled by default; boards enable what they wire up. PD_NPU0 and PD_NPU1 are siblings under PD_NPUTOP and hold one core each, but the convolution buffer and the DSU sit above them: ACLK_RKNN_CBUF, HCLK_RKNN_CBUF and CLK_RKNN_DSU0 belong to the block rather than to either core, and PD_NPUTOP already lists all three. Add them to both core domains as well, so a core domain switching state has the clocks of the path it shares running, and give each core domain the BIU reset that the pmdomain driver now cycles once power is on. Each core lists both core domains, its own first, so that a core in use has the whole block powered. Whether a single core can reach the shared path with the sibling domain off is not something this series establishes; listing both is the description that has been tested here. The IOMMU in front of each core lists that core's domain only. Label the outer PD_NPU node so a board can attach the NPU rail to the domain that gates the block. Clock the NPU inside the voltage its rail is given. CLK_RKNN_DSU0 clocks both cores and the CBUF they share, nothing in mainline sets its rate, and the block comes up at 786.432 MHz. Rockchip's OPP table for this NPU asks 800 mV of its 800 MHz step at the worst leakage bins, and nothing in mainline sets the rail either, so a board that follows this DTS runs the NPU above the step whose voltage it happens to boot with. On a ROCK 4D with both cores enabled and vdd_npu_s0 at the 750 mV its PMIC comes up with, two jobs in flight at once make the second core write single words of its output wrong: the right value with a bit of the accumulator set, always the same position in the array. Either core alone is exact. Four device trees, same board, kernel and userspace, four passes of 5400 rows each, every row compared with the same multiply done one row at a time: 786 MHz, 750 mV 13 to 20 wrong rows a pass 594 MHz, 750 mV 0, 0, 0, 0 786 MHz, 800 mV 0, 0, 0, 0 786 MHz, 850 mV 0, 0, 0, 0 594 MHz is a divider off GPLL and sits between that table's 500 and 600 MHz steps, both of which ask 725 mV at every leakage bin, so it is inside the voltage a board that describes no NPU rail already provides. The trade it buys is a core against a clock, and both halves are measured. The rate lives in the device tree, so the two clocks cannot share a boot; boot-to-boot drift was measured first, by booting 594 twice, and is under 1%. Five runs an arm, the arms alternating inside a boot, one warm-up a model discarded, medians of five: decode tok/s 594 MHz 786 MHz Llama-3.2-1B 17.85 18.60 two cores 11.17 13.77 one core SmolLM2-135M 41.46 43.12 two cores 38.26 41.90 one core Losing 192 MHz costs 4.0 to 4.2% of decode with both cores running. Losing a core costs 26 to 37% on the 1B model, at either clock. The rate is the cheaper of the two by seven to nine times. The two arms cross-check each other: the clock is worth 23% on ONE core against 4% on two. With both cores running the bottleneck is no longer the clock, which is why this configuration can afford to give up 192 MHz. A core is worth much less on a small model, 2.8 to 7.7% on 135M, where the second core's dispatch overhead is not repaid. TTFT moves by under 2% either way, so none of this says anything about prefill. An OPP table with the rail attached is the proper answer, and it wants driver support this series does not have. Signed-off-by: Jiaxing Hu Tested-by lines stand as he sent them. --- arch/arm64/boot/dts/rockchip/rk3576.dtsi | 86 +++++++++++++++++++++++- 1 file changed, 83 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts= /rockchip/rk3576.dtsi index d418bfc04..e9cd11b58 100644 --- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi @@ -1042,7 +1042,7 @@ power: power-controller { #address-cells =3D <1>; #size-cells =3D <0>; =20 - power-domain@RK3576_PD_NPU { + pd_npu: power-domain@RK3576_PD_NPU { reg =3D ; #power-domain-cells =3D <1>; #address-cells =3D <1>; @@ -1070,14 +1070,22 @@ power-domain@RK3576_PD_NPUTOP { power-domain@RK3576_PD_NPU0 { reg =3D ; clocks =3D <&cru HCLK_RKNN_ROOT>, - <&cru ACLK_RKNN0>; + <&cru ACLK_RKNN0>, + <&cru CLK_RKNN_DSU0>, + <&cru ACLK_RKNN_CBUF>, + <&cru HCLK_RKNN_CBUF>; + resets =3D <&cru SRST_A_RKNN0_BIU>; pm_qos =3D <&qos_npu_m0>; #power-domain-cells =3D <0>; }; power-domain@RK3576_PD_NPU1 { reg =3D ; clocks =3D <&cru HCLK_RKNN_ROOT>, - <&cru ACLK_RKNN1>; + <&cru ACLK_RKNN1>, + <&cru CLK_RKNN_DSU0>, + <&cru ACLK_RKNN_CBUF>, + <&cru HCLK_RKNN_CBUF>; + resets =3D <&cru SRST_A_RKNN1_BIU>; pm_qos =3D <&qos_npu_m1>; #power-domain-cells =3D <0>; }; @@ -1261,6 +1269,78 @@ power-domain@RK3576_PD_VO1 { }; }; =20 + rknn_core_0: npu@27700000 { + compatible =3D "rockchip,rk3576-rknn-core"; + reg =3D <0x0 0x27700000 0x0 0x1000>, + <0x0 0x27701000 0x0 0x1000>, + <0x0 0x27703000 0x0 0x1000>; + reg-names =3D "pc", "cna", "core"; + interrupts =3D ; + clocks =3D <&cru ACLK_RKNN0>, <&cru HCLK_RKNN_ROOT>, + <&cru CLK_RKNN_DSU0>, <&cru PCLK_NPUTOP_ROOT>, + <&cru ACLK_RKNN_CBUF>, <&cru HCLK_RKNN_CBUF>; + clock-names =3D "aclk", "hclk", "npu", "pclk", + "aclk_cbuf", "hclk_cbuf"; + assigned-clocks =3D <&cru CLK_RKNN_DSU0>; + assigned-clock-rates =3D <594000000>; + resets =3D <&cru SRST_A_RKNN0>; + reset-names =3D "srst_a"; + power-domains =3D <&power RK3576_PD_NPU0>, <&power RK3576_PD_NPU1>; + iommus =3D <&rknn_mmu_0>; + status =3D "disabled"; + }; + + rknn_mmu_0: iommu@27702000 { + compatible =3D "rockchip,rk3576-npu-iommu", "rockchip,rk3568-iommu"; + reg =3D <0x0 0x27702000 0x0 0x100>, + <0x0 0x27702100 0x0 0x100>; + interrupts =3D ; + clocks =3D <&cru ACLK_RKNN0>, <&cru HCLK_RKNN_ROOT>, + <&cru CLK_RKNN_DSU0>, <&cru ACLK_RKNN_CBUF>, + <&cru HCLK_RKNN_CBUF>; + clock-names =3D "aclk", "iface", "npu", + "aclk_cbuf", "hclk_cbuf"; + #iommu-cells =3D <0>; + power-domains =3D <&power RK3576_PD_NPU0>; + status =3D "disabled"; + }; + + rknn_core_1: npu@27708000 { + compatible =3D "rockchip,rk3576-rknn-core"; + reg =3D <0x0 0x27708000 0x0 0x1000>, + <0x0 0x27709000 0x0 0x1000>, + <0x0 0x2770b000 0x0 0x1000>; + reg-names =3D "pc", "cna", "core"; + interrupts =3D ; + clocks =3D <&cru ACLK_RKNN1>, <&cru HCLK_RKNN_ROOT>, + <&cru CLK_RKNN_DSU0>, <&cru PCLK_NPUTOP_ROOT>, + <&cru ACLK_RKNN_CBUF>, <&cru HCLK_RKNN_CBUF>; + clock-names =3D "aclk", "hclk", "npu", "pclk", + "aclk_cbuf", "hclk_cbuf"; + assigned-clocks =3D <&cru CLK_RKNN_DSU0>; + assigned-clock-rates =3D <594000000>; + resets =3D <&cru SRST_A_RKNN1>; + reset-names =3D "srst_a"; + power-domains =3D <&power RK3576_PD_NPU1>, <&power RK3576_PD_NPU0>; + iommus =3D <&rknn_mmu_1>; + status =3D "disabled"; + }; + + rknn_mmu_1: iommu@2770a000 { + compatible =3D "rockchip,rk3576-npu-iommu", "rockchip,rk3568-iommu"; + reg =3D <0x0 0x2770a000 0x0 0x100>, + <0x0 0x2770a100 0x0 0x100>; + interrupts =3D ; + clocks =3D <&cru ACLK_RKNN1>, <&cru HCLK_RKNN_ROOT>, + <&cru CLK_RKNN_DSU0>, <&cru ACLK_RKNN_CBUF>, + <&cru HCLK_RKNN_CBUF>; + clock-names =3D "aclk", "iface", "npu", + "aclk_cbuf", "hclk_cbuf"; + #iommu-cells =3D <0>; + power-domains =3D <&power RK3576_PD_NPU1>; + status =3D "disabled"; + }; + gpu: gpu@27800000 { compatible =3D "rockchip,rk3576-mali", "arm,mali-bifrost"; reg =3D <0x0 0x27800000 0x0 0x20000>; --=20 2.43.0 From nobody Fri Sep 25 13:16:57 2026 Received: from fhigh-b3-smtp.messagingengine.com (fhigh-b3-smtp.messagingengine.com [202.12.124.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A5E133793CA; Sat, 12 Sep 2026 06:53:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.154 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789196032; cv=none; b=SovT2RxY+PQ0ghoapLTwGJR79shyB6+EX0nNRxwY5hF7bCIbRuTkG5puAxDjUl9G17ldgBJR/wZXAPuegD17+b9r042qCeNj3RMeCW78nwYD4iZNalpoiUtLmFvQWMf55iE8DjBZ7PlnEStTm+yRAkZJPAcLwcYLZk6rYO8JBYU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789196032; c=relaxed/simple; bh=D4ppPQapyLhd/s9SIDIm3/DEZoesU7DqcPjoruLNSyw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LEi6oR5sdjII0RBP/RLMV2tbgOfTLDjplYRrW0Zr4cVhDEOB3gcI7lxYnUqs5+oiNrVSkzyRvfAVrLkgqHECoxa/C8zp1qajCrzrpu5SlSIl73w4CCEsDwiLb9r3H0PSYxLgj18t4deqn6WncFoJqeRT71xjbuBFFNTvNfk2TEY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com; spf=pass smtp.mailfrom=gahingwoo.com; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b=fK+Xymrk; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=FAE1otxT; arc=none smtp.client-ip=202.12.124.154 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b="fK+Xymrk"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="FAE1otxT" Received: from phl-compute-08.internal (phl-compute-08.internal [10.202.2.48]) by mailfhigh.stl.internal (Postfix) with ESMTP id 4A2957A00B7; Sat, 12 Sep 2026 02:53:50 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-08.internal (MEProxy); Sat, 12 Sep 2026 02:53:51 -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=1789196030; x= 1789282430; bh=0k2WO5fN2pPgdnD7jJ6cdxK1ff8uhQPVB9+e5XeZDfk=; b=f K+XymrkLWoxteljZXabGSBIqL61Zu2BTTuOAD0N4cV/lHW1NuVtqIkkwM5wmOe0w yrYGCB00b9Klz07FvhcQbJ6qO159bHcM5gTdJzrhU+cq8DxN5iO/nQQqjJbwosBR 7yAQix4XY01Af/R8rDzTf8ozcGNm5E80MbrX6WXURmSArQOjfc1Yuqzv3FvgiQQt Myyb2JBKxnDV5xWJwbtkPFpU9gkhR6KTWPHTxBDUUQ+4VDpa3gld2ZQEJBjZnHR3 RmW0BXHSk09CU/a3SCz/rWCtK2zLu6CQE4nog9+GWXXW4ytaTPIwnZ0IeO75khKw KAue8PSE7kasYymJHGHRA== 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=1789196030; x=1789282430; bh=0 k2WO5fN2pPgdnD7jJ6cdxK1ff8uhQPVB9+e5XeZDfk=; b=FAE1otxThQyCWh8dk 07JN03sDnUdnKEVkkICGsvWDiv5vupR7ANEcL/hyeOdB+o7+q+O7cgIrdEAOH0d6 WNjNV3pi6tOnwtEpHjhbJh3wOenUIo4J7laC2ewfz93rtL1yRYE11yg36XGoBhDM SlJMnfX1iNnTRKaiGsYHNoGuVvAJhMkbhmJEan8zQo/Y3w835uNU2R/kAtQ42qD0 fetiImiRIRbfaKe8mDrKX/qMHv8/7GMMWJELsoq4guaTTt45Z6+uoeGhZ9DQUGfk bFoVQAMV85EuzM7GDEhFTC69OaIQ04EfDjIbMsLV9avM8u2JZIncSO4FnDK9q158 ohDAw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEPb8qUI/Bch63DUv9Os4CRaZnJidcR38w4lyHY6iaGmzqubjANrD0SeN/gjpgWtD 9JpSgLNav7upxo5UY8BD+gTgneuYvtjdT7xUeoI37l3u3ANYgfWTUMIQPTBe+0FGjKZ893 EmiED4E9ABLDGP636x+3BNPL+06gHQG63VHM2tKDilhH/OyX7+TagruxeFKd93pQCYj32B BeiQF2P6k05N47Few9BlXMbV3J128+kb4hnRL4hf+Yoc0wDQXXqOQeonbIg1B1tOCqO85x XB7Y9LiCcE2oZkETEXdiacCDRMuKmK7OMtWiJEvsJa8P7QUcJM2B6xHrJPAU/2XBsLk7bM m27vY8ozK/KlfZmGBKAPbjJMlPQrud7ajj9pjQQJECGhLRlUzuPDe6o2kZ6X6599jvqvPZ h8Dgp8Q3N9bMaltRzFbHYkAFHOlbVPdKse6mY6gfIt5wKu0FwlkdB6qrQTd2hhd+QygHni 2aHzPO2jen3yb8J1HhHjm3Qmvb4Id63GebKaIrE7dXgM+wb+lHhDez1B36yFGuYawoitaf nGSQqYygetd4z+PfVwECu409nXImY6ttuPzKi3bkOT2x8xns50PPLgZbW5sXvPyDVyh5Ik OkKCCAY+DN6nMTbaDemvNIiavZruGa2BnQ/oWyh8EoKS1WqDEKuUIJoesOYg X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Sep 2026 02:53:40 -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 14/14] arm64: dts: rockchip: enable the NPU on rk3576-rock-4d Date: Sat, 12 Sep 2026 18:50:53 +1200 Message-ID: <20260912065053.1519165-15-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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Enable both RKNN cores and their IOMMUs on the Radxa ROCK 4D, and hand vdd_npu_s0 to the NPU power domain as its domain-supply, so the rail is switched by the domain that gates the block. Measured on a ROCK 4D with this in place. The rail's regulator debugfs reports open_count 1, so the domain is the consumer that took it. A sampler running beside an inference caught use_count at 1, and three reads at rest report use_count 0 with the rail disabled, so it follows the domain rather than staying on. Over the same run the genpd active_time of all four NPU domains rises by roughly 60ms per inference, and the inferences either side of that are 128 of 128 channels against the CPU reference. Both cores keep npu-supply on the same rail, which the binding requires. v11 enabled rknn_core_0 alone and left the second to whoever could test it; it has been tested since. Both cores probe, each with its IOMMU, and a runtime that deals its submits across the two returns text identical to the one-core run over nine language models. Signed-off-by: Jiaxing Hu Tested-by lines stand as he sent them. --- .../boot/dts/rockchip/rk3576-rock-4d.dts | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts b/arch/arm64/b= oot/dts/rockchip/rk3576-rock-4d.dts index 272af1012..93d59c0a9 100644 --- a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts +++ b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts @@ -722,6 +722,10 @@ &pcie0 { status =3D "okay"; }; =20 +&pd_npu { + domain-supply =3D <&vdd_npu_s0>; +}; + &pinctrl { hdmi { hdmi_tx_on_h: hdmi-tx-on-h { @@ -779,6 +783,24 @@ wifi_en_h: wifi-en-h { }; }; =20 +&rknn_core_0 { + npu-supply =3D <&vdd_npu_s0>; + status =3D "okay"; +}; + +&rknn_mmu_0 { + status =3D "okay"; +}; + +&rknn_core_1 { + npu-supply =3D <&vdd_npu_s0>; + status =3D "okay"; +}; + +&rknn_mmu_1 { + status =3D "okay"; +}; + &sai6 { status =3D "okay"; }; --=20 2.43.0