linux-toradex.git/include/acpi/acpi_bus.h, branch v3.19-rc6

Merge branches 'acpi-scan', 'acpi-utils' and 'acpi-pm'

2014-12-18T17:42:56+00:00

* acpi-scan:
  ACPI / scan: Change the level of _DEP-related messages to KERN_DEBUG

* acpi-utils:
  ACPI / utils: Drop error messages from acpi_evaluate_reference()

* acpi-pm:
  ACPI / PM: Do not disable wakeup GPEs that have not been enabled

ACPI / PM: Do not disable wakeup GPEs that have not been enabled

2014-12-12T21:51:58+00:00

In some cases acpi_device_wakeup() may be called to ensure wakeup
power to be off for a given device even though that device's wakeup
GPE has not been enabled so far.  It calls acpi_disable_gpe() on a
GPE that's not enabled and this causes ACPICA to return the AE_LIMIT
status code from that call which then is reported as an error by the
ACPICA's debug facilities (if enabled).  This may lead to a fair
amount of confusion, so introduce a new ACPI device wakeup flag
to store the wakeup GPE status and avoid disabling wakeup GPEs
that have not been enabled.

Reported-and-tested-by: Venkat Raghavulu 
Signed-off-by: Rafael J. Wysocki

Merge branch 'pm-runtime'

2014-12-08T19:00:44+00:00

* pm-runtime: (25 commits)
  i2c-omap / PM: Drop CONFIG_PM_RUNTIME from i2c-omap.c
  dmaengine / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  drivers: sh / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  e1000e / igb / PM: Eliminate CONFIG_PM_RUNTIME
  MMC / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  MFD / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  misc / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  media / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  input / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  iio / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  hsi / OMAP / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  i2c-hid / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  drm / exynos / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  gpio / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  hwrandom / exynos / PM: Use CONFIG_PM in #ifdef
  block / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  USB / PM: Drop CONFIG_PM_RUNTIME from the USB core
  PM: Merge the SET*_RUNTIME_PM_OPS() macros
  PM / Kconfig: Do not select PM directly from Kconfig files
  PCI / PM: Drop CONFIG_PM_RUNTIME from the PCI core
  ...

Merge branches 'acpi-scan', 'acpi-pm', 'acpi-lpss' and 'acpi-processor'

2014-12-08T18:52:16+00:00

* acpi-scan:
  ACPI: Add _DEP support to fix battery issue on Asus T100TA

* acpi-pm:
  ACPI / sleep: Drain outstanding events after disabling multiple GPEs
  ACPI / PM: Fixed a typo in a comment

* acpi-lpss:
  dmaengine: dw: enable runtime PM
  ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA
  ACPI / LPSS: allow to use specific PM domain during ->probe()
  ACPI / LPSS: add all LPSS devices to the specific power domain

* acpi-processor:
  ACPI / cpuidle: avoid assigning signed errno to acpi_status
  ACPI / processor: remove unused variabled from acpi_processor_power structure
  ACPI / processor: Update the comments in processor.h

ACPI / PM: Drop CONFIG_PM_RUNTIME from the ACPI core

2014-12-03T23:50:19+00:00

After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so quite a few
depend on CONFIG_PM.

Replace CONFIG_PM_RUNTIME with CONFIG_PM in the ACPI core code.

Reviewed-by: Ulf Hansson 
Acked-by: Kevin Hilman 
Signed-off-by: Rafael J. Wysocki

ACPI: Add _DEP support to fix battery issue on Asus T100TA

2014-11-24T00:04:55+00:00

ACPI 5.0 introduces _DEP (Operation Region Dependencies) to designate
device objects that OSPM should assign a higher priority in start
ordering due to future operation region accesses.

On Asus T100TA, ACPI battery info are read from a I2C slave device via
I2C operation region. Before I2C operation region handler is installed,
battery _STA always returns 0. There is a _DEP method of designating
start order under battery device node.

