Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2011426imm; Tue, 10 Jul 2018 11:33:43 -0700 (PDT) X-Google-Smtp-Source: AAOMgpe529ETugO1VLT+2YqAym/N0fPCwM9Ok7uqMnvuynCyVb/rNhkhNSnC/NzzovbewWKiMMS3 X-Received: by 2002:a17:902:bd95:: with SMTP id q21-v6mr25451623pls.237.1531247623146; Tue, 10 Jul 2018 11:33:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531247623; cv=none; d=google.com; s=arc-20160816; b=HhMhZ/v3TVPYgWN6ANzRaOZepMR1Um6FbRTeNgIpRTlnTUz3aAE189673+YGbf3uU8 Fbp94KkMPw68zIWE8Dq66U8DOSbKexoTo0EC/Snoj6KdpfFTyfI4ZsUxS6/o09UsztBj xbxW8GYy7ci6sLFMDuaviZ0kwm2Iv3OGLXDIo5k7Iq3Ubua/ktPwloeaiXCpUHnFBwkr llxL+56shk0SETK1YaSRj9doUD7pBR8LAjMoLkiv/d/Kvsnog8REN7cLdEi5aAO4/tN/ eGBxiA1lpVPJ6TdTp2Na+9Y8DYM6fThe3S8wxG74I1yioDZ8DasumznJf57oN1nr3TpX uxog== 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=pLvSnv6d1dPgGZV5qKTXfdRZoOCJoBKHC4Xtj4FfTMw=; b=f1Rt3R4aQfSouTTzi07ni8kOAYIrpFRYE8BeXTQHuiHfvV/0ajKBNd81ctvmiOvXdu YmFGK8oIu3YYORpgL1TCFNii1lJyD1rzUJRuHEkl9rRVslXmvdMjl0Vo5P2kuknAFgzG 8LfAz2Ny5eEfXpePE//jbDAqmcrdlAVZKHaMTRfdzB03HDjnIsYCRkHn+RWgsA/IuSBs +xCtgkv2oxUC9Q1YfcQOSCQM9ib8t8ZEKieeoUVVv33k6WkhfXEvXswvICvdENFa8wl9 0HIQaQJrzMEyntotXk/63BvLunud95McFZlBvLLE2rB5AD3rG3D7MRDrDj7U1YzvwAfj XmzQ== 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 o1-v6si17067968plb.279.2018.07.10.11.33.28; Tue, 10 Jul 2018 11:33:43 -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 S2388466AbeGJSbu (ORCPT + 99 others); Tue, 10 Jul 2018 14:31:50 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:46366 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732845AbeGJSbt (ORCPT ); Tue, 10 Jul 2018 14:31:49 -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 3F61FEE8; Tue, 10 Jul 2018 18:31:37 +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.9 40/52] PM / OPP: Update voltage in case freq == old_freq Date: Tue, 10 Jul 2018 20:25:08 +0200 Message-Id: <20180710182453.043776853@linuxfoundation.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180710182449.285532226@linuxfoundation.org> References: <20180710182449.285532226@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.9-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/base/power/opp/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/base/power/opp/core.c +++ b/drivers/base/power/opp/core.c @@ -651,7 +651,7 @@ int dev_pm_opp_set_rate(struct device *d rcu_read_unlock(); /* Scaling up? Scale voltage before frequency */ - if (freq > old_freq) { + if (freq >= old_freq) { ret = _set_opp_voltage(dev, reg, u_volt, u_volt_min, u_volt_max); if (ret)