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 X-Spam-Level: X-Spam-Status: No, score=-10.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0976C433E6 for ; Tue, 12 Jan 2021 15:01:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6A14C23107 for ; Tue, 12 Jan 2021 15:01:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388991AbhALPBF (ORCPT ); Tue, 12 Jan 2021 10:01:05 -0500 Received: from mga06.intel.com ([134.134.136.31]:48640 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728574AbhALPBE (ORCPT ); Tue, 12 Jan 2021 10:01:04 -0500 IronPort-SDR: bigQfL0RdZSvw+EWQaaSpXiKIKlc/Pa70HSwZzEIOiQ3PQ6mFkC2WuPLYwWwYSXJ3sVVVATmGf ccCxMfc80g6Q== X-IronPort-AV: E=McAfee;i="6000,8403,9861"; a="239592233" X-IronPort-AV: E=Sophos;i="5.79,341,1602572400"; d="scan'208";a="239592233" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2021 07:00:22 -0800 IronPort-SDR: 9X8eWtH59RL9xfctl3owzHGS3bEVAKRfaT8ZCCkLMo6joFK2nyLXZ8olC2Oyl4rU4BQBdKaBl2 U7Sukbtiy/Yg== X-IronPort-AV: E=Sophos;i="5.79,341,1602572400"; d="scan'208";a="381456283" Received: from chenyu-office.sh.intel.com ([10.239.158.173]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2021 07:00:20 -0800 Date: Tue, 12 Jan 2021 23:03:40 +0800 From: Chen Yu To: "Rafael J. Wysocki" Cc: Srinivas Pandruvada , "Rafael J. Wysocki" , Len Brown , Viresh Kumar , Linux PM , Linux Kernel Mailing List Subject: Re: [PATCH][v3] cpufreq: intel_pstate: Get percpu max freq via HWP MSR register if available Message-ID: <20210112150340.GA17152@chenyu-office.sh.intel.com> References: <20210112052127.4557-1-yu.c.chen@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 12, 2021 at 02:52:50PM +0100, Rafael J. Wysocki wrote: > On Tue, Jan 12, 2021 at 6:19 AM Chen Yu wrote: > > > > Currently when turbo is disabled(either by BIOS or by the user), the > > intel_pstate driver reads the max non-turbo frequency from the package-wide > > MSR_PLATFORM_INFO(0xce) register. However on asymmetric platforms it is > > possible in theory that small and big core with HWP enabled might have > > different max non-turbo cpu frequency, because the MSR_HWP_CAPABILITIES > > is percpu scope according to Intel Software Developer Manual. > > > > The turbo max freq is already percpu basis in current code, thus make > > similar change to the max non-turbo frequency as well. > > > > Reported-by: Wendy Wang > > Signed-off-by: Chen Yu > > --- > > v2: Per Srinivas' suggestion, avoid duplicated assignment of max_pstate. > > v3: Per Rafael's suggestion, do not add new argument in intel_pstate_get_hwp_max() > > to avoid redundant local vars. > > Per Srinivas' suggestion, refined the commit log to reflect the 'non-turbo' > > max frequency. > > Looks good now, thanks! > > Is it needed in -stable and if so, which -stable series should it go into? > Yes, I think so, it should be Cc: stable@vger.kernel.org # 4.18+ as the HWP reading turbo frequency was firstly introduced in v4.18-rc2 and it was easier to be applied. BTW, this patch is on top of your previous patch set on intel_pstate clean up: https://patchwork.kernel.org/project/linux-pm/list/?series=410797 thanks, Chenyu