linux-stable.git/drivers/acpi/Makefile, branch linux-3.19.y

Merge branches 'acpi-video' and 'acpi-pmic'

2014-12-08T18:54:45+00:00

* acpi-video:
  ACPI / video: Run _BCL before deciding registering backlight

* acpi-pmic:
  ACPI / PMIC: AXP288: support virtual GPIO in ACPI table
  ACPI / PMIC: support PMIC operation region for XPower AXP288
  ACPI / PMIC: support PMIC operation region for CrystalCove
  iio/axp288_adc: remove THIS_MODULE owner
  mfd/axp20x: avoid irq numbering collision
  iio: adc: Add module device table for autoloading
  iio: adc: Add support for axp288 adc
  mfd: axp20x: Extend axp20x to support axp288 pmic

ACPI / PMIC: support PMIC operation region for XPower AXP288

2014-11-26T22:32:05+00:00

The Baytrail-T-CR platform firmware has defined two customized operation
regions for PMIC chip Dollar Cove XPower - one is for power resource
handling and one is for thermal just like the CrystalCove one. This patch
adds support for them on top of the common PMIC opregion region code.

Signed-off-by: Aaron Lu 
Acked-by: Lee Jones  for the MFD part
Signed-off-by: Rafael J. Wysocki

ACPI / PMIC: support PMIC operation region for CrystalCove

2014-11-26T22:32:05+00:00

The Baytrail-T platform firmware has defined two customized operation
regions for PMIC chip Crystal Cove - one is for power resource handling
and one is for thermal: sensor temperature reporting, trip point setting,
etc. This patch adds support for them on top of the existing Crystal Cove
PMIC driver.

The reason to split code into a separate file intel_pmic.c is that there
are more PMIC drivers with ACPI operation region support coming and we can
re-use those code. The intel_pmic_opregion_data structure is created also
for this purpose: when we need to support a new PMIC's operation region,
we just need to fill those callbacks and the two register mapping tables.

Signed-off-by: Aaron Lu 
Acked-by: Lee Jones  for the MFD part
Signed-off-by: Rafael J. Wysocki

ACPI: Add support for device specific properties

2014-11-04T20:58:21+00:00

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", },
			Package () {"name2", },
			...
		}
	})

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 
Reviewed-by: Josh Triplett 
Reviewed-by: Grant Likely 
Signed-off-by: Darren Hart 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki

ACPI: introduce ACPI int340x thermal scan handler

2014-09-11T15:35:15+00:00

Newer laptops and tablets that use ACPI may have thermal sensors and
other devices with thermal control capabilities outside the core CPU/SOC,
for thermal safety reasons.
They are exposed for the OS to use via
1) INT3400 ACPI device object as the master.
2) INT3401 ~ INT340B ACPI device objects as the slaves.

This patch introduces a scan handler to enumerate the INT3400
ACPI device object to platform bus, and prevent its slaves
from being enumerated before the controller driver being probed.

Signed-off-by: Zhang Rui

ACPI / processor: Introduce ARCH_MIGHT_HAVE_ACPI_PDC

2014-07-21T11:50:58+00:00

The use of _PDC is deprecated in ACPI 3.0 in favor of _OSC,
as ARM platform is supported only in ACPI 5.0 or higher version,
_PDC will not be used in ARM platform, so make Make _PDC only for
platforms with Intel CPUs.

Introduce ARCH_MIGHT_HAVE_ACPI_PDC and move _PDC related code in
ACPI processor driver into a single file processor_pdc.c, make x86
and ia64 select it when ACPI is enabled.

This patch also use pr_* to replace printk to fix the checkpatch
warning and factor acpi_processor_alloc_pdc() a little bit to
avoid duplicate pr_err() code.

Suggested-by: Robert Richter 
Signed-off-by: Hanjun Guo 
Signed-off-by: Rafael J. Wysocki

ACPI / scan: always register ACPI LPSS scan handler

2014-05-30T14:04:36+00:00

Prevent platform devices from being created for ACPI LPSS devices
if CONFIG_X86_INTEL_LPSS is unset by compiling out the LPSS scan
handler's callbacks only in that case and still compiling its device
ID list in and registering the scan handler in either case.

This change is based on a prototype from Zhang Rui.

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mika Westerberg

ACPI / scan: always register memory hotplug scan handler

2014-05-30T14:04:36+00:00

Prevent platform devices from being created for ACPI memory device
objects if CONFIG_ACPI_HOTPLUG_MEMORY is unset by compiling out the
memory hotplug scan handler's callbacks only in that case and still
compiling its device ID list in and registering the scan handler in
either case.

Also unset the memory hotplug scan handler's .attach() callback
if acpi_no_memhotplug is set, but still register the scan handler to
avoid creating platform devices for ACPI memory devices in that case
too.

This change is based on a prototype from Zhang Rui.

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mika Westerberg

ACPI / scan: always register container scan handler

2014-05-30T14:04:36+00:00

Prevent platform devices from being created for ACPI containers
if CONFIG_ACPI_CONTAINER is unset by compiling out the container
scan handler's callbacks only in that case and still compiling
its device ID list in and registering the scan handler in either
case.

This change is based on a prototype from Zhang Rui.

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mika Westerberg

ACPI / PNP: use device ID list for PNPACPI device enumeration

2014-05-30T14:04:35+00:00

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 
[rjw: Rewrote the changelog, modified the PNP ACPI scan handler code]
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mika Westerberg