2005-04-17 06:20:36 +08:00
|
|
|
#
|
|
|
|
|
# Makefile for the Linux ACPI interpreter
|
2007-03-08 03:28:00 +08:00
|
|
|
#
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-01-09 13:13:17 +08:00
|
|
|
ccflags-y := -Os
|
|
|
|
|
ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# ACPI Boot-Time Table Parsing
|
|
|
|
|
#
|
2005-08-25 00:07:20 +08:00
|
|
|
obj-y += tables.o
|
2005-09-22 13:15:57 +08:00
|
|
|
obj-$(CONFIG_X86) += blacklist.o
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# ACPI Core Subsystem (Interpreter)
|
|
|
|
|
#
|
2009-03-12 06:37:19 +08:00
|
|
|
obj-y += acpi.o \
|
2009-01-09 13:13:17 +08:00
|
|
|
acpica/
|
|
|
|
|
|
2009-03-12 06:37:19 +08:00
|
|
|
# All the builtin files are in the "acpi." module_param namespace.
|
|
|
|
|
acpi-y += osl.o utils.o reboot.o
|
2011-12-08 11:25:49 +08:00
|
|
|
acpi-y += nvs.o
|
2009-03-12 06:37:19 +08:00
|
|
|
|
2012-11-02 08:40:09 +08:00
|
|
|
# Power management related files
|
2009-03-12 06:37:19 +08:00
|
|
|
acpi-y += wakeup.o
|
|
|
|
|
acpi-y += sleep.o
|
2013-05-17 04:29:28 +08:00
|
|
|
acpi-y += device_pm.o
|
2011-12-08 11:25:49 +08:00
|
|
|
acpi-$(CONFIG_ACPI_SLEEP) += proc.o
|
2009-01-09 13:13:17 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# ACPI Bus and Device Drivers
|
|
|
|
|
#
|
2009-03-12 06:37:19 +08:00
|
|
|
acpi-y += bus.o glue.o
|
|
|
|
|
acpi-y += scan.o
|
2012-11-15 07:30:01 +08:00
|
|
|
acpi-y += resource.o
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-03 06:26:22 +08:00
|
|
|
acpi-y += acpi_processor.o
|
2010-02-23 03:11:14 +08:00
|
|
|
acpi-y += processor_core.o
|
2014-07-18 18:02:54 +08:00
|
|
|
acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
|
2009-03-12 06:37:19 +08:00
|
|
|
acpi-y += ec.o
|
|
|
|
|
acpi-$(CONFIG_ACPI_DOCK) += dock.o
|
2012-12-23 07:02:54 +08:00
|
|
|
acpi-y += pci_root.o pci_link.o pci_irq.o
|
2014-05-30 20:34:05 +08:00
|
|
|
acpi-y += acpi_lpss.o
|
2012-11-01 05:45:02 +08:00
|
|
|
acpi-y += acpi_platform.o
|
ACPI / PNP: use device ID list for PNPACPI device enumeration
ACPI can be used to enumerate PNP devices, but the code does not
handle this in the right way currently. Namely, if an ACPI device
object
1. Has a _CRS method,
2. Has an identification of
"three capital characters followed by four hex digits",
3. Is not in the excluded IDs list,
it will be enumerated to PNP bus (that is, a PNP device object will
be create for it). This means that, actually, the PNP bus type is
used as the default bus type for enumerating _HID devices in ACPI.
However, more and more _HID devices need to be enumerated to the
platform bus instead (that is, platform device objects need to be
created for them). As a result, the device ID list in acpi_platform.c
is used to enforce creating platform device objects rather than PNP
device objects for matching devices. That list has been continuously
growing recently, unfortunately, and it is pretty much guaranteed to
grow even more in the future.
To address that problem it is better to enumerate _HID devices
as platform devices by default. To this end, change the way of
enumerating PNP devices by adding a PNP ACPI scan handler that
will use a device ID list to create PNP devices for the ACPI
device objects whose device IDs are present in that list.
The initial device ID list in the PNP ACPI scan handler contains
all of the pnp_device_id strings from all the existing PNP drivers,
so this change should be transparent to the PNP core and all of the
PNP drivers. Still, in the future it should be possible to reduce
its size by converting PNP drivers that need not be PNP for any
technical reasons into platform drivers.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
[rjw: Rewrote the changelog, modified the PNP ACPI scan handler code]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 10:23:01 +08:00
|
|
|
acpi-y += acpi_pnp.o
|
2014-03-14 00:34:05 +08:00
|
|
|
acpi-y += int340x_thermal.o
|
2009-03-12 06:37:19 +08:00
|
|
|
acpi-y += power.o
|
2010-07-15 10:46:33 +08:00
|
|
|
acpi-y += event.o
|
2010-07-15 10:46:30 +08:00
|
|
|
acpi-y += sysfs.o
|
ACPI: Add support for device specific properties
Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.
ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.
In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.
If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"name1", <VALUE1>},
Package () {"name2", <VALUE2>},
...
}
})
The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].
We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.
The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.
[1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-21 19:33:55 +08:00
|
|
|
acpi-y += property.o
|
2013-06-05 10:27:50 +08:00
|
|
|
acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
|
2010-07-15 10:46:15 +08:00
|
|
|
acpi-$(CONFIG_DEBUG_FS) += debugfs.o
|
2009-03-12 06:37:19 +08:00
|
|
|
acpi-$(CONFIG_ACPI_NUMA) += numa.o
|
2014-05-04 11:07:24 +08:00
|
|
|
acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
|
2009-03-12 06:37:19 +08:00
|
|
|
ifdef CONFIG_ACPI_VIDEO
|
|
|
|
|
acpi-y += video_detect.o
|
2005-04-17 06:20:36 +08:00
|
|
|
endif
|
|
|
|
|
|
2009-03-12 06:37:19 +08:00
|
|
|
# These are (potentially) separate modules
|
2012-10-17 04:53:37 +08:00
|
|
|
|
|
|
|
|
# IPMI may be used by other drivers, so it has to initialise before them
|
|
|
|
|
obj-$(CONFIG_ACPI_IPMI) += acpi_ipmi.o
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
obj-$(CONFIG_ACPI_AC) += ac.o
|
|
|
|
|
obj-$(CONFIG_ACPI_BUTTON) += button.o
|
|
|
|
|
obj-$(CONFIG_ACPI_FAN) += fan.o
|
2006-10-21 05:30:25 +08:00
|
|
|
obj-$(CONFIG_ACPI_VIDEO) += video.o
|
2008-06-11 05:30:42 +08:00
|
|
|
obj-$(CONFIG_ACPI_PCI_SLOT) += pci_slot.o
|
2005-04-17 06:20:36 +08:00
|
|
|
obj-$(CONFIG_ACPI_PROCESSOR) += processor.o
|
2014-05-30 10:28:20 +08:00
|
|
|
obj-y += container.o
|
2005-04-17 06:20:36 +08:00
|
|
|
obj-$(CONFIG_ACPI_THERMAL) += thermal.o
|
2014-05-30 10:29:14 +08:00
|
|
|
obj-y += acpi_memhotplug.o
|
2009-01-11 03:19:05 +08:00
|
|
|
obj-$(CONFIG_ACPI_BATTERY) += battery.o
|
2007-09-26 23:43:28 +08:00
|
|
|
obj-$(CONFIG_ACPI_SBS) += sbshc.o
|
2008-02-09 16:22:13 +08:00
|
|
|
obj-$(CONFIG_ACPI_SBS) += sbs.o
|
2010-05-18 14:35:17 +08:00
|
|
|
obj-$(CONFIG_ACPI_HED) += hed.o
|
2010-07-16 19:11:31 +08:00
|
|
|
obj-$(CONFIG_ACPI_EC_DEBUGFS) += ec_sys.o
|
2011-05-26 18:26:24 +08:00
|
|
|
obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
|
2012-02-01 02:19:20 +08:00
|
|
|
obj-$(CONFIG_ACPI_BGRT) += bgrt.o
|
2009-03-12 06:37:19 +08:00
|
|
|
|
2009-04-03 10:49:43 +08:00
|
|
|
# processor has its own "processor." module_param namespace
|
2010-02-23 03:11:08 +08:00
|
|
|
processor-y := processor_driver.o processor_throttling.o
|
2009-04-03 10:49:43 +08:00
|
|
|
processor-y += processor_idle.o processor_thermal.o
|
|
|
|
|
processor-$(CONFIG_CPU_FREQ) += processor_perflib.o
|
ACPI: create Processor Aggregator Device driver
ACPI 4.0 created the logical "processor aggregator device" as
a mechinism for platforms to ask the OS to force otherwise busy
processors to enter (power saving) idle.
The intent is to lower power consumption to ride-out
transient electrical and thermal emergencies,
rather than powering off the server.
On platforms that can save more power/performance via P-states,
the platform will first exhaust P-states before forcing idle.
However, the relative benefit of P-states vs. idle states
is platform dependent, and thus this driver need not know
or care about it.
This driver does not use the kernel's CPU hot-plug mechanism
because after the transient emergency is over, the system must
be returned to its normal state, and hotplug would permanently
break both cpusets and binding.
So to force idle, the driver creates a power saving thread.
The scheduler will migrate the thread to the preferred CPU.
The thread has max priority and has SCHED_RR policy,
so it can occupy one CPU. To save power, the thread will
invoke the deep C-state entry instructions.
To avoid starvation, the thread will sleep 5% of the time
time for every second (current RT scheduler has threshold
to avoid starvation, but if other CPUs are idle,
the CPU can borrow CPU timer from other,
which makes the mechanism not work here)
Vaidyanathan Srinivasan has proposed scheduler enhancements
to allow injecting idle time into the system. This driver doesn't
depend on those enhancements, but could cut over to them
when they are available.
Peter Z. does not favor upstreaming this driver until
the those scheduler enhancements are in place. However,
we favor upstreaming this driver now because it is useful
now, and can be enhanced over time.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
NACKed-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-07-28 06:11:02 +08:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
|
2010-05-18 14:35:12 +08:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_ACPI_APEI) += apei/
|
2013-10-22 05:29:25 +08:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o
|
2014-11-24 17:21:54 +08:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_PMIC_OPREGION) += pmic/intel_pmic.o
|
|
|
|
|
obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
|
2014-11-24 17:24:47 +08:00
|
|
|
obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
|