Message ID | 20231229212853.277334-2-nfraprado@collabora.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-13242-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:6f82:b0:100:9c79:88ff with SMTP id tb2csp2806941dyb; Fri, 29 Dec 2023 13:31:41 -0800 (PST) X-Google-Smtp-Source: AGHT+IGnYxwdo+kGAemOFyJvu33HJzGzfa5sB1DyUZgjnJfrEf4fqAocszqekcVz97dFMQLimodU X-Received: by 2002:a05:6359:630f:b0:172:ab3b:cc1e with SMTP id sf15-20020a056359630f00b00172ab3bcc1emr8630886rwb.4.1703885501015; Fri, 29 Dec 2023 13:31:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703885500; cv=none; d=google.com; s=arc-20160816; b=sV9sLSFJloSbFsmdescYWLAsVCbJ8VwW8ztoJXTTL3nVqQ+BhEwb4lCt8+dWUS50Za 3jLCPoWEx3dm/9J9StFXoanCbjDNnF2mBbOU7Ml6Te80RfrtYoVY8NTLCk8SNOtW0Wuu 8zCMhTxhVEU/HrNX22ZXF+4MmAWrriQUn5hpPQoLTQ/JUmvWpjRShDDcGfQSsNStT/IF 2UHsu0DL3poujtS1CsAGfBU0v+dDYK51AEMrG2Hb4a3o18U/jNHW60zzvSrkcUdVHCrC 5X6aeTa5bxjwH6BnDOv2t7SkGPfuIPmDQOTQym6CijoXnkPkEQnF7M+WzkB0tnUsxBIB NGfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=e0uNg0JJza3ekbCEOERdWEzmvDh/VhU6Jzy3Re4RDF0=; fh=7iT0F+vlNmjieKvkExnW2JmE0ytlxlPcl83g8i1GN8M=; b=09cq8suvRZWKVbZ/jNr6EZsNCJPfkkc95MczM2gYzrWuS2Tl4r8+mFxOJxa1bZflsK gNHQIPyJTDww5VGARBf+LPhmM/DiE+wDRiRxeGK3IGD3ayDcgTEpwmk797eOWxL1xxYA I1X4YCbCPE//V4oo8HNhaLzk747FjFaauLfnRllQUnJY5/Ehzr96fyiu5hVvrfLJ/tyg ehHnLclkNnw9sNzy2qMfYDN1MMl1FOyWGJSq+1fK4rMySYtWG38MLyaQ1sTtFXeUIzq2 yWMvL6zVKEEOk6cudfHrEqZK/lIeXfpx41Jbsw6ti5XWx0aqVLyxyyxHUD33NNw9es2U TB/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=HPgwDdLK; spf=pass (google.com: domain of linux-kernel+bounces-13242-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-13242-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id b8-20020a17090a9bc800b0028cad5040b4si2057566pjw.72.2023.12.29.13.31.40 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Dec 2023 13:31:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-13242-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=HPgwDdLK; spf=pass (google.com: domain of linux-kernel+bounces-13242-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-13242-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 7AA4B283A04 for <ouuuleilei@gmail.com>; Fri, 29 Dec 2023 21:31:39 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5513014F72; Fri, 29 Dec 2023 21:31:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="HPgwDdLK" X-Original-To: linux-kernel@vger.kernel.org Received: from madrid.collaboradmins.com (madrid.collaboradmins.com [46.235.227.194]) (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 582D014AA5; Fri, 29 Dec 2023 21:31:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1703885467; bh=XL6wkiD2HYx6HaI4hGDV0Keb34y3XqC2DjGmqSSBy68=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HPgwDdLKJcKpAtUbU9HxQhIW+JM1CO3SqRQv5YJMD2R4TwrVN+DJJBNTbNklpO7nS Bfklfoae+bCfaUPBoDG9McM1aebFRKxtHozaTaQZ2xjsuoC8tUX2utslWOKSADvf04 X3SsEQVGUlzn4VfGVG6l45wtPcjIY10tTUeqZE1BMjpgEdkp9qbFSx/B+rl2z0vc6r Pc3Z+/REaBuT1b029wtURtyKCBUpAcvbzgfDOiGMi98HAa1J+/5/Kj+5QPvT44UK92 9/ZIkguje/JeQsZ+vuHU81HeqEy4/e9iz0AM/HwPdFOdLMqtxuaV3IA0ALA/L8jQWL Pfsh9wZQX7AdA== Received: from localhost.localdomain (zone.collabora.co.uk [167.235.23.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nfraprado) by madrid.collaboradmins.com (Postfix) with ESMTPSA id E0A023781FDE; Fri, 29 Dec 2023 21:31:02 +0000 (UTC) From: =?utf-8?b?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= <nfraprado@collabora.com> To: Viresh Kumar <viresh.kumar@linaro.org>, "Rafael J . Wysocki" <rafael@kernel.org> Cc: kernel@collabora.com, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, =?utf-8?b?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= <nfraprado@collabora.com>, Conor Dooley <conor+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Matthias Brugger <matthias.bgg@gmail.com>, Rob Herring <robh+dt@kernel.org>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: [PATCH 2/2] arm64: dts: mediatek: cherry: Add CPU supply dependency to cpufreq-hw Date: Fri, 29 Dec 2023 18:28:40 -0300 Message-ID: <20231229212853.277334-2-nfraprado@collabora.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20231229212853.277334-1-nfraprado@collabora.com> References: <20231229212853.277334-1-nfraprado@collabora.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1786653443173348695 X-GMAIL-MSGID: 1786653443173348695 |
Series |
[1/2] dt-bindings: cpufreq: Add big CPU supply
|
|
Commit Message
Nícolas F. R. A. Prado
Dec. 29, 2023, 9:28 p.m. UTC
When the mediatek-cpufreq-hw driver enables the hardware (by
writing to REG_FREQ_ENABLE), if the regulator supplying the voltage to
the big CPUs hasn't probed yet, the platform hangs shortly after and
"rcu: INFO: rcu_preempt detected stalls on CPUs/tasks" are printed in
the log.
To prevent this from happening, describe the big CPUs regulator in the
performance-controller DT node, so that devlink ensures the regulator
has been probed and configured before the frequency scaling hardware is
probed and enabled.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 4 ++++
1 file changed, 4 insertions(+)
Comments
On 29-12-23, 18:28, Nícolas F. R. A. Prado wrote: > When the mediatek-cpufreq-hw driver enables the hardware (by > writing to REG_FREQ_ENABLE), if the regulator supplying the voltage to > the big CPUs hasn't probed yet, the platform hangs shortly after and > "rcu: INFO: rcu_preempt detected stalls on CPUs/tasks" are printed in > the log. > > To prevent this from happening, describe the big CPUs regulator in the > performance-controller DT node, so that devlink ensures the regulator > has been probed and configured before the frequency scaling hardware is > probed and enabled. > > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> > > --- > > arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi > index dd5b89b73190..505da60eee90 100644 > --- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi > +++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi > @@ -502,6 +502,10 @@ &pcie1 { > pinctrl-0 = <&pcie1_pins_default>; > }; > > +&performance { > + big-cpus-supply = <&mt6315_6_vbuck1>; > +}; > + > &pio { > mediatek,rsel-resistance-in-si-unit; > pinctrl-names = "default"; I think the regulator needs to be mentioned in the CPU's node and not here ?
Il 02/01/24 07:11, Viresh Kumar ha scritto: > On 29-12-23, 18:28, Nícolas F. R. A. Prado wrote: >> When the mediatek-cpufreq-hw driver enables the hardware (by >> writing to REG_FREQ_ENABLE), if the regulator supplying the voltage to >> the big CPUs hasn't probed yet, the platform hangs shortly after and >> "rcu: INFO: rcu_preempt detected stalls on CPUs/tasks" are printed in >> the log. >> >> To prevent this from happening, describe the big CPUs regulator in the >> performance-controller DT node, so that devlink ensures the regulator >> has been probed and configured before the frequency scaling hardware is >> probed and enabled. >> >> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> >> >> --- >> >> arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi >> index dd5b89b73190..505da60eee90 100644 >> --- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi >> +++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi >> @@ -502,6 +502,10 @@ &pcie1 { >> pinctrl-0 = <&pcie1_pins_default>; >> }; >> >> +&performance { >> + big-cpus-supply = <&mt6315_6_vbuck1>; >> +}; >> + >> &pio { >> mediatek,rsel-resistance-in-si-unit; >> pinctrl-names = "default"; > > I think the regulator needs to be mentioned in the CPU's node and not > here ? > Even if the regulator voltage is being changed by firmware with cpufreq-hw, the actual regulators should go to each CPU node and not in the cpufreq driver node, I agree with Viresh. Besides, that's the same thing that we're doing with mediatek-cpufreq as well... and since we're talking about that, we should also do something about this such that we stop declaring `regulator-always-on` for CPU cores in devicetree, but this is probably slightly out of context for what you're trying to do here, so, read that as an "extra consideration" :-) Cheers, Angelo
diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi index dd5b89b73190..505da60eee90 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi @@ -502,6 +502,10 @@ &pcie1 { pinctrl-0 = <&pcie1_pins_default>; }; +&performance { + big-cpus-supply = <&mt6315_6_vbuck1>; +}; + &pio { mediatek,rsel-resistance-in-si-unit; pinctrl-names = "default";