Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1040252pxj; Sat, 15 May 2021 01:50:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy6dMMvFwpjJTjNxAToHcLBkDK7sNPWquX+cjHNTGVdLuDfCfJUqT3vM4AfWn8M8He55yka X-Received: by 2002:a02:9f85:: with SMTP id a5mr48321010jam.75.1621068639169; Sat, 15 May 2021 01:50:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621068639; cv=none; d=google.com; s=arc-20160816; b=rDP9tuNwVBHI2nXV8EBpB8yvLrLr1dBE1ici+F1UuHcupBu06zSIf/Pa6m51zSmsvl Sjn1xlzetBl4w3zcotV1sceiEHQumz86x0UQm9t+HJk3FPs6R3FXth3/WUjml7xoF2Du 9Z7yg9E5X9mtI0zj1OGUx8kQv8U5AF+vKF9Kpm4yZWK942wf5vyCcBREJmoG70hvzo47 9P4Sf5KDDkTs7kaDVCmvw/L3iGktdXccDS/v9BZZaRAU0SYq4NPacq3uM9J4B5hdnlwN J8uwqaDnf4JVpPu0yipxL2h5oEzfYmRt3Y6dNOy7LAgfUj80TTrUhT4ebCBcl0F2/bj4 DDZQ== 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 :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=ln1kFv8xAePvQgfYTObX55n7ZBsyTyjiazCZ6zNlnAs=; b=TAv417XAT/xK27kylSMHu8RRRqazuUW4qoMajsUB0oqsgr5++QhllC3tlICu8M+2xo lpEyu7BnvLXlSEvfU+YoZtYyV0CZFJo2aZFtZSLzh+uDz8WbBLZQAcrQPOLC27XryAiF Fkdm3FODp25DsxO767XsXcmbvPLYh2Zinvt2QM99vpEIWfvaPKN996ccuu6m+HDxwp08 rGTji3KQbJNwzP+L244Sg0mSLAX+TGKK3vmUcCGgWD8+z+LndH5BibdyqAy1qQ0h51Qg +iPl6tl37/nmAZhQD8HweLJGR9ms25Zv25m8bYZYGfOLtYs9/YiceA4Mhj9FXGsCixZB M2mA== 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 y11si9413649jat.123.2021.05.15.01.50.27; Sat, 15 May 2021 01:50:39 -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 S230455AbhENUec (ORCPT + 99 others); Fri, 14 May 2021 16:34:32 -0400 Received: from mx2.suse.de ([195.135.220.15]:47668 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229932AbhENUec (ORCPT ); Fri, 14 May 2021 16:34:32 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 40DE9AFCF; Fri, 14 May 2021 20:33:19 +0000 (UTC) Message-ID: <067ee60e47a0350d01f0c3f216c1032818044b36.camel@suse.cz> Subject: Re: [PATCH v2] cpufreq: intel_pstate: Add Icelake servers support in no-HWP mode From: Giovanni Gherdovich To: Doug Smythies Cc: "Rafael J . Wysocki" , Viresh Kumar , Srinivas Pandruvada , Len Brown , Linux PM list , Linux Kernel Mailing List Date: Fri, 14 May 2021 22:33:18 +0200 In-Reply-To: References: <20210513132051.31465-1-ggherdovich@suse.cz> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2021-05-14 at 08:31 -0700, Doug Smythies wrote: > Hi All, > > Can I on-board to this patch or do you want me to submit another? > I want to add COMETLAKE (tested), as below: > > ... Doug Hello Doug! Wait, why you don't want to use HWP? It's such a fantastic technology! :) I'm just teasing you. More seriously: when COMETLAKE is not in that list, can you confirm that if you go into the BIOS config at boot, and disable HWP from there, then intel_pstate does *not* load? Does it say "intel_pstate: CPU model not supported" in the dmesg log? The control may be somewhere around "power mangement" in the BIOS config, and may be called "Enable/disable Intel Speed Shift". I'm asking because I've just checked on two Dell laptops, one Skylake and the other Kabylake, and the menu is there in the BIOS config to disable HWP, but if I disable it... nothing happens. "lscpu" shows all the hwp flags as usual: # lscpu | grep Flags | tr ' ' '\n' | grep hwp hwp hwp_notify hwp_act_window hwp_epp and turbostat gives me: # turbostat -Summary -i 1 : 2>&1 | grep MSR_PM_ENABLE cpu0: MSR_PM_ENABLE: 0x00000001 (HWP) Which is to say, on the Intel client machines I have, the firmware doesn't seem to be able to hide HWP from the OS. Buggy BIOS? Maybe, the fact of the matter is, I wouldn't need to add, say, KABYLAKE to that list, based on my experience. The other side of the issue is that, from my understanding, the preferred/supported way to disable HWP is to boot with intel_pstate=no_hwp, and that list is a sort of "known exceptions" that people really can't live without (it's mostly server CPUs, and mostly because of unfortunate firmware defaults). Otherwise you'd see the entire intel-family.h file in there. Cheers, Giovanni > > On Thu, May 13, 2021 at 6:21 AM Giovanni Gherdovich wrote: > > Users may disable HWP in firmware, in which case intel_pstate wouldn't load > > unless the CPU model is explicitly supported. > > > > Add ICELAKE_X to the list of CPUs that can register intel_pstate while not > > advertising the HWP capability. Without this change, an ICELAKE_X in no-HWP > > mode could only use the acpi_cpufreq frequency scaling driver. > > > > See also commit d8de7a44e11f ("cpufreq: intel_pstate: Add Skylake servers > > support"). > > > > Signed-off-by: Giovanni Gherdovich > > --- > > This replaces https://lore.kernel.org/lkml/20210513075930.22657-1-ggherdovich@suse.cz > > > > drivers/cpufreq/intel_pstate.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > > index f0401064d7aa..28c9733e0dce 100644 > > --- a/drivers/cpufreq/intel_pstate.c > > +++ b/drivers/cpufreq/intel_pstate.c > > @@ -2087,6 +2087,7 @@ static const struct x86_cpu_id intel_pstate_cpu_ids[] = { > > X86_MATCH(ATOM_GOLDMONT, core_funcs), > > X86_MATCH(ATOM_GOLDMONT_PLUS, core_funcs), > > X86_MATCH(SKYLAKE_X, core_funcs), > > + X86_MATCH(ICELAKE_X, core_funcs), > + X86_MATCH(COMETLAKE, core_funcs), > > {} > > }; > > MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids); > > -- > > 2.26.2 > >