Commit graph

2394 commits

Author SHA1 Message Date
Len Brown
b2cb9dcb98 Merge branch 'pcc' into release 2010-02-23 00:39:00 -05:00
Pallipadi, Venkatesh
d306ebc286 ACPI: Be in TS_POLLING state during mwait based C-state entry
ACPI deep C-state entry had a long standing bug/missing feature, wherein we were sending
resched IPIs when an idle CPU is in mwait based deep C-state. Only mwait based C1 was using
the write to the monitored address to wake up mwait'ing CPU.

This patch changes the code to retain TS_POLLING bit if we are entering an mwait based
deep C-state.

The patch has been verified to reduce the number of resched IPIs in general and also
improves the performance/power on workloads with low system utilization (i.e., when mwait based
deep C-states are being used).

Fixes "netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f"
http://marc.info/?l=linux-kernel&m=126441481427331&w=4

Reported-by: Lin Ming <ming.m.lin@intel.com>
Tested-by: Alex Shi <alex.shi@intel.com>
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 13:10:14 -05:00
Darrick J. Wong
455c0d71d4 ACPI: Fix regression where _PPC is not read at boot even when ignore_ppc=0
Earlier, Ingo Molnar posted a patch to make it so that the kernel would avoid
reading _PPC on his broken T60.  Unfortunately, it seems that with Thomas
Renninger's patch last July to eliminate _PPC evaluations when the processor
driver loads, the kernel never actually reads _PPC at all!  This is problematic
if you happen to boot your non-T60 computer in a state where the BIOS _wants_
_PPC to be something other than zero.

So, put the _PPC evaluation back into acpi_processor_get_performance_info if
ignore_ppc isn't 1.

Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-19 01:11:48 -05:00
Len Brown
0e2ecbaefd Merge branches 'bugzilla-14886', 'bugzilla-15000', 'bugzilla-15040', 'bugzilla-15108', 'pdc', 'hotplug-null-ref' and 'thinkpad' into release 2010-02-18 03:51:04 -05:00
Len Brown
49bf83a45f ACPI: fix "acpi=ht" boot option
We broke "acpi=ht" in 2.6.32 by disabling MADT parsing
for acpi=disabled.  e5b8fc6ac1
This also broke systems which invoked acpi=ht via DMI blacklist.

acpi=ht is a really ugly hack,
but restore it for those that still use it.

http://bugzilla.kernel.org/show_bug.cgi?id=14886

Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-18 03:49:38 -05:00
Arjan van de Ven
370d5cd885 ACPI: fix High cpu temperature with 2.6.32
Since the rewrite of the CPU idle governor in 2.6.32, two laptops have
surfaced where the BIOS advertises a C2 power state, but for some reason
this state is not functioning (as verified in both cases by powertop
before the patch in .32).

The old governor had the accidental behavior that if a non-working state
was chosen too many times, it would end up falling back to C1.  The new
governor works differently and this accidental behavior is no longer
there; the result is a high temperature on these two machines.

This patch adds these 2 machines to the DMI table for C state anomalies;
by just not using C2 both these machines are better off (the TSC can be
used instead of the pm timer, giving a performance boost for example).

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14742

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Reported-by: <akwatts@ymail.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-16 04:11:27 -05:00
Alex Chiang
49c6fb2e41 ACPI: dock: properly initialize local struct dock_station in dock_add()
Commit fe06fba2 (ACPI: dock: add struct dock_station * directly
to platform device data) changed dock_add() to use the
platform_device_register_data() API.

We passed that interface a stack variable, which is kmemdup'ed
and assigned to the device's platform_data pointer.

Unfortunately, whatever random garbage is in the stack variable
gets coped during the kmemdup, and that leads to broken behavior.

Explicitly zero out the structure before passing it to the API.

This fixes the T41 docking button issue:
http://bugzilla.kernel.org/show_bug.cgi?id=15000

Cc: stable@kernel.org
Reported-by: Chris Mason <chris.mason@oracle.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-16 03:54:28 -05:00
Thomas Renninger
7779688fc3 ACPI: acpi_bus_{scan,bus,add}: return -ENODEV if no device was found
Callers (acpi_memhotplug.c, dock.c and others) check for the return
value of acpi_bus_add() and assume a valid device was returned in
case zero was returned.

