Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp1563894pxb; Fri, 10 Sep 2021 08:37:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzMhzIC6Li5nkGMbR2nqGBchfTh2lauqMxzno2QmlZRlZfMU5zDiZw3ybEVVKFfnjaF3IXi X-Received: by 2002:a92:c211:: with SMTP id j17mr6847532ilo.35.1631288230365; Fri, 10 Sep 2021 08:37:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631288230; cv=none; d=google.com; s=arc-20160816; b=n+cTz10mI97Byq4vcQSqyMQoWlXeIWUogR0H4tn8NQOWgtqZcnoOTd8AIe7rk0tQ2Y PxxmSgiP6Dp1nRWHzpIcmXPfjE021UrGzamb0uZrzFk+Z7yCwfUTXPniC4HLE1x/ulEB Yn8WTjMhxUYFpRnlYe0eTtFxiOjTur4I+ZTz9lgQje+Wix2aJmU+RYft3PnDnhztct2B PcLh97jNCxjx1Sqqf5oD3AZMmvVixnN8uw+9EBYha+2O6yhWkpDife2HEXyi6ccKfadH LDZiCvp0oVgLMIZnJh6IG+oIGq3YfYM3Eq89sXgQEZrL2AIV9CrDpqHpoZM9TxU0zKy4 W1Dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=KnvzNi+rxgycVJiXwuyBHq+TROY+i/0lp8Qo1/L/oj4=; b=yEm+z6VfgaR2SuEIe0k9GGQmCSIaFnSVaknU4uzGo3wR8Rf0hRurbh2b0VpMIM2X4v /xYj5W/P0ALEYbMPW4UCaUi+Jv2NN2NLKehxc9xh2gjxhkBL+6bNIKdP06ORpBKMS3Sv klOBT64kSSHugFyXbg5xEHkdlqpU9O8x8R0M/PpVi2a4aeaSyC3gXWB1ed5bReiVSZ8w 3r5x/eRgmYEfgSILKA73S+4yH9YY7rKGIcZgsRvq4GOX0uaxMLtPPXcUiIS25A9SUdb/ MAzTCOSYNXzV29hCChmI9LDoB8M9K9XVqzEHvTnueGliim0g1Q4lQPsfnfIwFl9bMLZe hzvA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@telus.net header.s=google header.b=f7vwDM02; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=telus.net Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n21si4926599ioh.16.2021.09.10.08.36.56; Fri, 10 Sep 2021 08:37:10 -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; dkim=pass header.i=@telus.net header.s=google header.b=f7vwDM02; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=telus.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234483AbhIJPgZ (ORCPT + 99 others); Fri, 10 Sep 2021 11:36:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232438AbhIJPgY (ORCPT ); Fri, 10 Sep 2021 11:36:24 -0400 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B38AC061756 for ; Fri, 10 Sep 2021 08:35:12 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id i25so889848lfg.6 for ; Fri, 10 Sep 2021 08:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telus.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KnvzNi+rxgycVJiXwuyBHq+TROY+i/0lp8Qo1/L/oj4=; b=f7vwDM02YJYqezAPda9pI/Ba+C+u+2E6w2Q8tGtD4Sg16wjEf9XSYgkk+VjBIcoo90 Pro4xK3pQH+UlvBJFlnPqiOBHem4pxqUbmPwNyhuABqiv8voFNG2ozAU+tQJpHV/QCPB 3dneg5DsbRjeSKuGXdmw5uVT3aCO6GD3GHP8y5aFghHoReTAYMcwRk0awxfYVvGaYjcC XyjOkZJrBRJ6ChWG7iZFDxDEXvxlPb4TzFFLrgO9Ejpr6iEzXY1GnuO4H97hc+J0aOKA 5R5G8gwAs/6cbuGcqHX/0DVag+43oqy+uI/4IS+HxY7pRI8Z4nF6aLkK/EFGiTBNQt+V BSvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KnvzNi+rxgycVJiXwuyBHq+TROY+i/0lp8Qo1/L/oj4=; b=YReG1Q/j0auavw3LvkhJiG+1Yrw4dkGWbDYnfbHNr4841fyAGhcpsmsM6k86A06Q2G W72lyTxf38ZGFEsxNqu2Aebyt0u8R5j3vfrVz46R7f024dPtkpfKi3WFIvkq1nzaBsPi 2uxZkgxCS/BRPn+2ihXNnaA6th4GxRf3+TDnaEbfY2U9wCm3XHwY1jE8bRyjvBrRN6wU SIw2tRFIfy//LO1RWQLYZlyQBlTil6ozHoQTsOJbsULo0cmayE1d+Mgjn4OF7jloU7Mk d5W7U2TtHmQgM/kt7xbyQRy24jURoR6v2Ai3pvtRHUw0OkvF6SLkLUNKdPVCJRz28wMy QAyg== X-Gm-Message-State: AOAM533qgtHHAyf+A+nFXV23zJBJKTOyR2n486Io0G97cTXORlDA5xr/ kTUyNVVyuzPIlTJZdYHlap1EswMYCDSCi0k2iCwO3ILApuw= X-Received: by 2002:a05:6512:4003:: with SMTP id br3mr4352150lfb.465.1631288110669; Fri, 10 Sep 2021 08:35:10 -0700 (PDT) MIME-Version: 1.0 References: <20210909034802.1708-1-dsmythies@telus.net> <223a72d91cfda9b13230e4f8cd6a29f853535277.camel@linux.intel.com> In-Reply-To: From: Doug Smythies Date: Fri, 10 Sep 2021 08:34:59 -0700 Message-ID: Subject: Re: [PATCH] cpufreq: intel_pstate: Override parameters if HWP forced by BIOS To: "Rafael J. Wysocki" Cc: Srinivas Pandruvada , Len Brown , Linux Kernel Mailing List , Linux PM , dsmythies Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 10, 2021 at 4:18 AM Rafael J. Wysocki wrote: > On Fri, Sep 10, 2021 at 5:14 AM Doug Smythies wrote: > > On Thu, Sep 9, 2021 at 10:22 AM Rafael J. Wysocki wrote: > > > On Thu, Sep 9, 2021 at 6:12 PM Rafael J. Wysocki wrote: > > > > On Thu, Sep 9, 2021 at 3:20 PM Doug Smythies wrote: > > > > > On Thu, Sep 9, 2021 at 4:18 AM Rafael J. Wysocki wrote: > > > > > > On Thu, Sep 9, 2021 at 8:52 AM Srinivas Pandruvada > > > > > > wrote: > > > > > > > > > > > > > > On Wed, 2021-09-08 at 20:48 -0700, Doug Smythies wrote: > > > > > > > > If HWP has been already been enabled by BIOS, it may be > > > > > > > > necessary to override some kernel command line parameters. > > > > > > > > Once it has been enabled it requires a reset to be disabled. > > > > > > > > > > > > > > > > Signed-off-by: Doug Smythies > > > > > > > > --- > > > > > > > > drivers/cpufreq/intel_pstate.c | 22 ++++++++++++++++------ > > > > > > > > 1 file changed, 16 insertions(+), 6 deletions(-) > > > > > > > > > > > > > > > > diff --git a/drivers/cpufreq/intel_pstate.c > > > > > > > > b/drivers/cpufreq/intel_pstate.c > > > > > > > > index bb4549959b11..073bae5d4498 100644 > > > > > > > > --- a/drivers/cpufreq/intel_pstate.c > > > > > > > > +++ b/drivers/cpufreq/intel_pstate.c > > > > > > > > @@ -3267,7 +3267,7 @@ static int __init intel_pstate_init(void) > > > > > > > > */ > > > > > > > > if ((!no_hwp && boot_cpu_has(X86_FEATURE_HWP_EPP)) || > > > > > > > > intel_pstate_hwp_is_enabled()) { > > > > > > > > - hwp_active++; > > > > > > > > + hwp_active = 1; > > > > > > > Why this change? > > > > > > > > > > > > I think hwp_active can be changed to bool and then it would make sense > > > > > > to update this line. > > > > > > > > > > > > > > hwp_mode_bdw = id->driver_data; > > > > > > > > intel_pstate.attr = hwp_cpufreq_attrs; > > > > > > > > intel_cpufreq.attr = hwp_cpufreq_attrs; > > > > > > > > @@ -3347,17 +3347,27 @@ device_initcall(intel_pstate_init); > > > > > > > > > > > > > > > > static int __init intel_pstate_setup(char *str) > > > > > > > > { > > > > > > > > + /* > > > > > > > > + * If BIOS is forcing HWP, then parameter > > > > > > > > + * overrides might be needed. Only print > > > > > > > > + * the message once, and regardless of > > > > > > > > + * any overrides. > > > > > > > > + */ > > > > > > > > + if(!hwp_active > > > > > > > This part of code is from early_param, Is it possible that > > > > > > > hwp_active is not 0? > > > > > > > > > > > > Well, it wouldn't matter even if it were nonzero. This check is just > > > > > > pointless anyway. > > > > > > > > > > > > > > && boot_cpu_has(X86_FEATURE_HWP)) > > > > > > > > + if(intel_pstate_hwp_is_enabled()){ > > > > > > > > > > > > This should be > > > > > > > > > > > > if (boot_cpu_has(X86_FEATURE_HWP) && intel_pstate_hwp_is_enabled()) { > > > > > > > > > > Disagree. > > > > > This routine gets executed once per intel_pstate related grub command > > > > > line entry. The purpose of the "if(!hwp_active" part is to prevent the > > > > > printing of the message to the logs multiple times. > > > > > > > > Ah OK. Fair enough. > > > > > > > > You can do all of the checks in one conditional, though. They will be > > > > processed left-to-right anyway. > > > > > > > > But then it would be good to avoid calling > > > > intel_pstate_hwp_is_enabled() multiple times if it returns false. > > > > > > > > And having said all that I'm not sure why you are trying to make > > > > no_hwp depend on !hwp_active? I will not be taken into account anyway > > > > if intel_pstate_hwp_is_enabled() returns 'true'? > > > > > > > > So if no_hwp is covered regardless, you may move the > > > > intel_pstate_hwp_is_enabled() inside the no_load conditional. > > > > > > > > Alternatively, and I would do that, intel_pstate_hwp_is_enabled() > > > > could be evaluated earlier in intel_pstate_init() and if it returned > > > > 'true', both no_load and no_hwp would be disregarded. > > > > > > Something like the attached, for the record. > > > > O.K. and Thanks. > > I was trying to avoid this line getting into the log: > > > > [ 0.000000] intel_pstate: HWP disabled > > > > only to overridden later by, now, these lines: > > > > [ 0.373742] intel_pstate: HWP enabled by BIOS > > [ 0.374177] intel_pstate: Intel P-state driver initializing > > [ 0.375097] intel_pstate: HWP enabled > > > > Let me see if I can go with your suggestion and get to > > what I had hoped to get in the logs. > > It would be sufficient to put the "disabled" printk() after the > "no_hwp" if () statement in intel_pstate_init(). See attached. Agreed, thanks. Yes, I was thinking similar. > BTW, I've changed the message to "HWP not enabled", because that's > what really happens to be precise. Agreed. Good idea. Give me a fews days to create and test a formal patch. I currently have limited access to a computer that doesn't force HWP via BIOS. ... Doug