Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1977031imm; Thu, 14 Jun 2018 06:57:31 -0700 (PDT) X-Google-Smtp-Source: ADUXVKL6UiEzpT+9aDViNqfrNwSOLtKsPeFO4KfX1NBTey0LFKWoASY3qiRXnzS3JCHMeFfFhqUf X-Received: by 2002:a63:7d1b:: with SMTP id y27-v6mr2412193pgc.418.1528984651434; Thu, 14 Jun 2018 06:57:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528984651; cv=none; d=google.com; s=arc-20160816; b=kiW1pA0NxunyKFHv7/uvQ+7KEXxnGi9DJK6TDcEa3E8jWHi3nsElTYj2gb6dcWe7eM RkiGOrkLO2OvozRfBTqryXzwO8a9OUfE6nZQT5mpsCSof+cqvw/y719PdC0WMIqKWisu nanakDoXVNpc/E/XoT4bCUUirnoAIuP7dZPpVWgitnX+6mj+LgERC21QQPnLvc3CKspi 2mYJBtpCz4/js/SqZYZnCbkNJaDlvbWnkhmT3X7NyCfpNDeEfjIepRgQOTDO36rg0/YP bhs+sFlNEW5FYAkhHx+9HtX2Kpwc9Bfy3hXDz99QGCb/q6XHaLuwsibfNPnkQzl/PymX GK2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=wLUjZCN4B/yAE6WhhIqjVPFbIiCEpd6QAFRryBTmi74=; b=IcrvbQDMQoeillGZWpFKSfqe4U89ct93ERK/FpMNPte7n/0ViHdf6LmuLudgL3aeJd Vn3KRvZ2qpEP08bJM/2n7GmIaBbx5eioUWSzAM/rPIzxzFlgk5dPDp3SVtsH9Nd6CJcs hPf3l12SQe7e6wu6aleF5k7/4RubSpGRtgsfl5trnbdcwye5cKi5jq8Pw8hupiYhUR0z B5VKwn+FN6JuA6HU5bNhJys34WwsO2x8YSpv8qda2AOUOia+RqJlTKxUA/beuqa35zbv 1AY4g1LDxrEn/M4B2ug72CFq4ndRxD4kASaTK07T8NFXUl7wmk04cOctdQiNttSo2fyh eVHQ== 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; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o3-v6si4546551pgr.521.2018.06.14.06.57.16; Thu, 14 Jun 2018 06:57:31 -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; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936047AbeFNN4k (ORCPT + 99 others); Thu, 14 Jun 2018 09:56:40 -0400 Received: from mga05.intel.com ([192.55.52.43]:55499 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755208AbeFNN4j (ORCPT ); Thu, 14 Jun 2018 09:56:39 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2018 06:56:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,222,1526367600"; d="scan'208";a="63152194" Received: from mucrsa0015.imu.intel.com ([10.62.163.98]) by fmsmga004.fm.intel.com with ESMTP; 14 Jun 2018 06:56:37 -0700 From: Waldemar Rymarkiewicz To: Viresh Kumar , Nishanth Menon , Stephen Boyd Cc: Waldemar Rymarkiewicz , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] PM / OPP: Update voltage in case freq == old_freq Date: Thu, 14 Jun 2018 15:56:08 +0200 Message-Id: <20180614135609.20574-1-waldemar.rymarkiewicz@gmail.com> X-Mailer: git-send-email 2.10.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Signed-off-by: Waldemar Rymarkiewicz --- drivers/opp/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/opp/core.c b/drivers/opp/core.c index ab2f3fe..31ff03d 100644 --- a/drivers/opp/core.c +++ b/drivers/opp/core.c @@ -598,7 +598,7 @@ static int _generic_set_opp_regulator(const struct opp_table *opp_table, } /* 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; -- 2.10.1