From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from flow-b7-smtp.messagingengine.com (flow-b7-smtp.messagingengine.com [202.12.124.142]) (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 5FFD53B95FA for ; Thu, 13 Aug 2026 09:27:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.142 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786613234; cv=none; b=dSwt4XKbJ5qj0NOESWdtsbjx753bYk+ej7tGnbLG+1hfA8vMH2c0kLuw5vv0bgl/b5zoxbHVG9CGRVulWHq/61NGYyJg6ORtpei6/7V58niJKT7UHD4/cokVt9UUaPiHO72a2qU0NqzcF/MfWo85INsddd/jw78g7ySljn6zPd8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786613234; c=relaxed/simple; bh=VNrUh43mbgcpQE1hEY4DZAGOVjmd0An7GABPQEMBPj0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HNVchs+1/apN2QKrZZ2Zn7cWPCzH0RAxEtqgz8zeFvC0a8a98OYGQXhNi4HR4XrJEVFr/B/L7IiJw6kpvbaOV0MMpV57AQEsfGY93E6so6lqh4ZX4aXVeyYZelrDcAJxEnNgEjhZORiFQrkrSLoIZ/AUkD7Fiwv2sIpBWV3qZFg= 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=Xwk8AWY8; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=Q/9SiPgS; arc=none smtp.client-ip=202.12.124.142 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="Xwk8AWY8"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="Q/9SiPgS" Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailflow.stl.internal (Postfix) with ESMTP id C088513002E3; Thu, 13 Aug 2026 05:27:10 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-12.internal (MEProxy); Thu, 13 Aug 2026 05:27:11 -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=fm1; t=1786613230; x= 1786616830; bh=hsFxZ3Ixcxao/UXVeMngQAQyl2hgDxb8MfUV5pS9FUs=; b=X wk8AWY8y35vFRSuC0ov4nAO2Q2loXiexbgX7ejR4U7I7ayhSOnWRtCRvqtVkMqCt NouaXTbR1h7dbbLl2V5tF8dn2dqWA0SELOs15A5AktZjwZi0+5XIwrBSlu/3FsXV i+r/16Riveo7a8euMTs4OyINO4YhS1ZNn1to4VmG3BnR8uQ1ppBIhaG+BH/6JXos clLt90XpluD8XIVWvMKLX/hJQJIlHQ1vVv4qi/yQkNREj83lXosfpb9QKzjMRgDI vi0umdk+QjLUCr/eD+yi/DoOL24V7uXymAxQ+lNL4e+sf67RZYWes+j8eSOWFS0M iYcNjLrOPe0boUhK3n/Gw== 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=fm3; t=1786613230; x=1786616830; bh=h sFxZ3Ixcxao/UXVeMngQAQyl2hgDxb8MfUV5pS9FUs=; b=Q/9SiPgSDD5isYTw/ kl2IM8TDJ7SyZd4QGFYywlNOQsHuUbdiqPGmnlXeeTmqAs8rTERrfXHcgk7fa5vL eXyz4MpWlEe46/+Nf88v5J9aNZT7ow5exUvmXSCY5S6Iy0cdaz7YprPjB4V3xX5B PelCSqOkY1wgBaupp9rY31nAvUwsBI83HZHxTpHMRJSjmSz6P21lBFC1CLkeKng3 TJfGld6jMDu8s14NO7IpAsrKUkWD8Ic8I8d4DhWJrLwEVfi9OzCdC8Q0i/nGjBvo y9VoYyhw0kH4bkDEdB8LYbxwlAGDQ2Ahl/Kv0RWLAo5gLGIamEIQFJWl15jo4Dy7 vMvvw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFvkSju2jPjsNthsipJjLLcKiFKo2iZfGlFycdFk+MydEAZMZ8gLXf+IJPcsUPR7q 8Lu23Zv43b+dFbQ7TjLTmPjFPmS1byNHUQMmyTnEfd3+zp8aMAPcQyxqEG2X7Wh9zAGCZO ASfeTun9KO56biKJV5zVg16tsQhRU+6nbKkIbeQQqpYAylrTOrls7RmnSCLmRbmc2VPoBx vZ1P4cH26vteFh0edZtGGFBd7vW83H5gdsKKOvjG4hwjTKUneZFr39S9vg1vWvHxW1qTXR zUPf2/JEHD3iDaAfdm0gPNK5y+li0Yp5cV+EPNl29rBRAnACwpAGVl/KnlQtSLM0ttX4J2 l/am9K2O25bP9VtmYiIW+Ly6VtUhOdy3nwxs4s4paixrmj2wHjw6niht4buWZq5Asathg6 Dbkf3vfYVYIuGsr8OqC4kUSpHnopYqD2B1I1lcBGxFLDwkMzgVNIl9UwDGwBGLeAOHbbt/ zrpjS30/nQOBC9mfp6MZRGCNVf5ooC5X9K42rk+Wn7kUL8YNSHsfX23UoiiyVImXKYepqA LZeamRMgClsJiboYwdWqADPrqjEP8BIGfaM/h0cYcfyyurW+EBHPTe3j+7YPmX4UWiLHUV sZPMA1wA7khI+wfKRscvUa0o9jFbm+dsi+zz5LhEmixxzjFL1pi6+NaQzMhg X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 13 Aug 2026 05:27:01 -0400 (EDT) From: Jiaxing Hu To: royalnet026@gmail.com Cc: tomeu@tomeuvizoso.net, heiko@sntech.de, chaoyi.chen@rock-chips.com, alchark@flipper.net, dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Jiaxing Hu Subject: Re: [PATCH v7 08/10] accel/rocket: add RK3576 NPU (RKNN) support Date: Thu, 13 Aug 2026 21:26:56 +1200 Message-ID: <20260813092656.2568538-1-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260812124850.6597-1-royalnet026@gmail.com> References: <20260812094106.1391698-1-gahing@gahingwoo.com> <20260812094106.1391698-9-gahing@gahingwoo.com> <20260812124850.6597-1-royalnet026@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Igor, Thank you for the run, and for reading the patch rather than only testing it. Both of your points are right and both are fixed for v8. I am answering your 1/10 question here as well so it stays in one place. > That is the v6 comment for the poll. Yes, and it should not have shipped. The cover letter withdraws the premise that comment states, the patch under it deletes the machinery it describes, and it has no code beneath it at all. It is gone in v8. For the record on how it survived: it was fixed in my tree the day the correction went to the list and the fix never made it into the series I formatted. That is the second time a fix has existed here and not reached what I sent, so I now diff the posted patches against the tree before sending rather than trusting that they match. > It would sit more naturally in 1/10, which already touches that > function, or in a patch of its own. A patch of its own, placed after 1/10 rather than before it. 1/10 is a fix with a Fixes tag that someone may want to backport, and it should stay the smallest thing that fixes the bug. Refactoring the function first would put the backport on top of a restructure it does not need. So v8 is 1/10 unchanged, then the extraction on its own, then the RK3576 patch with no shared-path changes left in it. > would a synchronize_irq(core->irq) before the guard in > rocket_reset() be worth having as well? I think yes, and before the guard is the only place it can go. The handler takes job_lock, so calling it inside the scoped_guard would wait for a handler that is waiting for the lock we hold. Before the guard nothing is held, and both callers, the timedout_job callback and reset_work, are process context, so it is safe there. It also closes exactly the window you describe rather than a different one. drm_sched_stop() stops the scheduler and returns; a threaded handler already running is untouched by it, and the comment sitting above that code says "Remaining interrupts have been handled", which is the assumption your reading breaks. synchronize_irq() makes that sentence true instead of hopeful. What it does not do is stop a handler that has already read in_flight_job from finishing its work on a job the reset is about to drop. That one wants the check and the write to be one step under the lock, which is what 1/10 does. The two changes are complementary and I will send them as such, with the comment reworded to say what is actually guaranteed. Your RK3588 numbers are also the only evidence anyone has that 1/10 costs nothing on the path it protects, since I cannot run three cores here. Carrying the tag to v8: Tested-by: Igor Paunovic # RK3588, three cores One piece of news from the userspace side, since you run MobileNet through Teflon yourself. As of today the whole of MobileNet V1 runs on the RK3576 with the open stack: 995 of its 1001 outputs land within one count of the CPU reference, against 1001 channels of zero in every run before this. The kernel side of that is this series unchanged; what moved was four Mesa faults, the last of which was a coefficient buffer whose second operand has to be 16 byte aligned, which is why every layer whose output channel count was not a multiple of eight came back empty. Thanks again, Jiaxing