Thus return -ENODEV if no device was found in acpi_bus_scan and
propagate this through acpi_bus_add and acpi_bus_start.

Also remove a confusing comment in acpiphp_glue.c, acpi_bus_scan
will and cannot invoke if acpi_bus_add returns no valid device.

Signed-off-by: Thomas Renninger <trenn@suse.de>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-31 21:43:32 -05:00
Thomas Renninger
d2f6650a95 ACPI: Add NULL pointer check in acpi_bus_start
If acpi_bus_add does not return a device and it's passed
to acpi_bus_start, bad things will happen:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffff8128402d>] acpi_bus_start+0x14/0x24
...
[<ffffffffa008977a>] acpiphp_bus_add+0xba/0x130 [acpiphp]
[<ffffffffa008aa72>] enable_device+0x132/0x2ff [acpiphp]
[<ffffffffa0089b68>] acpiphp_enable_slot+0xb8/0x130 [acpiphp]
[<ffffffffa0089df7>] handle_hotplug_event_func+0x87/0x190 [acpiphp]

Next patch would make this NULL pointer check obsolete, but
better having one more than one missing...

Signed-off-by: Thomas Renninger <trenn@suse.de>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: stable@kernel.org
Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-31 21:43:04 -05:00
Alex Chiang
a4932299d0 ACPI: processor: only evaluate _PDC once per processor
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-22 12:39:56 -05:00
Alex Chiang
0406ad336c ACPI: processor: add kernel command line support for early _PDC eval
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-22 12:39:21 -05:00
Len Brown
418521deef Merge branch 'bugzilla-14954' into release 2010-01-20 01:26:22 -05:00
Len Brown
be6066f34c Merge branch 'misc' into release 2010-01-20 01:23:27 -05:00
Len Brown
b4cdd6ac4f Merge branch 'osc-bugfix' into release 2010-01-20 01:23:18 -05:00
Len Brown
b07f07e0c2 Merge branch 'ec' into release 2010-01-20 01:20:36 -05:00
Len Brown
361243fd62 Merge branch 'bugzilla-15064' into release 2010-01-20 01:15:21 -05:00
Len Brown
49897deeea Merge branch 'bugzilla-14858' into release 2010-01-20 01:14:57 -05:00
Len Brown
093e2961fe Merge branch 'bugzilla-13577-video' into release 2010-01-20 01:14:41 -05:00
Len Brown
9c6a6b3cbc Merge branch 'acpi-pad' into release 2010-01-20 01:14:30 -05:00
Len Brown
d22edd293f ACPI: delete acpi_processor_power_verify_c2()
no functional change -- cleanup only.

acpi_processor_power_verify_c2() was nearly empty due to a previous patch,
so expand its remains into its one caller and delete it.

Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-20 00:54:15 -05:00
Len Brown
a6d72c189f ACPI: allow C3 > 1000usec
Do for C3 what the previous patch did for C2.

The C2 patch was in response to a highly visible
and multiply reported C-state/turbo failure,
while this change has no bug report in-hand.

This will enable C3 in Linux on systems where BIOS
overstates C3 latency in _CST.  It will also enable
future systems which may actually have C3 > 1000usec.

Linux has always ignored ACPI BIOS C3 with exit latency > 1000 usec,
and the ACPI spec is clear that is correct FADT-supplied C3.

However, the ACPI spec explicitly states that _CST-supplied C-states
have no latency limits.

So move the 1000usec C3 test out of the code shared
by FADT and _CST code-paths, and into the FADT-specific path.

Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-20 00:54:15 -05:00
Len Brown
5d76b6f6c1 ACPI: enable C2 and Turbo-mode on Nehalem notebooks on A/C
Linux has always ignored ACPI BIOS C2 with exit latency > 100 usec,
and the ACPI spec is clear that is correct FADT-supplied C2.

However, the ACPI spec explicitly states that _CST-supplied C-states
have no latency limits.

So move the 100usec C2 test out of the code shared
by FADT and _CST code-paths, and into the FADT-specific path.

