From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-22.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 409BAC07E96 for ; Thu, 8 Jul 2021 14:34:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 293766146E for ; Thu, 8 Jul 2021 14:34:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231756AbhGHOhg (ORCPT ); Thu, 8 Jul 2021 10:37:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:41542 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229738AbhGHOhg (ORCPT ); Thu, 8 Jul 2021 10:37:36 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id F091561447; Thu, 8 Jul 2021 14:34:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1625754894; bh=P4PBX+GAQy0bO8fw85gOwG3PJ2Psj8KDGEnKC6hNrTc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=r/aMWZUU4sxAM6tQacQmFtX8vgQR7dO0Il1mCuRHlKhPYHxcTsuUjJmEtFR9xlISe m3fYl0wcNBVsaH5YthbOHdwHFOWJvrF6vDxZqGzmyBSEoKlMWtefyP9bgsWUMfTY3h q5s92fhxR/JzIc/rdTHqF7C4JNI3UNvSCY9w9vfJkOxxTJi9IEHqqL8bg25i4TtHVO s9BJninc4SnHHcqOvO3Ou0KIGL9ZgLJC7M4eIqM3K4KDZLwns0Z4a3q2riCrX/dHVP tUeObXiOu8KwIvvMVd4KRdh8adZC53fkl2T38anOBYJkftvSZ+UQRVRPXz9bLsV+hX ULhBo625NKYGA== Received: by pali.im (Postfix) id 3747F7B5; Thu, 8 Jul 2021 16:34:51 +0200 (CEST) Date: Thu, 8 Jul 2021 16:34:51 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Konstantin Porotchkin , Nadav Haklai , Ken Ma , Victor Gu , Jason Hung Cc: Marek =?utf-8?B?QmVow7pu?= , Viresh Kumar , Gregory CLEMENT , Robert Marko , Tomasz Maciej Nowak , Anders Trier Olesen , Philip Soares , linux-pm@vger.kernel.org, Sebastian Hesselbarth , linux-arm-kernel@lists.infradead.org, nnet Subject: Re: [PATCH v2] cpufreq: armada-37xx: forbid cpufreq for 1.2 GHz variant Message-ID: <20210708143451.4htvdop4zvjufrq6@pali> References: <20210630135942.29730-1-kabel@kernel.org> <20210630225601.6372-1-kabel@kernel.org> <20210702163035.nmb5pniwpqtmaz4b@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210702163035.nmb5pniwpqtmaz4b@pali> User-Agent: NeoMutt/20180716 Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Konstantin, Nadav, Ken, Victor, Jason: This issue is pretty serious, CPU on 1.2GHz A3720 is crashing. Could you please look at it? On Friday 02 July 2021 18:30:35 Pali Rohár wrote: > +Jason from GlobalScale as this issue affects GlobalScale Espressobin Ultra and V7 1.2 GHz boards. > > On Thursday 01 July 2021 00:56:01 Marek Behún wrote: > > The 1.2 GHz variant of the Armada 3720 SOC is unstable with DVFS: when > > the SOC boots, the WTMI firmware sets clocks and AVS values that work > > correctly with 1.2 GHz CPU frequency, but random crashes occur once > > cpufreq driver starts scaling. > > > > We do not know currently what is the reason: > > - it may be that the voltage value for L0 for 1.2 GHz variant provided > > by the vendor in the OTP is simply incorrect when scaling is used, > > - it may be that some delay is needed somewhere, > > - it may be something else. > > > > The most sane solution now seems to be to simply forbid the cpufreq > > driver on 1.2 GHz variant. > > > > Signed-off-by: Marek Behún > > Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx") > > --- > > If someone from Marvell could look into this, it would be great since > > basically 1.2 GHz variant cannot scale, which is a feature that was > > claimed to be supported by the SOC. > > > > Ken Ma / Victor Gu, you have worked on commit > > https://github.com/MarvellEmbeddedProcessors/linux-marvell/commit/d6719fdc2b3cac58064f41b531f86993c919aa9a > > in linux-marvell. > > Your patch takes away the 1202 mV constant for 1.2 GHz base CPU > > frequency and instead adds code that computes the voltages from the > > voltage found in L0 AVS register (which is filled in by WTMI firmware). > > > > Do you know why the code does not work correctly for some 1.2 GHz > > boards? Do we need to force the L0 voltage to 1202 mV if it is lower, > > or something? > > --- > > drivers/cpufreq/armada-37xx-cpufreq.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c b/drivers/cpufreq/armada-37xx-cpufreq.c > > index 3fc98a3ffd91..c10fc33b29b1 100644 > > --- a/drivers/cpufreq/armada-37xx-cpufreq.c > > +++ b/drivers/cpufreq/armada-37xx-cpufreq.c > > @@ -104,7 +104,11 @@ struct armada_37xx_dvfs { > > }; > > > > static struct armada_37xx_dvfs armada_37xx_dvfs[] = { > > - {.cpu_freq_max = 1200*1000*1000, .divider = {1, 2, 4, 6} }, > > + /* > > + * The cpufreq scaling for 1.2 GHz variant of the SOC is currently > > + * unstable because we do not know how to configure it properly. > > + */ > > + /* {.cpu_freq_max = 1200*1000*1000, .divider = {1, 2, 4, 6} }, */ > > {.cpu_freq_max = 1000*1000*1000, .divider = {1, 2, 4, 5} }, > > {.cpu_freq_max = 800*1000*1000, .divider = {1, 2, 3, 4} }, > > {.cpu_freq_max = 600*1000*1000, .divider = {2, 4, 5, 6} }, > > -- > > 2.31.1 > >