Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3862808pxb; Mon, 1 Feb 2021 06:38:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJxaynrI6lV0S5KkdGj+d12EHbfQzcpQb0VczyUaAdyj59MhrNN9Aa+TAwDZHvq5vDwDeZai X-Received: by 2002:a50:c04d:: with SMTP id u13mr6704757edd.226.1612190320632; Mon, 01 Feb 2021 06:38:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612190320; cv=none; d=google.com; s=arc-20160816; b=baAv+IJ9uk3GEz+5W883t45bc6E9NOXqo0AIQnohdkGjfSGqeqDne405KIZDQWtLPC 9r2Uk/VkHOEH/i8Sh4W27JuDT2PbM3p6lRBl5E/x0WgjosAdhVu243o5QZzvDicDXz0R WDXsECgfigkypi/PynCJAmVkWQVIRWYk2H+hj3S/tyrU01qJCGTPeebWnhAh+kzleYao n12N8Nn0ET0U8QqcjVF+eU4i4+XV3YORqO9N+g2AvYIiE2yT5lG1afPvGyR5qg76KHCp LtW25EQVj7fcllHy872KNSwagsy5Q4UfaF2BXarbHnFnTWqUTF2fl4mIwUIoishEEIkQ 4UuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=p0y1B4xpVR87SDn57GPRXm1SVNsp6DiLP4/759/Wuh8=; b=anO+eGb4w8NsUsWZ3O+bY1VCO9ioQ0YS8KRYAKyRhUY5zCZRMhtvNm6Umizc7ZrHEC L5MI4psYJIgqNz7tmMsurSXoD4vBeGRKaCab9sc22zI5u/1Zzvk7iuZMIhL3OVEvSUxv CNbsOpnFvgLpFmRBpOzM6VM7yGshNbJIVtpcuMrtL5wvzGjUhq9qS7oMRMMqco9AQNnM OKx49xJDanEKGym7KApMRTRflcXk3sU68teZxNlJplp14cSwZDjVKnKQ6hUwssSUHm7N WpP0dp8c/SA7Ree03P3pP0qudeYOqjVEKZi4/xltMHqnnH5Cd6WM0ia78mpFSMcDyq4U UmLA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=K+gFxd8z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g22si10732898edw.133.2021.02.01.06.38.14; Mon, 01 Feb 2021 06:38:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=K+gFxd8z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231211AbhBAOgf (ORCPT + 99 others); Mon, 1 Feb 2021 09:36:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58290 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229530AbhBAOgD (ORCPT ); Mon, 1 Feb 2021 09:36:03 -0500 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D291FC061786; Mon, 1 Feb 2021 06:35:22 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id hs11so24719935ejc.1; Mon, 01 Feb 2021 06:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=p0y1B4xpVR87SDn57GPRXm1SVNsp6DiLP4/759/Wuh8=; b=K+gFxd8za+oG8OKw/uRdYOGMCOw2HY9GwIFkNWZ7xcPkEIZRMtze+PEmUIzexvr+6m /lKxD9Mo8DvphlsBGkZfh0oGgg0Q5Cg/60ueM/shhQk4DYMhzwgxNvNFfUUlQReqjHf+ 2xja190TvVsxgSJzxjyHZ7t8/HKxr48ucWiTO0PZw77E/l8lbirulVTLItKVcDy9RrXW lf5MNpMo6cR04iBo+AlqwP14StlmS8dW3k5lMY1o+X8VC4TU86YZ2AZc1MwffEY9LsUQ 30jCI9H4J9TsUBfpO1zZZLOIeitQ7xEvFEKDUKM+NjzBhqVYa1uqPgDlbTQKNq9ldYAS fLBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=p0y1B4xpVR87SDn57GPRXm1SVNsp6DiLP4/759/Wuh8=; b=KFDo76rwd13kQ8ZHnQ5SrppE445s1CU947hlWd7QBMmZ0T86s073+ewTpLYtQYCTTc lejJVd/QRpXQic4GXsSyaE6nchWJ8LnFFAvVwnlpWRvVLM4/QZWHKh0oAE49gELhztRm PvTI9B54zjBaczTpWaEikdQINdBuNEVJM270GzkCtGWfqazzA9UBmJ7AUS/JPRmfeED4 rwK2YXXOuq3i+TQ358ptwiCPwVAfeNAYeLVpSgXp/xFNzJ99fp44Gv7aprLwPzJbJWll /fomcckvF3uHfDgqytl5AEpugTDH1Z9fITVfD7HUh9xsNw+rQnCpOAmCRhM++2MOienI JBmg== X-Gm-Message-State: AOAM532D9VV678Xy59u6xPZr3ibr3W9HHFV1knjm/hSF+D0xB86aXhKc ZMIHBLL6f8bswsQfs7uap0YDuIJ0AJju4EHWXfc= X-Received: by 2002:a17:906:2e85:: with SMTP id o5mr6995806eji.238.1612190121269; Mon, 01 Feb 2021 06:35:21 -0800 (PST) Received: from [10.8.0.2] (terefe.re. [5.255.96.200]) by smtp.gmail.com with ESMTPSA id du6sm6377449ejc.78.2021.02.01.06.35.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Feb 2021 06:35:20 -0800 (PST) Subject: Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz To: =?UTF-8?Q?Pali_Roh=c3=a1r?= , Gregory Clement , Andrew Lunn , Michael Turquette , Stephen Boyd , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org Cc: =?UTF-8?Q?Marek_Beh=c3=ban?= , Miquel Raynal , Luka Perkov , Andre Heider , Vladimir Vid , Russell King , =?UTF-8?Q?G=c3=a9rald_Kerma?= , Konstantin Porotchkin References: <20210114124032.12765-1-pali@kernel.org> From: Tomasz Maciej Nowak Message-ID: <0d5518be-9b22-a714-f5f0-72aadc2eebf5@gmail.com> Date: Mon, 1 Feb 2021 15:35:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210114124032.12765-1-pali@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org W dniu 14.01.2021 o 13:40, Pali Rohár pisze: > Hello! > > The armada-37xx-cpufreq driver changes base CPU speed from 1000 MHz to > 800 MHz on EspressoBIN and Turris MOX. The commit message in patch 2/10 > explains why and how can this be discovered. > > That patch 2/10 led us to discover another bug, in the SOC itself, > that causes the CPU to behave weirdly when frequency changes to 1 GHz. > A similar erratum is documented by Marvell but only for systems where > base frequency is 1.2 GHz. > > We've discovered that to make cpufreq scaling stable on Armada 3720 > systems with base frequency 1 GHz, we also have to set voltage levels > for L0 and L1 loads to at least 1108 mV. We were led to this by patch we > found in Marvell kernel fork. Fix is in the patch 4/10. > > https://github.com/MarvellEmbeddedProcessors/linux-marvell/commit/dc33b62c90696afb6adc7dbcc4ebbd48bedec269 > > During fixing this voltage issue for 1 GHz we discovered another bug in > armada-37xx-cpufreq driver that causes CPU instability. Erratum for VDD > stabilization was improperly implemented, details are in patch 6/10. > > This patch series is also available in my git tree in branch a3720-cpufreq-issues: > > https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=a3720-cpufreq-issues > > We have tested this patch series on Espressobin v5 and Turris MOX > boards. If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, > Devel Board, ...) then it will be nice to do an additional tests and > check if instability issues are finally fixed. > > There is a discussion on armbian forum that Espressobin v7 is unstable > when running at 1 GHz and in this thread was also mentioned above > voltage patch from Marvell kernel fork: > > https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/ > > Marek & Pali > > > Marek Behún (3): > arm64: dts: marvell: armada-37xx: add syscon compatible to NB clk node > cpufreq: armada-37xx: Fix setting TBG parent for load levels > clk: mvebu: armada-37xx-periph: remove .set_parent method for CPU PM > clock > > Pali Rohár (7): > cpufreq: armada-37xx: Fix the AVS value for loads L0 and L1 > clk: mvebu: armada-37xx-periph: Fix switching CPU freq from 250 Mhz to > 1 GHz > clk: mvebu: armada-37xx-periph: Fix workaround for switching from L1 > to L0 > cpufreq: armada-37xx: Fix driver cleanup when registration failed > cpufreq: armada-37xx: Fix determining base CPU frequency > cpufreq: armada-37xx: Remove cur_frequency variable > cpufreq: armada-37xx: Fix module unloading Hi. After running this series for three days, the system is stable and the issue with switching frequency doesn't seem to be there anymore. So: Tested-by: Tomasz Maciej Nowak Thanks. > > arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 3 +- > drivers/clk/mvebu/armada-37xx-periph.c | 83 ++++++++------- > drivers/cpufreq/armada-37xx-cpufreq.c | 100 ++++++++++++++----- > 3 files changed, 124 insertions(+), 62 deletions(-) > -- TMN