From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D8263441037 for ; Wed, 29 Jul 2026 13:08:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785330485; cv=none; b=lEpybkGlvjMHGiEH5ElOoY/0ZsXsZxprXZJ4uSl3iX+05AwjkAm/XnawYIi1TFuVtunqhBfkZeq5l4loLbfukMYVxu/GpT6xyVjRaktOZzNm7uwaYPOuy9Rsiy8UkJMQU3OpreXS1cnB7pnBnmVPbUo4bhlvQb7BuwktkI4a4PA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785330485; c=relaxed/simple; bh=nLXsb/mchvpbNBx/HyW0BeMe4Wq8RpcpcNPPH1EYpI8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=CbJiKGevMm60COsnT1Wc7ncJqKn/B1U8e/nNqHrWLgLiVB6tr4/Orl0DM91VLbMUuRRgQ2EtpI3YzLbnH4bxZK10tPHQlvMlhefLiUhlvOQkl6hR39kSZM4o06E/AV1b9kl1mhPUqb0LapW1rEgHptI0tcuZnF4XrFrsppCa2N0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=dWApHM73; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dWApHM73" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-47f5d5dbf80so81905f8f.2 for ; Wed, 29 Jul 2026 06:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785330482; x=1785935282; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=Q/pbacYlJpkDaCE9RbWRQcg2zDk1XOgU/3Z2HS4A2NQ=; b=dWApHM736AbmblWYR+veEsbWoGLj3lw3mwB0M2gcDanD2vy0vsYzkEVl3iktP17VU7 pPfZxH0FTg8Ys4VlZwla4GAHS9XkS5GvWKNRqc8pwJKudPd81Ee8ExErF5hN4Ej/imwg FqfnrXC82RFcl7rNP+k2vQepPC85GZGx5V413JRbWu8+qOwB/TZXGDJedh4PSct/Dq5X ofRl5n1Nnm3Px6xFaeBJp1GVN9ViWrPQMM/pDWySJyAI9Lp4VL2zcNkgnM9xpQTJ/miO 5eCoB+yUSpST/a67dFn+IiUFbSSKGBqdhuUXpqt4Cu+Gu78+Vnezt+emsiNJDv1OYKR9 M8oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785330482; x=1785935282; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Q/pbacYlJpkDaCE9RbWRQcg2zDk1XOgU/3Z2HS4A2NQ=; b=OCH+sfooY4SoWgf1S9wQyeBeeMzAZQtQswIUevF+j3O9RVmWXfa8i7tSi7ZrI61bGu e/xCA28Rw3PSw2ER0JaJEGrLdUQPxe/V74D+4mdCuPPVYEoj5wg/fH4l0bRKCxprsiQQ nmGCt+4QQyw99ANI/IRjQSVNy6I3UAc7sauo3Gefclai2tbBpQE2vDV7oKnB2RtP0rLk HdckCf8pPEvghv1VpW+aV8ekROt9KliOyOBBgnyTZfBxMlfjQ5O4/SOCUBuoiJ9TkUi7 A5MrUGTnucAbXhzbL6jCPyEvgwXJaP+qjk6Y9Jcfa4cA6lGHIpXDB9LCWaIlROyvyXnF FbtA== X-Forwarded-Encrypted: i=1; AHgh+RoDK/Je/JRcbJ+M4BdqVjUPdetTUnVs01vclBBEKDKJJzFNl5PKdtiu0N4VNH5fCJzgW6VUaS8AxDhVkDU=@vger.kernel.org X-Gm-Message-State: AOJu0YyexASzDpfqhhsESqtFijns1BuQfuLDhKWOgVHRT5rWzZABpCZq RS0X9sUA7Km/x1GdHFyPwh4900h+zb/ZpLM4ObFLziwP16NWJYjJy9Lc X-Gm-Gg: AR+sD12g/XH+OWmuIIZ1c1+MwAhvdVZ5+OaoWBw0FysuX2CypulbWufY4nsAqQ+BwS0 1IKqJCN7kwwDn/c7phVIU6tOIeXvYmwuztw8dl6ym6Iqz0XgFhXMfJYUWI0+UuAW4scrCE7O3Qs Rp1sDjha3CuKAXFhkSLQFmSIKZ7tnLcbaTzdbNWbYvjG/b6OM6E/JvrL2cddcI8KuMADvRsgdx3 Lg/zxZyJfJQGHVZ0coC6I7G4gVg3ndxg1/guhITRB7olAJ1Jd15CVHLdFx9YrTq2duJfeYr0UgF TsPg5GgT4w7IT08CMVnklL3jSUpygV4eGF8ad918R18NKbaOM/WTj3Wc5jgECjsSSC45i4tToQt 0OZ5l+bEnG4q9jQoXvH/r8a3PdjnTBEaT3Isr2lN82Sp8OBqJojRtOHf4QJW98u3GAy6BTzp2Yw I8PZolsYVXJyZus02XxELaazeW6QeYc4me8p65gpyid4KYPs7jhJB8q/+MogL4Hfi6EtwGNAtYK Y9Gu09vwwmApxOtfayJVpezVDXHw1ZDnuJVG0G41ZuyH6n1O2YubyZaOpXfq2Ei8Rv+ww== X-Received: by 2002:a05:600c:4583:b0:493:f42e:1b3f with SMTP id 5b1f17b1804b1-496c6571e01mr50134555e9.3.1785330481530; Wed, 29 Jul 2026 06:08:01 -0700 (PDT) Received: from OrangePi5-Plus.BB-HOME (20014C4E1B886F0027B74C8463513DA4.dsl.pool.telekom.hu. [2001:4c4e:1b88:6f00:27b7:4c84:6351:3da4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-497fecfccc7sm37571645e9.12.2026.07.29.06.08.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jul 2026 06:08:01 -0700 (PDT) From: Igor Paunovic To: Tomeu Vizoso Cc: Oded Gabbay , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, Jiaxing Hu , Heiko Stuebner , Igor Paunovic Subject: [PATCH v2] accel/rocket: request the core clocks by name Date: Wed, 29 Jul 2026 15:07:43 +0200 Message-ID: <20260729130743.128876-1-royalnet026@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 Reviewed-by: Jiaxing Hu --- v2: - document that resolving by name is a behaviour change for DTs that do not carry all four clock-names (Jiaxing Hu) - collect Jiaxing's Reviewed-by v1: https://lore.kernel.org/linux-rockchip/20260729092939.118779-1-royalnet026@gmail.com/ The same four id assignments are board-tested on RK3576 (ROCK 4D) as part of Jiaxing's RK3576 enablement series (v2 6/8), so the change has been exercised on two SoCs between us. Verified on RK3588 (Orange Pi 5 Plus): after the change clk_summary shows one consumer handle per clock instead of four handles on aclk, the NPU still powers up and down cleanly through runtime PM, and a MobileNetV1 inference run via the Teflon TFLite delegate produces bit-identical output tensors to the unpatched driver. 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/rocket_core.c index b3b2fa9..5dd260b 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", core->index); + core->clks[0].id = "aclk"; + core->clks[1].id = "hclk"; + core->clks[2].id = "npu"; + core->clks[3].id = "pclk"; err = 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", core->index);