Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <3a60384a-b26f-3591-fca9-b10764bd2b24@baylibre.com>
Date:   Fri, 11 Feb 2022 10:25:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: [PATCH v2 2/2] arm64: dts: meson: remove CPU opps below 1GHz for
 SM1 boards
Content-Language: en-US
To:     Marc Zyngier <maz@kernel.org>,
        Christian Hewitt <christianshewitt@gmail.com>
Cc:     Rob Herring <robh+dt@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Kevin Hilman <khilman@baylibre.com>,
        devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org
References: <20220210100638.19130-1-christianshewitt@gmail.com>
 <20220210100638.19130-3-christianshewitt@gmail.com>
 <8211344a481dd40f260106bdd3f03bfb@kernel.org>
From:   Neil Armstrong <narmstrong@baylibre.com>
Organization: Baylibre
In-Reply-To: <8211344a481dd40f260106bdd3f03bfb@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Marc,

On 10/02/2022 11:36, Marc Zyngier wrote:
> On 2022-02-10 10:06, Christian Hewitt wrote:
>> Amlogic SM1 devices experience CPU stalls and random board wedges when
>> the system idles and CPU cores clock down to lower opp points. Recent
>> vendor kernels include a change to remove 100-250MHz and other distro
>> sources also remove the 500/667MHz points. Unless all 100-667Mhz opps
>> are removed or the CPU governor forced to performance stalls are still
>> observed, so let's remove them to improve stability and uptime.
>>
>> Fixes: 3d9e76483049 ("arm64: dts: meson-sm1-sei610: enable DVFS")
>> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
>> ---
>>  arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 20 --------------------
>>  1 file changed, 20 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
>> index 3c07a89bfd27..80737731af3f 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
>> @@ -95,26 +95,6 @@
>>          compatible = "operating-points-v2";
>>          opp-shared;
>>
>> -        opp-100000000 {
>> -            opp-hz = /bits/ 64 <100000000>;
>> -            opp-microvolt = <730000>;
>> -        };
>> -
>> -        opp-250000000 {
>> -            opp-hz = /bits/ 64 <250000000>;
>> -            opp-microvolt = <730000>;
>> -        };
>> -
>> -        opp-500000000 {
>> -            opp-hz = /bits/ 64 <500000000>;
>> -            opp-microvolt = <730000>;
>> -        };
>> -
>> -        opp-667000000 {
>> -            opp-hz = /bits/ 64 <666666666>;
>> -            opp-microvolt = <750000>;
>> -        };
>> -
>>          opp-1000000000 {
>>              opp-hz = /bits/ 64 <1000000000>;
>>              opp-microvolt = <770000>;
> 
> That's not nearly enough. If that's an actual issue, the driver
> should be updated not to use these OPPs, and you can't assume
> that people will just update their DT (mine comes from u-boot,
> and it is unlikely I will update it anytime soon).

The driver is the generic cpufreq and a generic clock driver, we do not
filter out the possible OPP frequencies because the possible freq
is large and depends on the die revision.

I don't see why we should filter out these frequencies so far.

Neil

> 
> Thanks,
> 
>          M.