2005-04-17 02:20:36 +04:00
|
|
|
#
|
|
|
|
|
# Makefile for the Linux ACPI interpreter
|
2007-03-07 22:28:00 +03:00
|
|
|
#
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2009-01-09 08:13:17 +03:00
|
|
|
ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# ACPI Boot-Time Table Parsing
|
|
|
|
|
#
|
2015-11-20 20:35:02 +03:00
|
|
|
obj-$(CONFIG_ACPI) += tables.o
|
2005-09-22 09:15:57 +04:00
|
|
|
obj-$(CONFIG_X86) += blacklist.o
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# ACPI Core Subsystem (Interpreter)
|
|
|
|
|
#
|
2015-11-20 20:35:02 +03:00
|
|
|
obj-$(CONFIG_ACPI) += acpi.o \
|
2009-01-09 08:13:17 +03:00
|
|
|
acpica/
|
|
|
|
|
|
2009-03-12 01:37:19 +03:00
|
|
|
# All the builtin files are in the "acpi." module_param namespace.
|
2016-05-03 11:49:01 +03:00
|
|
|
acpi-y += osi.o osl.o utils.o reboot.o
|
2011-12-08 07:25:49 +04:00
|
|
|
acpi-y += nvs.o
|
2009-03-12 01:37:19 +03:00
|
|
|
|
2012-11-02 04:40:09 +04:00
|
|
|
# Power management related files
|
2009-03-12 01:37:19 +03:00
|
|
|
acpi-y += wakeup.o
|
2015-03-24 17:02:39 +03:00
|
|
|
acpi-$(CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT) += sleep.o
|
2015-07-17 23:53:43 +03:00
|
|
|
acpi-y += device_sysfs.o device_pm.o
|
2011-12-08 07:25:49 +04:00
|
|
|
acpi-$(CONFIG_ACPI_SLEEP) += proc.o
|
2009-01-09 08:13:17 +03:00
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# ACPI Bus and Device Drivers
|
|
|
|
|
#
|
2009-03-12 01:37:19 +03:00
|
|
|
acpi-y += bus.o glue.o
|
|
|
|
|
acpi-y += scan.o
|
2012-11-15 03:30:01 +04: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 02:26:22 +04:00
|
|
|
acpi-y += acpi_processor.o
|
2010-02-22 22:11:14 +03:00
|
|
|
acpi-y += processor_core.o
|
2014-07-18 14:02:54 +04:00
|
|
|
acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
|
2009-03-12 01:37:19 +03:00
|
|
|
acpi-y += ec.o
|
|
|
|
|
acpi-$(CONFIG_ACPI_DOCK) += dock.o
|
2012-12-23 03:02:54 +04:00
|
|
|
acpi-y += pci_root.o pci_link.o pci_irq.o
|
2016-06-10 22:55:13 +03:00
|
|
|
obj-$(CONFIG_ACPI_MCFG) += pci_mcfg.o
|
2015-02-06 03:27:51 +03:00
|
|
|
acpi-y += acpi_lpss.o acpi_apd.o
|
2012-11-01 01:45:02 +04: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 06:23:01 +04:00
|
|
|
acpi-y += acpi_pnp.o
|
2016-01-20 17:29:27 +03:00
|
|
|
acpi-$(CONFIG_ARM_AMBA) += acpi_amba.o
|
2009-03-12 01:37:19 +03:00
|
|
|
acpi-y += power.o
|
2010-07-15 06:46:33 +04:00
|
|
|
acpi-y += event.o
|
ACPI: implement Generic Event Device
Generic Event Device described in ACPI 6.1 allows platforms to handle
platform interrupts in ACPI ASL statements. It borrows constructs like
_EVT from GPIO events. All interrupts are listed in _CRS and the handler
is written in _EVT method. Here is an example.
Device (GED0)
{
Name (_HID, "ACPI0013")
Name (_UID, 0)
Name(_CRS, ResourceTemplate ()
{
Interrupt(ResourceConsumer, Edge, ActiveHigh, Shared, , , )
{123}
})
Method (_EVT, 1) {
if (Lequal(123, Arg0))
{
}
}
}
Wake capability has not been implemented yet.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-07 18:00:31 +03:00
|
|
|
acpi-$(CONFIG_ACPI_REDUCED_HARDWARE_ONLY) += evged.o
|
2010-07-15 06:46:30 +04: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 15:33:55 +04:00
|
|
|
acpi-y += property.o
|
2013-06-05 06:27:50 +04:00
|
|
|
acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
|
ACPI / property: Support Apple _DSM properties
While the rest of the world has standardized on _DSD as the way to store
device properties in AML (introduced with ACPI 5.1 in 2014), Apple has
been using a custom _DSM to achieve the same for much longer (ever since
they switched from DeviceTree-based PowerPC to Intel in 2005, verified
with MacOS X 10.4.11).
The theory of operation on macOS is as follows: AppleACPIPlatform.kext
invokes mergeEFIproperties() and mergeDSMproperties() for each device to
merge properties conveyed by EFI drivers as well as properties stored in
AML into the I/O Kit registry from which they can be retrieved by
drivers. We've been supporting EFI properties since commit 58c5475aba67
("x86/efi: Retrieve and assign Apple device properties"). The present
commit adds support for _DSM properties, thereby completing our support
for Apple device properties. The _DSM properties are made available
under the primary fwnode, the EFI properties under the secondary fwnode.
So for devices which possess both property types, they can all be
elegantly accessed with the uniform API in <linux/property.h>.
Until recently we had no need to support _DSM properties, they contained
only uninteresting garbage. The situation has changed with MacBooks and
MacBook Pros introduced since 2015: Their keyboard is attached with SPI
instead of USB and the _CRS data which is necessary to initialize the
spi driver only contains valid information if OSPM responds "false" to
_OSI("Darwin"). If OSPM responds "true", _CRS is empty and the spi
driver fails to initialize. The rationale is very simple, Apple only
cares about macOS and Windows: On Windows, _CRS contains valid data,
whereas on macOS it is empty. Instead, macOS gleans the necessary data
from the _DSM properties.
Since Linux deliberately defaults to responding "true" to _OSI("Darwin"),
we need to emulate macOS' behaviour by initializing the spi driver with
data returned by the _DSM.
An out-of-tree driver for the SPI keyboard exists which currently binds
to the ACPI device, invokes the _DSM, parses the returned package and
instantiates an SPI device with the data gleaned from the _DSM:
https://github.com/cb22/macbook12-spi-driver/commit/9a416d699ef4
https://github.com/cb22/macbook12-spi-driver/commit/0c34936ed9a1
By adding support for Apple's _DSM properties in generic ACPI code, the
out-of-tree driver will be able to register as a regular SPI driver,
significantly reducing its amount of code and improving its chances to
be mainlined.
The SPI keyboard will not be the only user of this commit: E.g. on the
MacBook8,1, the UART-attached Bluetooth device likewise returns empty
_CRS data if OSPM returns "true" to _OSI("Darwin").
The _DSM returns a Package whose format unfortunately deviates slightly
from the _DSD spec: The properties are marshalled up in a single Package
as alternating key/value elements, unlike _DSD which stores them as a
Package of 2-element Packages. The present commit therefore converts
the Package to _DSD format and the ACPI core can then treat the data as
if Apple would follow the standard.
Well, except for one small annoyance: The properties returned by the
_DSM only ever have one of two types, Integer or Buffer. The former is
retrievable as usual with device_property_read_u64(), but the latter is
not part of the _DSD spec and it is not possible to retrieve Buffer
properties with the device_property_read_*() functions due to the type
checking performed in drivers/acpi/property.c. It is however possible
to retrieve them with acpi_dev_get_property(). Apple is using the
Buffer type somewhat sloppily to store null-terminated strings but also
integers. The real data type is not distinguishable by the ACPI core
and the onus is on the caller to use the contents of the Buffer in an
appropriate way.
In case Apple moves to _DSD in the future, this commit first checks for
_DSD and falls back to _DSM only if _DSD is not found.
Tested-by: Ronald Tschalär <ronald@innovation.ch>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-01 15:10:41 +03:00
|
|
|
acpi-$(CONFIG_X86) += x86/apple.o
|
2017-04-21 13:47:40 +03:00
|
|
|
acpi-$(CONFIG_X86) += x86/utils.o
|
2010-07-15 06:46:15 +04:00
|
|
|
acpi-$(CONFIG_DEBUG_FS) += debugfs.o
|
2009-03-12 01:37:19 +03:00
|
|
|
acpi-$(CONFIG_ACPI_NUMA) += numa.o
|
2014-05-04 07:07:24 +04:00
|
|
|
acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
|
2015-01-28 22:56:46 +03:00
|
|
|
acpi-y += acpi_lpat.o
|
2017-02-03 02:23:58 +03:00
|
|
|
acpi-$(CONFIG_ACPI_GENERIC_GSI) += irq.o
|
2016-09-20 15:30:51 +03:00
|
|
|
acpi-$(CONFIG_ACPI_WATCHDOG) += acpi_watchdog.o
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2009-03-12 01:37:19 +03:00
|
|
|
# These are (potentially) separate modules
|
2012-10-17 00:53:37 +04: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 02:20:36 +04:00
|
|
|
obj-$(CONFIG_ACPI_AC) += ac.o
|
|
|
|
|
obj-$(CONFIG_ACPI_BUTTON) += button.o
|
|
|
|
|
obj-$(CONFIG_ACPI_FAN) += fan.o
|
2006-10-21 01:30:25 +04:00
|
|
|
obj-$(CONFIG_ACPI_VIDEO) += video.o
|
2008-06-11 01:30:42 +04:00
|
|
|
obj-$(CONFIG_ACPI_PCI_SLOT) += pci_slot.o
|
2005-04-17 02:20:36 +04:00
|
|
|
obj-$(CONFIG_ACPI_PROCESSOR) += processor.o
|
2015-11-20 20:35:02 +03:00
|
|
|
obj-$(CONFIG_ACPI) += container.o
|
2005-04-17 02:20:36 +04:00
|
|
|
obj-$(CONFIG_ACPI_THERMAL) += thermal.o
|
2016-07-24 07:24:19 +03:00
|
|
|
obj-$(CONFIG_ACPI_NFIT) += nfit/
|
2015-11-20 20:35:02 +03:00
|
|
|
obj-$(CONFIG_ACPI) += acpi_memhotplug.o
|
2015-02-05 08:44:49 +03:00
|
|
|
obj-$(CONFIG_ACPI_HOTPLUG_IOAPIC) += ioapic.o
|
2009-01-10 22:19:05 +03:00
|
|
|
obj-$(CONFIG_ACPI_BATTERY) += battery.o
|
2007-09-26 19:43:28 +04:00
|
|
|
obj-$(CONFIG_ACPI_SBS) += sbshc.o
|
2008-02-09 11:22:13 +03:00
|
|
|
obj-$(CONFIG_ACPI_SBS) += sbs.o
|
2010-05-18 10:35:17 +04:00
|
|
|
obj-$(CONFIG_ACPI_HED) += hed.o
|
2010-07-16 15:11:31 +04:00
|
|
|
obj-$(CONFIG_ACPI_EC_DEBUGFS) += ec_sys.o
|
2011-05-26 14:26:24 +04:00
|
|
|
obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
|
2012-01-31 22:19:20 +04:00
|
|
|
obj-$(CONFIG_ACPI_BGRT) += bgrt.o
|
2015-10-02 17:01:19 +03:00
|
|
|
obj-$(CONFIG_ACPI_CPPC_LIB) += cppc_acpi.o
|
2016-09-27 23:54:13 +03:00
|
|
|
obj-$(CONFIG_ACPI_SPCR_TABLE) += spcr.o
|
2015-12-03 05:43:14 +03:00
|
|
|
obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
|
2009-03-12 01:37:19 +03:00
|
|
|
|
2009-04-03 06:49:43 +04:00
|
|
|
# processor has its own "processor." module_param namespace
|
2015-08-05 16:40:26 +03:00
|
|
|
processor-y := processor_driver.o
|
|
|
|
|
processor-$(CONFIG_ACPI_PROCESSOR_IDLE) += processor_idle.o
|
2015-08-05 16:40:25 +03:00
|
|
|
processor-$(CONFIG_ACPI_CPU_FREQ_PSS) += processor_throttling.o \
|
|
|
|
|
processor_thermal.o
|
2009-04-03 06:49:43 +04:00
|
|
|
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 02:11:02 +04:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
|
2010-05-18 10:35:12 +04:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_ACPI_APEI) += apei/
|
2013-10-22 01:29:25 +04:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o
|
2014-11-24 12:21:54 +03:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_PMIC_OPREGION) += pmic/intel_pmic.o
|
|
|
|
|
obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
|
2014-11-24 12:24:47 +03:00
|
|
|
obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
|
2016-06-24 03:48:51 +03:00
|
|
|
obj-$(CONFIG_BXT_WC_PMIC_OPREGION) += pmic/intel_pmic_bxtwc.o
|
2017-04-19 16:06:59 +03:00
|
|
|
obj-$(CONFIG_CHT_WC_PMIC_OPREGION) += pmic/intel_pmic_chtwc.o
|
2015-06-16 17:27:47 +03:00
|
|
|
|
2016-07-11 16:13:36 +03:00
|
|
|
obj-$(CONFIG_ACPI_CONFIGFS) += acpi_configfs.o
|
2015-06-16 17:27:47 +03:00
|
|
|
|
|
|
|
|
video-objs += acpi_video.o video_detect.o
|
2016-07-17 23:45:32 +03:00
|
|
|
obj-y += dptf/
|
2016-09-12 21:54:20 +03:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_ARM64) += arm64/
|
