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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0C19CCA471 for ; Wed, 1 Jun 2022 14:06:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354451AbiFAOGn (ORCPT ); Wed, 1 Jun 2022 10:06:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51892 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355434AbiFAOBj (ORCPT ); Wed, 1 Jun 2022 10:01:39 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D59EB87239; Wed, 1 Jun 2022 06:58:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2BEDFB81AFB; Wed, 1 Jun 2022 13:57:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C7F6C36AF4; Wed, 1 Jun 2022 13:57:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654091829; bh=rwAcKcC1TTyoUSUWY4uS7Xn/Go0skmGw/R7r7MS/DDM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tSH20pBZqhenih5BABvB5kAn+1Vj2KxjALUw5D91kHhPvHuIe4xTJ6ZOKVUkkTQH3 FDsoHkdW1bTfLugJYNWbhEK3d27Tyl55fPT0W0BCxrM1zbh1qYy7Ly9lBNBARpBB9S MyK3/NvNhrFEryuKwz6jCi/CjdNGaG0CXMZgqz5WQlx2ZztT3rg5aWfYwzOm/s+5/4 tWEhecsTSTggCKaIjnPBib/qvmcvSyEPRNZP20q/+yAcFjSZ47btWDgTmGbEFEJuWY OQOaN3AOvMDjxGfbLb9cgpTuapb9aXaDbvi4lKZUhUK/kuWP37iRzjc3kcsb24I6Mi FNLO7daEYq+vA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Viresh Kumar , Rex-BC Chen , Jia-wei Chang , Matthias Brugger , "Rafael J . Wysocki" , Sasha Levin , rafael@kernel.org, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Subject: [PATCH AUTOSEL 5.15 23/37] cpufreq: Avoid unnecessary frequency updates due to mismatch Date: Wed, 1 Jun 2022 09:56:08 -0400 Message-Id: <20220601135622.2003939-23-sashal@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220601135622.2003939-1-sashal@kernel.org> References: <20220601135622.2003939-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Viresh Kumar [ Upstream commit f55ae08c89873e140c7cac2a7fa161d31a0d60cf ] For some platforms, the frequency returned by hardware may be slightly different from what is provided in the frequency table. For example, hardware may return 499 MHz instead of 500 MHz. In such cases it is better to avoid getting into unnecessary frequency updates, as we may end up switching policy->cur between the two and sending unnecessary pre/post update notifications, etc. This patch has chosen allows the hardware frequency and table frequency to deviate by 1 MHz for now, we may want to increase it a bit later on if someone still complains. Reported-by: Rex-BC Chen Signed-off-by: Viresh Kumar Tested-by: Jia-wei Chang Reviewed-by: Matthias Brugger Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin --- drivers/cpufreq/cpufreq.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index eeac6d809229..cddf7e13c232 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -28,6 +28,7 @@ #include #include #include +#include #include static LIST_HEAD(cpufreq_policy_list); @@ -1701,6 +1702,16 @@ static unsigned int cpufreq_verify_current_freq(struct cpufreq_policy *policy, b return new_freq; if (policy->cur != new_freq) { + /* + * For some platforms, the frequency returned by hardware may be + * slightly different from what is provided in the frequency + * table, for example hardware may return 499 MHz instead of 500 + * MHz. In such cases it is better to avoid getting into + * unnecessary frequency updates. + */ + if (abs(policy->cur - new_freq) < HZ_PER_MHZ) + return policy->cur; + cpufreq_out_of_sync(policy, new_freq); if (update) schedule_work(&policy->update); -- 2.35.1