This bug has not been visible until Nehalem, which advertises
a CPU-C2 worst case exit latency on servers of 205usec.
That (incorrect) figure is being used by BIOS writers
on mobile Nehalem systems for the AC configuration.
Thus, Linux ignores C2 leaving just C1, which is
saves less power, and also impacts performance
by preventing the use of turbo mode.

http://bugzilla.kernel.org/show_bug.cgi?id=15064

Tested-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-20 00:54:01 -05:00
Darren Jenkins
7f07a605a3 ACPI: power_meter: remove double kfree()
resource->domain_devices can be double kfree()'d in a couple of places.
Fix this by setting num_domain_devices = 0 after the kfree().

Coverity CID: 13356, 13355, 13354

Signed-off-by: Darren Jenkins <darrenrjenkins@gmail.com>
Acked-by: Darrick J. Wong <djwong@us.ibm.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-19 23:56:02 -05:00
Alex Chiang
2205cbe8ec ACPI: processor: restrict early _PDC to opt-in platforms
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-19 23:43:47 -05:00
Rakib Mullick
c19bdb6126 ACPI: Fix unused variable warning in sbs.c
When CONFIG_ACPI_SYSFS_POWER=n and CONFIG_ACPI_PROCFS_POWER=n, then
we're warned by the following warning:

drivers/acpi/sbs.c: In function `acpi_battery_remove':
drivers/acpi/sbs.c:825: warning: unused variable `battery'

Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-16 16:04:18 -05:00
Márton Németh
c97adf9e7b acpi: make ACPI device id constant
The ids field of the struct acpi_driver is constant in <linux/acpi/acpi_bus.h>
so it is worth to make the initialization data also constant.

The semantic match that finds this kind of pattern is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
disable decl_init,const_decl_init;
identifier I1, I2, x;
@@
	struct I1 {
	  ...
	  const struct I2 *x;
	  ...
	};
@s@
identifier r.I1, y;
identifier r.x, E;
@@
	struct I1 y = {
	  .x = E,
	};
@c@
identifier r.I2;
identifier s.E;
@@
	const struct I2 E[] = ... ;
@depends on !c@
identifier r.I2;
identifier s.E;
@@
+	const
	struct I2 E[] = ...;
// </smpl>

Signed-off-by: Márton Németh <nm127@freemail.hu>
Cc: Julia Lawall <julia@diku.dk>
Cc: cocci@diku.dk
Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-16 15:56:43 -05:00
Luck, Tony
7a0b73a49a ACPI: Fix section mismatch error for acpi_early_processor_set_pdc()
Alex Chiang introduced acpi_early_processor_set_pdc() in commit:
 ACPI: processor: call _PDC early
 78f1699659

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>
2010-01-16 02:00:44 -05:00
H Hartley Sweeten
070a24f4d2 ACPI: Remove unnecessary cast.
The struct seq_file 'private' member is a void *, the cast is not needed.
Also, remove an extra whitespace line.

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-15 23:06:44 -05:00
Zhao Yakui
6a4e2b7503 ACPI: Advertise to BIOS in _OSC: _OST on _PPC changes
If the BIOS pokes the system-wide OSC bits to see if Linux
supports evaluating _OST after a _PPC change notification,
answer yes.

Also, fix an oversight where we neglected to set the OSC
bit advertising processor aggregator device support
when acpi-pad is compiled as a module.

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-15 23:05:00 -05:00
Alexey Starikovskiy
54070101f8 ACPI: EC: Add wait for irq storm
Merge of poll and irq modes accelerated EC transaction, so
that keyboard starts to suffer again. Add msleep(1) into
transaction path for the storm to allow keyboard controller
to do its job.

Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14747

Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-15 22:53:04 -05:00
Alexey Starikovskiy
f5347867c5 ACPI: SBS: Move SBS HC callback to faster Notify queue
SBS transactions should happen in Notify work queue, to not create
a dead lock with GPE execution accessing SBS devices.

Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-15 22:52:48 -05:00
Zhang Rui
c504f8cb68 ACPI video: Prune dupe video devices, unless "video.allow_duplicates"
Some buggy BIOS exports multiple ACPI video bus devices for the same
VGA controller, and multiple backlight control methods as well.
This messes up the ACPI video backlight control.

http://bugzilla.kernel.org/show_bug.cgi?id=13577