This patch is to implement _DEP feature to fix battery issue on the
Asus T100TA.  Introducing acpi_dep_list and adding dep_unmet count
in struct acpi_device. During ACPI namespace scan, create struct
acpi_dep_data for a valid pair of master (device pointed to by _DEP)/
slave(device with _DEP), record master's and slave's ACPI handle in
it and put it into acpi_dep_list. The dep_unmet count will increase
by one if there is a device under its _DEP. Driver's probe() should
return EPROBE_DEFER when find dep_unmet is larger than 0. When I2C
operation region handler is installed, remove all struct acpi_dep_data
on the acpi_dep_list whose master is pointed to I2C host controller
and decrease slave's dep_unmet. When dep_unmet decreases to 0, all
_DEP conditions are met and then do acpi_bus_attach() for the device
in order to resolve battery _STA issue on the Asus T100TA.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=69011
Tested-by: Jan-Michael Brummer 
Tested-by: Adam Williamson 
Tested-by: Michael Shigorin 
Acked-by: Wolfram Sang 
Acked-by: Mika Westerberg 
Signed-off-by: Lan Tianyu 
Signed-off-by: Rafael J. Wysocki

ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs

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

Provide a way for device drivers using GPIOs described by ACPI
GpioIo resources in _CRS to tell the GPIO subsystem what names
(connection IDs) to associate with specific GPIO pins defined
in there.

To do that, a driver needs to define a mapping table as a
NULL-terminated array of struct acpi_gpio_mapping objects
that each contain a name, a pointer to an array of line data
(struct acpi_gpio_params) objects and the size of that array.

Each struct acpi_gpio_params object consists of three fields,
crs_entry_index, line_index, active_low, representing the index of
the target GpioIo()/GpioInt() resource in _CRS starting from zero,
the index of the target line in that resource starting from zero,
and the active-low flag for that line, respectively.

Next, the mapping table needs to be passed as the second
argument to acpi_dev_add_driver_gpios() that will register it with
the ACPI device object pointed to by its first argument.  That
should be done in the driver's .probe() routine.

On removal, the driver should unregister its GPIO mapping table
by calling acpi_dev_remove_driver_gpios() on the ACPI device
object where that table was previously registered.

Included are fixes from Mika Westerberg.

Acked-by: Alexandre Courbot 
Reviewed-by: Linus Walleij 
Signed-off-by: Rafael J. Wysocki

Driver core: Unified interface for firmware node properties

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

Add new generic routines are provided for retrieving properties from
device description objects in the platform firmware in case there are
no struct device objects for them (either those objects have not been
created yet or they do not exist at all).

The following functions are provided:

fwnode_property_present()
fwnode_property_read_u8()
fwnode_property_read_u16()
fwnode_property_read_u32()
fwnode_property_read_u64()
fwnode_property_read_string()
fwnode_property_read_u8_array()
fwnode_property_read_u16_array()
fwnode_property_read_u32_array()
fwnode_property_read_u64_array()
fwnode_property_read_string_array()

in analogy with the corresponding functions for struct device added
previously.  For all of them, the first argument is a pointer to struct
fwnode_handle (new type) that allows a device description object
(depending on what platform firmware interface is in use) to be
obtained.

Add a new macro device_for_each_child_node() for iterating over the
children of the device description object associated with a given
device and a new function device_get_child_node_count() returning the
number of a given device's child nodes.

The interface covers both ACPI and Device Trees.

Suggested-by: Grant Likely 
Acked-by: Greg Kroah-Hartman 
Acked-by: Grant Likely 
Signed-off-by: Rafael J. Wysocki

ACPI: Allow drivers to match using Device Tree compatible property

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

We have lots of existing Device Tree enabled drivers and allocating
separate _HID for each is not feasible. Instead we allocate special _HID
"PRP0001" that means that the match should be done using Device Tree
compatible property using driver's .of_match_table instead if the driver
is missing .acpi_match_table.

If there is a need to distinguish from where the device is enumerated
(DT/ACPI) driver can check dev->of_node or ACPI_COMPATION(dev).

Signed-off-by: Mika Westerberg 
Acked-by: Grant Likely 
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