23 Jan, 2010
2 commits
-
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
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
Allow platforms not listed in DMI table
to opt-in and evaluate _PDC early.Signed-off-by: Alex Chiang
Signed-off-by: Len Brown
20 Jan, 2010
2 commits
-
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=14954Signed-off-by: Alex Chiang
Signed-off-by: Len Brown
16 Jan, 2010
1 commit
-
Alex Chiang introduced acpi_early_processor_set_pdc() in commit:
ACPI: processor: call _PDC early
78f1699659963fff97975df44db6d5dbe7218e55But 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
Acked-by: Alex Chiang
Signed-off-by: Len Brown
22 Dec, 2009
10 commits
-
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 timeThis saves 2834 bytes of stack.
Update the interface accordingly.
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
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
Signed-off-by: Len Brown -
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
Signed-off-by: Len Brown -
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
Signed-off-by: Len Brown -
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
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
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
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
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
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
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
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
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
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
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
Signed-off-by: Len Brown