From nobody Fri Sep 25 07:56:18 2026 Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 A84B3485CD6; Tue, 15 Sep 2026 10:43:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469039; cv=none; b=WMnPZdBTVbjjPpc2eXU9sXCdF51EncLYY7dcGx57cr2O607SQPExC0QsaBwbyObslfqZBFI5hDgfvF72kR9/Pmb3tBRSxxvkonBbNR18KwM+6didtNIEkT6NwpSexF7GbVEVYuGZ9ExuPZiRs1YZyE0qj+/8Jay3uk2W63nWHrs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469039; c=relaxed/simple; bh=NzFBEuKw+edBTPRDPqk05HVymcwE1+Hsrc/T5KLMj4k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Y0ukRaWqp6lVOoTyGJNFK62mr6Ss06wfLOXQgE0Ot7Eleh6fBRYGeNN5XDaZhJxxmugJxD9k/QqHvC9sBm5goxlPhRkxbJ6zXAFwO4/JWp4CVMGOv69o6948ptQQwMXu1zMsltUpnn+/1w0qxyT2C4DFpi1SC4tf7UNTs17RYqY= 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=JOwYt+Oa; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=R1y2D1kk; arc=none smtp.client-ip=202.12.124.141 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="JOwYt+Oa"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="R1y2D1kk" Received: from phl-compute-08.internal (phl-compute-08.internal [10.202.2.48]) by mailflow.stl.internal (Postfix) with ESMTP id 4C11C130050A; Tue, 15 Sep 2026 06:43:55 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-08.internal (MEProxy); Tue, 15 Sep 2026 06:43:56 -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=1789469035; x= 1789476235; bh=bhEwuQXKYWMYM7UfAE9zXDC7PfmHACUKFcOafx5HkO8=; b=J OwYt+OafxXCRMaXL1Qq2O3plf7gkfpdplNbl9LltZI6ZSLhJ2bQRIGroTFNVZDy5 BVYkdbBzSGQZRW76BPvu1tW1MW/Fq4GtPmslBhctlmf9L+fDnUb1aKcSFcJY+HG3 tY0VHYKtj7ytNkkIVyjSR0Bn+FNjFDlkFzayF7W/yZOgjVQxGq4KTogdCXNvgqja 6kLvPbFq074I0l8Tysp3w9MgRMYlab73baS9gnOwMWfKRaAZtkpTPSIGEvKqWbnl itdGEp8D0Fdic2HT7hPAyy6oQbN20gw71Vk4EFa30NLU3TqAwm64U0j3oPkxYDyc tloIZtI4B9Wnktew/pifg== 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=1789469035; x=1789476235; bh=b hEwuQXKYWMYM7UfAE9zXDC7PfmHACUKFcOafx5HkO8=; b=R1y2D1kkxLklhMTaa uDNn62OcZ3YDUmtF7Axiupfb07Ud8AhHOSQVgybZQEldFjNXYkWZ7MhM4rRWKVBR C1mLYuY2uDch1Rex4XgrRJF5xkcGJbNoW9/gOLfjrOkYV0iX7S9dTs1nc+7FIyx+ DaNWemG9ChCdkBL6Nl2XJ4NGTSaZQQsOw/iYmKDMIyjn9B0YjtIqbEhwqdZUIsNK MzeoO82dgIrNP7+rHD/RWpFFnNLi4JlD8LxkIwE3DEu2Uu6M7GK6b8eLRFOCoi2b SfN7tbzXRabOcX1sGZFoTmJ/HXDOghNPklqQ9JNKPUX1rHZy/iFa6xTKq9AHcpuE jj/fg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEJ7lsNMc5MXcmK0yAby6zAyahnp/o+BLQRTsAUuD6zUFYE1mfayW4ARlNvxFxbHL RViSXklp2Mvqoh7nMl9WcpZxcA5zX09aM17WbnSDD1mVdJoa+dDoRGgFZ+ZZgzctt5mn// Fi1Mt6BzxdDiSZyXddMkKr5ZuKnhcJKMT/Ww41HfwQaAux+0BU99FP+g6srkBweq+0Pyu4 FpApM0KD75gdC3rQ4X6qbPGbs1ABgnV9cF7lajdZo5Ix2shyw0qolijI7Y4mlyGIz0nhlc sJGrQ0glbm4LA0H4VdiK+uhUvmoFkp3adh0VEvVmG9UeMUF3kO5gMGvK351yi5uht+G8ce DI7/ZiNybPTuBoz++yjJPRGtS44vvbyjusqOT9iol7emrB4kj7YhT9UdW604rLiJ/Shmi8 JBTltnyRRqh0h+4rhdebi6ygPNLMmHn1hBORW4tfXhCVQ+DEnkk/JloYpdyEWCG1ehWuld gOtJRMEapgatlm+E2j7VEY1x5ljIgDaiTIVALzGirBGxdKsnpaU4yWgnbr1U9KYEx3i/Vp ASLpc53MK7MsdnqDjG4sjcnOWI1g36X4NRCP/8iuJtEhrb5U+LDPG4VqNpXQaGvyU8HHT2 QzVVllk3jxuHCFrEJgEO4YqoHhkcDjazkIiw6vM7TAC0jOgZt3cTImBwMPew X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Sep 2026 06:43:46 -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 v13 01/14] accel/rocket: request the core clocks by name Date: Tue, 15 Sep 2026 22:43:15 +1200 Message-ID: <20260915104328.45901-2-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260915104328.45901-1-gahing@gahingwoo.com> References: <20260915104328.45901-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 --- 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 07:56:18 2026 Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 696AE48821E; Tue, 15 Sep 2026 10:44:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469050; cv=none; b=IF/zYimmWT1gZ+rg9Tn3cbRYm4OtfiDeutIIIYm3/y3TXIX6jNXjhCg3Bp8IQHH2PRw62TZO/1R0FiLzskxvb8YX8BiWt4fWKOQ0bMT9p9z2/54pzhSo/SdnKwPkHhCHntphf0DC+haE88nAZpqKRFsXq998qpMV/mq4IXBajy8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469050; c=relaxed/simple; bh=UNtUWedXOFw6Y84guT0ri0JEMNMiMFLDLbVrN0d1vzM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dJbde7d8mr7n4puyFTAf7SlJvh33lr/7Y2GrgRKowr+41zDOymIZPEpY3kUY8Pg7OEGYhuQn7oD0as2rkYkMN1Wg9muYGRWluXLbsQx/+1ducVs9TVpUa3bpdradQQ6zGr2+vQOmyQoOxNM0kCplDV5PahIHu+6GKI61/6yQfZo= 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=rGrL2iyq; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=Szew/k5R; arc=none smtp.client-ip=202.12.124.141 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="rGrL2iyq"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="Szew/k5R" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailflow.stl.internal (Postfix) with ESMTP id 07EE2130050A; Tue, 15 Sep 2026 06:44:07 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Tue, 15 Sep 2026 06:44:07 -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=1789469046; x= 1789476246; bh=v1ElCBSyTnCFYrsQFQwtZaxsgmNkPMyYPZX+ryKcWRc=; b=r GrL2iyqQQWO8+8HBmci/t8HWjVRbcseCtQOYKljW6CSG0K8vd6c66UsRSqo6UvJ7 I7JXug7/5RwewgC6sdVFdvlWqR3TCGK+/I6waHy38xeN7M8pnE/QIGto71iE2TP3 RtKRkq9yNjreEYnTuQQXOQCg4N30eJYypP5zqcUIipslwimZA71gL+4Z8PaDX7Ca Iyv8PegFRnIwqAXy1uail0X6ktfMbf2NXDqrf6g0LjMwOFoiQJRsNyMqqOCTZAH9 j7EneBr/2PH3QW8iM2VD0DgBd2E99M6d2TTQpSp2ysSvq2QL5wOFpaT5TfVeMdNm E5TejJXRwO8EF9FIyxkdw== 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=1789469046; x=1789476246; bh=v 1ElCBSyTnCFYrsQFQwtZaxsgmNkPMyYPZX+ryKcWRc=; b=Szew/k5RMyQelOvT/ 7vWtqRDYTlZsrya+RycBeZxBdSXcZtvhEXg4Mya/1yJwYrxLSOkBa9yV2zDMhSnN enOaNVoqIp9nBbW5qt/sY71flV/4jUrr6GvKcOOPGHswC84kwNKxihN7O5QlmG0n K8M3Ao2TCDUiYOZZXFHqx2Vam+YMbv8NOZW0Iid/kUbS/vnOCGveMgX6vxXMGIQq wORyaYiYvp+tb1ek6oSbJybOFJNjXn/yypycRe1Xy2RZml4+Ndf461vgwCwf9enB 6Q9oDE7r6jx6LRLZGlEqSeshE4k9XSsO6YsGzMLsuVOusl4TFqKivuM3uuKFeT8B VlFTQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEJ7lsNMc5MXcmK0yAby6zAyahnp/o+BLQRTsAUuD6zUFYE1mfayW4ARlNvxFxbHL RViSXklp2Mvqoh7nMl9WcpZxcA5zX09aM17WbnSDD1mVdJoa+dDoRGgFZ+ZZgzctt5mn// Fi1Mt6BzxdDiSZyXddMkKr5ZuKnhcJKMT/Ww41HfwQaAux+0BU99FP+g6srkBweq+0Pyu4 FpApM0KD75gdC3rQ4X6qbPGbs1ABgnV9cF7lajdZo5Ix2shyw0qolijI7Y4mlyGIz0nhlc sJGrQ0glbm4LA0H4VdiK+uhUvmoFkp3adh0VEvVmG9UeMUF3kO5gMGvK351yi5uht+G8HJ 9VIQDdOShQh0XpTD2S2lGQbN+p0sfwZyLoHdudE5j8rPF0gisWveIjbPVJ2de4yTnbnZRb yhKAkObkGu9cCJKGyUZ/ogRYYyw65d8zdgDZf7yNUl315cvni+3qPAOgqxwWeK3+uklvg/ VeZsYBwOcZLbKU89lu2goMk8FJdXZWg96ZmXXhJI+yHUzWVe/UnWGOVQvuUL7MpfjiDubX 4d1PM9xRi1VbQGC0W4xwRNiug/af2YtVXaRe4KfNB6Odx+5bA+Tq93vcBagC8gKkWwuoEX 65YeQwDhMUgv5ohAfgua27G3SIbLrcWlmtJvbzKypmfH/0u2VQKkBK5XruDQ X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Sep 2026 06:43:58 -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 v13 02/14] accel/rocket: take the completion register writes under job_lock Date: Tue, 15 Sep 2026 22:43:16 +1200 Message-ID: <20260915104328.45901-3-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260915104328.45901-1-gahing@gahingwoo.com> References: <20260915104328.45901-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, ind= uced reset, JOB_TIMEOUT_MS=3D2 --- 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 07:56:18 2026 Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 668EC48CD60; Tue, 15 Sep 2026 10:44:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469061; cv=none; b=eHRwyFPMQLhtcZdFUh4UeMcEnkQZLmNrlCwwZgiI2hxoWR/7smV+BQeNdFK0IQaNumvgyvUvCGags2qtW8Mxgl/clehayyLiaTq7dWHHXbiYlzn9Hfu5WQYCtNbOq7gYzuSCXDTBUTgmrUGeqM+weMhUtuneOSN9a8+u2VPq7OQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469061; c=relaxed/simple; bh=oxhxGUx2HMNqsz0n/0zSX+4g/cPJMS8th5puphONEyA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=c16TxrtKgD15Z8C+DtHeHIyr4L+RD4kPJe1UIQ0Vl9Km8JAF9YjSyGs3TPJ5ksLI4AgnB+6kAN899LzNQ+v42x2WTKxPuH7ha9LOj64iAq0XSJh/SiMb9twkkwRxY/N0yreuqwB0TsSAyz5CpTZ2oQ36pCDfyJIroaZuAro/9Ck= 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=reF3IplS; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=VuQio1mk; arc=none smtp.client-ip=202.12.124.141 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="reF3IplS"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="VuQio1mk" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailflow.stl.internal (Postfix) with ESMTP id 11558130050A; Tue, 15 Sep 2026 06:44:18 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Tue, 15 Sep 2026 06:44: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=1789469057; x= 1789476257; bh=I6ioBW7ScYUdG/oTToYCNPrLN7Q7315lvgvDhvoEbok=; b=r eF3IplSZl/1fOwjtHMfcDCZFXsMAAmY328L9vvhLZjQktqT3A+pmPl6AW7GSCEdh Jup0Nm7mI5YSbwwBhAdxXn+5HfQqkl047nX6bHvwOp69IOCP5em8k9SO3d3t8sAB ThQzQjb0sMybLTpiH8esM8UzLnj5XGW9fpphVJJv1vEfRNJaKTYe6Tzp+hDfo1wD mhfu/FoKMJp3EfvMigkI/bno5T/Xx3LfuDile4/0+67t9nAQWxIHYl8QVeexcBRt +L0f1NW2eGZp5UZuggcg0bKFAoRu+ufkldQnpZ/ScpUA2TBmZQ+zSh5WE5ZhvL1X umy15VeNIQ+Run/Wt+EVg== 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=1789469057; x=1789476257; bh=I 6ioBW7ScYUdG/oTToYCNPrLN7Q7315lvgvDhvoEbok=; b=VuQio1mkFpj6GJwvF AQZb96Jc733eoM3pOP1rFTkc+iEYVmR0QvQ76GiWSwANnbvwY1FNFtDdGBrxEMVF oygKw9Emoo2EGbTepEMIn95grJoY39DK4t1GkdX49aUVsSIak2lXjDxNTpBv8ggH dRVBeMMQoO5GqR53uunIa1A3xwnQFEhPb/A2UaoZOHUpSWdlIPSIOnN0jWuqqOQe KDuyKJlTzDGcSwqlCj+rlAm5mFUK3CFEZkzumz42bKHNKx/O9wMLaRIhDPWJMxuT gjIGd6noT7LQre7xzhe+pjKXhWliING5h3aNgeQHuCdMDs4ZtNIqxLwcS4JjAIyt 2qzNg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTE+OOtKqCgoTSrVlWQquKDyDOihaRAkbxrETzU46WPYI4xRZhEiyJhifUIK7wOXWw wVB9SQ/RAi7MrJDFDtBnx7Pb+n0YwQkRdmArbygP/oxZoxHW8LIKLQIL2L7jzJ+dDFOc0i zgJzZNFATjdf2+j0asWJSTUnqqtG7PFp8Vs3eFHmviT3HEJrjWQLemcS9TcZGgU54P+FV5 4Pm9j2o7pLtOaGphBt5Uxmdvehz8zGy65174LdzdOvWQ05shZHdK5O0prBfSV/v5pCB4Ev utsMlLRk0S0Gt2QFQEaEqPdSBGLc8kXC99b8ea4ToJp+YO5u/c8PUKkTZ3pOeCnaAxuGfw HX+v75BTfd2sEB2EeANuHPDGM9vTWcdK4k/4guAv2h1+Sb8iwf86wlb7GGDMvZonjflT/6 QScWCcnQqRWBApSuoYoKU4tojI75MAb8Hcwevrh+u+i+fUJxRGW4+rTAaSQqVOtkVUfVu6 ju6c9PmbLB5pCYUzbWRTqHz4Tll/QWYUDqEIvk3yep9rYumZ0MUi9CoztUZoRhtpQE2jjp J12frvnHksQ1TRyyxB/jf5e5KWaTQLwEbaLGjj4eFnRycXK7vvVpg5Dx+gsHJQVurR4szb bF3lnsV6ZjfjnaqSRR6Ikwjddz9sDZKnH5RgOdufgDEdiXaWfKPCp4/AQdAA X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Sep 2026 06:44:09 -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 v13 03/14] accel/rocket: wait for a running IRQ handler before resetting a core Date: Tue, 15 Sep 2026 22:43:17 +1200 Message-ID: <20260915104328.45901-4-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260915104328.45901-1-gahing@gahingwoo.com> References: <20260915104328.45901-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 mask write goes UNDER job_lock, though the sync does not. rocket_job_hw_submit() arms the same register and always runs under that lock, while reset.pending is set here without it and read there with it, so a submit that has already passed its check can re-arm the mask after this clears it. The block is then left running a task with its interrupt live while synchronize_irq() fences a handler that has already finished, which is the same shape of race the previous patch closes for OPERATION_ENABLE. pm_runtime_get_if_active() takes a reference on an already-active device without invoking a callback, and pm_runtime_put_autosuspend() is asynchronous, so holding job_lock across them cannot re-enter this driver's runtime PM callbacks. 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 Paunovic ran an induced-reset protocol on RK3588. On 19 and 25 August = he ran it with this patch and the previous one removed as well as applied, so = what those sessions show bounds the pair rather than either one of them; the 12 September session ran two patched arms and no unpatched one, so it re-te= sts nothing differential. His own summary, which aggregates all three after he re-ran the protocol on v12 as posted and corrected his earlier reports: 45 induced resets on 19 August, 102 on 25 August and 74 on 12 September, every reset recovered, no MMU faults, no lockdep report from rocket or the scheduler in the runs where lockdep was still armed, and of the 420 inferences scored, 384 matched the CPU reference within 1 on all 48 output channels while 36 returned the all-0x80 buffer of a job the reset had cancelled. The protocol bounds; it does not prove. The all-0x80 buffer is not a differential signal. rocket_reset() calls drm_sched_stop(), drm_sched_start() then completes the detached jobs with -ECANCELED, and PREP_BO drops the fence error, so that buffer is what a cancelled job looks like from userspace whatever made it miss its deadline. Link: https://lore.kernel.org/all/20260819073530.6087-1-royalnet026@gmail.c= om/ Link: https://lore.kernel.org/all/CAEWPSH5mxTbUkNouxm6yecMZYvDowquhvYvhaXQ8= HoMtHD5U1g@mail.gmail.com/ Link: https://lore.kernel.org/all/20260912113717.6819-1-royalnet026@gmail.c= om/ Suggested-by: Igor Paunovic Signed-off-by: Jiaxing Hu Tested-by: Igor Paunovic # RK3588, three cores, ind= uced reset, JOB_TIMEOUT_MS=3D2 --- drivers/accel/rocket/rocket_job.c | 65 +++++++++++++++++++++++++++++-- 1 file changed, 62 insertions(+), 3 deletions(-) diff --git a/drivers/accel/rocket/rocket_job.c b/drivers/accel/rocket/rocke= t_job.c index 575945015..dfe9135d8 100644 --- a/drivers/accel/rocket/rocket_job.c +++ b/drivers/accel/rocket/rocket_job.c @@ -377,9 +377,68 @@ 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. + * + * UNDER job_lock, because rocket_job_hw_submit() arms this same + * register and always runs under that lock. reset.pending is set here + * without the lock and read there with it, so a submit that has already + * passed its check can re-arm the mask after this clears it, and then + * the synchronize_irq() below fences a handler that is no longer the + * one that matters: the block is left running a task with its + * interrupt live. That is the same race the previous patch took the + * completion writes under this lock to close, on the other register. + * + * pm_runtime_get_if_active() does not invoke a callback -- it only + * takes a reference on an already-active device -- and + * pm_runtime_put_autosuspend() is asynchronous, so neither can re-enter + * this driver's runtime PM callbacks while the lock is held. + */ + scoped_guard(mutex, &core->job_lock) { + 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 07:56:18 2026 Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 953D9481AA5; Tue, 15 Sep 2026 10:44:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469072; cv=none; b=BadHIOGDMvWQ4DSnFkjlJwa85Akbs5AKv/qvWpIbFEouUn/+5zG0POdH96lrQuRed1m0Zq5gokGjghxek0QKEb+0U4tn3QT+G1mrsIi11rpYqSlxVUY95iJaZAm7NIFRFZGLMbspl+NsjwgNvBW6iqX2Nphxh47rfN9SWPPhGgI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469072; c=relaxed/simple; bh=cB5+xlk7Wtmzfy3gi8s7D5t8vMIc/4/cKVl3DgU5ABE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YXoF1esXOiQtKYm+SMJuJohf6bVa9h/NYPyAM9EWlSm4GT14QXJcJb6hKAddru4fTMIiwEOUtamlC/wF1xbUl0kI3thlVtj7EU8hONQyEp2QWgpX/uGVs5bj/jNSK9lS91MxLodG0/yAvdCsfPAT1LqwfOhRIEts4WvoQ1GSAMQ= 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=s+msqHx8; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=WjnHBMwd; arc=none smtp.client-ip=202.12.124.141 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="s+msqHx8"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="WjnHBMwd" Received: from phl-compute-07.internal (phl-compute-07.internal [10.202.2.47]) by mailflow.stl.internal (Postfix) with ESMTP id 39E6B130050A; Tue, 15 Sep 2026 06:44:29 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-07.internal (MEProxy); Tue, 15 Sep 2026 06:44: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=1789469069; x= 1789476269; bh=ogiWiCQ3bNIbKL3gCXgpDZdn7OpFJCd90E8FcpUzIl4=; b=s +msqHx8wYt7BuCOFl3j9MsX9w5GJ8YE6oc4CkgbByOEn3NOMqoBjIiawV+IulPFL 9AwkeEoZGKzkdkerOj5nHQoZLp+mYaw8d7zEuSrN+boTRolFsnQqAqSn1L1m74tc 1aP3xbI1s96UbU3b9VKj8uDgq2C1nPSXcpZgQw7dMB6wZSwXkfYNqISMSEJaDa9E lE7qZbMNZ17/L/eyVyqR/tRbDsdaTmV9va9m/8B6OUdQYKXoJbM9yHvIYeh7kkDn G3v7iHZDDMA1MYSw5rvDL+dVN9ON+bp0r0lYSpOkTNhLC1SLIgl3xiwjnMo/ieAq hJLOPpSBPCkmTeeL2wtcA== 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=1789469069; x=1789476269; bh=o giWiCQ3bNIbKL3gCXgpDZdn7OpFJCd90E8FcpUzIl4=; b=WjnHBMwdVgj4BAee9 m/OgXvi+1kHFNoqgxNDz5qtHh2Q6iKnukLSZugVEwP4ARgDqBjjL52fM3RJCJLvs AIWtIp7Mv8TZ3JlAQaJjAlifBWSmrE3hdDfZLQZG3TejVjh5pFg6fhmDg1opvX2H TtwXoN23Vvp72wrI19uXcNXY8q+BxBGYIgV9ItX4VtoVuux++RNjjUuohNTGv8vn hwu5lB289sy8ikWyDgnxg4asa2/6/nnB80K5x7d7VpQllED2rwH+UpMeU8gKAS9r dTEkt+PGCkhYN7Ee3W7DYs8rM7KwoAhHQ53ERW9q2I5lF13cq52f5ZbJYOFxhim4 0zshA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTE+OOtKqCgoTSrVlWQquKDyDOihaRAkbxrETzU46WPYI4xRZhEiyJhifUIK7wOXWw wVB9SQ/RAi7MrJDFDtBnx7Pb+n0YwQkRdmArbygP/oxZoxHW8LIKLQIL2L7jzJ+dDFOc0i zgJzZNFATjdf2+j0asWJSTUnqqtG7PFp8Vs3eFHmviT3HEJrjWQLemcS9TcZGgU54P+FV5 4Pm9j2o7pLtOaGphBt5Uxmdvehz8zGy65174LdzdOvWQ05shZHdK5O0prBfSV/v5pCB4Ev utsMlLRk0S0Gt2QFQEaEqPdSBGLc8kXC99b8ea4ToJp+YO5u/c8PUKkTZ3pOeCnaAxuGdJ /BT8K/nh0P2FrQdFEYE10UTIUcJu1LBR0D58cwa6sA7yRrw8n3uAEOF9WPqwtcDwa042iz mhczxIDOr1uQ4NzgmUNuf7i05ePBq49Vg54C/SPO7k7KbGPcvm6e3rQTKt4k5jlFlVIX9e wBFEYsWLJpoqkNgf6E+q6bXxB3tH/w09nozAW55tQU40NUhjLbj3etpz4hy/OzwnbNWZK1 bXAj4gQwE6OfDnkkv1yfUSmhhdvWNDGhi66omzFpzZkhm9Hjd+xxjJKmjo8eczfSA6tPeL B/iZ54o49qMTeRC3U05fb0n3Pg1n8Cgw4GricS8ygP1+0Y1iEQFNmKcZi3ig X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Sep 2026 06:44: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 v13 04/14] accel/rocket: let the core suspend after a reset Date: Tue, 15 Sep 2026 22:43:18 +1200 Message-ID: <20260915104328.45901-5-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260915104328.45901-1-gahing@gahingwoo.com> References: <20260915104328.45901-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, all of them on core 0 with the other two cores bound but idle in his single client protocol, 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 --- 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 dfe9135d8..2a0b8af6f 100644 --- a/drivers/accel/rocket/rocket_job.c +++ b/drivers/accel/rocket/rocket_job.c @@ -437,12 +437,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 07:56:18 2026 Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 8FF39481AB7; Tue, 15 Sep 2026 10:44:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469084; cv=none; b=CJaregUpc2YO1eS1ChbKd/QoEVNmQu8U06AO58uBsZHlTnDQ4uOYOU6YCFir62WnlDqDtQK9BRIpV8n55P3MEv69XWxoUg3FtM3aphdGO3IgdwqG2kgTo4SP9RaCFfMH99ctDHp9kQTUxEV05/EXsn4SIbIN+i07ZuR2I8/E8lI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469084; c=relaxed/simple; bh=VY+jAzc2LpYZrHfjHkhavBoH4rrL0d63DJB6mvv2fk8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EEDgvkaxxQ1U79szrrWjeBkn3v8IcF44cnXpnDO6BdFLJGoJUNzviefVE6oj/J/Xd5B37iebhzIOlEYEVUKqTRS8sasQg1Yw+q6GgivFtWlOW3aF7WlEE8qYxmkr+i6YRcnfeRteqMqSsOgtr/EQtigbcr2OJCS/+eIvtsOJdhQ= 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=aj/kfVAU; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=NSS5GWOT; arc=none smtp.client-ip=202.12.124.141 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="aj/kfVAU"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="NSS5GWOT" Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailflow.stl.internal (Postfix) with ESMTP id 30071130050E; Tue, 15 Sep 2026 06:44:41 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Tue, 15 Sep 2026 06:44: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=1789469081; x= 1789476281; bh=lQdZ0GHKydOrKI+dUcKiWk5+c+F2epU+605XobNgMDI=; b=a j/kfVAULkQ7Zl+5CTq4oWRIGyK+jSYdSb+kceBSWxB5CwZpF2H14siu6rd7FPUPK tULObl6PDTehISiwCcyM1dT45XXzKORzQPy3Wk0h7vbcNfyiqmAgz9uoupH7r5Pz xL91HkGsi/FNvHQ7wWESYKwTs4+L65iqfHdhcD9CjQmsDfh44XgH+w+KezgHftHz 1LSdC0KDQPo+2fLE2S3cv8e5gC2irXXfotCDYK9zTo4GEwwnQjuXYGOkRkoOM5zP TaoOy/p7jMIfpQVd3lzgQIYLVufvLvF6le0p/RcTLomtUft37LgKJKoFvcee+Vv2 E90qnbUBlNhtGvwr3hgoQ== 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=1789469081; x=1789476281; bh=l QdZ0GHKydOrKI+dUcKiWk5+c+F2epU+605XobNgMDI=; b=NSS5GWOTn39hXlrjh 2tynGo4wuL6qi8Uutjv9s1wC/6C3JGTixQ9RcDynsquvj0a2yu3vRBDa6xn5xTNv PGAjeKG6r7WbdteYWg/sRwnbpn1aJZROpUo5MWB+4s687zZ6MwmzJPVsMQuTLSXJ VFYrXUy4GebYjpW0oMBAiHkEgXEbDTyG4fDrS2e7cr9d03ajtgEWvV1DZEDFKj7D uVm4q/WMPwt9kXANMZIcegfjGamCMwtwywU8F1k0SYaTNWEkcQJWnt1x71qa6/di PbSYUZsw6FmPs+2KJWXCU6ux1qZlJ1HLEVVeDUI8xsBu4Zr0Y/oBzikVwZfk7QLU Xm9uw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEJ7lsNMc5MXcmK0yAby6zAyahnp/o+BLQRTsAUuD6zUFYE1mfayW4ARlNvxFxbHL RViSXklp2Mvqoh7nMl9WcpZxcA5zX09aM17WbnSDD1mVdJoa+dDoRGgFZ+ZZgzctt5mn// Fi1Mt6BzxdDiSZyXddMkKr5ZuKnhcJKMT/Ww41HfwQaAux+0BU99FP+g6srkBweq+0Pyu4 FpApM0KD75gdC3rQ4X6qbPGbs1ABgnV9cF7lajdZo5Ix2shyw0qolijI7Y4mlyGIz0nhlc sJGrQ0glbm4LA0H4VdiK+uhUvmoFkp3adh0VEvVmG9UeMUF3kO5gMGvK351yi5uht+G8Y6 Qn4mGh9p2Xp3teJ7lrtCnrs4DdEl2OlXx9GRcKrLB9ltkK7+THqkrBW73sBwUIHNGSQ33T t1jiSbJMzpBY0x54Agj03p0KNE9PU/CBjhMk4rkAqh17Ocw2+BegO5gj4Is1+nmY/Hr4Ud 4es7cuCAO7MwuMjnKHCkWXetZkXS760OVgVfVVBxFrnofhsZa9oIEDunDHREs2Lgald8I0 SQPER3rKqOKGJcscVf2nyPIosWdeo6M/ItD1XXQJqRWmfNTgaG8R4SrD8rGd7DrdQjUjzR m6bKc0yRBgXKgVwqjX9KAhf8HV14wdHyfrq02KY8hpjbMsVrColr2Vd2Minw X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Sep 2026 06:44:32 -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 v13 05/14] accel/rocket: factor the completion tail out of the IRQ handler Date: Tue, 15 Sep 2026 22:43:19 +1200 Message-ID: <20260915104328.45901-6-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260915104328.45901-1-gahing@gahingwoo.com> References: <20260915104328.45901-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 --- 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 2a0b8af6f..54f9c299d 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 07:56:18 2026 Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 1E91B480953; Tue, 15 Sep 2026 10:44:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469097; cv=none; b=bQLjRGR6+LXabLfKE1OHBIyhdrRwwBiXj00dnXy4QTkBNjiViv7BbSxhsnaiMS1zHPjp8P/uVa8Q5kwPpJ4mBmF0vkvEwjbQ7NvYuOqRjThNq/rL4Zs4QACHLJ8y3MaqPrBpuPZIDzPS72eiGo51Y45Bq2ukWuPQ1wNYKDUzCZ8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469097; c=relaxed/simple; bh=k+gwYS+NobpdAIM3dOhrv68WcBmgsiY15gPhhplWBQ0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=inH1qxDq1wkZ1oLUSlU17lkits5UT8TYeUuhgiZFYZdEy+fLQWHRkANLukv8EyAMGCVhOgyseQ9VNvnyd8bWOttFsrFTF5uOAXm8UzAnvmLGCI4TZJ5zz04hXvquVT0dNrENWI5cyBQjIIsH4Uogm3DyQvN2l7pS+pjjoCcMXYY= 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=i18ug41K; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=OG9hm8Qf; arc=none smtp.client-ip=202.12.124.141 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="i18ug41K"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="OG9hm8Qf" Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailflow.stl.internal (Postfix) with ESMTP id E5EB4130050E; Tue, 15 Sep 2026 06:44:52 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Tue, 15 Sep 2026 06:44: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=1789469092; x= 1789476292; bh=muWc6YiNsdF4ep6300eTVDZM5wKjxIUffmssTrDfe8A=; b=i 18ug41KGqS1mve1Vz/btkKAXgbD+CDR+oBjrKoWulOHa5zTCigod16FSlxwriloI Tf8z1dX3LNmM8NM73BNybwxAdqQmZbJkmCJbBcdNsCCl1+YL0P0xkUD4Ao86qRPz GHd7vbzBnIplUhjrcQYnF9RRKHFaFOlLJx2IUkoHUNSmcm7mI2eZ7YzfkkT3Cnvk mnuIpTMcMzOAkY3DrBtTiil5cxb9jICw+Xmfe8h4k5viYuVBqjIEYj9ODcnYn+fj +rgJZX9J49f6utcIZ6W6oQq0C/0gwkhathb/49ZCd78mpASBNCpuGKYcRzxEzONT tnW05xeKuiMRrKyA4u9xg== 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=1789469092; x=1789476292; bh=m uWc6YiNsdF4ep6300eTVDZM5wKjxIUffmssTrDfe8A=; b=OG9hm8QfDR3O4ywsF SoTIGx49jIv0dGB34kTsYmsvxedPchY5c/xpNtqOv2yLSt+uRg+BiJItHH3O31Mp fVctZhjI7ux7rzfMonMctlPqtjHfAo+RRpmAswvkbe3/nXIm8mzACVRutJANiZLK 0uqnoGDez1bMx5A7USaiCQrMNPxSEZFSoxEczUClRVz43JScovzzWcgj86PgQL4G LsayBQ69fu/dm8UXt8IKjh8L9YfUM4ZIn8s46oHWbsiguzKDbQT33CJp1Pylnugm tLQi4RTrB0ZG2rC7rQy9Bhz25ud7ECTDv/qW/F/Y4cjpgRL/MdQTobALhsi7jAfN FxlKA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGG3t2Pe1SQ59PtZsJ9lIVvEWiYOOj+0OhEqMiVdyr6iU+SncWxYSaExRHbc/bY+w IDwvw0pEZBeElcDo44rRPSGzxThkv1vu71HD6PI/8P1vTeNPkT4iulfMaXjiRLKNHYVVk9 aein6He4mNcKEJbzo1aFhlbM9FynxX90WqJkFhFHJIZ7YlgFb/2LYweskGuo8VrfwFLhzV F59VjdycwptChPkod4n6zXjLHXvqFYxkDDn9Zw2hI6vbJGi0gmeW/SgOGrXXTiKDCS0hvE ehCMQh2BKjfCh5AtTH1KLgsisCAf/WKXuD8QWLXjFSAT8ca6C5CzvDf5T/iHoC7Tc1KVQo sOxOGvOVWjCykUXoIdp6y5nsZfzvutkmiRrm57Mw5ZmvoCiYh3klByggSOgGCN8FFV24tF Aw6AFmchmDbxVIe7232M8j24MOH2peydO0eWOKLXHfqQI6yGlE/k2QkfRuGeYsuvEe2NVB pjpp1n0zR55Yp7EgSoCYhf/eyouV0iUyE3rrGnKDe7kKBMF067cfjPYOU6naUL1gwv3EHF 2sXvD4Is81JUPJBnTTiBTtR3K3n/G+RwpF+Xfl6sfG/Ojeg8r+VqJnc+k/s3klBzukoZWj c3mLcJxpgg2ECtT0wRsNBr8MGE5IHgJHDGjhjM2eMoPGjQNsdipsaUy3HOfQ X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Sep 2026 06:44: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 , Krzysztof Kozlowski Subject: [PATCH v13 06/14] dt-bindings: npu: rockchip: add rockchip,rk3576-rknn-core Date: Tue, 15 Sep 2026 22:43:20 +1200 Message-ID: <20260915104328.45901-7-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260915104328.45901-1-gahing@gahingwoo.com> References: <20260915104328.45901-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 --- .../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 07:56:18 2026 Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 1601B489FAE; Tue, 15 Sep 2026 10:45:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469109; cv=none; b=Xw5D6zun3P8kauXjkjCAQUUgx+RNDlxpLYBcBym2X5GNASNaX5qh8/9wboFCAWfxG5dZHDAGKjreYmnb5wbu14QONHDlUpgWLctErA9zQb9rlWhtsm+HJ1PRfbQRQzpvhiBMEkQSO2g45TK9lcuboUB3+ZyfuhQYe/IJ5xTX8JI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469109; c=relaxed/simple; bh=dNAZ2fcLPxuDRucYqOpUmntaART7AfrXkvG+7ZnZ/ck=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IIEBcoIfHPPGO6LfHd5mIIjMyes+o0HeI9UjdD5T7cpc56fgIwrQwEPlg3YNnjD30QMMdMTapXiP2dkisLtEX/tGggFV75Bz+RQZSlAsfyus22+duwp9fC77o4dA+gv6/mDFFIoeNwt1bYheXka1k4IknpoJwu8gmY0rQRlMDZs= 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=GIBP/MYX; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=FbWUE2rp; arc=none smtp.client-ip=202.12.124.141 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="GIBP/MYX"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="FbWUE2rp" Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailflow.stl.internal (Postfix) with ESMTP id 85FE1130050A; Tue, 15 Sep 2026 06:45:04 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Tue, 15 Sep 2026 06:45:05 -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=1789469104; x= 1789476304; bh=2mKKiQO9zpo513ebYoXsjxDsShdmIQsmiSfHdP5Kuwk=; b=G IBP/MYX2SPAyIVGTVTp1HDSvQ8xU6yvFmpfHRptn9ciZ1ZIcIf/zEjXvQCV4g9a2 aGhHRYKXvZNHvYT0ytP/dstu/qOBjgMopZRRTX4+ZZbQRa7SNvrvO647ip9Wn4MI F3NVZNmRNTq3oiQbi4qH1ugT1Bc76t2ffFoRwIqsm1L1s1x1HGL14zgZEycvbHbH HwZRFhQU86xWkrpd9aTOcfpPhefkyyGNqRyt7oYlYUIEX95MKYlrxxR07KVStqBJ 1ZXxIIVa+1SoKEqI9vNkkSHhprrTy2cWja/jVt4I1ERAHehkI2NLbL5A/EN+nUM6 E+LljCIS0dABwzq64iR8A== 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=1789469104; x=1789476304; bh=2 mKKiQO9zpo513ebYoXsjxDsShdmIQsmiSfHdP5Kuwk=; b=FbWUE2rpAw+uBF3ql JmnlVUpSKLRb5OD7gCRvUOk3Tzk7kB+yBLC+Hrahp9VvID0R0nDvuNr7Rq1Xg4j4 waiyUclgqXpMI0ZeaW16Vh6R3juLy4FzG/EaEBIkXvFuAGRrTFBHw74Ji2DGSf6z qt5d7Y2WD+fo3vBCru7Bvtf5JlRFZzIQkGx9TwJyCeL+CAOMoJXHn5C9ai5KoBDU 4RNZ0AhB21IuYmFD2TUQh3eoGNnGRuyQDNGEPvPFQTvDHUcnhk3XwfOgDvCy3b6N NdK0a1EmSQCnjFeZzkwCJHv+Zz+zWo+Iq81cmY/FHNFtSlxEk9QrD19WmhH2Z+vD hDWnQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGG3t2Pe1SQ59PtZsJ9lIVvEWiYOOj+0OhEqMiVdyr6iU+SncWxYSaExRHbc/bY+w IDwvw0pEZBeElcDo44rRPSGzxThkv1vu71HD6PI/8P1vTeNPkT4iulfMaXjiRLKNHYVVk9 aein6He4mNcKEJbzo1aFhlbM9FynxX90WqJkFhFHJIZ7YlgFb/2LYweskGuo8VrfwFLhzV F59VjdycwptChPkod4n6zXjLHXvqFYxkDDn9Zw2hI6vbJGi0gmeW/SgOGrXXTiKDCS0hvE ehCMQh2BKjfCh5AtTH1KLgsisCAf/WKXuD8QWLXjFSAT8ca6C5CzvDf5T/iHoC7Tc1KVI0 eTfwMEni30Di4tPPH+ll4gBlN2kn+5CKS9nCZL5vXTX5k+ArAkvbqPSyjZkFlnwVq5zeBi 48MEQtxBaV9I0zD+bwKwH3Nn59Vbrg5U8zbkVSVHUswZn8n3/VUtR4JKLF7wI8ct/lBJwG tlovkrqUmw2wwirnhf9V5mzS8F+WTIxjsJqgmuBZX4lRfBcLvx8UJqXtryGvBIQvEaY3JQ sIbJkSmXGuQ1gkvecfsyyRzTz1PTUQ6DbbFrDvEU8yzBs6YZ37RxwSZP1LBObpJfU1EXav ByahpLTk5joQF8EactHogL9qvz96BuNphLXuyPWtEytq+cDTy9I2VbId+/UQ X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Sep 2026 06:44:56 -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 v13 07/14] dt-bindings: power: rockchip: allow resets in a power domain node Date: Tue, 15 Sep 2026 22:43:21 +1200 Message-ID: <20260915104328.45901-8-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260915104328.45901-1-gahing@gahingwoo.com> References: <20260915104328.45901-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 Reviewed-by: Heiko Stuebner --- .../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 07:56:18 2026 Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 A3A5F48380C; Tue, 15 Sep 2026 10:45:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469119; cv=none; b=m3UJyNeZHq23G/NJqiLLS+XqOCmmU5YNnB/7zTfsG/UYtQJb2NcjFuJHm84Irnizz2dpP44tbb+6rIs4Zfzrjd38bDkx2xOOv/dA4y5665zjvXlrEfzk+sesae8nHa2cdGk0QwtX5ZaG2rRu8scXHqt87A1COZ0ZKA/5t952tqU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469119; c=relaxed/simple; bh=t8745wRWNkKuyuDHBQoZFLJWeOid9g1cW7YEvJI2P74=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=T/fEtzOWXlySHZTygFm3hrLNU5OTSoYP2wzm5qiDDiWSzD4UPi37TcHUcmLZEtIiEjf32CV0GjH8c2RZAa5qXtmusZVFL1cTZgd9xAuXSMI5CxKz2Vaj9vmCQVc4j833TQiCTCy8TLVTUBBeHf3/gEQbwBu2vsE71E3dQgPnAlI= 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=ZNBdsXjO; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=jr5jwo89; arc=none smtp.client-ip=202.12.124.141 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="ZNBdsXjO"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="jr5jwo89" Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailflow.stl.internal (Postfix) with ESMTP id 3CAB5130050E; Tue, 15 Sep 2026 06:45:16 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Tue, 15 Sep 2026 06:45:17 -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=1789469116; x= 1789476316; bh=EM0swreY1zyIAIB6E9vTAuQx73Txv82P4kLUWclFi0w=; b=Z NBdsXjOTfxQLqShF/u10fmxMjcWSCmihmXU0lorl4p4dzoTmvac/Bn9h7hCApnBZ RwV+1DI1PsdGqaNDKPzQIGhVzAuV9eY++JLdKq1h4beIQfnPuhaFlyMjGcTSZB2Q PWBhczMiu/HMSibgKuALKDAngekjHeiuXaokSrcVAtMweRvVnyytxbeP1SjVxN1K Pb+AcTDEgiLiAnLNmmz70nQTjh8Scz+iDk/UD62WHb4+AHY3it0G001eDOmZwab4 pTdFyhK5So1fyauJ643TpBKN35nVNZUwkuxUqlBtd9fgmHIahMsfvlJ2ewWfGFV2 Oy3zsYLsm78kAVirwgZKw== 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=1789469116; x=1789476316; bh=E M0swreY1zyIAIB6E9vTAuQx73Txv82P4kLUWclFi0w=; b=jr5jwo89juUECPKIA fxvcps5oWmrfFeBY8k72oXGjlMUz5p93xC+Yj7YH0m3UOBIAHtaRAio2dmYOcIPA /tTsUHCfT4wsQEEscB9J6aDQEEbk2sWN/TpOGqiYBt7gn4gjrWK8Tq63w1zwwwf4 ak7wAA73Vab6jufB3Ic2E0hKKvktdaeJAH3/7oxi5yu8iVBZ2sRVNpHoRojSaRi1 yuJHCbGPTqcnurJh5m9pykGrg4MZzTLSwS807yxDi6nYN69sLoQQ9wj5+ZPVPiia uff4jZxkIEe3tHCtZDQbz1dEujSayXj/DKXCcRvV3V31eEFVfYqWTlnBKq+GxBtj B8zDQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGG3t2Pe1SQ59PtZsJ9lIVvEWiYOOj+0OhEqMiVdyr6iU+SncWxYSaExRHbc/bY+w IDwvw0pEZBeElcDo44rRPSGzxThkv1vu71HD6PI/8P1vTeNPkT4iulfMaXjiRLKNHYVVk9 aein6He4mNcKEJbzo1aFhlbM9FynxX90WqJkFhFHJIZ7YlgFb/2LYweskGuo8VrfwFLhzV F59VjdycwptChPkod4n6zXjLHXvqFYxkDDn9Zw2hI6vbJGi0gmeW/SgOGrXXTiKDCS0hvE ehCMQh2BKjfCh5AtTH1KLgsisCAf/WKXuD8QWLXjFSAT8ca6C5CzvDf5T/iHoC7Tc1KVVA S1IdwXS2VGoXxxGqKXkQb8xscbE8Q6Y0JvzsYbHxu5MjsVUxQa/dDIMyDcJziRJiQ6l2cf 72No3qjFknmHNlLSW83hFj9f4IciEOPkPLdJas09hDZTKVfOKaZDQUVTPkvEtapRelno3U HFE1oYXsx8Nc1SiEmBr96L+YvqaeOSrHj90aFz3WFUnKTYdHeNgB2yRUGq+Cm2FgFqrwik bg+ECg0XXlLvP8y1/rHZ9VE3hepf3VzZXR4kvhca2Am/rzI/i0ggqNbGJy7C/xJ9M6R/SU K0c7boogVZUK5B6TF5ngxKGI3TfwKXoPNxbTIbzmWhIfIHWw6bM7W6Bq+tgQ X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Sep 2026 06:45:07 -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 v13 08/14] dt-bindings: iommu: rockchip: describe the RK3576 NPU MMU Date: Tue, 15 Sep 2026 22:43:22 +1200 Message-ID: <20260915104328.45901-9-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260915104328.45901-1-gahing@gahingwoo.com> References: <20260915104328.45901-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 --- .../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 07:56:18 2026 Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 B7CDC757EA; Tue, 15 Sep 2026 10:45:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469131; cv=none; b=ol+k5iOgqxognQFY7Ey8I0qaI/lmwhHNYo+KPFY9E+7O2LEemfTcbDFq62xn63j/XqKLRo6EXM7H6VGJRwEBtC0Z5J59fv3NbF7Sr+RZZDnfI4fMuM0IZCU0i4glaQzFi19LDaqf5dhWxXXBVMzaIxunb+MHpWrgKCNOp583WzE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469131; c=relaxed/simple; bh=9JlB1wAfk8eiNm0B+CSchjx4/2s+XxWZWZHlOOyUWuE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tukCZI2qrAKbpImygIvv6qlRHbJ5Zx2Scsj5LKKgG/d/WO8piaGoWyM1fal+12hvhTrivadPvgTv25OFzIlgojkGh6/oo8lShPYm2Z/Jcb4aQhpBjGbnPFy6G5PYlEe/Vkax0Pv/s0VYUvL/md4E4pO/CqXbU5yVKDeB3mmb7Lo= 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=mTn3J3Mk; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=E0X8oEK1; arc=none smtp.client-ip=202.12.124.141 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="mTn3J3Mk"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="E0X8oEK1" Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailflow.stl.internal (Postfix) with ESMTP id 8803B1300517; Tue, 15 Sep 2026 06:45:28 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Tue, 15 Sep 2026 06:45: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=1789469128; x= 1789476328; bh=AfLTjFKcw6FIMbVcNJi5khAPRHJ+oln3BDqlR9X/rnM=; b=m Tn3J3Mkjl49KxlXL2Plxc921MirCSA82PKh4dw6sgnzymKpjLTeJsYvxdjszRISx PefIqs8K+nbrO/Vk6eA/Xo+RqHFQsCnGwJt0ym+AtzCDqBiy/aHlAbURhK90+D30 fU2LvnhXs/YxnInjc8qNRikpqeZJKzh6mETWsEvJgTW0h/Zpv4dEDHA2CeliUTLq aKCNwaLq7kk87Xf5zsXNoaoeosEumlM8PZRJBaDOhkCmq0Y5IdZ/bzSoj92xbdrt D1wxi0D0gISN36NnsIOyPuFOYLBDoUErz8tH4ql7BFmdyZYJTd/j8g1PiAmgBWI6 PABiUwXIy7CDJ3zX9RYvg== 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=1789469128; x=1789476328; bh=A fLTjFKcw6FIMbVcNJi5khAPRHJ+oln3BDqlR9X/rnM=; b=E0X8oEK1da214JzgY Uo/Ee+chaOhL6V5d2AmdE26w2u1QJqmJnQdZmRKhs4GPpQS73ffD78TTqWtFIgrU EjJ37ynNjhZbkTXsoDwrdIaCIiePYHpxzgrJ63t8DEDI2hFZeFtuswSvS6YL64vW kKkvlq6Rv4iiiBT01/OBawJJU12wK8RhuiN8cjxOJjE2lZPonTOH79U2wGiZpfjk auexxFxvLYkaVoHotSFeR7RkDwUikzvOSs76f0vD714Wke19TCgm2lXVtm3Xdew/ 4re68Z9i4Z7iSS+j77bO7uT+aOz3n164x6NZZt5Qkd5Lnd9shjQTxElTNNBYO0Bj RwOlw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEvgn30TE/Bhy7j+lDgP7gXmnxf1yEA4+9JDGkkLDKOX+PjWS6C4wfYB6bRewT1h4 g+oMcdzBaiIBs5c+Pz0dQXZKfUwZnHiQVlJVJDqMWGJD2749OJ0l99nR2edJCf/ZcGPYLu 30RXGTuoiFK6E8ovSjrRraOKQw1/yZ9qQ/P4z8BMLsmS14llkOiSgUnfVjorc51oae8LTo anVnmEPQ5HlX5K1+WHVdnXvbEVz7yNCh4wXVnb5mrixp2KjAAisQetPkg2Ry4FRfbKhSiZ 90+dZVL2qmx3uYvp96MNB3kt9H9Tf++stO3hlho9KW9Zr3E3C1i+M3opDz8IhDGp0X2el+ CMH4AvZTd9APlTfZ8R6sNS+p7snSOylauz7eHbO1uQoZYnBXzoWJrt50hTUdgNtKkGViSD NfOnEFuO38iOR6NzHOpJ7V2iEw3NS5dvUSLr0uhkkU/00i6fLVkhWJTrLqmYWsw2XAVMgy aKKkB62T9ZUgTzTukaon1yk272JexLptgIUGL341lBC+o1/nMA6WSpR5Uf+z36Vg113NDM kjLaO/pzVRypXy2BLgXE/3ERfOyGpw+sw56rcuHiv/qae4aAzKIWLJArPjdM8sZZfOgKRP iznA5uc1t7RuKo9dkSss9xOnjxYmlgBfRYnwczrTL1l5mCNqAS2S1fV92Hyw X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Sep 2026 06:45:19 -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 v13 09/14] pmdomain: rockchip: add optional per-domain power-on settle delay Date: Tue, 15 Sep 2026 22:43:23 +1200 Message-ID: <20260915104328.45901-10-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260915104328.45901-1-gahing@gahingwoo.com> References: <20260915104328.45901-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 for the settle delay it now carries; RK3576 is its only user, so the old spelling is not kept around. The suffix scheme does not survive this cleanly and it is worth saying so rather than leaving it for review. The letters name fields, but R already means two things in this family: DOMAIN_M_O_R takes r_status and r_offset AND a regulator under one R, while DOMAIN_M_R has no repair fields and its R is the regulator. DOMAIN_M_O_R_G's R was the repair pair -- it did not set need_regulator at all -- so the paragraph below, which gives it one, adds a field the name does not mention. Naming it _W_R or _RG would be inventing a convention rather than following one. Say which you would rather have. 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. Only rock-4d enables an NPU core, and it is the one that declares the supply, so on the other twelve ->power_on never runs and the regulator is never looked up at all. 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. This is not new behaviour in this driver. RK3588_PD_NPU has carried need_regulator since it was added and its req_mask is 0 exactly as this one's is, so rockchip_pd_power(pd, false) has been running at probe on every rk3588 board, with rockchip_pmu_set_idle_request() returning immediately because there is no request to make. Of the forty-nine in-tree rk3588 board files, twenty-one enable an NPU core and declare the supply, twenty-six do not enable one at all so ->power_on never runs for them, and two enable it with no supply: quartzpro64 and youyeetoo-yy3588 take the dummy regulator and the one line dev_warn from the regulator core today. The idle handshake lives in the child domains and on both SoCs they keep it: NPUTOP, NPU0 and NPU1 carry req and idle masks of their own. If that is too much for one patch, say so and it splits. Signed-off-by: Jiaxing Hu Reviewed-by: Abel Vesa --- 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 07:56:18 2026 Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 23FC3414A11; Tue, 15 Sep 2026 10:45:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469143; cv=none; b=RTI59obT0oHm+8s9G+/vizYkT6ddgQfTPx8uGajtS5MRB66duUmH/075SFdBnRVrKpBbmiOYqRp9td8v2MVFN9O1+BnGH3Wg+Tt/9+ek5rdqhXd+pSNypg0y71ZPiz9MnVLwSDE7BNQEHb2tliwpZoYbY8xw+R6rktsJkjtTCME= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469143; c=relaxed/simple; bh=XkKS64ilmfTZbzrK5Po4eJtI/KFUDUj/aHDPQvHk5fg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IKdCsrV7aovmUPddAN9mX+fmTF8JBYHLIvsKLRStT1VJXqYa0RC0G4qRz7SuP3v9QRm6/H0eIzDSeTM/mQrdbe6HQbENR0RsRjPRGk78GfBSBX5OXF9wTN2j0o5LCdgUjvV9Uca1lAkWqOzji+paepPW7euoCecGOS75N873oaA= 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=ocrzfgVq; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=E2RaB+eE; arc=none smtp.client-ip=202.12.124.141 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="ocrzfgVq"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="E2RaB+eE" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailflow.stl.internal (Postfix) with ESMTP id DD2ED130050E; Tue, 15 Sep 2026 06:45:39 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Tue, 15 Sep 2026 06:45:40 -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=1789469139; x= 1789476339; bh=e9LoMMVEroZGsuUE/y7jMO1McFxznbr3sDdiQfN22eo=; b=o crzfgVqIX9nzqSsKB4VVaOb2yCi3rp6vwWP/QMVgFgQhjQrfSP0wq30iq2DZ2Sqk dFb4l5Uqy+EBg8ADSYtZCe8Uzg9/xFdRfwduF7uZNeQXatEOsWdxiy0vyLqCTwEe CBwV2F6xxKunC1SGVmEZKP21vu/3AGo3OEACuF+KhDJWa56jTyJyw2weFZAGD/Bg tY3SvaMRQjg0QNCvFHuRDQqPD0vkXcX74ATD7MWMNzK6N6L2B0/aXeLXcAG918Mg b/RwThctvpvq2a3SfkuMqAC6ZBqX7Lj3GaEKRIR+qQqlj4opYpdYKsi+00snA9rL fWapoJHgI5ehw5MxdWkNw== 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=1789469139; x=1789476339; bh=e 9LoMMVEroZGsuUE/y7jMO1McFxznbr3sDdiQfN22eo=; b=E2RaB+eE+296Vo8hZ c+PPBM71bH5Ju2czyFZHQZ4aPOSgwE1RPbwfgysKdSKmSWgoD6P5UmOFJJr/maJQ 5d0WFgnyE90oUb9u801pkyrQ6oH0UIA6hNYEtReWvLeVleD6SROAlVqmodtjltbq oFbDsXFPQ0CJgZZEPw4HuXIaPGz6Y5+gd4MLIKRM6VCBVDqUEhG3PCJiRf9ZlBwK Lg6UHzcLPpE1Zje/1yGpMTt2VrAlZjF3tcfqzCXmgzt8SjFzUTAQ/09Oh39iFxAH 8U1nW3wimXTEhw8tSfGK13sj3A6ihWmal+GfoKUKJfauVgKa05qXWPzQpvqWTXMs Lpaww== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEJ7lsNMc5MXcmK0yAby6zAyahnp/o+BLQRTsAUuD6zUFYE1mfayW4ARlNvxFxbHL RViSXklp2Mvqoh7nMl9WcpZxcA5zX09aM17WbnSDD1mVdJoa+dDoRGgFZ+ZZgzctt5mn// Fi1Mt6BzxdDiSZyXddMkKr5ZuKnhcJKMT/Ww41HfwQaAux+0BU99FP+g6srkBweq+0Pyu4 FpApM0KD75gdC3rQ4X6qbPGbs1ABgnV9cF7lajdZo5Ix2shyw0qolijI7Y4mlyGIz0nhlc sJGrQ0glbm4LA0H4VdiK+uhUvmoFkp3adh0VEvVmG9UeMUF3kO5gMGvK351yi5uht+G8ld OEGeDapE9d4TJjJj8/jfXCLJSvp4JuqEodsMQbji7yujrCR0Ylfh6QlYm17IhhMp4x9e89 GDmb9ncnSDvBZJUsyFOavh2XFTtkEAXGEUUjK2K1aVvkmT8CPEvCGeCZqTgiwoJVZq9xVR FIlolqXE6zSJhIEnGLpgLfAUMaFlZCx+yuDWQkCRN8BX0nbSq7QgQ9JRQP31SSR8OP5OZ9 vKbD5QQh5WaHA7ot0CBeaHimgO26UwSqTk0fw2cEe8Ez/3+YnRE5TPtaubS3frMRDbnRCi 2+OcKxI1Z8YeZmXpLhiDu8ANWPqr6v+2sLJbhHz1JfDtzlc6k8P+emlq3pBg X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Sep 2026 06:45: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 v13 10/14] pmdomain: rockchip: cycle optional power-domain resets on power-on Date: Tue, 15 Sep 2026 22:43:24 +1200 Message-ID: <20260915104328.45901-11-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260915104328.45901-1-gahing@gahingwoo.com> References: <20260915104328.45901-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 --- 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 07:56:18 2026 Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 D8A1347F3A0; Tue, 15 Sep 2026 10:45:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469153; cv=none; b=h0P9E7sx9+ak88bprmX2RF+Uo5/1FySQlyKJBbQvcVURB6/WJvhgFMwrJruGGShU1I1R2YGQtKL7FkD45Og8zOySGp6cE2j+bP2VlqZ9FGjHa154cCJvi/65OV9owoM0m1WXlromUxhe1ZlNNY3dXOjpFYAKVd8abPKHBsKdYow= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469153; c=relaxed/simple; bh=IE3xWBXDo6VtwItgviJPad/JRbM0VHzIDuwI7KgwfBc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fz/Qee2Ua9RB1xWCTSPNT/jeTAPZxjO+2+xq85T4DFHPgd/zpMrr7SVeJYG8NpOTvC6csPzAlHmdkiwWLY3U7gqoFkkkrsEspMDCbYA90d9xyGVFT3BZlKXVMyuCfcu/REWAjLa9i84Cv1KPFV+Tl9EloEHg/asXBRzY8IaJe94= 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=aOe9tJc/; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=ZEtvQCXW; arc=none smtp.client-ip=202.12.124.141 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="aOe9tJc/"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="ZEtvQCXW" Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailflow.stl.internal (Postfix) with ESMTP id A228E130050E; Tue, 15 Sep 2026 06:45:50 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Tue, 15 Sep 2026 06:45: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=1789469150; x= 1789476350; bh=eIbu+FRnuIaeFrU8yxIF1UYO5RWNoHkH+v38kjzzSXI=; b=a Oe9tJc/KbSPm6LnSS0W12ygsu/gOyiXfDmTbaLCRRPdRXTmbsCm6PD0/UPF+CnLU A21GDL+L5wchSKXPquENUGYGvK+qt4wb6pOr/f+W3R1rJuuAg1Ay8JvvRlAinSRb DfkluYUaG3AF3zfDLFeVcsQ0ozCom/e4YYbcUowRQmpRXYuini9pSLDqsvKQiSJP uXa4xL6vudnALo9WXSldUkMZn78ALH0U+W8J30uuy6SfONq0OgdWYBn7CliDNEBM dTqro4+Zas5EsiCAviCUD3lK+fFu/GRribdi3bOOOyNSWuxDQeyhUEKC9+fd7Mip kEazL0lM9SoE82n97YYnA== 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=1789469150; x=1789476350; bh=e Ibu+FRnuIaeFrU8yxIF1UYO5RWNoHkH+v38kjzzSXI=; b=ZEtvQCXWbG1zhneiL F6wLta87fZXvyI5HZedfG+4Ml9SoBwWV3u455yXpjoLv+GaN1IdvHXDcmA6g4OIk s1TG3D2elRJ7IzPxugBTNHYQL15/naka1eg87nxpSIrxj+oL6Pp6q3rX5s6rPVNX jXRk4qHgvVg3c1Nu0mEDIg1URo+TS9G0LN5L4ewrsmO/amS0sawkEupT/B//I4zk tA5jCuyWoEiFm3tqL9DVLC7min53CxFUqqeFq869PhuLELlrlm5HuWcbm5Pt9Ya4 QR6O5fc8rLV/jn7lxz1igAuo56dVeWjrDGF0/6UPBzNVKfBT4YB0ouDPE9dda3RY M+hZQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEvgn30TE/Bhy7j+lDgP7gXmnxf1yEA4+9JDGkkLDKOX+PjWS6C4wfYB6bRewT1h4 g+oMcdzBaiIBs5c+Pz0dQXZKfUwZnHiQVlJVJDqMWGJD2749OJ0l99nR2edJCf/ZcGPYLu 30RXGTuoiFK6E8ovSjrRraOKQw1/yZ9qQ/P4z8BMLsmS14llkOiSgUnfVjorc51oae8LTo anVnmEPQ5HlX5K1+WHVdnXvbEVz7yNCh4wXVnb5mrixp2KjAAisQetPkg2Ry4FRfbKhSiZ 90+dZVL2qmx3uYvp96MNB3kt9H9Tf++stO3hlho9KW9Zr3E3C1i+M3opDz8IhDGp0X2eHi fM6eIWurbrqHYUdEAqZyIBGPJyjfsgnsEWYhWmUYhRbgy4VD0rHKaB7ZnAGRG+/MsvY6NO S+r9ZhbQ1otdM7Ol1ucyRq4VXv0s5TUXXHcQwQsI5mZ02nENOvZVUGsCpN9JpkbB4YYUcz RTAAoj143E677ktRlQg9bhB6TcCDFblU5e7CZoYoHac1JjLDQ11yw3XTAT0kil5BJXIK7W c8LX/GvSNYmfL2HuNK7ywErbjPKrUj9ERcRxrNU0c42kY7+uWK146/uWIvgekCF19wUmfW nJUKhxHkiGVHZ+WfCvBh7vbopaHA74c0qMQ2tn5xpMhJM8LY5k1jKjxd1MdQ X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Sep 2026 06:45:42 -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 v13 11/14] accel/rocket: select the per-core clock and reset counts from match data Date: Tue, 15 Sep 2026 22:43:25 +1200 Message-ID: <20260915104328.45901-12-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260915104328.45901-1-gahing@gahingwoo.com> References: <20260915104328.45901-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 --- 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 07:56:18 2026 Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 C6E69488232; Tue, 15 Sep 2026 10:46:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469166; cv=none; b=gZT0wwphSasLXZS47R473gCkBRfXekLJD6jaRBEnAG7SjwifBbqM2Jdk2i//NQhwID3a+PAd9H1dopy3WG6z87n0n5Hz8/kk+r+QFaEY9bfeKa1flWPcL1rfJHQ92eM+MA1Iwm97knU3k32/50R8rCZSvBZ/4e+jEHE+0zWnmuM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469166; c=relaxed/simple; bh=ZUgjix6KuhmcgRLEHDMNrkOpuWTJXcIFB15xJ/dQR5c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uDmYXsa0K1zAFezJ/5lM9YTdY4URnXbhf321Lb1Ej4Q/VVKbusUn/lrCon8ItaVt/nZ1q1/5eg82uCag8WStskgJqyn1gwKzpt2qQgGt6qc1g3S9+C33vzXI8YqCSR1vECy6qFWvEBYAzBE64LsKFPb44vImX8DApZwmRRx5pC8= 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=FK7zKJSA; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=F1GfD4dG; arc=none smtp.client-ip=202.12.124.141 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="FK7zKJSA"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="F1GfD4dG" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailflow.stl.internal (Postfix) with ESMTP id 49AB3130050E; Tue, 15 Sep 2026 06:46:02 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Tue, 15 Sep 2026 06:46:03 -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=1789469162; x= 1789476362; bh=Xf0AIYtJ/K+4XytoHu51Tg+JXdKoXOAcW1Dw8eFawmY=; b=F K7zKJSAiRWZGOrxhRnrUIigJhtKny+A8RNuj1pCuOiM4f+6Mqt2rvHIq7MeHk6TE KRY0FQb8ZPbpHahFh28Mx1QEbQcaRztFy7KFcfL6F+XXSVpmgXuLNAbWH73xplQn p+0R9PP7ukG5Pn3LAQ8NNsyhy86RPn2+gw3q5MrtBaFP2k77aj0D/CVQmCXGqBNZ EIa2qlYvib9KVEdh9LLYkKCL2QyiSmBBiJDAMovMNgQC51ipSUM60dQ+qrCmg/94 Xq4+HvaW8UIvaEjx3NFZAFL6dASVrx6V7xWnysEoiIKpo4enEGaBjWmQ9Nrpd2rJ 7ZllBxnPHGdZEHYiwuV2g== 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=1789469162; x=1789476362; bh=X f0AIYtJ/K+4XytoHu51Tg+JXdKoXOAcW1Dw8eFawmY=; b=F1GfD4dG8LW1btkcf IKqwPAzPDvbs9vn9APljTXY3kwIMBsdbnIh0GvhhhfsbIZtEyhBw2Xz4sN210r8x s68Au3RKrkEEYj4ma+cdhlL0r46Iy78iVfrqap60PRQXf3pv3E9KVuZ1Kdsc9XZi JnCCQ+ky8tKv1Y413kZDHmfcKHEDftm0WYeHV74AqKMwUaAfnQg+8p7jAED0wH58 421BJcG4PMjJUY9XOO7yC8Pm33x6sf7XFXtR3smWqMyA9Lga9LM2Rt0kvLDMBWNW T2cs1S6CBoYgvDyv+JDffT6BIZnwSW8+OdudJ6s8g3g9hVhFt6DTu+LuRRO3Nij1 H+LbA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFc/f+iTQ6Xfq8OwsHzZalkNFS5P1a6mZ7+SKzJ+aIlWQZ9LIu8SZaXig2kry8E4l fqsKlj3MQKO04+Ry1s2dzksMu8//PfpznkMcS7S0FTNR02UB+H90E0R50vg1i9QArKyNlm gX8Ab8omn0B6sAhsguvaDuBppxzYAQwY06yjONgTFYdDGGfRGS/a9g4hE7Ar4SFi/MRz61 2uJP5RE1b7aIo73DUWiBj4be9ejQ2H5+el8KS4AzHHeG1WdfgJuy1tS41N487ll4GlcDe5 ou0gTnVo40xv1I79htHXpLrcsmhzpMHZEV2IyCxqzqtgB8RdVggG44bhnSZOFuyLoMpNWW dP7hbzFa4tVYG9RSdC6OS+8nsNt7SsBKsUuikCv1pGIYBr0cotRMh/ZtFxLeFUihTNL8U8 mDPRA4rgIn2aNkqyygtrFXOg1hhCf3gPY37A7R4YxLucVh7qZeMsZH05asCMOVar4kKiZ/ QD6fWwST2GE757bACSNj/nlS1v+Wc/Q1alo4Sm9QtkFqCS34p9Zc5NqaViT16f6MezT23k YVpK7cIQ5xBGf+dL+ucm4BCPRzH00voqKa7nNKvKBVNzSOZT35RbrYbrEDkZFN6PvpLgg/ 0FF7yK+bNauUUWSOMpdZP2RXXE9SG7DU8FB38qVPtovZ5/T1TgMnHGAOl8vQ X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Sep 2026 06:45: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 v13 12/14] accel/rocket: add RK3576 NPU (RKNN) support Date: Tue, 15 Sep 2026 22:43:26 +1200 Message-ID: <20260915104328.45901-13-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260915104328.45901-1-gahing@gahingwoo.com> References: <20260915104328.45901-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 --- 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 54f9c299d..c862f8bc7 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 07:56:18 2026 Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 CD9F9492E35; Tue, 15 Sep 2026 10:46:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469181; cv=none; b=rLKIXBqQ5rA7o5Xr1IssuiJeMpYmZGaSo5Ro49M7CJeGIC8k3AQB4rVCT6yVFQZ/cq5WQBNgodk7/YynJqJroe5IefSqeiPCODDEYamwi3a9gJKxgb0p/XTZ5VmsKa1yFyKxwE15AfjpB03l9AOaivrFEX4M0pQrDUhJF92suZk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469181; c=relaxed/simple; bh=bTZi84lqnDkfZfad7zQtc84YDTWWzuRD19OT0NO3jp0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Z+19eUUaBRDtwg2/9xvTCpDNlDioSIaBQqpY7a9Xkhw5646LZL3dTPMe2tfvUQiO0X+JYJO1xGAOGSmPUcPFyMQKGndNJip5dW5O66qizKkihnxGJ77UY6xqdFfJN6kuPdX3IBzrkEqBAsKDOpYGsgk2k4j/7f0ny3CoKXS4I4w= 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=E2aVIb+d; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=GO9XxQj/; arc=none smtp.client-ip=202.12.124.141 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="E2aVIb+d"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="GO9XxQj/" Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailflow.stl.internal (Postfix) with ESMTP id 68573130050E; Tue, 15 Sep 2026 06:46:14 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Tue, 15 Sep 2026 06:46:15 -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=1789469174; x= 1789476374; bh=6ZH2yhhWclrOGlZcOwgI16yHIaMMZoDMxlrEMqFGo8Y=; b=E 2aVIb+dee4JLFHHK4W56LhBnLykb1jzc6oy3EdSGUkXxqGCf5So/fjIgADrlpvaE LCjfIbwhVxg3+ekNra22jby3DX3rcXAgp+sg8Fu7CmBdFGrrnYv1kouupcOcJjH3 p7bWn+w9mrz4rPlZsAce1Vi6+fT/Tjo44JnpXlIcqB+bNbdaJE6lpvaDKg8AawFQ lgwlzWtr3xYOcPZQTiHEp/n4DckOAIXXF2cGZOUWNEU1M5vO5IOnubyiFPOA9S3O 64dYqluqCILKegXw3apYHIrTsRadFIrAgomGx8xsQ67nCqNBqDI3lVe0vINHvCVZ gFYXXWwRzByaUZCHteaXg== 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=1789469174; x=1789476374; bh=6 ZH2yhhWclrOGlZcOwgI16yHIaMMZoDMxlrEMqFGo8Y=; b=GO9XxQj/khu5BUHFm aJdUcFoSRxN9VIif0Hr9+H2N764CGXXTB/HUyEieFQ9WE6ztopOqewWw08agr4UL qNlH+KTYopTSIcZ4Y90U82RA7fjfx7tsZIFYYi+SlTA4R4k4UfkQItCJECR2X5kx pmLfldHpl7JPwabQGAlFb9c+UYF9ihMvgSrJCMODi0+sEBib3J3QXvho46rLDuY0 yAfOpGsOh9uFFNUxIpX26zR/JoSFZ+HsQYJEJRwu1NM6Buz8RqJrVciZbH0HmkAK n43tO/pODy1UQ1ztyyGVPlE6GIPbSgoIBi738D4+ADFh/Cg4V4l/BjMSaa5MoxNU Ot42Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGC7j62tXMGgajHCaYl9LRDhSVXli2vpHPtOTENmffy8Ld5NQ16KawirlQvrTExft 1qKI73d8VGGBe6ldYvpEYhDk7nGJB2x3hhHvQe7KrdNdaOsKt8QX2IJy8nOwVc7OoBQxdr GjY1+iqmQdvn8Zk7yLBMwDU1Aj/or9TQqkmYa9aHQ5qlx1Ur4fYJSE8D+QtjgctyBzJQ4d KMzItB7ejokhvHcWczLqIjmuYQb4vNsIbJpZUHTUB8BcUIME9ULFzDYFecEiEp06cqAF8J w4TbrI7BG0D0BtAgtD5VP12d9ktSc8KO1eudi2Uy03TledXfu8K25SPKpiCb757wIcntfB TgG6P4mz6NTX8B3cNRCYMlnyFvD8nZhopJva9eJ8EpQvP88Yqys1GRT3pq3Ya6jdL/WWDc y10LXBdlWPdbqKMiWys8KZdrtTmH9esAwM5eHlR/3hiWT2wH33JrEVLwIZyecpSqpgA9As IlqQOxy1AQSqz5Lfd5bI8sZ0wnaa2J3kbCuI+K8WB7iee1MsDefiJaXZ2wRcXsqCq2R/Et Og/tuNNnSKwyb+uiLxHvVdDTpiFBz0H7/rD4rY6rCEzY3O6bTGWHSSMmYRlQhHTgxbMMmZ zuUTyYNJ1wT+O3tn/fvRgmneV4e0Jdzpj8cFbsj910CO4WzxMRbXSPO6Ge8A X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Sep 2026 06:46: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 v13 13/14] arm64: dts: rockchip: add NPU (RKNN) nodes to rk3576 Date: Tue, 15 Sep 2026 22:43:27 +1200 Message-ID: <20260915104328.45901-14-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260915104328.45901-1-gahing@gahingwoo.com> References: <20260915104328.45901-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, which means this comparison is across boots and has to clear the noise of one. Twenty readings of a single arm inside one boot, nothing changed between them, span 2.5%; across boots it can only be worse. So the 4.0 to 4.2% below clears that floor by under a factor of two, and the 26 to 37% clears it by ten. 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 six 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 --- 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 07:56:18 2026 Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 94EE8485CE2; Tue, 15 Sep 2026 10:46:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469192; cv=none; b=fxk5nI9JpWBlMccbP6k1pWvYij7REuYk7a0DttW4H1h3Ge6U1oN9ZcZ6Fn04Tb4+LEv9x/wF+I/Pq0Jv4EsCu53LZoJXuH6564R/IDXbZNKiS6OpUYpC5jC67+SW+P81Xj1e1+2wkfxyCTx8cjqqvDQgGgUtBhuxPJ13HAWas18= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789469192; c=relaxed/simple; bh=D4ppPQapyLhd/s9SIDIm3/DEZoesU7DqcPjoruLNSyw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Gf2S5FJbwNyk5yR2CjR7SIYEdsR6/K00rKbcMvmp8BCA8Oc5THriuHalTJhBQNOT8ISwEh/x3ltQ4g1f9J/PD51kg5BlYJjCHxukUH6OLZI7z08dsDM5xsJpx7Y8GHcsJcpq9ejbRpm+noouR4ST6Y4/psgUJLidIrgLisgZYP4= 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=o5KcKxv/; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=a+jRTOGW; arc=none smtp.client-ip=202.12.124.141 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="o5KcKxv/"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="a+jRTOGW" Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailflow.stl.internal (Postfix) with ESMTP id E4CEA130050E; Tue, 15 Sep 2026 06:46:25 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Tue, 15 Sep 2026 06:46: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=1789469185; x= 1789476385; bh=0k2WO5fN2pPgdnD7jJ6cdxK1ff8uhQPVB9+e5XeZDfk=; b=o 5KcKxv/SlV2aYjj0KfjiwqAjYLU/J+yZ4Wg+42qPde9qFeZvxLQ2rwR3iKzjj4bc W4Z9gQ02OpW9Ea6eEGxBrBB1lP8Q2/HoBxkn7NYRajwK0KjZC911AfQv8TJsa0zL 3htZhYruMmYsYuQjHFV9chxWRcRR1A58CTs+blKNLNjCIUndc68BWHDqTcdltfOw 0p0rme9iLcfYJsSCpYJ1cwyOcAoAJh2Ti4EWHQ4cvUKYYwvLPNOu/dkbPbWFPQN3 6L2uFEay0F8S2qk3pTBCPJxpztTMUF04R3GUZay6TjndIYeWw5JqkvLdIfcVCaKI 8CzVuB9D9RzMoy6B6hpvA== 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=1789469185; x=1789476385; bh=0 k2WO5fN2pPgdnD7jJ6cdxK1ff8uhQPVB9+e5XeZDfk=; b=a+jRTOGW2gW9D9uRd 58qAB2jFVMu687OEygroRLYvOHTqlqcoevsa09QZw19JfgWWwRSMJOeOIJ1oRN9B s/KCkeXvl1D6vTx+U0yKCdxa34GkeheHmC7XrVlVZfDQANh9Y1pSwuemxg50SEFW 9/K1rczH8Qorot9wneCm501+E3iktZ54ecMmMmHC1afyjOEIR6RYGuHr95vZKbJy BIVmDvj/bLjWG3CMV+tz3LiBXdH096RUoo3q9vM5+2YJgutpMvshrp5qhL+SDb4l iOx7SgPQxzvMI6HwVnl7YG5fL5fyW3qew0qUM9FsFozDe1lZuY/3oO674iVk4deu gFGhg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTERaSqH5KPECAN19InuPeLsiKMx6D5y15UiNi79LQSE+6PwQZueGcEC5S1rOFrK3s AYJQ5gLhphYiIeKw6agxUW6Fop3EpWpekZBzn5CD9c5ViahuaZguxQ6ney6sO43OfzeyFX kYhoR9UDnAzR8pnmcjQlc+x5gLPOpxNVIBYuMwia89SdQ/qFDD3jNxIWu4HvJyRrQkT5fi Bc2tWX66wGyq3ia2uvvLsx+3+MQXh8ILcdhexnLin+iBHzzQwqqqN6rvF+dRwz/tz6mc79 V2Z2N8t1wVU0baTbSz4IGhSDBvU+gOblwoPbiM80kR6dUxb7moWmec21zQauVhFlqpiZq+ vpW0GhBX31bWwlGN0QFZ/wI39d6+Fet+dUwUDz5xKxisTx6SB3mk5UuglUIe5BsqJZck8R TZ5r3ICH6hOBlPs29Do869msBDk3MBAG12RC0wVjVCLn5K+URgWZ8eGYfaxral+2o4ELka S4o2LahSPRTF8U6V+UNvoq5fHZQ21M73f6wKlYeBfP4nd7vfxuuIIjSbTzHtbyUh2Ps5D/ NooK3dyiiu2xLcMiqWy6Sx9UoOaN3HueZgsJbt/7aynudz+zMJYu+7/oTzABlpdKLo2m01 WWr7b0rPSU+KYpcPkJ05VaRdzLeSUFMrH2a1A2a1jzwlUIM1QTcdgtVs1PtQ X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Sep 2026 06:46: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 v13 14/14] arm64: dts: rockchip: enable the NPU on rk3576-rock-4d Date: Tue, 15 Sep 2026 22:43:28 +1200 Message-ID: <20260915104328.45901-15-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260915104328.45901-1-gahing@gahingwoo.com> References: <20260915104328.45901-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 --- .../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