Message ID | 20231205063537.872834-5-li.meng@amd.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp3246442vqy; Mon, 4 Dec 2023 22:38:48 -0800 (PST) X-Google-Smtp-Source: AGHT+IEvdtW+uC5myGNQHAqjP9fcVva+gsOM2lGcSIpvYMpBtz018q3NT7h6i1rYWUhy7qj7yQD4 X-Received: by 2002:a05:6830:3707:b0:6d7:ed31:b24e with SMTP id bl7-20020a056830370700b006d7ed31b24emr5839104otb.26.1701758328270; Mon, 04 Dec 2023 22:38:48 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1701758328; cv=pass; d=google.com; s=arc-20160816; b=W/GmOLajKncQ2C1IQgnfG2T30Rf/lovfPhxTvyR5Bc1YAsC0cK4vIHKc/+uGiBso6+ MHNxXcMfd4jK1VMg56xnMxoS9LClwNOmFodFwXsKnoV/0vmfW+iTeHqBLco4/wZ3SyAK Gss6gdwQOMepWqavHtqyMpTh5SFhDL11Jbu6v7HhNB7svoq3hKMHabOC7mqXkIMzcnBh hy2QVgU9r2QhpK4ukPKF9UdOWQBbqP9eC+UotgttIP0FHzRfB/JTvHa1DvYv+bcSQF7A 9xa7rg3YasMurUTM4XILpk90rb89knJO6N7fZJet/oBUg509Zm76DVV4NOSp6tpm2N3/ WSsg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Y5Mk/Pmr691XK7NaMy3vWvMLF4PXHaH5/AChBpT75o0=; fh=IDm9gtU7icMEavMADyF4GyYGXiUtLhHagtUq6I41Ngc=; b=U/E6w5wbI7HgI0vWlbRrNxROTDKI84qDaDmhR/LCIkP8UN6RVr+99PrIOKB9JV0Snv 1lrYUWRRopNTLGvBGXa7RIZM5EJeGxitgIuoRQtRRPRyZ+Uo1A2Pv3OTJ6hQnShmW6eF NwJJVoHHmml0qvpkCEicLAL10GaPWxjt7VaqxH2mgp8/8qaGHR4HmOoThb2hR1EzeZCW Zxo+LkLJKyrZ8AhJ62bjMqyv4TATMUXvOVrjOv0bUCJzJcDlhVCcPV8lwhIqTfB4Wcr5 OSn9lvWQ0XFtPxhiFdQMD7AcSZy4d0FhgQmrlYvt82KdecgmspjeGLn/8FiPijEWedMR 7Y0A== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=RCcgVCZp; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id r7-20020a635d07000000b005b7c45c8acasi9034180pgb.238.2023.12.04.22.38.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Dec 2023 22:38:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=RCcgVCZp; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id DE86A80213A0; Mon, 4 Dec 2023 22:38:43 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344466AbjLEGif (ORCPT <rfc822;chrisfriedt@gmail.com> + 99 others); Tue, 5 Dec 2023 01:38:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344428AbjLEGid (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 5 Dec 2023 01:38:33 -0500 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam04on2075.outbound.protection.outlook.com [40.107.101.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 41485FA; Mon, 4 Dec 2023 22:38:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X3GQdh+uSW3faHocWNy4KklZRhulo6Vf8/tofS4cNZz7BOgmPXqR3YaOXLTNVXAXacqESxSCLKXl49N0k1GvaIeUbe6nBO4/wiTVlabJj9xvehIPrV3uzsWOFxS72Baj+ItV2buiwlp2nSYYgKRbkKROv/ulFRWrgFqunF6n18b00+I1vnBAYNsYjTARwpmSOpOtBSOZzlUj3cpsGqgOi72JNyUs7Rs7WeEazF/mec+o9PxOrHbcZTYID0wXB6Wp9JnZcilIlt6agPGv8XT9PFIbMFtgLh3AyhfDePaTaeP3JsixKKBflJj1hUWoFNidaeRG7K/9PG0Pz24mXfXEOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Y5Mk/Pmr691XK7NaMy3vWvMLF4PXHaH5/AChBpT75o0=; b=hYX4zDDB767sM6jbJvnSyv1XTQ+5WPznoX2QpuLtCa9d1iHiz7e5rQG3s7gIgL1X0XZL3YuWL1dphh16ZyBCQIEjLmD+pkcwEc1KH6Q+Kp4AM25nvgWZEFT/LSZP0sd9JYriPoke30G52Rn147C9lzAXRaNbhp31LSpMbjvCQ5Yo0Wno9Ud43Q/qSQe/WFryoJuKwwUg+QVj9NxZavtMmBuCovS7Tdmz2dUOKHO4uQHbfyl4guyI03A69Xw5gZTvM77wNFo4JQFJbEl0rZQWMhx6dMZhpBjcs0y9WCpvxnPLRHeg9JGAV44i2ynHNoYt2N1Ecynxqb+b99YaHTDuaA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=intel.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y5Mk/Pmr691XK7NaMy3vWvMLF4PXHaH5/AChBpT75o0=; b=RCcgVCZp/Di8takhWu53HNlM0E4PZgIR14XfhvGW59+b/qG+hMRomRp4Y1wu1CIxIo4oxj0hXccIjZaQrekvFYflm8o8zA8v0FoCV5W18adqV/lR/oO28t3rJA3gsAaeUow3COim90k1Mn+xPkGSPqnKv2ABJjFszdIjr3cYLRU= Received: from CH0P220CA0019.NAMP220.PROD.OUTLOOK.COM (2603:10b6:610:ef::26) by CH3PR12MB9316.namprd12.prod.outlook.com (2603:10b6:610:1ce::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7046.34; Tue, 5 Dec 2023 06:38:37 +0000 Received: from DS3PEPF000099DB.namprd04.prod.outlook.com (2603:10b6:610:ef:cafe::9a) by CH0P220CA0019.outlook.office365.com (2603:10b6:610:ef::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7046.34 via Frontend Transport; Tue, 5 Dec 2023 06:38:37 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by DS3PEPF000099DB.mail.protection.outlook.com (10.167.17.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7068.20 via Frontend Transport; Tue, 5 Dec 2023 06:38:36 +0000 Received: from jasmine-meng.amd.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.34; Tue, 5 Dec 2023 00:38:08 -0600 From: Meng Li <li.meng@amd.com> To: "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>, Huang Rui <ray.huang@amd.com> CC: <linux-pm@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <x86@kernel.org>, <linux-acpi@vger.kernel.org>, Shuah Khan <skhan@linuxfoundation.org>, <linux-kselftest@vger.kernel.org>, "Nathan Fontenot" <nathan.fontenot@amd.com>, Deepak Sharma <deepak.sharma@amd.com>, Alex Deucher <alexander.deucher@amd.com>, Mario Limonciello <mario.limonciello@amd.com>, Shimmer Huang <shimmer.huang@amd.com>, "Perry Yuan" <Perry.Yuan@amd.com>, Xiaojian Du <Xiaojian.Du@amd.com>, Viresh Kumar <viresh.kumar@linaro.org>, Borislav Petkov <bp@alien8.de>, "Oleksandr Natalenko" <oleksandr@natalenko.name>, Meng Li <li.meng@amd.com>, Perry Yuan <perry.yuan@amd.com> Subject: [PATCH V12 4/7] cpufreq: Add a notification message that the highest perf has changed Date: Tue, 5 Dec 2023 14:35:34 +0800 Message-ID: <20231205063537.872834-5-li.meng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231205063537.872834-1-li.meng@amd.com> References: <20231205063537.872834-1-li.meng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS3PEPF000099DB:EE_|CH3PR12MB9316:EE_ X-MS-Office365-Filtering-Correlation-Id: a566373c-4b6b-4f7f-f900-08dbf55ccf83 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: i9a90ojb7EjoYOtm4M6sBW9Z4jxcGG4YZw/oBRFC1ExXfsaBkR9v06WSQa/fjp+Ih0dKlr8ZTAtqcAe+BvqM+34zxq+mc1bZGsZG1ek5yy1iPhEgOZI2xoLNUJJ0no9F4Ze82K65KFj6l9UG8cCuIYTwxaKpQDPmR7kjpFWlDClHD/wrvmqcalMuxtwt/LjGRJceesvxKvqTkGleJcDRQHsiFkMaXqAxHTo2QmLpg0bgmP6ZQephEOGewhQ/tOMMpTwfwmp7Xedfdt3MwEQKmm2ElOm+BmWOSedpaNAWs7XPRWNXFd5Plkqe41mtFOS6Ir4PwqcGSmuIyLTPsmr5kvvejftF7UF7E1bN1Zq0dgT9J3swXod0X70roFGznQUjyuaDz2VFD2m/yrZLKdlawqcW4Nt8QQ3P7Bb9v0+FcMCrmw7luQ2ydZ+Bfa2bb4Gggeh4dfvqc0xdiTAtxjlDDMxjS3iqKvbua/wc76nPHn/P6Nm5zhKKMKdx/Siq4CEKm6Xvgw2X67AhD1AYHHv+JOYM4L7tjqCftxI3w/GsJk/8A8BcsUOG+WwuZwgDVvKpbQKNr8KODf2r2GB+aEQHuLr2K8zYPbEWT2dYaW2IUjuMQemdqC+TTjzqczPZxYRTAAKsDkis85ctsVOa69lecl2wK8Ko+ZEKe8iYrVc7xdB6ZqZ5qBJTn4cex4ZS7vRtirMcAqjlu3hjqKb43zxYbIYoLs40WRqN4tfur+Ejal+VHBXgcUMzXwzOfJB30gOit3O9hJ6Jp8F13VynpwOOiAImr+Fjz6mlU3boa7fPSrI= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(4636009)(346002)(376002)(39860400002)(396003)(136003)(230922051799003)(82310400011)(1800799012)(64100799003)(451199024)(186009)(40470700004)(46966006)(36840700001)(26005)(478600001)(966005)(83380400001)(336012)(16526019)(47076005)(7696005)(6666004)(356005)(81166007)(426003)(1076003)(40480700001)(82740400003)(36756003)(2616005)(316002)(110136005)(6636002)(54906003)(70586007)(70206006)(36860700001)(5660300002)(4326008)(86362001)(2906002)(8936002)(8676002)(40460700003)(7416002)(41300700001)(15650500001)(226483002)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2023 06:38:36.9604 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a566373c-4b6b-4f7f-f900-08dbf55ccf83 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS3PEPF000099DB.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9316 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Mon, 04 Dec 2023 22:38:44 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784422940801063832 X-GMAIL-MSGID: 1784422940801063832 |
Series |
amd-pstate preferred core
|
|
Commit Message
Meng Li
Dec. 5, 2023, 6:35 a.m. UTC
ACPI 6.5 section 8.4.6.1.1.1 specifies that Notify event 0x85 can be emmitted to cause the the OSPM to re-evaluate the highest performance register. Add support for this event. Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Signed-off-by: Meng Li <li.meng@amd.com> Link: https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#processor-device-notification-values --- drivers/acpi/processor_driver.c | 6 ++++++ drivers/cpufreq/cpufreq.c | 13 +++++++++++++ include/linux/cpufreq.h | 5 +++++ 3 files changed, 24 insertions(+)
Comments
On Tue, Dec 5, 2023 at 7:38 AM Meng Li <li.meng@amd.com> wrote: > > ACPI 6.5 section 8.4.6.1.1.1 specifies that Notify event 0x85 can be > emmitted to cause the the OSPM to re-evaluate the highest performance Typos above. Given the number of iterations of this patch, this is kind of disappointing. > register. Add support for this event. Also it would be nice to describe how this is supposed to work at least roughly, so it is not necessary to reverse-engineer the patch to find out that. > Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> > Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> > Reviewed-by: Huang Rui <ray.huang@amd.com> > Reviewed-by: Perry Yuan <perry.yuan@amd.com> > Signed-off-by: Meng Li <li.meng@amd.com> > Link: https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#processor-device-notification-values > --- > drivers/acpi/processor_driver.c | 6 ++++++ > drivers/cpufreq/cpufreq.c | 13 +++++++++++++ > include/linux/cpufreq.h | 5 +++++ > 3 files changed, 24 insertions(+) > > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c > index 4bd16b3f0781..29b2fb68a35d 100644 > --- a/drivers/acpi/processor_driver.c > +++ b/drivers/acpi/processor_driver.c > @@ -27,6 +27,7 @@ > #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 > #define ACPI_PROCESSOR_NOTIFY_POWER 0x81 > #define ACPI_PROCESSOR_NOTIFY_THROTTLING 0x82 > +#define ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED 0x85 > > MODULE_AUTHOR("Paul Diefenbaugh"); > MODULE_DESCRIPTION("ACPI Processor Driver"); > @@ -83,6 +84,11 @@ static void acpi_processor_notify(acpi_handle handle, u32 event, void *data) > acpi_bus_generate_netlink_event(device->pnp.device_class, > dev_name(&device->dev), event, 0); > break; > + case ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED: > + cpufreq_update_highest_perf(pr->id); And the design appears to be a bit ad-hoc here. Because why does it have anything to do with cpufreq? > + acpi_bus_generate_netlink_event(device->pnp.device_class, > + dev_name(&device->dev), event, 0); > + break; > default: > acpi_handle_debug(handle, "Unsupported event [0x%x]\n", event); > break; > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 934d35f570b7..14a4cbc6dd05 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -2717,6 +2717,19 @@ void cpufreq_update_limits(unsigned int cpu) > } > EXPORT_SYMBOL_GPL(cpufreq_update_limits); > > +/** > + * cpufreq_update_highest_perf - Update highest performance for a given CPU. > + * @cpu: CPU to update the highest performance for. > + * > + * Invoke the driver's ->update_highest_perf callback if present > + */ > +void cpufreq_update_highest_perf(unsigned int cpu) > +{ > + if (cpufreq_driver->update_highest_perf) > + cpufreq_driver->update_highest_perf(cpu); > +} > +EXPORT_SYMBOL_GPL(cpufreq_update_highest_perf); > + > /********************************************************************* > * BOOST * > *********************************************************************/ > diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h > index 1c5ca92a0555..f62257b2a42f 100644 > --- a/include/linux/cpufreq.h > +++ b/include/linux/cpufreq.h > @@ -235,6 +235,7 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu); > void refresh_frequency_limits(struct cpufreq_policy *policy); > void cpufreq_update_policy(unsigned int cpu); > void cpufreq_update_limits(unsigned int cpu); > +void cpufreq_update_highest_perf(unsigned int cpu); > bool have_governor_per_policy(void); > bool cpufreq_supports_freq_invariance(void); > struct kobject *get_governor_parent_kobj(struct cpufreq_policy *policy); > @@ -263,6 +264,7 @@ static inline bool cpufreq_supports_freq_invariance(void) > return false; > } > static inline void disable_cpufreq(void) { } > +static inline void cpufreq_update_highest_perf(unsigned int cpu) { } > #endif > > #ifdef CONFIG_CPU_FREQ_STAT > @@ -380,6 +382,9 @@ struct cpufreq_driver { > /* Called to update policy limits on firmware notifications. */ > void (*update_limits)(unsigned int cpu); > > + /* Called to update highest performance on firmware notifications. */ > + void (*update_highest_perf)(unsigned int cpu); > + > /* optional */ > int (*bios_limit)(int cpu, unsigned int *limit); > > -- > 2.34.1 > >
On Wed, Dec 6, 2023 at 9:58 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Tue, Dec 5, 2023 at 7:38 AM Meng Li <li.meng@amd.com> wrote: > > > > ACPI 6.5 section 8.4.6.1.1.1 specifies that Notify event 0x85 can be > > emmitted to cause the the OSPM to re-evaluate the highest performance > > Typos above. Given the number of iterations of this patch, this is > kind of disappointing. > > > register. Add support for this event. > > Also it would be nice to describe how this is supposed to work at > least roughly, so it is not necessary to reverse-engineer the patch to > find out that. > > > Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> > > Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> > > Reviewed-by: Huang Rui <ray.huang@amd.com> > > Reviewed-by: Perry Yuan <perry.yuan@amd.com> > > Signed-off-by: Meng Li <li.meng@amd.com> > > Link: https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#processor-device-notification-values > > --- > > drivers/acpi/processor_driver.c | 6 ++++++ > > drivers/cpufreq/cpufreq.c | 13 +++++++++++++ > > include/linux/cpufreq.h | 5 +++++ > > 3 files changed, 24 insertions(+) > > > > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c > > index 4bd16b3f0781..29b2fb68a35d 100644 > > --- a/drivers/acpi/processor_driver.c > > +++ b/drivers/acpi/processor_driver.c > > @@ -27,6 +27,7 @@ > > #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 > > #define ACPI_PROCESSOR_NOTIFY_POWER 0x81 > > #define ACPI_PROCESSOR_NOTIFY_THROTTLING 0x82 > > +#define ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED 0x85 > > > > MODULE_AUTHOR("Paul Diefenbaugh"); > > MODULE_DESCRIPTION("ACPI Processor Driver"); > > @@ -83,6 +84,11 @@ static void acpi_processor_notify(acpi_handle handle, u32 event, void *data) > > acpi_bus_generate_netlink_event(device->pnp.device_class, > > dev_name(&device->dev), event, 0); > > break; > > + case ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED: > > + cpufreq_update_highest_perf(pr->id); > > And the design appears to be a bit ad-hoc here. > > Because why does it have anything to do with cpufreq? Well, clearly, cpufreq can be affected by this, but why would it be not affected the same way as in the ACPI_PROCESSOR_NOTIFY_PERFORMANCE case? That is, why isn't cpufreq_update_limits() the right thing to do?
On Wed, Dec 6, 2023 at 10:13 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Wed, Dec 6, 2023 at 9:58 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > On Tue, Dec 5, 2023 at 7:38 AM Meng Li <li.meng@amd.com> wrote: > > > > > > ACPI 6.5 section 8.4.6.1.1.1 specifies that Notify event 0x85 can be > > > emmitted to cause the the OSPM to re-evaluate the highest performance > > > > Typos above. Given the number of iterations of this patch, this is > > kind of disappointing. > > > > > register. Add support for this event. > > > > Also it would be nice to describe how this is supposed to work at > > least roughly, so it is not necessary to reverse-engineer the patch to > > find out that. > > > > > Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> > > > Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> > > > Reviewed-by: Huang Rui <ray.huang@amd.com> > > > Reviewed-by: Perry Yuan <perry.yuan@amd.com> > > > Signed-off-by: Meng Li <li.meng@amd.com> > > > Link: https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#processor-device-notification-values > > > --- > > > drivers/acpi/processor_driver.c | 6 ++++++ > > > drivers/cpufreq/cpufreq.c | 13 +++++++++++++ > > > include/linux/cpufreq.h | 5 +++++ > > > 3 files changed, 24 insertions(+) > > > > > > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c > > > index 4bd16b3f0781..29b2fb68a35d 100644 > > > --- a/drivers/acpi/processor_driver.c > > > +++ b/drivers/acpi/processor_driver.c > > > @@ -27,6 +27,7 @@ > > > #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 > > > #define ACPI_PROCESSOR_NOTIFY_POWER 0x81 > > > #define ACPI_PROCESSOR_NOTIFY_THROTTLING 0x82 > > > +#define ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED 0x85 > > > > > > MODULE_AUTHOR("Paul Diefenbaugh"); > > > MODULE_DESCRIPTION("ACPI Processor Driver"); > > > @@ -83,6 +84,11 @@ static void acpi_processor_notify(acpi_handle handle, u32 event, void *data) > > > acpi_bus_generate_netlink_event(device->pnp.device_class, > > > dev_name(&device->dev), event, 0); > > > break; > > > + case ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED: > > > + cpufreq_update_highest_perf(pr->id); > > > > And the design appears to be a bit ad-hoc here. > > > > Because why does it have anything to do with cpufreq? > > Well, clearly, cpufreq can be affected by this, but why would it be > not affected the same way as in the ACPI_PROCESSOR_NOTIFY_PERFORMANCE > case? > > That is, why isn't cpufreq_update_limits() the right thing to do? Seriously, I'm not going to apply this patch so long as my comments above are not addressed.
[AMD Official Use Only - General] Hi Rafael: > -----Original Message----- > From: Rafael J. Wysocki <rafael@kernel.org> > Sent: Tuesday, December 12, 2023 9:44 PM > To: Meng, Li (Jassmine) <Li.Meng@amd.com> > Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>; Huang, Ray > <Ray.Huang@amd.com>; linux-pm@vger.kernel.org; linux- > kernel@vger.kernel.org; x86@kernel.org; linux-acpi@vger.kernel.org; Shuah > Khan <skhan@linuxfoundation.org>; linux-kselftest@vger.kernel.org; > Fontenot, Nathan <Nathan.Fontenot@amd.com>; Sharma, Deepak > <Deepak.Sharma@amd.com>; Deucher, Alexander > <Alexander.Deucher@amd.com>; Limonciello, Mario > <Mario.Limonciello@amd.com>; Huang, Shimmer > <Shimmer.Huang@amd.com>; Yuan, Perry <Perry.Yuan@amd.com>; Du, > Xiaojian <Xiaojian.Du@amd.com>; Viresh Kumar <viresh.kumar@linaro.org>; > Borislav Petkov <bp@alien8.de>; Oleksandr Natalenko > <oleksandr@natalenko.name> > Subject: Re: [PATCH V12 4/7] cpufreq: Add a notification message that the > highest perf has changed > > Caution: This message originated from an External Source. Use proper > caution when opening attachments, clicking links, or responding. > > > On Wed, Dec 6, 2023 at 10:13 PM Rafael J. Wysocki <rafael@kernel.org> > wrote: > > > > On Wed, Dec 6, 2023 at 9:58 PM Rafael J. Wysocki <rafael@kernel.org> > wrote: > > > > > > On Tue, Dec 5, 2023 at 7:38 AM Meng Li <li.meng@amd.com> wrote: > > > > > > > > ACPI 6.5 section 8.4.6.1.1.1 specifies that Notify event 0x85 can > > > > be emmitted to cause the the OSPM to re-evaluate the highest > > > > performance > > > > > > Typos above. Given the number of iterations of this patch, this is > > > kind of disappointing. > > > > > > > register. Add support for this event. > > > > > > Also it would be nice to describe how this is supposed to work at > > > least roughly, so it is not necessary to reverse-engineer the patch > > > to find out that. > > > > > > > Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> > > > > Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> > > > > Reviewed-by: Huang Rui <ray.huang@amd.com> > > > > Reviewed-by: Perry Yuan <perry.yuan@amd.com> > > > > Signed-off-by: Meng Li <li.meng@amd.com> > > > > Link: > > > > > https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model > > > > .html#processor-device-notification-values > > > > --- > > > > drivers/acpi/processor_driver.c | 6 ++++++ > > > > drivers/cpufreq/cpufreq.c | 13 +++++++++++++ > > > > include/linux/cpufreq.h | 5 +++++ > > > > 3 files changed, 24 insertions(+) > > > > > > > > diff --git a/drivers/acpi/processor_driver.c > > > > b/drivers/acpi/processor_driver.c index 4bd16b3f0781..29b2fb68a35d > > > > 100644 > > > > --- a/drivers/acpi/processor_driver.c > > > > +++ b/drivers/acpi/processor_driver.c > > > > @@ -27,6 +27,7 @@ > > > > #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 > > > > #define ACPI_PROCESSOR_NOTIFY_POWER 0x81 > > > > #define ACPI_PROCESSOR_NOTIFY_THROTTLING 0x82 > > > > +#define ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED 0x85 > > > > > > > > MODULE_AUTHOR("Paul Diefenbaugh"); > MODULE_DESCRIPTION("ACPI > > > > Processor Driver"); @@ -83,6 +84,11 @@ static void > > > > acpi_processor_notify(acpi_handle handle, u32 event, void *data) > > > > acpi_bus_generate_netlink_event(device->pnp.device_class, > > > > dev_name(&device->dev), event, 0); > > > > break; > > > > + case ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED: > > > > + cpufreq_update_highest_perf(pr->id); > > > > > > And the design appears to be a bit ad-hoc here. > > > > > > Because why does it have anything to do with cpufreq? > > > > Well, clearly, cpufreq can be affected by this, but why would it be > > not affected the same way as in the > ACPI_PROCESSOR_NOTIFY_PERFORMANCE > > case? > > > > That is, why isn't cpufreq_update_limits() the right thing to do? > > Seriously, I'm not going to apply this patch so long as my comments above > are not addressed. [Meng, Li (Jassmine)] Sorry for the delayed reply to the email. BIOS/AGESA is responsible to issue the Notify 0x85 to OS that the preferred core has changed. It will only affect the ranking of the preferred core, not the impact policy limits. AMD P-state driver will set the priority of the cores based on the preferred core ranking, and prioritize selecting higher priority core to run the task.
[AMD Official Use Only - General] Hi Rafael: > -----Original Message----- > From: Meng, Li (Jassmine) > Sent: Tuesday, December 26, 2023 4:27 PM > To: Rafael J. Wysocki <rafael@kernel.org> > Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>; Huang, Ray > <Ray.Huang@amd.com>; linux-pm@vger.kernel.org; linux- > kernel@vger.kernel.org; x86@kernel.org; linux-acpi@vger.kernel.org; Shuah > Khan <skhan@linuxfoundation.org>; linux-kselftest@vger.kernel.org; > Fontenot, Nathan <Nathan.Fontenot@amd.com>; Sharma, Deepak > <Deepak.Sharma@amd.com>; Deucher, Alexander > <Alexander.Deucher@amd.com>; Limonciello, Mario > <Mario.Limonciello@amd.com>; Huang, Shimmer > <Shimmer.Huang@amd.com>; Yuan, Perry <Perry.Yuan@amd.com>; Du, > Xiaojian <Xiaojian.Du@amd.com>; Viresh Kumar <viresh.kumar@linaro.org>; > Borislav Petkov <bp@alien8.de>; Oleksandr Natalenko > <oleksandr@natalenko.name> > Subject: RE: [PATCH V12 4/7] cpufreq: Add a notification message that the > highest perf has changed > > Hi Rafael: > > > -----Original Message----- > > From: Rafael J. Wysocki <rafael@kernel.org> > > Sent: Tuesday, December 12, 2023 9:44 PM > > To: Meng, Li (Jassmine) <Li.Meng@amd.com> > > Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>; Huang, Ray > > <Ray.Huang@amd.com>; linux-pm@vger.kernel.org; linux- > > kernel@vger.kernel.org; x86@kernel.org; linux-acpi@vger.kernel.org; > > Shuah Khan <skhan@linuxfoundation.org>; > > linux-kselftest@vger.kernel.org; Fontenot, Nathan > > <Nathan.Fontenot@amd.com>; Sharma, Deepak > <Deepak.Sharma@amd.com>; > > Deucher, Alexander <Alexander.Deucher@amd.com>; Limonciello, Mario > > <Mario.Limonciello@amd.com>; Huang, Shimmer > <Shimmer.Huang@amd.com>; > > Yuan, Perry <Perry.Yuan@amd.com>; Du, Xiaojian > <Xiaojian.Du@amd.com>; > > Viresh Kumar <viresh.kumar@linaro.org>; Borislav Petkov > > <bp@alien8.de>; Oleksandr Natalenko <oleksandr@natalenko.name> > > Subject: Re: [PATCH V12 4/7] cpufreq: Add a notification message that > > the highest perf has changed > > > > Caution: This message originated from an External Source. Use proper > > caution when opening attachments, clicking links, or responding. > > > > > > On Wed, Dec 6, 2023 at 10:13 PM Rafael J. Wysocki <rafael@kernel.org> > > wrote: > > > > > > On Wed, Dec 6, 2023 at 9:58 PM Rafael J. Wysocki <rafael@kernel.org> > > wrote: > > > > > > > > On Tue, Dec 5, 2023 at 7:38 AM Meng Li <li.meng@amd.com> wrote: > > > > > > > > > > ACPI 6.5 section 8.4.6.1.1.1 specifies that Notify event 0x85 > > > > > can be emmitted to cause the the OSPM to re-evaluate the highest > > > > > performance > > > > > > > > Typos above. Given the number of iterations of this patch, this > > > > is kind of disappointing. > > > > > > > > > register. Add support for this event. > > > > > > > > Also it would be nice to describe how this is supposed to work at > > > > least roughly, so it is not necessary to reverse-engineer the > > > > patch to find out that. > > > > > > > > > Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> > > > > > Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> > > > > > Reviewed-by: Huang Rui <ray.huang@amd.com> > > > > > Reviewed-by: Perry Yuan <perry.yuan@amd.com> > > > > > Signed-off-by: Meng Li <li.meng@amd.com> > > > > > Link: > > > > > > > https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model > > > > > .html#processor-device-notification-values > > > > > --- > > > > > drivers/acpi/processor_driver.c | 6 ++++++ > > > > > drivers/cpufreq/cpufreq.c | 13 +++++++++++++ > > > > > include/linux/cpufreq.h | 5 +++++ > > > > > 3 files changed, 24 insertions(+) > > > > > > > > > > diff --git a/drivers/acpi/processor_driver.c > > > > > b/drivers/acpi/processor_driver.c index > > > > > 4bd16b3f0781..29b2fb68a35d > > > > > 100644 > > > > > --- a/drivers/acpi/processor_driver.c > > > > > +++ b/drivers/acpi/processor_driver.c > > > > > @@ -27,6 +27,7 @@ > > > > > #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 > > > > > #define ACPI_PROCESSOR_NOTIFY_POWER 0x81 > > > > > #define ACPI_PROCESSOR_NOTIFY_THROTTLING 0x82 > > > > > +#define ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED > 0x85 > > > > > > > > > > MODULE_AUTHOR("Paul Diefenbaugh"); > > MODULE_DESCRIPTION("ACPI > > > > > Processor Driver"); @@ -83,6 +84,11 @@ static void > > > > > acpi_processor_notify(acpi_handle handle, u32 event, void *data) > > > > > acpi_bus_generate_netlink_event(device->pnp.device_class, > > > > > dev_name(&device->dev), event, 0); > > > > > break; > > > > > + case ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED: > > > > > + cpufreq_update_highest_perf(pr->id); > > > > > > > > And the design appears to be a bit ad-hoc here. > > > > > > > > Because why does it have anything to do with cpufreq? > > > > > > Well, clearly, cpufreq can be affected by this, but why would it be > > > not affected the same way as in the > > ACPI_PROCESSOR_NOTIFY_PERFORMANCE > > > case? > > > > > > That is, why isn't cpufreq_update_limits() the right thing to do? > > > > Seriously, I'm not going to apply this patch so long as my comments > > above are not addressed. > [Meng, Li (Jassmine)] > Sorry for the delayed reply to the email. > BIOS/AGESA is responsible to issue the Notify 0x85 to OS that the preferred > core has changed. > It will only affect the ranking of the preferred core, not the impact policy > limits. > AMD P-state driver will set the priority of the cores based on the preferred > core ranking, and prioritize selecting higher priority core to run the task. [Meng, Li (Jassmine)] From ACPI v6.5, Table 5.197 Processor Device Notification Values: Hex value Description 0x80 Performance Present Capabilities Changed. Used to notify OSPM that the number of supported processor performance states has changed. This notification causes OSPM to re-evaluate the _PPC object. See Section 8.4.5.3 for more information. 0x85 Highest Performance Changed. Used to notify OSPM that the value of the CPPC Highest Performance Register has changed. I think they are different notify events, so they need different functions to handle these events. Also see: https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#processor-device-notification-values
On Wed, Dec 27, 2023 at 2:40 AM Meng, Li (Jassmine) <Li.Meng@amd.com> wrote: > > [AMD Official Use Only - General] > > Hi Rafael: > > > -----Original Message----- > > From: Meng, Li (Jassmine) > > Sent: Tuesday, December 26, 2023 4:27 PM > > To: Rafael J. Wysocki <rafael@kernel.org> > > Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>; Huang, Ray > > <Ray.Huang@amd.com>; linux-pm@vger.kernel.org; linux- > > kernel@vger.kernel.org; x86@kernel.org; linux-acpi@vger.kernel.org; Shuah > > Khan <skhan@linuxfoundation.org>; linux-kselftest@vger.kernel.org; > > Fontenot, Nathan <Nathan.Fontenot@amd.com>; Sharma, Deepak > > <Deepak.Sharma@amd.com>; Deucher, Alexander > > <Alexander.Deucher@amd.com>; Limonciello, Mario > > <Mario.Limonciello@amd.com>; Huang, Shimmer > > <Shimmer.Huang@amd.com>; Yuan, Perry <Perry.Yuan@amd.com>; Du, > > Xiaojian <Xiaojian.Du@amd.com>; Viresh Kumar <viresh.kumar@linaro.org>; > > Borislav Petkov <bp@alien8.de>; Oleksandr Natalenko > > <oleksandr@natalenko.name> > > Subject: RE: [PATCH V12 4/7] cpufreq: Add a notification message that the > > highest perf has changed > > > > Hi Rafael: > > > > > -----Original Message----- > > > From: Rafael J. Wysocki <rafael@kernel.org> > > > Sent: Tuesday, December 12, 2023 9:44 PM > > > To: Meng, Li (Jassmine) <Li.Meng@amd.com> > > > Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>; Huang, Ray > > > <Ray.Huang@amd.com>; linux-pm@vger.kernel.org; linux- > > > kernel@vger.kernel.org; x86@kernel.org; linux-acpi@vger.kernel.org; > > > Shuah Khan <skhan@linuxfoundation.org>; > > > linux-kselftest@vger.kernel.org; Fontenot, Nathan > > > <Nathan.Fontenot@amd.com>; Sharma, Deepak > > <Deepak.Sharma@amd.com>; > > > Deucher, Alexander <Alexander.Deucher@amd.com>; Limonciello, Mario > > > <Mario.Limonciello@amd.com>; Huang, Shimmer > > <Shimmer.Huang@amd.com>; > > > Yuan, Perry <Perry.Yuan@amd.com>; Du, Xiaojian > > <Xiaojian.Du@amd.com>; > > > Viresh Kumar <viresh.kumar@linaro.org>; Borislav Petkov > > > <bp@alien8.de>; Oleksandr Natalenko <oleksandr@natalenko.name> > > > Subject: Re: [PATCH V12 4/7] cpufreq: Add a notification message that > > > the highest perf has changed > > > > > > Caution: This message originated from an External Source. Use proper > > > caution when opening attachments, clicking links, or responding. > > > > > > > > > On Wed, Dec 6, 2023 at 10:13 PM Rafael J. Wysocki <rafael@kernel.org> > > > wrote: > > > > > > > > On Wed, Dec 6, 2023 at 9:58 PM Rafael J. Wysocki <rafael@kernel.org> > > > wrote: > > > > > > > > > > On Tue, Dec 5, 2023 at 7:38 AM Meng Li <li.meng@amd.com> wrote: > > > > > > > > > > > > ACPI 6.5 section 8.4.6.1.1.1 specifies that Notify event 0x85 > > > > > > can be emmitted to cause the the OSPM to re-evaluate the highest > > > > > > performance > > > > > > > > > > Typos above. Given the number of iterations of this patch, this > > > > > is kind of disappointing. > > > > > > > > > > > register. Add support for this event. > > > > > > > > > > Also it would be nice to describe how this is supposed to work at > > > > > least roughly, so it is not necessary to reverse-engineer the > > > > > patch to find out that. > > > > > > > > > > > Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> > > > > > > Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> > > > > > > Reviewed-by: Huang Rui <ray.huang@amd.com> > > > > > > Reviewed-by: Perry Yuan <perry.yuan@amd.com> > > > > > > Signed-off-by: Meng Li <li.meng@amd.com> > > > > > > Link: > > > > > > > > > https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model > > > > > > .html#processor-device-notification-values > > > > > > --- > > > > > > drivers/acpi/processor_driver.c | 6 ++++++ > > > > > > drivers/cpufreq/cpufreq.c | 13 +++++++++++++ > > > > > > include/linux/cpufreq.h | 5 +++++ > > > > > > 3 files changed, 24 insertions(+) > > > > > > > > > > > > diff --git a/drivers/acpi/processor_driver.c > > > > > > b/drivers/acpi/processor_driver.c index > > > > > > 4bd16b3f0781..29b2fb68a35d > > > > > > 100644 > > > > > > --- a/drivers/acpi/processor_driver.c > > > > > > +++ b/drivers/acpi/processor_driver.c > > > > > > @@ -27,6 +27,7 @@ > > > > > > #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 > > > > > > #define ACPI_PROCESSOR_NOTIFY_POWER 0x81 > > > > > > #define ACPI_PROCESSOR_NOTIFY_THROTTLING 0x82 > > > > > > +#define ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED > > 0x85 > > > > > > > > > > > > MODULE_AUTHOR("Paul Diefenbaugh"); > > > MODULE_DESCRIPTION("ACPI > > > > > > Processor Driver"); @@ -83,6 +84,11 @@ static void > > > > > > acpi_processor_notify(acpi_handle handle, u32 event, void *data) > > > > > > acpi_bus_generate_netlink_event(device->pnp.device_class, > > > > > > dev_name(&device->dev), event, 0); > > > > > > break; > > > > > > + case ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED: > > > > > > + cpufreq_update_highest_perf(pr->id); > > > > > > > > > > And the design appears to be a bit ad-hoc here. > > > > > > > > > > Because why does it have anything to do with cpufreq? > > > > > > > > Well, clearly, cpufreq can be affected by this, but why would it be > > > > not affected the same way as in the > > > ACPI_PROCESSOR_NOTIFY_PERFORMANCE > > > > case? > > > > > > > > That is, why isn't cpufreq_update_limits() the right thing to do? > > > > > > Seriously, I'm not going to apply this patch so long as my comments > > > above are not addressed. > > [Meng, Li (Jassmine)] > > Sorry for the delayed reply to the email. > > BIOS/AGESA is responsible to issue the Notify 0x85 to OS that the preferred > > core has changed. > > It will only affect the ranking of the preferred core, not the impact policy > > limits. > > AMD P-state driver will set the priority of the cores based on the preferred > > core ranking, and prioritize selecting higher priority core to run the task. > [Meng, Li (Jassmine)] > From ACPI v6.5, Table 5.197 Processor Device Notification Values: > Hex value Description > 0x80 Performance Present Capabilities Changed. Used to notify OSPM that the number of supported processor performance states has changed. This notification causes OSPM to re-evaluate the _PPC object. See Section 8.4.5.3 for more information. > > 0x85 Highest Performance Changed. Used to notify OSPM that the value of the CPPC Highest Performance Register has changed. > > I think they are different notify events, so they need different functions to handle these events. But they effectively mean pretty much the same thing: the highest available performance state of the CPU has changed. Why would the response need to be different?
[AMD Official Use Only - General] Hi Raphael: > -----Original Message----- > From: Rafael J. Wysocki <rafael@kernel.org> > Sent: Thursday, December 28, 2023 1:04 AM > To: Meng, Li (Jassmine) <Li.Meng@amd.com> > Cc: Rafael J. Wysocki <rafael@kernel.org>; Rafael J . Wysocki > <rafael.j.wysocki@intel.com>; Huang, Ray <Ray.Huang@amd.com>; linux- > pm@vger.kernel.org; linux-kernel@vger.kernel.org; x86@kernel.org; linux- > acpi@vger.kernel.org; Shuah Khan <skhan@linuxfoundation.org>; linux- > kselftest@vger.kernel.org; Fontenot, Nathan > <Nathan.Fontenot@amd.com>; Sharma, Deepak > <Deepak.Sharma@amd.com>; Deucher, Alexander > <Alexander.Deucher@amd.com>; Limonciello, Mario > <Mario.Limonciello@amd.com>; Huang, Shimmer > <Shimmer.Huang@amd.com>; Yuan, Perry <Perry.Yuan@amd.com>; Du, > Xiaojian <Xiaojian.Du@amd.com>; Viresh Kumar <viresh.kumar@linaro.org>; > Borislav Petkov <bp@alien8.de>; Oleksandr Natalenko > <oleksandr@natalenko.name> > Subject: Re: [PATCH V12 4/7] cpufreq: Add a notification message that the > highest perf has changed > > Caution: This message originated from an External Source. Use proper > caution when opening attachments, clicking links, or responding. > > > On Wed, Dec 27, 2023 at 2:40 AM Meng, Li (Jassmine) <Li.Meng@amd.com> > wrote: > > > > [AMD Official Use Only - General] > > > > Hi Rafael: > > > > > -----Original Message----- > > > From: Meng, Li (Jassmine) > > > Sent: Tuesday, December 26, 2023 4:27 PM > > > To: Rafael J. Wysocki <rafael@kernel.org> > > > Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>; Huang, Ray > > > <Ray.Huang@amd.com>; linux-pm@vger.kernel.org; linux- > > > kernel@vger.kernel.org; x86@kernel.org; linux-acpi@vger.kernel.org; > > > Shuah Khan <skhan@linuxfoundation.org>; > > > linux-kselftest@vger.kernel.org; Fontenot, Nathan > > > <Nathan.Fontenot@amd.com>; Sharma, Deepak > <Deepak.Sharma@amd.com>; > > > Deucher, Alexander <Alexander.Deucher@amd.com>; Limonciello, Mario > > > <Mario.Limonciello@amd.com>; Huang, Shimmer > <Shimmer.Huang@amd.com>; > > > Yuan, Perry <Perry.Yuan@amd.com>; Du, Xiaojian > > > <Xiaojian.Du@amd.com>; Viresh Kumar <viresh.kumar@linaro.org>; > > > Borislav Petkov <bp@alien8.de>; Oleksandr Natalenko > > > <oleksandr@natalenko.name> > > > Subject: RE: [PATCH V12 4/7] cpufreq: Add a notification message > > > that the highest perf has changed > > > > > > Hi Rafael: > > > > > > > -----Original Message----- > > > > From: Rafael J. Wysocki <rafael@kernel.org> > > > > Sent: Tuesday, December 12, 2023 9:44 PM > > > > To: Meng, Li (Jassmine) <Li.Meng@amd.com> > > > > Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>; Huang, Ray > > > > <Ray.Huang@amd.com>; linux-pm@vger.kernel.org; linux- > > > > kernel@vger.kernel.org; x86@kernel.org; > > > > linux-acpi@vger.kernel.org; Shuah Khan > > > > <skhan@linuxfoundation.org>; linux-kselftest@vger.kernel.org; > > > > Fontenot, Nathan <Nathan.Fontenot@amd.com>; Sharma, Deepak > > > <Deepak.Sharma@amd.com>; > > > > Deucher, Alexander <Alexander.Deucher@amd.com>; Limonciello, > Mario > > > > <Mario.Limonciello@amd.com>; Huang, Shimmer > > > <Shimmer.Huang@amd.com>; > > > > Yuan, Perry <Perry.Yuan@amd.com>; Du, Xiaojian > > > <Xiaojian.Du@amd.com>; > > > > Viresh Kumar <viresh.kumar@linaro.org>; Borislav Petkov > > > > <bp@alien8.de>; Oleksandr Natalenko <oleksandr@natalenko.name> > > > > Subject: Re: [PATCH V12 4/7] cpufreq: Add a notification message > > > > that the highest perf has changed > > > > > > > > Caution: This message originated from an External Source. Use > > > > proper caution when opening attachments, clicking links, or responding. > > > > > > > > > > > > On Wed, Dec 6, 2023 at 10:13 PM Rafael J. Wysocki > > > > <rafael@kernel.org> > > > > wrote: > > > > > > > > > > On Wed, Dec 6, 2023 at 9:58 PM Rafael J. Wysocki > > > > > <rafael@kernel.org> > > > > wrote: > > > > > > > > > > > > On Tue, Dec 5, 2023 at 7:38 AM Meng Li <li.meng@amd.com> wrote: > > > > > > > > > > > > > > ACPI 6.5 section 8.4.6.1.1.1 specifies that Notify event > > > > > > > 0x85 can be emmitted to cause the the OSPM to re-evaluate > > > > > > > the highest performance > > > > > > > > > > > > Typos above. Given the number of iterations of this patch, > > > > > > this is kind of disappointing. > > > > > > > > > > > > > register. Add support for this event. > > > > > > > > > > > > Also it would be nice to describe how this is supposed to work > > > > > > at least roughly, so it is not necessary to reverse-engineer > > > > > > the patch to find out that. > > > > > > > > > > > > > Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> > > > > > > > Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> > > > > > > > Reviewed-by: Huang Rui <ray.huang@amd.com> > > > > > > > Reviewed-by: Perry Yuan <perry.yuan@amd.com> > > > > > > > Signed-off-by: Meng Li <li.meng@amd.com> > > > > > > > Link: > > > > > > > > > > > > https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model > > > > > > > .html#processor-device-notification-values > > > > > > > --- > > > > > > > drivers/acpi/processor_driver.c | 6 ++++++ > > > > > > > drivers/cpufreq/cpufreq.c | 13 +++++++++++++ > > > > > > > include/linux/cpufreq.h | 5 +++++ > > > > > > > 3 files changed, 24 insertions(+) > > > > > > > > > > > > > > diff --git a/drivers/acpi/processor_driver.c > > > > > > > b/drivers/acpi/processor_driver.c index > > > > > > > 4bd16b3f0781..29b2fb68a35d > > > > > > > 100644 > > > > > > > --- a/drivers/acpi/processor_driver.c > > > > > > > +++ b/drivers/acpi/processor_driver.c > > > > > > > @@ -27,6 +27,7 @@ > > > > > > > #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 > > > > > > > #define ACPI_PROCESSOR_NOTIFY_POWER 0x81 > > > > > > > #define ACPI_PROCESSOR_NOTIFY_THROTTLING 0x82 > > > > > > > +#define ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED > > > 0x85 > > > > > > > > > > > > > > MODULE_AUTHOR("Paul Diefenbaugh"); > > > > MODULE_DESCRIPTION("ACPI > > > > > > > Processor Driver"); @@ -83,6 +84,11 @@ static void > > > > > > > acpi_processor_notify(acpi_handle handle, u32 event, void *data) > > > > > > > acpi_bus_generate_netlink_event(device- > >pnp.device_class, > > > > > > > dev_name(&device->dev), event, 0); > > > > > > > break; > > > > > > > + case ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED: > > > > > > > + cpufreq_update_highest_perf(pr->id); > > > > > > > > > > > > And the design appears to be a bit ad-hoc here. > > > > > > > > > > > > Because why does it have anything to do with cpufreq? > > > > > > > > > > Well, clearly, cpufreq can be affected by this, but why would it > > > > > be not affected the same way as in the > > > > ACPI_PROCESSOR_NOTIFY_PERFORMANCE > > > > > case? > > > > > > > > > > That is, why isn't cpufreq_update_limits() the right thing to do? > > > > > > > > Seriously, I'm not going to apply this patch so long as my > > > > comments above are not addressed. > > > [Meng, Li (Jassmine)] > > > Sorry for the delayed reply to the email. > > > BIOS/AGESA is responsible to issue the Notify 0x85 to OS that the > > > preferred core has changed. > > > It will only affect the ranking of the preferred core, not the > > > impact policy limits. > > > AMD P-state driver will set the priority of the cores based on the > > > preferred core ranking, and prioritize selecting higher priority core to run > the task. > > [Meng, Li (Jassmine)] > > From ACPI v6.5, Table 5.197 Processor Device Notification Values: > > Hex value Description > > 0x80 Performance Present Capabilities Changed. Used to notify > OSPM that the number of supported processor performance states has > changed. This notification causes OSPM to re-evaluate the _PPC object. See > Section 8.4.5.3 for more information. > > > > 0x85 Highest Performance Changed. Used to notify OSPM that > the value of the CPPC Highest Performance Register has changed. > > > > I think they are different notify events, so they need different functions to > handle these events. > > But they effectively mean pretty much the same thing: the highest available > performance state of the CPU has changed. > > Why would the response need to be different? [Meng, Li (Jassmine)] Thanks, I will modify this issue.
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c index 4bd16b3f0781..29b2fb68a35d 100644 --- a/drivers/acpi/processor_driver.c +++ b/drivers/acpi/processor_driver.c @@ -27,6 +27,7 @@ #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 #define ACPI_PROCESSOR_NOTIFY_POWER 0x81 #define ACPI_PROCESSOR_NOTIFY_THROTTLING 0x82 +#define ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED 0x85 MODULE_AUTHOR("Paul Diefenbaugh"); MODULE_DESCRIPTION("ACPI Processor Driver"); @@ -83,6 +84,11 @@ static void acpi_processor_notify(acpi_handle handle, u32 event, void *data) acpi_bus_generate_netlink_event(device->pnp.device_class, dev_name(&device->dev), event, 0); break; + case ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED: + cpufreq_update_highest_perf(pr->id); + acpi_bus_generate_netlink_event(device->pnp.device_class, + dev_name(&device->dev), event, 0); + break; default: acpi_handle_debug(handle, "Unsupported event [0x%x]\n", event); break; diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 934d35f570b7..14a4cbc6dd05 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -2717,6 +2717,19 @@ void cpufreq_update_limits(unsigned int cpu) } EXPORT_SYMBOL_GPL(cpufreq_update_limits); +/** + * cpufreq_update_highest_perf - Update highest performance for a given CPU. + * @cpu: CPU to update the highest performance for. + * + * Invoke the driver's ->update_highest_perf callback if present + */ +void cpufreq_update_highest_perf(unsigned int cpu) +{ + if (cpufreq_driver->update_highest_perf) + cpufreq_driver->update_highest_perf(cpu); +} +EXPORT_SYMBOL_GPL(cpufreq_update_highest_perf); + /********************************************************************* * BOOST * *********************************************************************/ diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 1c5ca92a0555..f62257b2a42f 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -235,6 +235,7 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu); void refresh_frequency_limits(struct cpufreq_policy *policy); void cpufreq_update_policy(unsigned int cpu); void cpufreq_update_limits(unsigned int cpu); +void cpufreq_update_highest_perf(unsigned int cpu); bool have_governor_per_policy(void); bool cpufreq_supports_freq_invariance(void); struct kobject *get_governor_parent_kobj(struct cpufreq_policy *policy); @@ -263,6 +264,7 @@ static inline bool cpufreq_supports_freq_invariance(void) return false; } static inline void disable_cpufreq(void) { } +static inline void cpufreq_update_highest_perf(unsigned int cpu) { } #endif #ifdef CONFIG_CPU_FREQ_STAT @@ -380,6 +382,9 @@ struct cpufreq_driver { /* Called to update policy limits on firmware notifications. */ void (*update_limits)(unsigned int cpu); + /* Called to update highest performance on firmware notifications. */ + void (*update_highest_perf)(unsigned int cpu); + /* optional */ int (*bios_limit)(int cpu, unsigned int *limit);