From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) (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 B17F08828 for ; Sun, 1 Jun 2025 07:51:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=210.118.77.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748764265; cv=none; b=Ih7dPpdp/+1RBlZp9hPIZwEgvfJONG6F+sS7u/kzszHamRla5cFsTsEMEwAguVQ0gMP7wWSWK8h/LoW3vE2Tk6KX+Bb3HrL688lCkH0irsaOUc5QytbesBJHnGJUygt1WzS4vw2e09x97W46de4x4bDOUHGMdqitB38WQzGHGmg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748764265; c=relaxed/simple; bh=5+6yz3aoyJHNsZavcO9AiQGNcAcAlecdhe/eFl9wu9w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To: Content-Type:References; b=asLQ45q6Igu/D/iyQJz7dPnijsyRo64/4VnvZSwgiZ4HWlt1AQ6RHTWf1kE8FoiqSxccDAGMaDc4dnQcsIX09St/YiFHsWJPJAmSsKfH3kARStyFIIO6ShUKkKpTvi3vYm89TN9Mg58TaLHfymBFASQfj7C/DHBVlHrbc8WWrAg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com; spf=pass smtp.mailfrom=samsung.com; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b=UGCFgDVR; arc=none smtp.client-ip=210.118.77.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=samsung.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b="UGCFgDVR" Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20250601075055euoutp02c58fd95f85eab8759e8859859b33dfb3~E29MhvoQ62922429224euoutp02n for ; Sun, 1 Jun 2025 07:50:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20250601075055euoutp02c58fd95f85eab8759e8859859b33dfb3~E29MhvoQ62922429224euoutp02n DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1748764255; bh=hqMY6JBjFHLi1UGuQGIN1VxhuxOXkbW6BShlkS0Hdbw=; h=Date:Subject:To:Cc:From:In-Reply-To:References:From; b=UGCFgDVRJfMsNd/HFXPrc3FxhgoON0esubBU904ELGdFgoc5nag30aAx/Zq6I6Anq wU81Hq0tIJkAqltlzi08+tzT/6bx9zT4Xg5krOQ6NwdpjEagLv6hDb7i0fNyU8I7Bo aJU1ON/FyAqKxKsp6hdOAPnSeEr8mfb6diXcIBC0= Received: from eusmtip2.samsung.com (unknown [203.254.199.222]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20250601075053eucas1p1a6f3d7c11210b61ea1d0c62f7f52cabd~E29LH_2j60784107841eucas1p1m; Sun, 1 Jun 2025 07:50:53 +0000 (GMT) Received: from [192.168.1.44] (unknown [106.210.136.40]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20250601075052eusmtip272f1587c5683112656d6389dcaa6908e~E29KC_7vN1949419494eusmtip2B; Sun, 1 Jun 2025 07:50:52 +0000 (GMT) Message-ID: <61eecafb-8ad1-4306-88cb-a032eefb2e48@samsung.com> Date: Sun, 1 Jun 2025 09:50:52 +0200 Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC 5/6] riscv: dts: thead: Add PVT node To: Drew Fustini Cc: =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , Guo Ren , Fu Wei , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Marek Szyprowski , linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-riscv@lists.infradead.org, devicetree@vger.kernel.org Content-Language: en-US From: Michal Wilczynski In-Reply-To: Content-Transfer-Encoding: 8bit X-CMS-MailID: 20250601075053eucas1p1a6f3d7c11210b61ea1d0c62f7f52cabd X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20250524211525eucas1p244963b69e0531c95a9052e4a7a1d1e01 X-EPHeader: CA X-CMS-RootMailID: 20250524211525eucas1p244963b69e0531c95a9052e4a7a1d1e01 References: <20250524-rust-next-pwm-working-fan-for-sending-v1-0-bdd2d5094ff7@samsung.com> <20250524-rust-next-pwm-working-fan-for-sending-v1-5-bdd2d5094ff7@samsung.com> On 5/27/25 10:00, Drew Fustini wrote: > On Sat, May 24, 2025 at 11:14:59PM +0200, Michal Wilczynski wrote: >> Add PVT DT node for thermal sensor. >> >> Signed-off-by: Michal Wilczynski >> --- >> arch/riscv/boot/dts/thead/th1520.dtsi | 11 +++++++++++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/arch/riscv/boot/dts/thead/th1520.dtsi b/arch/riscv/boot/dts/thead/th1520.dtsi >> index f24e12d7259fabcfbdc2dfa966d759db06684ab4..faf5c3aaf209b24cd99ddc377a88e08a8cce24fe 100644 >> --- a/arch/riscv/boot/dts/thead/th1520.dtsi >> +++ b/arch/riscv/boot/dts/thead/th1520.dtsi >> @@ -648,6 +648,17 @@ padctrl_aosys: pinctrl@fffff4a000 { >> thead,pad-group = <1>; >> }; >> >> + pvt: pvt@fffff4e000 { >> + compatible = "moortec,mr75203"; >> + reg = <0xff 0xfff4e000 0x0 0x80>, >> + <0xff 0xfff4e080 0x0 0x100>, >> + <0xff 0xfff4e180 0x0 0x680>, >> + <0xff 0xfff4e800 0x0 0x600>; >> + reg-names = "common", "ts", "pd", "vm"; >> + clocks = <&aonsys_clk>; >> + #thermal-sensor-cells = <1>; >> + }; >> + >> gpio@fffff52000 { >> compatible = "snps,dw-apb-gpio"; >> reg = <0xff 0xfff52000 0x0 0x1000>; >> >> -- >> 2.34.1 >> > > I found that on my lpi4a that boot while hang after applying this patch. > I think that it is related to clocks as boot finished okay when using > clk_ignore_unused on the kernel cmdline. Do you happen have that in your > kernel cmdline? > > I need to investigate further to understand which clocks are causing the > problem. > > Thanks, > Drew > Thanks for your earlier message. I've investigated, and you were right about the clocks – the specific one causing the hang is CLK_CPU2AON_X2H. This appears to be an AHB bus clock required for CPU access to the AON domain. My proposed solution is to make the pvt node a child of a new parent bus node in the Device Tree. This new "AON bus" node would then explicitly request and manage CLK_CPU2AON_X2H, ensuring it's enabled when its children are accessed. What are your thoughts on this approach? Best regards, -- Michal Wilczynski