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 7A850FA373D for ; Mon, 24 Oct 2022 23:58:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229890AbiJXX6V (ORCPT ); Mon, 24 Oct 2022 19:58:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231146AbiJXX6C (ORCPT ); Mon, 24 Oct 2022 19:58:02 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0DF6D347B57; Mon, 24 Oct 2022 15:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666649690; x=1698185690; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=IpovU0pr5GqNyG1RQY1BOg6p1QwyjDdZAzVeYeoqpcQ=; b=SdBlbZeQKdECKVnMMqoOrJdEMoKXO0cf3IXrb6FZgu/ztduI2hD8kiXD p3MCr9gJTe2FsaiKoE+NYpc7b+VK+OdnUVyoHnmEYuJ9yw6h2/U897t1n IpnhClCcrf/SHY6/jlnH5MoWJXLdupuZuVKm+ZWz+JX6AUgkMX1ziz8Dr 8c0l98S0X5jFr8wlFh86v5yVjaiMeG/7t1/dRMGXRVWTrwJMU/q1xe9ag deDA6JEA9RFv4gXC70RNwzvob9IUgjQaenB9nJ0oilQqD9KsrwdHsHNQO BU/98oveVyMRxpeohG+Miet2hBrGtjC6AOaL1sO18du+JWfAOJiKQFLSj A==; X-IronPort-AV: E=McAfee;i="6500,9779,10510"; a="308627361" X-IronPort-AV: E=Sophos;i="5.95,210,1661842800"; d="scan'208";a="308627361" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2022 15:14:39 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10510"; a="694715326" X-IronPort-AV: E=Sophos;i="5.95,210,1661842800"; d="scan'208";a="694715326" Received: from hossain3-mobl.amr.corp.intel.com (HELO spandruv-desk1.amr.corp.intel.com) ([10.209.39.87]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2022 15:14:37 -0700 Message-ID: <8bbd9bc65622aafd36433dbf0cf81338fde3007a.camel@linux.intel.com> Subject: Re: [PATCH 0/2] cpufreq: intel_pstate: Make HWP calibration work on all hybrid platforms From: srinivas pandruvada To: "Rafael J. Wysocki" , Linux PM Cc: LKML , Len Brown , Linux ACPI Date: Mon, 24 Oct 2022 15:14:36 -0700 In-Reply-To: <2258064.ElGaqSPkdT@kreacher> References: <2258064.ElGaqSPkdT@kreacher> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Mon, 2022-10-24 at 21:18 +0200, Rafael J. Wysocki wrote: > Hi All, > > The HWP calibration in intel_pstate is needed to map HWP performance > levels to > frequencies, which are used in the cpufreq sysfs interface, in a > reliable way. > On all non-hybrid "core" platforms it is sufficient to multiply the > HWP > performance levels by 100000 to obtain the corresponding frequencies, > but on > hybrid ones there is a difference between P-cores and E-cores. > > Previous attempts to make this work were based on using CPPC (and in > particular > the nominal performance values provided by _CPC), but it turns out > that the > CPPC information is not sufficiently reliable for this purpose and > the only > way to do it is to use a hard-coded scaling factors for P-cores and > for E-cores > (which fortunately is the same as in the non-hybrid case).  > Fortunately, the > same scaling factor for P-cores works on all of the hybrid platforms > to date. > > The first patch in the series ensures that all of the CPUs will use > correct > information from MSRs by avoiding the situations in which an MSR > values read > on one CPU will be used for performance scaling of another CPU. > > The second one implements the approach outlined above. > > Please see the changelogs for details. Acked-by: Srinivas Pandruvada Tested-by: Srinivas Pandruvada > > Thanks! > > >