From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.128.49 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794576218; b=2QE0kpq5l1CjDUI5Vn3qM+X1aEVONe6rN8I6BQhhQ2I55wMUxBadk9XELKZt9fS3/8lO LVWXoQVdVjP01pG+HplR+VcmoKAp/uuNhB+yR5oAgtiS/mNr/bTit/b/ywmXhdV6wXnfG yw9D7rXv6CJMpD4V3AMZ/5BRqu4qGN7LoAYMIWhOLKekIzxgEtB/C+krQb/yvvsRg6IXb 9FQtB0/RiMFYHhQC38SVhSUUxfCbkckW7XjGdpW7eromOUoyVTQIysNv3N74XJ1VlLpsX yqPSEc1v/RPStzB5gS6AV6EQlxWabVJcXRxOl4QI2uAEItazPCsfCbb24DTEf6Nb3mA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794576218; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: From:To:Cc:Subject:Date:Message-ID:X-Mailer:In-Reply-To:References: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=bPhouWL64Ss7xA+3PtWE37jW1mEzq4J5HXL5n/CanOg=; b=pS5R0PC8fqMtMpZjkQUSOQ8JvbUlI/y3qL/y3J+glwDMNBrt7DcUgGgi96ZjG/24QEUp mj5wAmiFRZdCTDiGMXUEx8Xf3uiRrVeg9QXyQgRuTVwTdk6iSRXGXNbaEm0NnazGNVbK7 ypzS3eafAa9RKityhRCHjJhw5F8Yq5n5i6EFcZGk72GmOpVKhrgpLorrYC6Nmj34Zfvws aVu9RUIU+DtjrarMo7SK8mLM3zRMOyOxY4yv5jOk1HI5pvJn5JG6YLWWe0KXk8PfeAFa4 8eZStryi4wJ+mHsvnRiR+xqn9N+yg8t9lL7sIuJBhMYjKn+vVpkVZ3SPAaVHBqXWnIQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=Gsx833mV; arc=none smtp.remote-ip=209.85.128.49 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7FCFF606EBEC for ; Fri, 13 Nov 2026 13:23:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 7FCFF606EBEC 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, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=Gsx833mV Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4ba013938d7so13695795e9.2 for ; Fri, 13 Nov 2026 05:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1794576217; x=1795181017; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=bPhouWL64Ss7xA+3PtWE37jW1mEzq4J5HXL5n/CanOg=; b=Gsx833mVHsC18NGzPWPM4Ukgyni+A4cjNY/b9YLRauqp+rhG7xq0PtIIF3bE3exkM6 YOMRHU/uZG5LlQLSWMKDmE6wI95QsnP9uk+M2uFSPXMpW8Rmra6QhaWufL7xtKcO5QRt 2bOUakzC6XSgEsZlgykAleWLqHdGdna94dSiqhvUk8jQYr/O+gidceODy5gAj7VvQXwH V7SEs6JU65QoZCQoPoX8h4AA+NXo6w1g0B+qs76eIzcc5o8YVSxenxtvypp3iEH3RRSN NgUJH7eHYYMS3yAePXFrb1WwEwuNTOjko4sW1qoB6WPO+1THGpU3dgZdVbeFPpJaST1/ MK1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794576217; x=1795181017; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to: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=bPhouWL64Ss7xA+3PtWE37jW1mEzq4J5HXL5n/CanOg=; b=si2dxbl6i92FGaSoc+UBMFiOadfNOcb72aBt8o4W4IPJaiJSaF5Kqe+qxrQicpByJF Cpd8RxL91Jw0Oin6JXdQ0ENuLOAR0UB9qUvkwkfmOJb9k70KxnFH5i3DRPU4BYyVsRfR WOZFabT3Wp92/iuBLCAVC/aIyv+svK9/YSr3pV+iNYVADdIDH6jpx3MQtNmBRcv98GwW z5pVJLL30rvLEImJEiYAQKmbN9ovO3/iWLNyPZq7lVXhE4AlaRNQviRl2NJJbCKuDXc3 9juVGScOmdqd9Ffrj1BptOKmfdzshyjIK0suZhgzwSkW1R/S4wuKHpg8+bBiUqxACh2w K92w== X-Forwarded-Encrypted: i=1; AL+hErFDtGsKho8yd/KL5S6OoYdWLZgc30rGluNangQ/i8h8TFyiAQvCmnZ0bTTTYQVg5C09QG7aasG7YWJXzaw=@vger.kernel.org X-Gm-Message-State: APuU4Z+D8461c4dPIjpyQzDrVaqCObPF+2IvUdCbqkHhNQKVejQqSAxM V2ZXF+N5gBquNlo0BqU64Za1gFy63R8Au0H1BlhEIpm3avCPsCI/WOgX X-Gm-Gg: AYBFou3yZSh97K9vzrW7zFKdNt45TveVsUcLeNPf57yAkX6GKtWf4l+OJN+4X+kmS+n mPC4VfvtjzYT0gN4l+DZDR2MHxwlXiiawKRVyNgY9FA88taOBfSZc8y+gPDCW7+Ddj6aPX83t7U No/+XMQdwqU25lPIAGwcIhqubTS7e3azab24sZ8GbOFBd4eo6W763fjcipRzHcT94E3FODgZrjb n50RaX46BN6HOxKm80i6gdk1pOh6iz+nPGcTN0RzcuZO8e9HgV7an+h7CWenyyjIAaK3w7huq7M ODlEvo9/73k41ZTRUQAd7ma9w+TYUEFfVsER0n/MdVovWiPi7B39EgslFFjT3zzYzfM4c2U7mXI /Gen/LDyJ1uOG9ogncbTmDowrY0hxKUQDYdnqvMtGH8Umxt2OdTUxmt5/VmjK6GfM/YBR0VNqDN e9pt/OexMDlOKg5vd0EYwuUN61QWn/Rqu2MwOu05FP1HrS+N/aV5Tfb8VK5YhoIpivPUKOzfOsF encEVabal7dHiVVhIenKBrqOyz+ODmlTv7nZyw5U23977KZw+YNH46bhKJ8KhuV2n80VHi8b9Eo yD6CD3Rr6cXyjN86grb4u9FkWt7rrp0HYusbiaMkQm8PGIuEPAyVk+OY/4b8ScJzwWb39nhZvLw = X-Received: by 2002:a05:600c:8010:b0:4a7:9025:5c3b with SMTP id 5b1f17b1804b1-4bb55a6a5f0mr53609575e9.19.1794576216701; Fri, 13 Nov 2026 05:23:36 -0800 (PST) Received: from vlw-PC.. (static.18.103.245.188.clients.your-server.de. [188.245.103.18]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4bb4e284339sm136419825e9.5.2026.11.13.05.23.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Nov 2026 05:23:36 -0800 (PST) From: Vladimir Bely To: Jiaxing Hu Cc: heiko@sntech.de, ulfh@kernel.org, finley.xiao@rock-chips.com, zhangqing@rock-chips.com, abel.vesa@oss.qualcomm.com, tomeu@tomeuvizoso.net, royalnet026@gmail.com, sebastian.reichel@collabora.com, shawn.lin@rock-chips.com, chaoyi.chen@rock-chips.com, diederik@cknow-tech.com, linux-rockchip@lists.infradead.org, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v16 09/16] pmdomain: rockchip: add optional per-domain power-on settle delay Date: Fri, 13 Nov 2026 16:23:22 +0300 Message-ID: <20261113132323.159015-1-vlwwwwww@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261108065917.135194-10-gahing@gahingwoo.com> References: <20261108065917.135194-1-gahing@gahingwoo.com> <20261108065917.135194-10-gahing@gahingwoo.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Sun, Nov 08, 2026 at 07:59:10PM +1300, Jiaxing Hu wrote: > The NPU power domain is switched off when the driver probes, so the first > power-on goes through this wait even when the bootloader left the NPU on. [...] > + [RK3576_PD_NPU] = DOMAIN_RK3576_R("npu", 0x0, BIT(0), BIT(0), 0, 0x0, 0, 0, 0, 0, false), Hi Jiaxing, (reply to https://lore.kernel.org/all/20261108065917.135194-10-gahing@gahingwoo.com/ ) This probe-time power-off hangs a board that does not enable the NPU. I hit it with v14 as Armbian carries it on 7.3.3; v16 has the same DOMAIN_RK3576_R("npu", ...), so I expect the same there, but I have not run v16. Board: FriendlyElec NanoPi R76S. Its DTS has no domain-supply on pd_npu and the NPU nodes stay disabled. vdd_npu_s0 is RK806 dcdc-reg2, regulator-boot-on, no consumers. On about every second boot the SoC hangs hard ~30 s after start: no oops, no answer to SysRq over the serial console, only the watchdog gets it out. The last console line is "vdd_npu_s0: disabling" from regulator_late_cleanup(). The kernel without the series (7.2.8) does not hang. 10 boots each, no hang, with any of: - regulator_ignore_unused - regulator-always-on on vdd_npu_s0 only - the NPU enabled as in your ROCK 4D patch (domain-supply and npu-supply on vdd_npu_s0, cores and MMUs okay) PMU registers after boot (regmap debugfs of 27380000.power-management): NPU not enabled NPU enabled as on ROCK 4D 0x110 req 0x000013e0 0x000013fe 0x128 idle 0x000313e0 0x000313fe 0x214 pwr 0x0000003e 0x000001fe 0x230 stat 0x003e4181 0x01fe4181 With the NPU not enabled, nputop/npu0/npu1 (bits 6..8 at 0x214) are still powered and their idle requests (bits 1..4 at 0x110) are not set, while pm_genpd_summary lists npu, nputop, npu0 and npu1 as off-0 from early boot. My reading: rockchip_pm_add_one_domain() powers the parent "npu" domain off at probe because of need_regulator, but the children U-Boot left on are neither idled nor powered off first, and genpd then treats them as off, so nothing cleans them up. When vdd_npu_s0 is cut later, the bus hangs on those NIUs. I have not dumped the PMU on a kernel without the series and have not tested a kernel fix, so this is a report rather than a diagnosis. Idling and powering off the children that are on before the parent at probe, or skipping the probe power-off when there is no domain-supply, look like possible directions. This would hit every RK3576 board that does not enable the NPU, which is most of them. More detail: https://github.com/gahingwoo/linux-rk3576-npu/issues/4 I am happy to test patches on the R76S; it has a serial console. Thanks, Vladimir