All of lore.kernel.org
 help / color / mirror / Atom feed
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: "Viresh Kumar" <viresh.kumar@linaro.org>,
	"Nícolas F. R. A. Prado" <nfraprado@collabora.com>
Cc: "Rafael J . Wysocki" <rafael@kernel.org>,
	kernel@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: Re: [PATCH 2/2] arm64: dts: mediatek: cherry: Add CPU supply dependency to cpufreq-hw
Date: Tue, 2 Jan 2024 10:09:30 +0100	[thread overview]
Message-ID: <a288d5c8-6eb9-49f8-bcbc-f2b41e51c797@collabora.com> (raw)
In-Reply-To: <20240102061123.frvwltggqqh6m7pm@vireshk-i7>

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

WARNING: multiple messages have this Message-ID (diff)
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: "Viresh Kumar" <viresh.kumar@linaro.org>,
	"Nícolas F. R. A. Prado" <nfraprado@collabora.com>
Cc: "Rafael J . Wysocki" <rafael@kernel.org>,
	kernel@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: Re: [PATCH 2/2] arm64: dts: mediatek: cherry: Add CPU supply dependency to cpufreq-hw
Date: Tue, 2 Jan 2024 10:09:30 +0100	[thread overview]
Message-ID: <a288d5c8-6eb9-49f8-bcbc-f2b41e51c797@collabora.com> (raw)
In-Reply-To: <20240102061123.frvwltggqqh6m7pm@vireshk-i7>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-01-02  9:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-29 21:28 [PATCH 1/2] dt-bindings: cpufreq: Add big CPU supply Nícolas F. R. A. Prado
2023-12-29 21:28 ` Nícolas F. R. A. Prado
2023-12-29 21:28 ` [PATCH 2/2] arm64: dts: mediatek: cherry: Add CPU supply dependency to cpufreq-hw Nícolas F. R. A. Prado
2023-12-29 21:28   ` Nícolas F. R. A. Prado
2024-01-02  6:11   ` Viresh Kumar
2024-01-02  6:11     ` Viresh Kumar
2024-01-02  9:09     ` AngeloGioacchino Del Regno [this message]
2024-01-02  9:09       ` AngeloGioacchino Del Regno
2024-01-04  8:03 ` [PATCH 1/2] dt-bindings: cpufreq: Add big CPU supply Krzysztof Kozlowski
2024-01-04  8:03   ` Krzysztof Kozlowski
2024-01-09  4:26 ` Rob Herring
2024-01-09  4:26   ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a288d5c8-6eb9-49f8-bcbc-f2b41e51c797@collabora.com \
    --to=angelogioacchino.delregno@collabora.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@collabora.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=nfraprado@collabora.com \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.