From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from flow-b8-smtp.messagingengine.com (flow-b8-smtp.messagingengine.com [202.12.124.143]) (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 AB9BD40FDAD; Wed, 12 Aug 2026 09:41:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.143 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786527683; cv=none; b=fZjoXbN2Ym2nEbPesrg+GaG4QD/qCwY78TnVh3s+qx2JtVlZrk0dDcvIQGaJvNgGbo4KxbkF1j4PUXeIB/0Ki6Ads/LSdD7+rRAhDQxbr1WOG/jBKPDEUP/HyS8WwaKw2z4pnmls1AsBT3DYgTpvYMvL+JcB7dbx9grUrFCxxsA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786527683; c=relaxed/simple; bh=6QPynWrMzLJ0HW2fmIrfr1z8hcilft2HswPt7Sat954=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=RUtHtCRrSpjNCLmNboYhmKTOuB8Mmmy/kaox5Re3n76oZVrMAe36KHOzpR9MsPeWnJz0fNQUEkgA0HO18YvY5axQZfjbVjpxnVE5129AGTwD4kUh1vmn1k4KEf7d0fXLS3Df/6uQwuA1NuKST+O3Srwyx5X84KGYCqXiG4YCnmo= 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=Do3+aaE4; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=btQRECF2; arc=none smtp.client-ip=202.12.124.143 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="Do3+aaE4"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="btQRECF2" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailflow.stl.internal (Postfix) with ESMTP id 31829130082A; Wed, 12 Aug 2026 05:41:19 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Wed, 12 Aug 2026 05:41:19 -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:message-id:mime-version:reply-to:subject :subject:to:to; s=fm1; t=1786527679; x=1786531279; bh=XTtrf9QqIJ 0aEwhEPUrpZWj0OOWgjuwh9E5x/Ee+vU4=; b=Do3+aaE4i5NUeaY7SfW37Pv25l QUqp2DkEix2OMEKW2ejeNDwBY/EZZJUenQZ9uSZbixupOlZFEntTSb/QgCwgDacH DvRtGzpFbGUAcconqSl45ZnVslcobtb3T2yIbJoFvqL91siSMIHyys2Ik8aeBezx cPSyTv00jaYgSTGCvFJm4FcR0k8+D3jIe7pms7OgT3wSz1chERp709rnNx4cT3VN 3kx6Hzw3lUVdqJTzRwjuWoK/dMPvv02dUf7xsWhHSHsqF80UKw80zbNmZzw3hT/s Is3t2Itf6eSVFFeCjLKJv8O438bKp3P29x4jYr8YW7WuK0aVQiYctqgx0+XA== 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:message-id:mime-version:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1786527679; x=1786531279; bh=XTtrf9QqIJ0aEwhEPUrpZWj0OOWgjuwh9E5 x/Ee+vU4=; b=btQRECF23aTza3IYQHkV0GTKQTlE9dEXDtuTd/kLYeJ/N7cEJDm IiWhKkB3lU2kKH62Qxxd8PYm4pFiZExgW8NFXZ2ty+39XHTMUz8KafzqvX33Mz8l bN5z6UeDkps6q495gzqtxHxZdBGRMrlrBkAh6qRmH4108GXIiGlEln6nZVgdrsrB dbtXdnK3n9mgxVWkKzuGMPw26XnJffPU1NZAdNQP5ToIU9YwXdcu5xgjzllOEwZo f8rYVGKQVPAgHql625a8leMv6hzYuM92/u9WEOrL1/PLKNeD58iSHTxu9auqL2cT 8JQoyz87j8UF8vYqO3jQhkcMT35PiJFMqbg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGczlsc6lTmWVXF5EdFbdBVrzj/e7Ns03qZEcXkYEtO1ejPPywerw48yQ4lW5hk3J fT+nPF6HwKq4wLnadj9B/7Dxa+JyDDEx+4c7COf2RfNTk8z5C7N//KLe5jziAvw/TtX/Jp OrC/dIaTR/CyYlCFQH75cyZe9sWyJHnxZXS6yI7T6OJVjuheIcXU/eK6bZTz4XhwORckp+ 14uoPBgn1Yp6vTSRddKOl657KK8RRAbUi7J1na8KuT9wzNcxlASvghh7F98Jutl24ebq9g llnAP0pM5Ea0ZgFR9n5XPa2NKSElqXsALbI2HKi6XGVMFztOK0Iz3JFRIByX2nDIiMMtXZ UayMLhX5L+S5al0XL9J/cmf77OnCUAbzlK/sgfcDEOMzs5USN3TTAHwETXv90c4PKmhd3E Zmz/EZ0BjpxB8OvYiYRpneXAP1XbgYOrNEKBJcIp5n8s/2jaS0bqmK1X9Vn9sof/vgYmTk bvyl8cFXFIBWFfgbSL2CbvQsUC+cHXRo+QL67C/1tkaNU1MwgMrG1H86LT0nPU5APvaGh/ KlRbyLA/BLZ9XeMTVX8Jka4laTBy/2rMvzmVvmGiEmGpS/a8BNddhIHgaQa5EQZWWVVCcX CbidpSWly9KWj0mV1YU1or1O0uOzTW9F4XmzyDq/iNxuoMmBJCXvIZyMncMA X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 12 Aug 2026 05:41: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, alchark@flipper.net, chaoyi.chen@rock-chips.com, diederik@cknow-tech.com, 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 v7 00/10] accel/rocket: RK3576 NPU (RKNN) enablement Date: Wed, 12 Aug 2026 21:40:55 +1200 Message-ID: <20260812094106.1391698-1-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Based on Igor Paunovic's "[PATCH v2] accel/rocket: request the core clocks by name", as v6 was: https://lore.kernel.org/linux-rockchip/20260729130743.128876-1-royalnet026@gmail.com/ Tested on a Radxa ROCK 4D, on next-20260730. The thing this series has been describing as unsolved since v3 is solved, and it was one register write. That changes the cover letter more than it changes the patches, so the correction comes first. The claim I have to withdraw ============================ Every version of this series from v1 to v6 has said that the RK3576's completion interrupt is armed exactly as on RK3588 and never reaches the GIC, and v6 shipped an hrtimer that samples INTERRUPT_RAW_STATUS instead of waiting for it. That is not true. The interrupt works. It never fired because the block believed it had 28672 tasks left to run, so the job was never complete. PC_TASK_CON packs the task number with three controls above it, and the field widths are not the same on both SoCs: 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 rocket_registers.h is generated from the RK3588 description, so writing it unchanged on an RK3576 asks for task_number 0x7001, that is 28673 tasks, and puts TASK_COUNT_CLEAR on a bit that does nothing. The counter was then only ever cleared by a reset, which is precisely the "one task per reset" shape v6 reported, and it is why every completion path I added looked necessary. It was found by taking an ordered trace of every register write during one submit and diffing it against the same trace from the vendor driver on the same board. Exactly one value differed. Robin and Diederik, my apologies for the thread that premise cost you. Robin's shortlist for an interrupt that never arrives was an extra clock or power domain in the path, a masking control that had been overlooked, a wrong description, or terminally broken hardware. It was none of those, because the interrupt was not the thing that was wrong. Chaoyi Chen of Rockchip confirmed the layout on the list, including the fourth control at BIT(18) that the trace could not have named: https://lore.kernel.org/all/4f300b78-d96d-4d98-8819-dc292b0c9b97@rock-chips.com/ I sent a correction to the list when this landed rather than leaving it until now: https://lore.kernel.org/all/20260807211629.1573228-1-gahing@gahingwoo.com/ So v7 drops the poll entirely. There is no hrtimer, no poll work, no second completion path and no arbitration between two of them. A job is retired by its interrupt, the way it is on RK3588. Changes in v7 ============= * accel/rocket: PC_TASK_CON is written with the RK3576 field layout. The defines are in rocket_job.c rather than in rocket_registers.h, which is generated and says not to edit it by hand. * accel/rocket: the completion poll and everything supporting it is gone: poll_completion, the hrtimer, the work, poll_seq and its mirror, poll_dying, the teardown ordering in rocket_job_fini() and the arbitration in rocket_job_handle_irq(). 7/9 in v6 was 142 added lines in rocket_job.c and 8/10 here is 90, most of which is the comment explaining the register. * accel/rocket: the job_lock fix is its own patch now, 1/10, with a Fixes tag. It is an RK3588 bug and it was buried in the middle of a preparation patch in v6, where nobody could backport it. * accel/rocket: the power domain list is attached before iommu_group_get() rather than after rocket_job_init(). In v6 a failure there returned without unwinding either of them. Igor caught it. Moving the call is better than adding an unwind path, since everything before that point is devres managed and a plain return is then correct. It also keeps commit f509a081f6a2 ("accel/rocket: fix unwinding in error path in rocket_core_init") from having a second copy of itself to keep in step. * accel/rocket: struct rocket_core's clks[] no longer grows in 7/10. Igor pointed out that 7/10 claimed nothing changes for RK3588 while growing the array there, with the two extra names only arriving in 8/10. The array now grows in the patch that adds the names. * The series is 10 patches rather than 9 because of the split above. Nothing else moved. What this means for the split in 7/10 and 8/10 ============================================== Diederik asked for the enablement to be split and Igor seconded it, and v6 did that. The split survives v7 unchanged: 7/10 is the soc_data plumbing with RK3588 keeping four clocks and two resets, and 8/10 is the RK3576 enablement. What changed is that 8/10 is now much smaller. Where it stands =============== With every debug knob off, on a ROCK 4D: * the NPU probes with the two domain list and no attach failure; * 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; * the NPU's line in /proc/interrupts goes from zero to three across those three submits, one each and no more; * unbind and rebind is clean with no warning; * every patch builds on its own; * dt_binding_check is clean on all three bindings the series touches. The measurement in v6 that could not tell a recomputation from an untouched output buffer has been replaced by one that can: the inputs differ between submits, so a stale buffer cannot pass. That was run on this branch with nothing else applied. The out of tree work this hardware has needed for the userspace investigation, including an rk_iommu flush_iotlb_all that is neither upstream nor in this series, is not present, and the userspace results below are the same without it. The userspace side is a separate matter and is not part of this series. It runs regular convolutions, depthwise convolutions and the first convolution of MobileNet V1 byte exact per output channel against the CPU reference, and two chained operators come out at the accuracy the hardware's own arithmetic allows. A whole MobileNet does not run yet. Nothing that is still wrong there is in the kernel. Igor, thank you again for the RK3588 review. Both of the things you found in v6 are addressed above and the completion path has changed enough that it needs another look rather than a carried tag. Your offer to run this on all three RK3588 cores would be very welcome, since the only behaviour change to RK3588 in the series is the job_lock ordering in 1/10 and I cannot test it here. Jiaxing Hu (10): accel/rocket: take the completion register writes under job_lock dt-bindings: npu: rockchip: add rockchip,rk3576-rknn-core dt-bindings: power: rockchip: allow resets in a power domain node dt-bindings: iommu: rockchip: allow the RK3576 NPU MMU clock set pmdomain/rockchip: add optional per-domain power-on settle delay pmdomain/rockchip: cycle optional power-domain resets on power-on accel/rocket: select the per-core clock and reset counts from match data accel/rocket: add RK3576 NPU (RKNN) support arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes arm64: dts: rockchip: rk3576-rock-4d: enable NPU .../bindings/iommu/rockchip,iommu.yaml | 8 ++ .../npu/rockchip,rk3588-rknn-core.yaml | 47 +++++++++- .../power/rockchip,power-controller.yaml | 8 ++ .../boot/dts/rockchip/rk3576-rock-4d.dts | 10 +++ arch/arm64/boot/dts/rockchip/rk3576.dtsi | 80 ++++++++++++++++- drivers/accel/rocket/rocket_core.c | 28 +++++- drivers/accel/rocket/rocket_core.h | 11 ++- drivers/accel/rocket/rocket_device.c | 4 + drivers/accel/rocket/rocket_drv.c | 22 ++++- drivers/accel/rocket/rocket_job.c | 90 ++++++++++++++----- drivers/pmdomain/rockchip/pm-domains.c | 71 ++++++++++----- 11 files changed, 324 insertions(+), 55 deletions(-) -- 2.43.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 77106C5B56A for ; Wed, 12 Aug 2026 09:41:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=Zqcdlkri8QsvQzrc/2sT00IzEXuxSB3nmMU273GhA3g=; b=YhN6OjVt60jtpO D2gn1H1mKfYGC5UHed1F2pZGydqvLlntpH5UDPCmfKO0J25jnf9nd1Qbz3mvM43O1LwfAisAWzzRf HKs3yCC3ieSrd4ASEoMRmr+KCSlW5jEsFyWoP2X8AsjKjE58PYpitZm0ixCl1Q04IitHj1AW9a/d7 Jy238pbSMTHmX0V4V5RquFwggVtQ+GRtxYu1exyoVBlir9x5tkFkOSrO93yirazggthUsbEMHrWWw QJ4yQ3xR6LNxFIkCpEg1n5CukHFnElnaT3Q4Zs+XH6bICGw+bHiwiTtxz3w4cnM6w6KZfo/vLHp5v zk8wi+W9w2qZhryW5dNA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wu5Sl-0000000FmPS-0NE8; Wed, 12 Aug 2026 09:41:31 +0000 Received: from flow-b8-smtp.messagingengine.com ([202.12.124.143]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wu5Sf-0000000FmNu-2aXP; Wed, 12 Aug 2026 09:41:28 +0000 Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailflow.stl.internal (Postfix) with ESMTP id 31829130082A; Wed, 12 Aug 2026 05:41:19 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Wed, 12 Aug 2026 05:41:19 -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:message-id:mime-version:reply-to:subject :subject:to:to; s=fm1; t=1786527679; x=1786531279; bh=XTtrf9QqIJ 0aEwhEPUrpZWj0OOWgjuwh9E5x/Ee+vU4=; b=Do3+aaE4i5NUeaY7SfW37Pv25l QUqp2DkEix2OMEKW2ejeNDwBY/EZZJUenQZ9uSZbixupOlZFEntTSb/QgCwgDacH DvRtGzpFbGUAcconqSl45ZnVslcobtb3T2yIbJoFvqL91siSMIHyys2Ik8aeBezx cPSyTv00jaYgSTGCvFJm4FcR0k8+D3jIe7pms7OgT3wSz1chERp709rnNx4cT3VN 3kx6Hzw3lUVdqJTzRwjuWoK/dMPvv02dUf7xsWhHSHsqF80UKw80zbNmZzw3hT/s Is3t2Itf6eSVFFeCjLKJv8O438bKp3P29x4jYr8YW7WuK0aVQiYctqgx0+XA== 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:message-id:mime-version:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1786527679; x=1786531279; bh=XTtrf9QqIJ0aEwhEPUrpZWj0OOWgjuwh9E5 x/Ee+vU4=; b=btQRECF23aTza3IYQHkV0GTKQTlE9dEXDtuTd/kLYeJ/N7cEJDm IiWhKkB3lU2kKH62Qxxd8PYm4pFiZExgW8NFXZ2ty+39XHTMUz8KafzqvX33Mz8l bN5z6UeDkps6q495gzqtxHxZdBGRMrlrBkAh6qRmH4108GXIiGlEln6nZVgdrsrB dbtXdnK3n9mgxVWkKzuGMPw26XnJffPU1NZAdNQP5ToIU9YwXdcu5xgjzllOEwZo f8rYVGKQVPAgHql625a8leMv6hzYuM92/u9WEOrL1/PLKNeD58iSHTxu9auqL2cT 8JQoyz87j8UF8vYqO3jQhkcMT35PiJFMqbg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGczlsc6lTmWVXF5EdFbdBVrzj/e7Ns03qZEcXkYEtO1ejPPywerw48yQ4lW5hk3J fT+nPF6HwKq4wLnadj9B/7Dxa+JyDDEx+4c7COf2RfNTk8z5C7N//KLe5jziAvw/TtX/Jp OrC/dIaTR/CyYlCFQH75cyZe9sWyJHnxZXS6yI7T6OJVjuheIcXU/eK6bZTz4XhwORckp+ 14uoPBgn1Yp6vTSRddKOl657KK8RRAbUi7J1na8KuT9wzNcxlASvghh7F98Jutl24ebq9g llnAP0pM5Ea0ZgFR9n5XPa2NKSElqXsALbI2HKi6XGVMFztOK0Iz3JFRIByX2nDIiMMtXZ UayMLhX5L+S5al0XL9J/cmf77OnCUAbzlK/sgfcDEOMzs5USN3TTAHwETXv90c4PKmhd3E Zmz/EZ0BjpxB8OvYiYRpneXAP1XbgYOrNEKBJcIp5n8s/2jaS0bqmK1X9Vn9sof/vgYmTk bvyl8cFXFIBWFfgbSL2CbvQsUC+cHXRo+QL67C/1tkaNU1MwgMrG1H86LT0nPU5APvaGh/ KlRbyLA/BLZ9XeMTVX8Jka4laTBy/2rMvzmVvmGiEmGpS/a8BNddhIHgaQa5EQZWWVVCcX CbidpSWly9KWj0mV1YU1or1O0uOzTW9F4XmzyDq/iNxuoMmBJCXvIZyMncMA X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 12 Aug 2026 05:41: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, alchark@flipper.net, chaoyi.chen@rock-chips.com, diederik@cknow-tech.com, 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 v7 00/10] accel/rocket: RK3576 NPU (RKNN) enablement Date: Wed, 12 Aug 2026 21:40:55 +1200 Message-ID: <20260812094106.1391698-1-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260812_024126_431383_2EDEAC3A X-CRM114-Status: GOOD ( 27.76 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org Based on Igor Paunovic's "[PATCH v2] accel/rocket: request the core clocks by name", as v6 was: https://lore.kernel.org/linux-rockchip/20260729130743.128876-1-royalnet026@gmail.com/ Tested on a Radxa ROCK 4D, on next-20260730. The thing this series has been describing as unsolved since v3 is solved, and it was one register write. That changes the cover letter more than it changes the patches, so the correction comes first. The claim I have to withdraw ============================ Every version of this series from v1 to v6 has said that the RK3576's completion interrupt is armed exactly as on RK3588 and never reaches the GIC, and v6 shipped an hrtimer that samples INTERRUPT_RAW_STATUS instead of waiting for it. That is not true. The interrupt works. It never fired because the block believed it had 28672 tasks left to run, so the job was never complete. PC_TASK_CON packs the task number with three controls above it, and the field widths are not the same on both SoCs: 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 rocket_registers.h is generated from the RK3588 description, so writing it unchanged on an RK3576 asks for task_number 0x7001, that is 28673 tasks, and puts TASK_COUNT_CLEAR on a bit that does nothing. The counter was then only ever cleared by a reset, which is precisely the "one task per reset" shape v6 reported, and it is why every completion path I added looked necessary. It was found by taking an ordered trace of every register write during one submit and diffing it against the same trace from the vendor driver on the same board. Exactly one value differed. Robin and Diederik, my apologies for the thread that premise cost you. Robin's shortlist for an interrupt that never arrives was an extra clock or power domain in the path, a masking control that had been overlooked, a wrong description, or terminally broken hardware. It was none of those, because the interrupt was not the thing that was wrong. Chaoyi Chen of Rockchip confirmed the layout on the list, including the fourth control at BIT(18) that the trace could not have named: https://lore.kernel.org/all/4f300b78-d96d-4d98-8819-dc292b0c9b97@rock-chips.com/ I sent a correction to the list when this landed rather than leaving it until now: https://lore.kernel.org/all/20260807211629.1573228-1-gahing@gahingwoo.com/ So v7 drops the poll entirely. There is no hrtimer, no poll work, no second completion path and no arbitration between two of them. A job is retired by its interrupt, the way it is on RK3588. Changes in v7 ============= * accel/rocket: PC_TASK_CON is written with the RK3576 field layout. The defines are in rocket_job.c rather than in rocket_registers.h, which is generated and says not to edit it by hand. * accel/rocket: the completion poll and everything supporting it is gone: poll_completion, the hrtimer, the work, poll_seq and its mirror, poll_dying, the teardown ordering in rocket_job_fini() and the arbitration in rocket_job_handle_irq(). 7/9 in v6 was 142 added lines in rocket_job.c and 8/10 here is 90, most of which is the comment explaining the register. * accel/rocket: the job_lock fix is its own patch now, 1/10, with a Fixes tag. It is an RK3588 bug and it was buried in the middle of a preparation patch in v6, where nobody could backport it. * accel/rocket: the power domain list is attached before iommu_group_get() rather than after rocket_job_init(). In v6 a failure there returned without unwinding either of them. Igor caught it. Moving the call is better than adding an unwind path, since everything before that point is devres managed and a plain return is then correct. It also keeps commit f509a081f6a2 ("accel/rocket: fix unwinding in error path in rocket_core_init") from having a second copy of itself to keep in step. * accel/rocket: struct rocket_core's clks[] no longer grows in 7/10. Igor pointed out that 7/10 claimed nothing changes for RK3588 while growing the array there, with the two extra names only arriving in 8/10. The array now grows in the patch that adds the names. * The series is 10 patches rather than 9 because of the split above. Nothing else moved. What this means for the split in 7/10 and 8/10 ============================================== Diederik asked for the enablement to be split and Igor seconded it, and v6 did that. The split survives v7 unchanged: 7/10 is the soc_data plumbing with RK3588 keeping four clocks and two resets, and 8/10 is the RK3576 enablement. What changed is that 8/10 is now much smaller. Where it stands =============== With every debug knob off, on a ROCK 4D: * the NPU probes with the two domain list and no attach failure; * 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; * the NPU's line in /proc/interrupts goes from zero to three across those three submits, one each and no more; * unbind and rebind is clean with no warning; * every patch builds on its own; * dt_binding_check is clean on all three bindings the series touches. The measurement in v6 that could not tell a recomputation from an untouched output buffer has been replaced by one that can: the inputs differ between submits, so a stale buffer cannot pass. That was run on this branch with nothing else applied. The out of tree work this hardware has needed for the userspace investigation, including an rk_iommu flush_iotlb_all that is neither upstream nor in this series, is not present, and the userspace results below are the same without it. The userspace side is a separate matter and is not part of this series. It runs regular convolutions, depthwise convolutions and the first convolution of MobileNet V1 byte exact per output channel against the CPU reference, and two chained operators come out at the accuracy the hardware's own arithmetic allows. A whole MobileNet does not run yet. Nothing that is still wrong there is in the kernel. Igor, thank you again for the RK3588 review. Both of the things you found in v6 are addressed above and the completion path has changed enough that it needs another look rather than a carried tag. Your offer to run this on all three RK3588 cores would be very welcome, since the only behaviour change to RK3588 in the series is the job_lock ordering in 1/10 and I cannot test it here. Jiaxing Hu (10): accel/rocket: take the completion register writes under job_lock dt-bindings: npu: rockchip: add rockchip,rk3576-rknn-core dt-bindings: power: rockchip: allow resets in a power domain node dt-bindings: iommu: rockchip: allow the RK3576 NPU MMU clock set pmdomain/rockchip: add optional per-domain power-on settle delay pmdomain/rockchip: cycle optional power-domain resets on power-on accel/rocket: select the per-core clock and reset counts from match data accel/rocket: add RK3576 NPU (RKNN) support arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes arm64: dts: rockchip: rk3576-rock-4d: enable NPU .../bindings/iommu/rockchip,iommu.yaml | 8 ++ .../npu/rockchip,rk3588-rknn-core.yaml | 47 +++++++++- .../power/rockchip,power-controller.yaml | 8 ++ .../boot/dts/rockchip/rk3576-rock-4d.dts | 10 +++ arch/arm64/boot/dts/rockchip/rk3576.dtsi | 80 ++++++++++++++++- drivers/accel/rocket/rocket_core.c | 28 +++++- drivers/accel/rocket/rocket_core.h | 11 ++- drivers/accel/rocket/rocket_device.c | 4 + drivers/accel/rocket/rocket_drv.c | 22 ++++- drivers/accel/rocket/rocket_job.c | 90 ++++++++++++++----- drivers/pmdomain/rockchip/pm-domains.c | 71 ++++++++++----- 11 files changed, 324 insertions(+), 55 deletions(-) -- 2.43.0 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip