diff mbox series

[V2] ARM: dts: omap36xx: Remove turbo mode for 1GHz variants

Message ID 20210109170103.1249838-1-aford173@gmail.com (mailing list archive)
State New, archived
Headers show
Series [V2] ARM: dts: omap36xx: Remove turbo mode for 1GHz variants | expand

Commit Message

Adam Ford Jan. 9, 2021, 5:01 p.m. UTC
Previously, the 1GHz variants were marked as a turbo,
because that variant has reduced thermal operating range.

Now that the thermal throttling is in place, it should be
safe to remove the turbo-mode from the 1GHz variants, because
the CPU will automatically slow if the thermal limit is reached.

Signed-off-by: Adam Ford <aford173@gmail.com>
---
V2:  The orignal patch had the wrong file added. Add the omap36xx.dtsi

Comments

Tony Lindgren Jan. 26, 2021, 11:20 a.m. UTC | #1
* Adam Ford <aford173@gmail.com> [210109 19:01]:
> Previously, the 1GHz variants were marked as a turbo,
> because that variant has reduced thermal operating range.
> 
> Now that the thermal throttling is in place, it should be
> safe to remove the turbo-mode from the 1GHz variants, because
> the CPU will automatically slow if the thermal limit is reached.

Thanks applying into omap-for-v5.12/dt.

Tony
Andreas Kemnade Oct. 1, 2021, 7:54 a.m. UTC | #2
On Sat,  9 Jan 2021 11:01:03 -0600
Adam Ford <aford173@gmail.com> wrote:

> Previously, the 1GHz variants were marked as a turbo,
> because that variant has reduced thermal operating range.
> 
> Now that the thermal throttling is in place, it should be
> safe to remove the turbo-mode from the 1GHz variants, because
> the CPU will automatically slow if the thermal limit is reached.
> 
> Signed-off-by: Adam Ford <aford173@gmail.com>
> ---
> V2:  The orignal patch had the wrong file added. Add the omap36xx.dtsi
> 
hmm, I somehow expected that there is a revert of this thing going
through. But now, the turbo-mode is still missing and I understood the
revert is only in Nikolaus' trees. The 1Ghz mode was working for some
time but does not anymore. Is it just me or do others also have the
same problems?

Regards,
Andreas

> diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
> index 05fe5ed127b0..20844dbc002e 100644
> --- a/arch/arm/boot/dts/omap36xx.dtsi
> +++ b/arch/arm/boot/dts/omap36xx.dtsi
> @@ -72,7 +72,6 @@ opp1g-1000000000 {
>  					 <1375000 1375000 1375000>;
>  			/* only on am/dm37x with speed-binned bit set */
>  			opp-supported-hw = <0xffffffff 2>;
> -			turbo-mode;
>  		};
>  	};
>
H. Nikolaus Schaller Oct. 1, 2021, 9:59 a.m. UTC | #3
> Am 01.10.2021 um 09:54 schrieb Andreas Kemnade <andreas@kemnade.info>:
> 
> On Sat,  9 Jan 2021 11:01:03 -0600
> Adam Ford <aford173@gmail.com> wrote:
> 
>> Previously, the 1GHz variants were marked as a turbo,
>> because that variant has reduced thermal operating range.
>> 
>> Now that the thermal throttling is in place, it should be
>> safe to remove the turbo-mode from the 1GHz variants, because
>> the CPU will automatically slow if the thermal limit is reached.
>> 
>> Signed-off-by: Adam Ford <aford173@gmail.com>
>> ---
>> V2:  The orignal patch had the wrong file added. Add the omap36xx.dtsi
>> 
> hmm, I somehow expected that there is a revert of this thing going
> through. But now, the turbo-mode is still missing

tagging by turbo-mode means the OPP is *disabled* by default and
needs to be enabled actively.

> and I understood the
> revert is only in Nikolaus' trees.

It is just a revert for the gta04a5 because I think it is the only board
which is affected (maybe it would need SmartReflex in operation to
fine tune the OPPs compared to the generic table). Therefore I have
a patch which adds turbo-mode to the gta04a5.dts

> The 1Ghz mode was working for some
> time but does not anymore. Is it just me or do others also have the
> same problems?

That would be interesting to know.

BR,
NIkolaus

> 
> 
>> diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
>> index 05fe5ed127b0..20844dbc002e 100644
>> --- a/arch/arm/boot/dts/omap36xx.dtsi
>> +++ b/arch/arm/boot/dts/omap36xx.dtsi
>> @@ -72,7 +72,6 @@ opp1g-1000000000 {
>> 					 <1375000 1375000 1375000>;
>> 			/* only on am/dm37x with speed-binned bit set */
>> 			opp-supported-hw = <0xffffffff 2>;
>> -			turbo-mode;
>> 		};
>> 	};
>> 
>
Adam Ford Oct. 2, 2021, 12:12 p.m. UTC | #4
On Fri, Oct 1, 2021 at 4:59 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
>
>
> > Am 01.10.2021 um 09:54 schrieb Andreas Kemnade <andreas@kemnade.info>:
> >
> > On Sat,  9 Jan 2021 11:01:03 -0600
> > Adam Ford <aford173@gmail.com> wrote:
> >
> >> Previously, the 1GHz variants were marked as a turbo,
> >> because that variant has reduced thermal operating range.
> >>
> >> Now that the thermal throttling is in place, it should be
> >> safe to remove the turbo-mode from the 1GHz variants, because
> >> the CPU will automatically slow if the thermal limit is reached.
> >>
> >> Signed-off-by: Adam Ford <aford173@gmail.com>
> >> ---
> >> V2:  The orignal patch had the wrong file added. Add the omap36xx.dtsi
> >>
> > hmm, I somehow expected that there is a revert of this thing going
> > through. But now, the turbo-mode is still missing
>
> tagging by turbo-mode means the OPP is *disabled* by default and
> needs to be enabled actively.
>
> > and I understood the
> > revert is only in Nikolaus' trees.
>
> It is just a revert for the gta04a5 because I think it is the only board
> which is affected (maybe it would need SmartReflex in operation to
> fine tune the OPPs compared to the generic table). Therefore I have
> a patch which adds turbo-mode to the gta04a5.dts
>
> > The 1Ghz mode was working for some
> > time but does not anymore. Is it just me or do others also have the
> > same problems?
>
> That would be interesting to know.
>

What version are you seeing the break?  It's working for me on 5.15.y branch

# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
300000 600000 800000 1000000
# uname -a
Linux buildroot 5.14.9-00260-g70248e7b378b-dirty #1 SMP Sat Oct 2
06:56:02 CDT 2021 armv7l GNU/Linux
#

adam


> BR,
> NIkolaus
>
> >
> >
> >> diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
> >> index 05fe5ed127b0..20844dbc002e 100644
> >> --- a/arch/arm/boot/dts/omap36xx.dtsi
> >> +++ b/arch/arm/boot/dts/omap36xx.dtsi
> >> @@ -72,7 +72,6 @@ opp1g-1000000000 {
> >>                                       <1375000 1375000 1375000>;
> >>                      /* only on am/dm37x with speed-binned bit set */
> >>                      opp-supported-hw = <0xffffffff 2>;
> >> -                    turbo-mode;
> >>              };
> >>      };
> >>
> >
>
Andreas Kemnade Oct. 7, 2021, 6 p.m. UTC | #5
On Sat, 2 Oct 2021 07:12:05 -0500
Adam Ford <aford173@gmail.com> wrote:

> On Fri, Oct 1, 2021 at 4:59 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:
> >
> >
> >  
> > > Am 01.10.2021 um 09:54 schrieb Andreas Kemnade <andreas@kemnade.info>:
> > >
> > > On Sat,  9 Jan 2021 11:01:03 -0600
> > > Adam Ford <aford173@gmail.com> wrote:
> > >  
> > >> Previously, the 1GHz variants were marked as a turbo,
> > >> because that variant has reduced thermal operating range.
> > >>
> > >> Now that the thermal throttling is in place, it should be
> > >> safe to remove the turbo-mode from the 1GHz variants, because
> > >> the CPU will automatically slow if the thermal limit is reached.
> > >>
> > >> Signed-off-by: Adam Ford <aford173@gmail.com>
> > >> ---
> > >> V2:  The orignal patch had the wrong file added. Add the omap36xx.dtsi
> > >>  
> > > hmm, I somehow expected that there is a revert of this thing going
> > > through. But now, the turbo-mode is still missing  
> >
> > tagging by turbo-mode means the OPP is *disabled* by default and
> > needs to be enabled actively.
> >  
> > > and I understood the
> > > revert is only in Nikolaus' trees.  
> >
> > It is just a revert for the gta04a5 because I think it is the only board
> > which is affected (maybe it would need SmartReflex in operation to
> > fine tune the OPPs compared to the generic table). Therefore I have
> > a patch which adds turbo-mode to the gta04a5.dts
> >  
> > > The 1Ghz mode was working for some
> > > time but does not anymore. Is it just me or do others also have the
> > > same problems?  
> >
> > That would be interesting to know.
> >  
> 
> What version are you seeing the break?  It's working for me on 5.15.y branch
> 
> # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
> 300000 600000 800000 1000000
> # uname -a
> Linux buildroot 5.14.9-00260-g70248e7b378b-dirty #1 SMP Sat Oct 2
> 06:56:02 CDT 2021 armv7l GNU/Linux
> #
> 

I see this one: I remember there was also a discussion about proper
handling of that but I do not remember the final result:

Author: H. Nikolaus Schaller <hns@goldelico.com>
Date:   Mon Dec 2 22:10:55 2019 +0100

    Revert "ARM: OMAP2+: Fix warnings with broken omap2_set_init_voltage()"
    
    This reverts commit cf395f7ddb9ebc6b2d28d83b53d18aa4e7c19701.
    
    This patch is in conflict with 1GHz OPP.




commit ae44b701fb6afb2be62defff590531e3b0632772
Author: H. Nikolaus Schaller <hns@goldelico.com>
Date:   Sat Apr 10 16:59:53 2021 +0200

    ARM: DTS: gta04a5: disable 1GHz OPP again because it is not reliable
    
    To enable on a running system:
    
    echo 1 >/sys/devices/system/cpu/cpufreq/boost
    
    The symptom can be spurious hangs and virtual paging error,
    kernel panics and strange things.

on top of 5.13-rcX in Nikolaus trees.

Regards,
Andreas
diff mbox series

Patch

diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 05fe5ed127b0..20844dbc002e 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -72,7 +72,6 @@  opp1g-1000000000 {
 					 <1375000 1375000 1375000>;
 			/* only on am/dm37x with speed-binned bit set */
 			opp-supported-hw = <0xffffffff 2>;
-			turbo-mode;
 		};
 	};