The performance-controller hardware block on MediaTek SoCs is
responsible for controlling the frequency of the CPUs. As such, it needs
any CPU regulator to have been configured prior to initializing. Add a
phandle in the binding so this dependency can be described.
Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
---
.../devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
index d0aecde2b89b..d75b01d04998 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
@@ -33,6 +33,8 @@ properties:
performance domains.
const: 1
+ big-cpus-supply: true
+
required:
- compatible
- reg
--
2.43.0
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 <[email protected]>
---
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";
--
2.43.0
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 <[email protected]>
>
> ---
>
> 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 ?
--
viresh
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 <[email protected]>
>>
>> ---
>>
>> 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
On 29/12/2023 22:28, Nícolas F. R. A. Prado wrote:
> The performance-controller hardware block on MediaTek SoCs is
> responsible for controlling the frequency of the CPUs. As such, it needs
> any CPU regulator to have been configured prior to initializing. Add a
> phandle in the binding so this dependency can be described.
>
> Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
> ---
>
> .../devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
> index d0aecde2b89b..d75b01d04998 100644
> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
> @@ -33,6 +33,8 @@ properties:
> performance domains.
> const: 1
>
> + big-cpus-supply: true
Why big? Neither little nor medium need power? Why you do not need to
provide all supplies?
About the naming, use something matching the devices, e.g. from their
datasheet/manual.
Best regards,
Krzysztof
On Fri, Dec 29, 2023 at 06:28:39PM -0300, N?colas F. R. A. Prado wrote:
> The performance-controller hardware block on MediaTek SoCs is
> responsible for controlling the frequency of the CPUs. As such, it needs
> any CPU regulator to have been configured prior to initializing. Add a
> phandle in the binding so this dependency can be described.
>
> Signed-off-by: N?colas F. R. A. Prado <[email protected]>
> ---
>
> .../devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
> index d0aecde2b89b..d75b01d04998 100644
> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
> @@ -33,6 +33,8 @@ properties:
> performance domains.
> const: 1
>
> + big-cpus-supply: true
> +
A CPU's supply belongs in the respective CPU nodes.
Rob