Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp3020816imm; Sun, 1 Jul 2018 10:27:23 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJ2jzNC9SDwRzWW6xp8FcVpVUoSwqb/66btEvX1eiQMYRpnJNjrqlaHzdE8Y5sbelW0Qn6x X-Received: by 2002:a65:6186:: with SMTP id c6-v6mr18952904pgv.360.1530466043548; Sun, 01 Jul 2018 10:27:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530466043; cv=none; d=google.com; s=arc-20160816; b=cMBpD9U8SEbI4xbDUCTyN+aDOPL1dGFdu45+Df2jPvDMKrMtvhz+86S1AuxiILF0f4 FLy99l6BksiQUELWez3B2r7hh7/j50OEoHSw/JGgqf5xzi0EvcOxNfLY/MHRDVUbBkcY YyR/57WvboF2JkaYBj3Zqc79CcIAAscmKZJey7lIY6IvwsMhHOiXxzg1xKwuHFuA22yo sYMFwT7W2omAhcFsef+99CH51SW0KYVGy7pi6Ou2RcR+9RBGJnHTiOPNPnebJUO3yEC/ LhUZOPilscM1dOSa+6FBFLMnu3xtusp3LwXFhylPCgokruBn7eNLeFb81oqOExT6k1vl 7HCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=GnZaJ5Uwcq4MIIyLJsqMBYelaQrivKz+DcgAl55Eey0=; b=poA7BJ/bnRzgREsg6K1PaFESgSLvhqF3zc42l/UEFe1TJLST/VQgHlwKNiM2xyc/Kb hPycYx/EcMvsIXH79FtAZlM60Ksslo2O3wNoHZaFQki5m0V5IoSgo0HwhKP+/qlUxWbX tF7eEdWLlS1KodzSl4cD3U/GT6uMkg1z7mwN5wcQadfECBXOZFXophBcCU/St/lQh1Ll NZ3pHbgI2evbe5+QAAQtt6WPMS8e4FA3LjgmtWSAHIWJlvjkAEHMihMORzn+PErTB8nJ S+zYPD7ghich7+QZctxtlc9wAQXa6SRVJSQ2v5iRNHUQYG7ATaPraezbQRs3wij9i8Om IpCA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a23-v6si13665803plm.305.2018.07.01.10.27.09; Sun, 01 Jul 2018 10:27:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031455AbeGAQhh (ORCPT + 99 others); Sun, 1 Jul 2018 12:37:37 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:36270 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031397AbeGAQh1 (ORCPT ); Sun, 1 Jul 2018 12:37:27 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 5735FACD; Sun, 1 Jul 2018 16:37:26 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Waldemar Rymarkiewicz , Viresh Kumar Subject: [PATCH 4.17 022/220] PM / OPP: Update voltage in case freq == old_freq Date: Sun, 1 Jul 2018 18:20:46 +0200 Message-Id: <20180701160909.276606362@linuxfoundation.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180701160908.272447118@linuxfoundation.org> References: <20180701160908.272447118@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.17-stable review patch. If anyone has any objections, please let me know. ------------------ From: Waldemar Rymarkiewicz commit c5c2a97b3ac7d1ec19e7cff9e38caca6afefc3de upstream. This commit fixes a rare but possible case when the clk rate is updated without update of the regulator voltage. At boot up, CPUfreq checks if the system is running at the right freq. This is a sanity check in case a bootloader set clk rate that is outside of freq table present with cpufreq core. In such cases system can be unstable so better to change it to a freq that is preset in freq-table. The CPUfreq takes next freq that is >= policy->cur and this is our target_freq that needs to be set now. dev_pm_opp_set_rate(dev, target_freq) checks the target_freq and the old_freq (a current rate). If these are equal it returns early. If not, it searches for OPP (old_opp) that fits best to old_freq (not listed in the table) and updates old_freq (!). Here, we can end up with old_freq = old_opp.rate = target_freq, which is not handled in _generic_set_opp_regulator(). It's supposed to update voltage only when freq > old_freq || freq > old_freq. if (freq > old_freq) { ret = _set_opp_voltage(dev, reg, new_supply); [...] if (freq < old_freq) { ret = _set_opp_voltage(dev, reg, new_supply); if (ret) It results in, no voltage update while clk rate is updated. Example: freq-table = { 1000MHz 1.15V 666MHZ 1.10V 333MHz 1.05V } boot-up-freq = 800MHz # not listed in freq-table freq = target_freq = 1GHz old_freq = 800Mhz old_opp = _find_freq_ceil(opp_table, &old_freq); #(old_freq is modified!) old_freq = 1GHz Fixes: 6a0712f6f199 ("PM / OPP: Add dev_pm_opp_set_rate()") Cc: 4.6+ # v4.6+ Signed-off-by: Waldemar Rymarkiewicz Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman --- drivers/opp/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/opp/core.c +++ b/drivers/opp/core.c @@ -591,7 +591,7 @@ static int _generic_set_opp_regulator(co } /* Scaling up? Scale voltage before frequency */ - if (freq > old_freq) { + if (freq >= old_freq) { ret = _set_opp_voltage(dev, reg, new_supply); if (ret) goto restore_voltage;