summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/processor_pdc.c
AgeCommit message (Collapse)Author
2014-07-21ACPI / processor: Introduce ARCH_MIGHT_HAVE_ACPI_PDCHanjun Guo
The use of _PDC is deprecated in ACPI 3.0 in favor of _OSC, as ARM platform is supported only in ACPI 5.0 or higher version, _PDC will not be used in ARM platform, so make Make _PDC only for platforms with Intel CPUs. Introduce ARCH_MIGHT_HAVE_ACPI_PDC and move _PDC related code in ACPI processor driver into a single file processor_pdc.c, make x86 and ia64 select it when ACPI is enabled. This patch also use pr_* to replace printk to fix the checkpatch warning and factor acpi_processor_alloc_pdc() a little bit to avoid duplicate pr_err() code. Suggested-by: Robert Richter <rric@kernel.org> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2010-03-14ACPI: processor: mv processor_pdc.c processor_core.cAlex Chiang
We've renamed the old processor_core.c to processor_driver.c, to convey the idea that it can be built modular and has driver-like bits. Now let's re-create a processor_core.c for the bits needed statically by the rest of the kernel. The contents of processor_pdc.c are a good starting spot, so let's just rename that file and complete our three card monte. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-22ACPI: processor: only evaluate _PDC once per processorAlex Chiang
If we evaluate _PDC in the early path, we do not want to evaluate it again when the processor driver is loaded. Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-22ACPI: processor: add kernel command line support for early _PDC evalAlex Chiang
Allow platforms not listed in DMI table to opt-in and evaluate _PDC early. Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-20Merge branch 'bugzilla-14954' into releaseLen Brown
2010-01-19ACPI: processor: restrict early _PDC to opt-in platformsAlex Chiang
Commit 78f1699 (ACPI: processor: call _PDC early) blindly walks the namespace and calls _PDC on every processor object it finds. This change may cause issues on platforms that declare dummy values for SSDTs on non-present processors (disabled in MADT). When we call _PDC and dynamically attempt to execute the AML Load() op on these dummy SSDTs, there's no telling what might happen. Rather than finding every platform that has bogus SSDTs, restrict early _PDC calls to platforms that are known to need early evaluation of _PDC. This is a minimal, temporary fix (given the context of the current release cycle). A real solution of checking the MADT for non-present processors will be written for the next merge window. References: http://bugzilla.kernel.org/show_bug.cgi?id=14710 http://bugzilla.kernel.org/show_bug.cgi?id=14954 Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-16ACPI: Fix section mismatch error for acpi_early_processor_set_pdc()Luck, Tony
Alex Chiang introduced acpi_early_processor_set_pdc() in commit: ACPI: processor: call _PDC early 78f1699659963fff97975df44db6d5dbe7218e55 But this results in a section mismatch: WARNING: drivers/acpi/acpi.o(.text+0xa9c1): Section mismatch in reference from the function acpi_early_processor_set_pdc() to the variable .cpuinit.data:processor_idle_dmi_table The function acpi_early_processor_set_pdc() references the variable __cpuinitdata processor_idle_dmi_table. This is often because acpi_early_processor_set_pdc lacks a __cpuinitdata annotation or the annotation of processor_idle_dmi_table is wrong. The only caller of acpi_early_processor_set_pdc() is acpi_bus_init() which is an "__init" function. So the correct fix here is to mark acpi_early_processor_set_pdc() "__init" too. Signed-off-by: Tony Luck <tony.luck@intel.com> Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-22ACPI: processor: change acpi_processor_set_pdc() interfaceAlex Chiang
When calling _PDC, we really only need the handle to the processor to call the method; we don't look at any other parts of the struct acpi_processor * given to us. In the early path, when we walk the namespace, we are given the handle directly, so just pass it through to acpi_processor_set_pdc() without stuffing it into a wasteful struct acpi_processor allocated on the stack each time This saves 2834 bytes of stack. Update the interface accordingly. Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-22ACPI: processor: open code acpi_processor_cleanup_pdcAlex Chiang
We have the acpi_object_list * right there in acpi_processor_set_pdc() so it doesn't seem necessary for an entire helper function just to free it. Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-22ACPI: processor: change acpi_processor_eval_pdc interfaceAlex Chiang
acpi_processor_eval_pdc() really only needs a handle and an acpi_object_list * to do its work. No need to pass in a struct acpi_processor *, so let's be more specific about what we want. Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-22ACPI: processor: introduce acpi_processor_alloc_pdc()Alex Chiang
acpi_processor_init_pdc() isn't really doing anything interesting with the struct acpi_processor * parameter. Its real job is to allocate the buffer for the _PDC bits. So rename the function to acpi_processor_alloc_pdc(), and just return the struct acpi_object_list * it's supposed to allocate. Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-22ACPI: processor: unify arch_acpi_processor_cleanup_pdcAlex Chiang
The x86 and ia64 implementations of the function in $subject are exactly the same. Also, since the arch-specific implementations of setting _PDC have been completely hollowed out, remove the empty shells. Cc: Tony Luck <tony.luck@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-22ACPI: processor: finish unifying arch_acpi_processor_init_pdc()Alex Chiang
The only thing arch-specific about calling _PDC is what bits get set in the input obj_list buffer. There's no need for several levels of indirection to twiddle those bits. Additionally, since we're just messing around with a buffer, we can simplify the interface; no need to pass around the entire struct acpi_processor * just to get at the buffer. Cc: Tony Luck <tony.luck@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-22ACPI: processor: factor out common _PDC settingsAlex Chiang
Both x86 and ia64 initialize _PDC with mostly common bit settings. Factor out the common settings and leave the arch-specific ones alone. Cc: Tony Luck <tony.luck@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-22ACPI: processor: unify arch_acpi_processor_init_pdcAlex Chiang
The x86 and ia64 implementations of arch_acpi_processor_init_pdc() are almost exactly the same. The only difference is in what bits they set in obj_list buffer. Combine the boilerplate memory management code, and leave the arch-specific bit twiddling in separate implementations. Cc: Tony Luck <tony.luck@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-22ACPI: processor: introduce arch_has_acpi_pdcAlex Chiang
arch dependent helper function that tells us if we should attempt to evaluate _PDC on this machine or not. The x86 implementation assumes that the CPUs in the machine must be homogeneous, and that you cannot mix CPUs of different vendors. Cc: Tony Luck <tony.luck@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-22ACPI: processor: call _PDC earlyAlex Chiang
We discovered that at least one machine (HP Envy), methods in the DSDT attempt to call external methods defined in a dynamically loaded SSDT. Unfortunately, the DSDT methods we are trying to call are part of the EC initialization, which happens very early, and the the dynamic SSDT is only loaded when a processor _PDC method runs much later. This results in namespace lookup errors for the (as of yet) undefined methods. Since Windows doesn't have any issues with this machine, we take it as a hint that they must be evaluating _PDC much earlier than we are. Thus, the proper thing for Linux to do should be to match the Windows implementation more closely. Provide a mechanism to call _PDC before we enable the EC. Doing so loads the dynamic tables, and allows the EC to be enabled correctly. The ACPI processor driver will still evaluate _PDC in its .add() method to cover the hotplug case. Resolves: http://bugzilla.kernel.org/show_bug.cgi?id=14824 Cc: ming.m.lin@intel.com Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>