[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XEN PATCH v1] x86/cpufreq: separate powernow/hwp cpufreq code
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Sergiy Kibrik <sergiy_kibrik@xxxxxxxx>
- Date: Fri, 7 Jun 2024 12:14:31 +0300
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
- 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=GiKVYOgXgaZpYoJuUo4D3kT4lGfZJ/ey2VihoOkDpHU=; b=F79Kl81dmgOYVf+6fzuohp7kBQuUdwdrmhsZH+5DCuFr+c1qnzbQXMTgpn6Hp2RUXVYzd9kzJ1Q+IURBsTWQ+cd71oW7Ol9IcNZxLbeg3ZVPOge1mYP+7W386qOqGFRRJjHc4KH3J5gkk3u6V4qd+hByx6/4FtBWznzfe9nD+CYj5HH0yjMTWYCTz15M/c++X1HDMJX2ctjjy07cMPy+b23aRQ76VlvGLTdX/B43ulK9PGCaReYvFtBPSi2p2pSBoPbn2Omv5WvQXJ5drT7YNIp8P14qqfWa6ohcF3cNz4NAtjFhfX8mOeTUtU5M5Gcun0jO2n3NwigRgm7Fdyxotg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mYOnVkWUUHaqMSpkk69QKjRiMTUJhdfh1v+Ow5eGCEt74p5tEsSa/pOIXq/57Ek3mTyEI85Yx8MARnDogUZ+8cpYy3/sBsCoPZpwW06jQJua7JTysGMNuW5W7us9Jd6JlYTq/gZZspztpPdbuXJwhjdtvSxzlU8S1vmb1rHR2EYYZfnFVxQaTBI2Jr/ce4P7YTupyz3s8KjCttFwk0+ikGvhqyJtD/yQNLg0ok5oErWqeHkILnKuPgrWG3Ad5WBDIZxrorHADZP/wh8ldp9UmTqFSmyQywGEQk6qRcVnAvb10fLwFPmXp77fLLx0GAKw6W3BAdrvgz1TRTYDcfVYsw==
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Jason Andryuk <jason.andryuk@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Fri, 07 Jun 2024 09:14:56 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
06.06.24 10:54, Jan Beulich:
On 06.06.2024 09:30, Sergiy Kibrik wrote:
06.06.24 10:08, Jan Beulich:
On 04.06.2024 11:34, Sergiy Kibrik wrote:
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -657,7 +657,7 @@ static int __init cf_check cpufreq_driver_init(void)
case X86_VENDOR_AMD:
case X86_VENDOR_HYGON:
- ret = powernow_register_driver();
+ ret = IS_ENABLED(CONFIG_AMD) ? powernow_register_driver() :
-ENODEV;
break;
}
What about the Intel-specific code immediately up from here?
Dealing with that as well may likely permit to reduce ...
you mean to guard a call to hwp_register_driver() the same way as for
powernow_register_driver(), and save one stub? ?
Yes, and perhaps more. Maybe more stubs can be avoided? And
acpi_cpufreq_driver doesn't need registering either, and hence
would presumably be left unreferenced when !INTEL?
{get,set}_hwp_para() can be avoided, as they're being called just once
and may be guarded by IS_ENABLED(CONFIG_INTEL).
The same for hwp_cmdline_parse().
As for hwp_active() it's being used many times by generic cpufreq code
and even outside of cpufreq, so probably it has to be either a stub, or
be moved outside of hwp.c and become smth, like this:
bool hwp_active(void)
{
return IS_ENABLED(CONFIG_INTEL) && hwp_in_use;
}
Though I'm not sure such movement would be any better than a stub.
acpi_cpufreq_driver, i.e. the most of code in cpufreq.c file, can
probably be separated into acpi.c and put under CONFIG_INTEL as well.
What you think of this?
-Sergiy
|