With this patch applied, only the FIRST ACPI video bus device
under a PCI device node is bind to ACPI video driver by default.

If the first ACPI video bus device doesn't work well, we can use
video.allow_duplicates=1 to go back to the old behavior.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-30 20:30:04 -05:00
Chen Gong
3b8cb427e9 acpi_pad: fix error checks
There are some fixes listed below:
1. When met a bogus BIOS, the return value of cpu number maybe is
   a negative value so that acpi_pad_pur get an unexpected result.
2. the return value of function acpi_pad_idle_cpus is useless.
3. enhance the process of create_power_saving_task/destroy_power_saving_task
4. Add more error checks when evaluating _PUR object.
5. one typo fix

Signed-off-by: Chen Gong <gong.chen@linux.intel.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-30 19:24:36 -05:00
Len Brown
1201b2a9be Merge branch 'resume-sci-force-bootparam' into release 2009-12-30 18:32:32 -05:00
Zhang Rui
d7f0eea9e4 ACPI: introduce kernel parameter acpi_sleep=sci_force_enable
Introduce kernel parameter acpi_sleep=sci_force_enable

some laptop requires SCI_EN being set directly on resume,
or else they hung somewhere in the resume code path.

We already have a blacklist for these laptops but we still need
this option, especially when debugging some suspend/resume problems,
in case there are systems that need this workaround and are not yet
in the blacklist.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-30 18:32:01 -05:00
Len Brown
cccc67a4cf Merge branch 'video-error-case' into release 2009-12-30 02:51:38 -05:00
Zhang Rui
e01ce79b7f ACPI video: correct error-handling code
backlight_device_register may return an ERR_PTR
value rather than a valid pointer.

Problem found by Julia Lawall, properly fixed by Zhang Rui.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-30 01:51:07 -05:00
Zhang Rui
28c32e99bd ACPI video: no warning message if "acpi_backlight=vendor" is used
AML code always sends notifications to ACPI video device,
even if we disable the ACPI backlight control by using
boot option "acpi_backlight=vendor".

In this case we should not print any warning message.
http://bugzilla.kernel.org/show_bug.cgi?id=13671#c14

Sigend-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-30 01:46:12 -05:00
Alexey Starikovskiy
a62e8f1978 ACPI: EC: Accelerate query execution
Split EC query handling into acknowledge and execution phase.
This allows much smaller pending query lattency and lowers chances
of EC going "wild" and losing events.

Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14858

Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-24 14:52:38 -05:00
Len Brown
da3df858c8 Merge branch 'pdc' into release 2009-12-24 01:17:21 -05:00
Len Brown
309ddc53be Merge branches 'bugzilla-14446', 'bugzilla-14753' and 'bugzilla-14824' into release 2009-12-24 01:17:01 -05:00
Len Brown
6f5464ce15 Merge branch 'osc' into release 2009-12-24 01:16:35 -05:00
Shaohua Li
9dc130fccb ACPI: fix OSC regression that caused aer and pciehp not to load
Executing _OSC returns a buffer, which has an acpi object in it.
Don't directly returns the buffer, instead, we return the acpi object's
buffer. This fixes a regression since caller of acpi_run_osc expects
an acpi object's buffer returned.

Tested-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-23 17:42:07 -05:00
Alex Chiang
43bab25ced ACPI: processor: change acpi_processor_set_pdc() interface
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-22 03:33:58 -05:00
Alex Chiang
b9c2db7834 ACPI: processor: open code acpi_processor_cleanup_pdc
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-22 03:24:16 -05:00
Alex Chiang
fa118564ed ACPI: processor: change acpi_processor_eval_pdc interface
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-22 03:24:15 -05:00
Alex Chiang
3b407aef57 ACPI: processor: introduce acpi_processor_alloc_pdc()
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-22 03:24:14 -05:00
Alex Chiang
47817254b8 ACPI: processor: unify arch_acpi_processor_cleanup_pdc
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-22 03:24:14 -05:00
Alex Chiang
6c5807d7bc ACPI: processor: finish unifying arch_acpi_processor_init_pdc()
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-22 03:24:13 -05:00
Alex Chiang
08ea48a326 ACPI: processor: factor out common _PDC settings
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-22 03:24:12 -05:00