Conflicts:
	drivers/acpi/video.c
Signed-off-by: Len Brown <len.brown@intel.com>

The recent ACPICA patch
(ACPICA: FADT: Favor 32-bit register addresses for compatibility)
makes machine to use the right FADT HW addresses
and C-states now work fine.

http://bugzilla.kernel.org/show_bug.cgi?id=8246Signed-off-by: Thomas Renninger <trenn@suse.de>
Tested-by: Mark Doughty <me@markdoughty.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>

drivers/gpu/drm/i915/i915_drv.c:102: error: too many arguments to
function ‘intel_opregion_init’
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI backlight control w/o _BQC support is kinda firmware bug.
Add a warning if _BQC is not implemented.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI has smart batteries, which work in units of energy and measure
rate of (dis)charge as power, thus it is not appropriate to export it
as a current_now. Current_now will still be exported to allow
for userland applications to match.
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

Intel graphics hardware that implements the ACPI IGD OpRegion spec
requires that the list of display devices be populated before any ACPI
video methods are called. Detect when this is the case and defer
registration until the opregion code calls it. Fixes crashes on HP
laptops.

http://bugzilla.kernel.org/show_bug.cgi?id=11259Signed-off-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Len Brown <len.brown@intel.com>

Some buggy BIOSes implements _BCQ instead of _BQC.
Male ACPI video driver support these buggy BIOS.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

The input/output of _BQC/_BCL/_BCM control methods should be represented
by a number between 0 and 100, and can be thought of as a percentage.
But some buggy _BQC/_BCL/_BCM methods use the index values instead.
http://bugzilla.kernel.org/show_bug.cgi?id=12302
http://bugzilla.kernel.org/show_bug.cgi?id=12249
http://bugzilla.kernel.org/show_bug.cgi?id=12037

Add the functionality to support such kind of BIOSes in ACPI video driver.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

The brightness levels returned by _BCL package are in a reversed order
on some laptops.
http://bugzilla.kernel.org/show_bug.cgi?id=12037
http://bugzilla.kernel.org/show_bug.cgi?id=12302
http://bugzilla.kernel.org/show_bug.cgi?id=12235

sort the _BCL packge in case it's reversed.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

Many buggy BIOSes don't export the brightness levels when machine
is on AC/Battery in the _BCL method.

Reformat the _BCL package for these laptops:
now the elements in device->brightness->levels[] are like:
levels[0]: brightness level when on AC power.
levels[1]: brightness level when on Battery power.
levels[2]: supported brightness level 1.
levels[3]: supported brightness level 2.
...
levels[n]: supported brightness level n-1.
levels[n + 1]: supported brightness level n.
So if there are n supported brightness levels on this laptop,
we will have n+2 entries in device->brightnes->levels[].

level[0] and level[1] are invalid on the laptops that don't
export the brightness levels on AC/Battery.
Fortunately, we never use these two values at all, even for the
valid ones.

http://bugzilla.kernel.org/show_bug.cgi?id=12249Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

When cpufreq driver call acpi_processor_preregister_performance() , function
will clean up pr->performance even if there is possibly already registered
other cpufreq driver. The patch fix this potential problem. It also remove
double checks in P domain basic validity code and move these checks to function
where _PSD data is captured.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>

In acpi_bus_ops, only the acpi_op_add and acpi_op_start flags are used,
so remove all the rest.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

No drivers use the .shutdown method, so remove it.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

No drivers use the .lock and .scan methods, and the Linux/ACPI
code doesn't even provide a way to invoke them, so remove them.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

Due to poor thermal design or Linux driving hardware outside its thermal
envelope, some systems will reach critical temperature and shut down
under high load. This patch adds support for forcing a polling-based
passive trip point if the firmware doesn't provide one. The assumption
is made that the processor is the most practical means to reduce the
dynamic heat generation, so hitting the passive thermal limit will cause
the CPU to be throttled until the temperature stabalises around the
defined value.

UI is provided via a "passive" sysfs entry in the thermal zone
directory. It accepts a decimal value in millidegrees celsius, or "0" to
disable the functionality. Default behaviour is for this functionality
to be disabled.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>

