Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp164929rwl; Sat, 24 Dec 2022 16:48:36 -0800 (PST) X-Google-Smtp-Source: AMrXdXuemMmFcgCte+o6KNpRjvPh7cFrPX8MV4JQ+Q9XPI6MM1N1PB3PgIj1IUPxIZWOp1/oe0t4 X-Received: by 2002:a17:906:1c59:b0:7bb:af66:f38c with SMTP id l25-20020a1709061c5900b007bbaf66f38cmr12188496ejg.10.1671929315923; Sat, 24 Dec 2022 16:48:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671929315; cv=none; d=google.com; s=arc-20160816; b=S2f1091hMDkTCEYSTJ9t5Wo+6hVfaE+EQsFPa1FAYQ+upzA5J2ZBHw9Du4myNNv/Hj BariX5SZ+mgpwg1E/dHL+JTEnTyno5xOvef+xWS+BXkgk96IrYR55Ux4NpgkZZXnVxgT YaZxRB6l5K7a+G62bKXGtmFIo0qbP46wbscJW2shpt3i5QW+shsPzIKkPrnmslmwcfxE vfzcfYPrv8PerNygIC2QBGkjiBVwg9LMMVGqKV2xDG32M02OZp67lpg0shnqcF463WC0 fvA6cHjf3yuVxMGbxUBkEczkrJZyQgfcWl+7p/tAC1QSqRcZy29CBdR49+e6fxCWHS8W v6ug== 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:dkim-signature; bh=ciyiqFZ66+rfNdupX3ADn0rA2S5orkXK/DKGrAKAWHs=; b=m5f7eneD+tMMk/nB9fUCthPkIWaMXE+Hyr+7hsBj3A2wolM67J+KZ40MENq78D5M2m Oz58WKwKBaYjofEDHsJ5m57is06P2BLT+pzKvecfQqGoK6w8QVTGk9+ZOUeSN9yxFkTi pc6mga7llALyHxzn7dIfCubRWCkqAgQlPixdMgmnTpLhoNILkV6eMrrnSHY4i2ly/Pk9 ddoMWylLirBTEj70yA/LRBtG0LLkFR6uKfhDE0HJZSFm2zJ3qT2NXqRTHLsKCfLVdPwk CiUxcc+QiOZlfB44Tpp2Kra3r//pdilvy9kzlr/tDEf5nKfj6ASMpUH4e098ZpOr/yO6 DS4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=elI4GEBt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hw20-20020a170907a0d400b007c0fa2e0fa1si4611776ejc.888.2022.12.24.16.48.13; Sat, 24 Dec 2022 16:48:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=elI4GEBt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230186AbiLYA2X (ORCPT + 66 others); Sat, 24 Dec 2022 19:28:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229445AbiLYA2V (ORCPT ); Sat, 24 Dec 2022 19:28:21 -0500 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B797E658F; Sat, 24 Dec 2022 16:28:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1671928100; x=1703464100; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=uNm9/E9vQwOQhQmRGADmicSeDE6R/5EWg07gbn3dlB4=; b=elI4GEBtrmlcZZ1lkvMjwfk/V6MsBQngM63bUnkEtfrfGEOpROE38ZV8 lCBgpE923OvBo7pzaKj58Xkxnl/WQNB4wG94lLrhhNlgqxFRF30jzGdiM VOlE8qZi0k4ToV5SVETjLCs10VkWMW2N70YkjpPc2LBZLAxYIjNP4jC4l CTHwTTQxKp4T6y81JemY/FCU9LifQbeYRWJOzolKcips8bQd1LoLMLQ6q Ju3DT5R4GmX1F8WUw6pgRq7BGIj5SEs1wluY7tYS1genOVlL9nIVp8whc DXQ7G9I9u1RzG8oXoIis31XPI0Gjc0FeiV1TDRD0t6/wmuhgFnQkox3KH Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10571"; a="319158882" X-IronPort-AV: E=Sophos;i="5.96,272,1665471600"; d="scan'208";a="319158882" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Dec 2022 16:28:20 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10571"; a="654475609" X-IronPort-AV: E=Sophos;i="5.96,272,1665471600"; d="scan'208";a="654475609" Received: from spandruv-desk.jf.intel.com ([10.54.75.8]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Dec 2022 16:28:20 -0800 Message-ID: <8e2cc66f7dadcfb04099aac7c4eef0b02075c91b.camel@linux.intel.com> Subject: Re: [PATCH 0/2] intel_pstate: fix turbo not being used after a processor is rebooted From: srinivas pandruvada To: Pratyush Yadav Cc: linux-pm@vger.kernel.org, "Rafael J. Wysocki" , Len Brown , Viresh Kumar , Robert Moore , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, devel@acpica.org Date: Sat, 24 Dec 2022 16:28:19 -0800 In-Reply-To: <2ed9702b67832e3e33ef352808124980206c1e95.camel@linux.intel.com> References: <20221221155203.11347-1-ptyadav@amazon.de> <72bcd14eef038ec9181d30b3d196b0a872f47ccb.camel@linux.intel.com> <2ed9702b67832e3e33ef352808124980206c1e95.camel@linux.intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2022-12-23 at 10:10 -0800, srinivas pandruvada wrote: > Hi Pratyush, > > On Thu, 2022-12-22 at 11:39 +0100, Pratyush Yadav wrote: > > > > Hi Srinivas, > > > > On Wed, Dec 21 2022, srinivas pandruvada wrote: > > > On Wed, 2022-12-21 at 16:52 +0100, Pratyush Yadav wrote: > > > > When a processor is brought offline and online again, it is > > > > unable to > > > > use Turbo mode because the _PSS table does not contain the whole > > > > turbo > > > > frequency range, but only +1 MHz above the max non-turbo > > > > frequency. > > > > This > > > > causes problems when ACPI processor driver tries to set frequency > > > > constraints. See patch 2 for more details. > > > > > I can reproduce on a Broadwell server platform. But not on a client > system with acpi_ppc usage. > > Need to check what change broke this. When PPC limits enforcement changed to PM QOS, this broke. Previously acpi_processor_get_platform_limit() was not enforcing any limits. It was just setting variable. So any update done after acpi_register_performance_state() call to pr->performance- >states[ppc].core_frequency, was effective. We don't really need to call ret = freq_qos_update_request(&pr->perflib_req, pr->performance->states[ppc].core_frequency * 1000); if the PPC is not changed. When PPC is changed, this gets called again, so then we can call the above function to update cpufreq limit. The below change fixed for me. diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c index 757a98f6d7a2..c6ced89c00dd 100644 --- a/drivers/acpi/processor_perflib.c +++ b/drivers/acpi/processor_perflib.c @@ -75,6 +75,11 @@ static int acpi_processor_get_platform_limit(struct acpi_processor *pr) pr_debug("CPU %d: _PPC is %d - frequency %s limited\n", pr->id, (int)ppc, ppc ? "" : "not"); + if (ppc == pr->performance_platform_limit) { + pr_debug("CPU %d: _PPC is %d - frequency not changed\n", pr->id, ppc); + return 0; + } + pr->performance_platform_limit = (int)ppc; if (ppc >= pr->performance->state_count || Thanks, Srinivas > > Thanks, > Srinivas > > > > > > > Thanks, > > > Srinivas > > > > > > > Pratyush Yadav (2): > > > >   acpi: processor: allow fixing up the frequency for a > > > > performance > > > > state > > > >   cpufreq: intel_pstate: use acpi perflib to update turbo > > > > frequency > > > > > > > >  drivers/acpi/processor_perflib.c | 40 > > > > ++++++++++++++++++++++++++++++++ > > > >  drivers/cpufreq/intel_pstate.c   |  5 ++-- > > > >  include/acpi/processor.h         |  2 ++ > > > >  3 files changed, 45 insertions(+), 2 deletions(-) > > > > > > > > -- > > > > 2.38.1 > > > > > > > > > >