Hi Sudeep Holla~
Thanks for your comments.
+config ARCH_HAS_CPUFREQ
boolhelpInternal node to signify that the ARCH has CPUFREQ supportand that the relevant menu configurations are displayed forit.This is already in the mainline now, not required anymore.
-> Thanks~
endmenu diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h index 8625eb1..69db3e7 100644 --- a/arch/arm64/include/asm/cpu.h +++ b/arch/arm64/include/asm/cpu.h @@ -20,6 +20,7 @@ struct cpuinfo_arm { #endif };
-DECLARE_PER_CPU(struct cpuinfo_arm, cpu_data); +DECLARE_PER_CPU(struct cpuinfo_arm, cpu_info); +#define cpu_data(cpu) per_cpu(cpu_info, cpu)
This looks like unnecessary change, as you don't use this.
+enum idle_boot_override {IDLE_NO_OVERRIDE=0, IDLE_HALT, IDLE_NOMWAIT,
IDLE_POLL};This doesn't belong to cpufreq related changes
/*
- Idle related variables and functions */ unsigned long
+boot_option_idle_override = IDLE_NO_OVERRIDE; +EXPORT_SYMBOL(boot_option_idle_override);
+/*
Again this doesn't belong to cpufreq related changes.
- This is our default idle handler.
*/ void arch_cpu_idle(void) diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index fecf272..99b973b 100644 --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -377,14 +377,15 @@ static int __init arm64_device_init(void) } arch_initcall(arm64_device_init);
-static DEFINE_PER_CPU(struct cpu, cpu_data); +DEFINE_PER_CPU(struct cpu, cpu_info); +EXPORT_PER_CPU_SYMBOL(cpu_info);
Now I think this is introduced just to fix some compilation ?
static int __init topology_init(void) { int i;
for_each_possible_cpu(i) {
struct cpu *cpu = &per_cpu(cpu_data, i);
struct cpu *cpu = &per_cpu(cpu_info, i);This is want I meant above, you define a macro for this and not use it here ?
-> Yes.~
cpu->hotpluggable = 1; register_cpu(cpu, i); }
6a89856 100644
--- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -177,6 +177,7 @@ static int acpi_processor_hotadd_init(struct acpi_processor *pr) cpu_maps_update_begin();
cpu_ho\12.36.155.51\jhbirdchoi\Kernel\leg-kerneltplug_begin();
???
-> My mistake. Sorry
+#ifdef CONFIG_X86 ret = acpi_map_lsapic(pr->handle, pr->apic_id, &pr->id); if (ret) goto out; @@ -186,6 +187,7 @@ static int acpi_processor_hotadd_init(struct acpi_processor *pr) acpi_unmap_lsapic(pr->id); goto out; } +#endif
/* * CPU got hot-added, but cpu_data is not initialized yet.Set a flag @@ -457,8 +459,10 @@ static void acpi_processor_remove(struct acpi_device *device) cpu_hotplug_begin();
/* Remove the CPU. */+#ifdef CONFIG_X86 arch_unregister_cpu(pr->id);
Why is this X86 specific ?
-> I used #ifdef for compile, but
acpi_unmap_lsapic(pr->id);+#endif
cpu_hotplug_done(); cpu_maps_update_done();diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c index 3dca36d..0556a0a 100644 --- a/drivers/acpi/processor_idle.c +++ b/drivers/acpi/processor_idle.c
These changes in this file doesn't belong to cpufreq related changes. IMO Moving all such hack separately to another patch makes it easy to review.
-> Ok, thanks
[...]
%d\n", diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index 3a7202d..6417406 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -228,7 +228,7 @@ source "drivers/cpufreq/Kconfig.x86" endmenu
menu "ARM CPU frequency scaling drivers" -depends on ARM +depends on ARM64
Interesting why are you removing ARM ?
-> Let me check.
source "drivers/cpufreq/Kconfig.arm" endmenu
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 3129749..ef00a4c 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -16,6 +16,21 @@ config ARM_DT_BL_CPUFREQ This enables probing via DT for Generic CPUfreq driver for ARM big.LITTLE platform. This gets frequency tables from DT.
+config ARM_ACPI_CPUFREQ
tristate "ACPI Processor P-States driver"depends on ACPI_PROCESSORhelpThis driver adds a CPUFreq driver which utilizes the ACPIProcessor Performance States.This driver also supports ARM CPUs.To compile this driver as a module, choose M here: themodule will be called acpi-cpufreq.For details, take a look at <file:Documentation/cpu-freq/>.If in doubt, say N.Do we really need this if we must have single ACPI CPUFreq driver ?
-> Let me check
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c index 18448a7..26bf7112 100644 --- a/drivers/cpufreq/acpi-cpufreq.c +++ b/drivers/cpufreq/acpi-cpufreq.c @@ -42,37 +42,17 @@
#include <acpi/processor.h>
-#include <asm/msr.h> +#include <asm/cpu.h> #include <asm/processor.h> -#include <asm/cpufeature.h>
+#include "acpi-cpufreq.h"
I am skipping all x86 changes for now.
diff --git a/drivers/cpufreq/acpi-cpufreq_arm.c b/drivers/cpufreq/acpi-cpufreq_arm.c new file mode 100644 index 0000000..241c2a1 --- /dev/null +++ b/drivers/cpufreq/acpi-cpufreq_arm.c @@ -0,0 +1,88 @@ +#include <linux/acpi.h> +#include <linux/cpu.h> +#include <linux/io.h> +#include <linux/delay.h> +#include <linux/uaccess.h>
+#include <acpi/processor.h>
+#include <asm/cpu.h> +#include <asm/processor.h>
+#include "acpi-cpufreq.h"
+/* Called via smp_call_function_single(), on the target CPU */ static +void arm_do_drv_read(void *_cmd, struct acpi_cpufreq_data *data) {
struct drv_cmd *cmd = _cmd;if (data->cpu_feature != SYSTEM_MEMORY_CAPABLE)return;This is the core part I would like to understand. So far very few(close to none) ARM SoCs have such memory mapped interface for DVFS. Is this based on you assumption ? Or have you come across such SoC/platforms ?
-> Considered our system. To change DVFS, we have to write control value to certain register.(only 1 register) So I added checking SYSTEM_MEMORY_CAPABLE. -> Let me check again
Even if this is present, we need to think of catering other possible alternate methods we might have to support on ARM SoCs.
-> -> Ok. Let me check.
acpi_os_read_memory((acpi_physical_address)cmd->addr.mem.addr,(u64*)&cmd->val,cmd->addr.mem.bit_width);Further all you are using is standard System Memory as the Address Space ID, hence IMO this can be part of generic acpi cpufreq driver. I don't see anything ARM specific in Address Space ID being System Memory.
-> Ok. Let me check.
Thanks for your kind comments.
Best Regards