> drivers/acpi/thermal.c: In function 'thermal_notify':
> drivers/acpi/thermal.c:768: error: 'struct device' has no member named 'bus_id'
>
> Caused by commit b1569e99 ("ACPI: move
> thermal trip handling to generic thermal layer") interacting with commit
> d4a078fca590911cdf87a8eaffee1b6e643c2558 ("driver core: get rid of struct
> device's bus_id string array").
>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Len Brown <len.brown@intel.com>

> arch/x86/kernel/cpu/cpufreq/longhaul.c: In function 'longhaul_setstate':
> arch/x86/kernel/cpu/cpufreq/longhaul.c:308: error: implicit declaration of function 'acpi_set_register'
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Compile-tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Len Brown <len.brown@intel.com>

This patch removes the suggestion that ec.o link order is important,
because it doesn't matter since acpi_ec_init() is no longer an initcall.
And it puts together most of the core modules that are not configurable.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

This patch makes acpi_init() call acpi_wakeup_device_init() directly.
Previously, acpi_wakeup_device_init() was a late_initcall (sequence 7).

acpi_wakeup_device_init() depends on acpi_wakeup_device_list, which
is populated when ACPI devices are enumerated by acpi_init() ->
acpi_scan_init().  Using late_initcall is certainly enough to make
sure acpi_wakeup_device_list is populated, but it is more than
necessary.  We can just as easily call acpi_wakeup_device_init()
directly from acpi_init(), which avoids the initcall magic.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

This patch makes acpi_init() call acpi_sleep_proc_init() directly.
Previously, acpi_sleep_proc_init() was a late_initcall (sequence 7),
apparently to make sure that the /proc hierarchy already exists:

    2003/02/13 12:38:03-06:00 mochel
    acpi sleep: demote sleep proc file creation.

    - Make acpi_sleep_proc_init() a late_initcall(), and not called from
      acpi_sleep_init(). This guarantees that the acpi proc hierarchy is at
      least there when we create the dang file.

This should no longer be an issue because acpi_bus_init() (called early
in acpi_init()) creates acpi_root_dir (/proc/acpi).
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

This patch makes acpi_init() call init_acpi_device_notify() directly.
Previously, init_acpi_device_notify() was an arch_initcall (sequence 3),
so it was called before acpi_init() (a subsys_initcall at sequence 4).

init_acpi_device_notify() sets the platform_notify and
platform_notify_remove function pointers.  These pointers
are not used until acpi_init() enumerates ACPI devices in
this path:

    acpi_init()
	    acpi_scan_init()
		acpi_bus_scan()
		    acpi_add_single_object()
			acpi_device_register()
			    device_add()
				<use platform_notify>

So it is sufficient to have acpi_init() call init_acpi_device_notify()
directly before it enumerates devices.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

This patch makes acpi_init() call acpi_debug_init() directly.
Previously, both were subsys_initcalls.  acpi_debug_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

This patch makes acpi_init() call acpi_system_init() directly.
Previously, both were subsys_initcalls.  acpi_system_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

This patch makes acpi_init() call acpi_power_init() directly.
Previously, both were subsys_initcalls.  acpi_power_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

This patch makes acpi_init() call acpi_ec_init() directly.
Previously, both were subsys_initcalls.  acpi_ec_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

This patch makes acpi_init() call acpi_scan_init() directly.

Previously, both acpi_init() and acpi_scan_init() were subsys_initcalls,
and acpi_init() was called first based on the link order from the
makefile (bus.o before scan.o).

acpi_scan_init() registers the ACPI bus type, creates the root device,
and enumerates fixed-feature and namespace devices.  All of this must
be done after acpi_init(), and it's better to call acpi_scan_init()
explicitly rather than rely on the link ordering.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

This patch makes acpi_init() exit early when ACPI is disabled.
This skips a DMI check that affects ACPI power management.   The
DMI check prints a notice that is misleading when ACPI is disabled.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

Version 20090320.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

For predefined method validation. Index value in warning message
could be off by one.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>