Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp5733918pxu; Thu, 22 Oct 2020 09:41:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwjMP+r6FLmc6OhkFEF/KC9MbuLdbmMP+cODTkjVIWFZHo88MAYUxl6h8cWwBIxkroAUOSL X-Received: by 2002:a17:906:3407:: with SMTP id c7mr2562123ejb.547.1603384897616; Thu, 22 Oct 2020 09:41:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603384897; cv=none; d=google.com; s=arc-20160816; b=sgjxoK6EfiwbPeROSKlgeW3y+wYL2ZW/7XJl8/MufY4nyDPXG+AXEANtIjnZgds41z uFm1FXiIz35oTSsJVCbdfwpq/47f3GR04J/OJsO3Gm6TesefU9RD6POvhdQ9vH2i6RyM jhea7LInvMA4oSaMKzC1tBa19VWPEDnCMTh12hTxTCtRo/PtwZMvTl2v759+Q135cAGk 68ZnV62HoE6cEwbHNSWr8pwY9z3dZDCPbkto03pMRdP7BKxlAvjMXYHFN50gOm6ZK+WQ SHBSGTlTPogjVxAKyijp9G7zax1KLBqOI1wSUDb4lpPE+rCX9MNOeI44C3KatIL3w0+3 uR5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=/Tfgrdyh9ce+irZLYhxcpIywP30zmmMDQ+J0eNtPoPE=; b=rRz//wJ62iOTEb/L3JLhA1CgHNrs3E4rH2vzY5IC7hxQTJoUju7pVBmrzunhCTmc7o 8EE3LQ3ehYCo4jLOwjF7XFCiVBElFwO1hUvs5Fu5BUYIUcj48NTb8l4np514Bx6JArgg cIJ74zu+YVyqlCpyfLvc8vnnLJJgft9duevu9B9oJm3kgX84fK3+C1gbf0au7KWxhzkA EqwNLKNZB0O2mseb5nUa79QcIAIIw6afMTZyabTFaPEAPd/nEp2T/PunyZV3iuJdvdUq dp1lzeGEhuj+yCNMFCTaKnS+AhoDZretbiZf1MnBYpWFYmEZ6/YJbrmAQvsXCBIBnh+v N/tg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y20si1231276ejm.593.2020.10.22.09.41.16; Thu, 22 Oct 2020 09:41:37 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2897715AbgJVL55 (ORCPT + 99 others); Thu, 22 Oct 2020 07:57:57 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:65220 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2897701AbgJVL54 (ORCPT ); Thu, 22 Oct 2020 07:57:56 -0400 Received: from 89-64-87-167.dynamic.chello.pl (89.64.87.167) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.491) id a032c57bee7ada70; Thu, 22 Oct 2020 13:57:54 +0200 From: "Rafael J. Wysocki" To: Linux PM Cc: LKML , Viresh Kumar , Srinivas Pandruvada , Zhang Rui Subject: [PATCH 1/2] cpufreq: intel_pstate: Avoid missing HWP max updates in passive mode Date: Thu, 22 Oct 2020 13:57:02 +0200 Message-ID: <76352140.UXiy1LajID@kreacher> In-Reply-To: <1666263.spd1I39WAV@kreacher> References: <1666263.spd1I39WAV@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafael J. Wysocki If the cpufreq policy max limit is changed when intel_pstate operates in the passive mode with HWP enabled and the "powersave" governor is used on top of it, the HWP max limit is not updated as appropriate. Namely, in the "powersave" governor case, the target P-state is always equal to the policy min limit, so if the latter does not change, the "target_freq == policy->cur" check in __cpufreq_driver_target() is "true" and the "target_pstate != old_pstate" check in intel_cpufreq_update_pstate() is "false", so intel_cpufreq_adjust_hwp() is not invoked to update the HWP Request MSR and the HWP max limit is not updated as a result. To prevent that from occurring, modify __cpufreq_driver_target() to do the "target_freq == policy->cur" check only in the frequency table case and change intel_cpufreq_update_pstate() to do the "target_pstate != old_pstate" check only in the non-HWP case and let intel_cpufreq_adjust_hwp() always run in the HWP case (it will update HWP Request only if the cached value of the register is different from the new one including the limits, so if neither the target P-state value nor the max limit changes, the register write will still be avoided). Fixes: f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled") Reported-by: Zhang Rui Cc: 5.9+ # 5.9+ Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/cpufreq.c | 6 +++--- drivers/cpufreq/intel_pstate.c | 12 +++++------- 2 files changed, 8 insertions(+), 10 deletions(-) Index: linux-pm/drivers/cpufreq/intel_pstate.c =================================================================== --- linux-pm.orig/drivers/cpufreq/intel_pstate.c +++ linux-pm/drivers/cpufreq/intel_pstate.c @@ -2550,14 +2550,12 @@ static int intel_cpufreq_update_pstate(s int old_pstate = cpu->pstate.current_pstate; target_pstate = intel_pstate_prepare_request(cpu, target_pstate); - if (target_pstate != old_pstate) { + if (hwp_active) { + intel_cpufreq_adjust_hwp(cpu, target_pstate, fast_switch); + cpu->pstate.current_pstate = target_pstate; + } else if (target_pstate != old_pstate) { + intel_cpufreq_adjust_perf_ctl(cpu, target_pstate, fast_switch); cpu->pstate.current_pstate = target_pstate; - if (hwp_active) - intel_cpufreq_adjust_hwp(cpu, target_pstate, - fast_switch); - else - intel_cpufreq_adjust_perf_ctl(cpu, target_pstate, - fast_switch); } intel_cpufreq_trace(cpu, fast_switch ? INTEL_PSTATE_TRACE_FAST_SWITCH : Index: linux-pm/drivers/cpufreq/cpufreq.c =================================================================== --- linux-pm.orig/drivers/cpufreq/cpufreq.c +++ linux-pm/drivers/cpufreq/cpufreq.c @@ -2182,6 +2182,9 @@ int __cpufreq_driver_target(struct cpufr pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n", policy->cpu, target_freq, relation, old_target_freq); + if (cpufreq_driver->target) + return cpufreq_driver->target(policy, target_freq, relation); + /* * This might look like a redundant call as we are checking it again * after finding index. But it is left intentionally for cases where @@ -2194,9 +2197,6 @@ int __cpufreq_driver_target(struct cpufr /* Save last value to restore later on errors */ policy->restore_freq = policy->cur; - if (cpufreq_driver->target) - return cpufreq_driver->target(policy, target_freq, relation); - if (!cpufreq_driver->target_index) return -EINVAL;