<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/acpi/internal.h, branch v4.1</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>ACPI / sleep: Introduce CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT</title>
<updated>2015-03-25T11:49:31+00:00</updated>
<author>
<name>Graeme Gregory</name>
<email>graeme.gregory@linaro.org</email>
</author>
<published>2015-03-24T14:02:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6e0a0ea12962a2175a9f47621f9fe7a4c866cb12'/>
<id>6e0a0ea12962a2175a9f47621f9fe7a4c866cb12</id>
<content type='text'>
ACPI 5.1 does not currently support S states for ARM64 hardware but
ACPI code will call acpi_target_system_state() and acpi_sleep_init()
for device power management, so introduce
CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT and select it for x86 and
ia64 only to make sleep functions available, and also introduce stub
function to allow other drivers to function until S states are defined
for ARM64.

It will be no functional change for x86 and IA64.

Suggested-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Acked-by: Lorenzo Pieralisi &lt;lorenzo.pieralisi@arm.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Graeme Gregory &lt;graeme.gregory@linaro.org&gt;
Signed-off-by: Tomasz Nowicki &lt;tomasz.nowicki@linaro.org&gt;
Signed-off-by: Hanjun Guo &lt;hanjun.guo@linaro.org&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ACPI 5.1 does not currently support S states for ARM64 hardware but
ACPI code will call acpi_target_system_state() and acpi_sleep_init()
for device power management, so introduce
CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT and select it for x86 and
ia64 only to make sleep functions available, and also introduce stub
function to allow other drivers to function until S states are defined
for ARM64.

It will be no functional change for x86 and IA64.

Suggested-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Acked-by: Lorenzo Pieralisi &lt;lorenzo.pieralisi@arm.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Graeme Gregory &lt;graeme.gregory@linaro.org&gt;
Signed-off-by: Tomasz Nowicki &lt;tomasz.nowicki@linaro.org&gt;
Signed-off-by: Hanjun Guo &lt;hanjun.guo@linaro.org&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'acpi-resources'</title>
<updated>2015-02-10T15:05:16+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2015-02-10T15:05:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8fbcf5ecb336eb6da560f08d60e95b51d318795c'/>
<id>8fbcf5ecb336eb6da560f08d60e95b51d318795c</id>
<content type='text'>
* acpi-resources: (23 commits)
  Merge branch 'pci/host-generic' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci into acpi-resources
  x86/irq, ACPI: Implement ACPI driver to support IOAPIC hotplug
  ACPI: Add interfaces to parse IOAPIC ID for IOAPIC hotplug
  x86/PCI: Refine the way to release PCI IRQ resources
  x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation
  x86/PCI: Fix the range check for IO resources
  PCI: Use common resource list management code instead of private implementation
  resources: Move struct resource_list_entry from ACPI into resource core
  ACPI: Introduce helper function acpi_dev_filter_resource_type()
  ACPI: Add field offset to struct resource_list_entry
  ACPI: Translate resource into master side address for bridge window resources
  ACPI: Return translation offset when parsing ACPI address space resources
  ACPI: Enforce stricter checks for address space descriptors
  ACPI: Set flag IORESOURCE_UNSET for unassigned resources
  ACPI: Normalize return value of resource parser functions
  ACPI: Fix a bug in parsing ACPI Memory24 resource
  ACPI: Add prefetch decoding to the address space parser
  ACPI: Move the window flag logic to the combined parser
  ACPI: Unify the parsing of address_space and ext_address_space
  ACPI: Let the parser return false for disabled resources
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* acpi-resources: (23 commits)
  Merge branch 'pci/host-generic' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci into acpi-resources
  x86/irq, ACPI: Implement ACPI driver to support IOAPIC hotplug
  ACPI: Add interfaces to parse IOAPIC ID for IOAPIC hotplug
  x86/PCI: Refine the way to release PCI IRQ resources
  x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation
  x86/PCI: Fix the range check for IO resources
  PCI: Use common resource list management code instead of private implementation
  resources: Move struct resource_list_entry from ACPI into resource core
  ACPI: Introduce helper function acpi_dev_filter_resource_type()
  ACPI: Add field offset to struct resource_list_entry
  ACPI: Translate resource into master side address for bridge window resources
  ACPI: Return translation offset when parsing ACPI address space resources
  ACPI: Enforce stricter checks for address space descriptors
  ACPI: Set flag IORESOURCE_UNSET for unassigned resources
  ACPI: Normalize return value of resource parser functions
  ACPI: Fix a bug in parsing ACPI Memory24 resource
  ACPI: Add prefetch decoding to the address space parser
  ACPI: Move the window flag logic to the combined parser
  ACPI: Unify the parsing of address_space and ext_address_space
  ACPI: Let the parser return false for disabled resources
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branches 'acpi-video' and 'acpi-soc'</title>
<updated>2015-02-10T15:04:01+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2015-02-10T15:04:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=99e4d89afc75d7bec31420c5aa2fba53e0411f95'/>
<id>99e4d89afc75d7bec31420c5aa2fba53e0411f95</id>
<content type='text'>
* acpi-video:
  ACPI / video: Add disable_native_backlight quirk for Samsung 510R
  ACPI / video: Add disable_native_backlight quirk for Samsung 730U3E/740U3E

* acpi-soc:
  ACPI: add AMD ACPI2Platform device support for x86 system
  ACPI / LPSS: Remove non-existing clock control from Intel Lynxpoint I2C
  ACPI / LPSS: check the result of ioremap()
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* acpi-video:
  ACPI / video: Add disable_native_backlight quirk for Samsung 510R
  ACPI / video: Add disable_native_backlight quirk for Samsung 730U3E/740U3E

* acpi-soc:
  ACPI: add AMD ACPI2Platform device support for x86 system
  ACPI / LPSS: Remove non-existing clock control from Intel Lynxpoint I2C
  ACPI / LPSS: check the result of ioremap()
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI / EC: Add command flushing support.</title>
<updated>2015-02-06T14:48:09+00:00</updated>
<author>
<name>Lv Zheng</name>
<email>lv.zheng@intel.com</email>
</author>
<published>2015-02-06T00:57:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9887d22add48f24ca3a7605c89b0a21ed337f185'/>
<id>9887d22add48f24ca3a7605c89b0a21ed337f185</id>
<content type='text'>
This patch implements the EC command flushing support.

During the grace period indicated by EC_FLAGS_STARTED and EC_FLAGS_STOPPED,
all submitted EC command transactions can be completed and new submissions
are prevented before suspending so that the EC hardware can be ensured to
be in the idle state when the system is resumed.

There is a good indicator for flush support:
All acpi_ec_submit_request() is invoked after checking driver state with
acpi_ec_started() except the first one. This means all code paths can be
flushed as fast as possible by discarding the requests occurred after the
flush operation. The reference increased for such kind of code path is
wrapped by acpi_ec_submit_flushable_request().

Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Tested-by: Ortwin Glück &lt;odi@odi.ch&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch implements the EC command flushing support.

During the grace period indicated by EC_FLAGS_STARTED and EC_FLAGS_STOPPED,
all submitted EC command transactions can be completed and new submissions
are prevented before suspending so that the EC hardware can be ensured to
be in the idle state when the system is resumed.

There is a good indicator for flush support:
All acpi_ec_submit_request() is invoked after checking driver state with
acpi_ec_started() except the first one. This means all code paths can be
flushed as fast as possible by discarding the requests occurred after the
flush operation. The reference increased for such kind of code path is
wrapped by acpi_ec_submit_flushable_request().

Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Tested-by: Ortwin Glück &lt;odi@odi.ch&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI: add AMD ACPI2Platform device support for x86 system</title>
<updated>2015-02-06T14:42:16+00:00</updated>
<author>
<name>Ken Xue</name>
<email>Ken.Xue@amd.com</email>
</author>
<published>2015-02-06T00:27:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=92082a8886f30a1c492a31ac4b5a4966bb64b1a6'/>
<id>92082a8886f30a1c492a31ac4b5a4966bb64b1a6</id>
<content type='text'>
This new feature is to interpret AMD specific ACPI device to
platform device such as I2C, UART, GPIO found on AMD CZ and
later chipsets. It based on example intel LPSS. Now, it can
support AMD I2C, UART and GPIO.

Signed-off-by: Ken Xue &lt;Ken.Xue@amd.com&gt;
Acked-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This new feature is to interpret AMD specific ACPI device to
platform device such as I2C, UART, GPIO found on AMD CZ and
later chipsets. It based on example intel LPSS. Now, it can
support AMD I2C, UART and GPIO.

Signed-off-by: Ken Xue &lt;Ken.Xue@amd.com&gt;
Acked-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86/irq, ACPI: Implement ACPI driver to support IOAPIC hotplug</title>
<updated>2015-02-05T14:09:26+00:00</updated>
<author>
<name>Jiang Liu</name>
<email>jiang.liu@linux.intel.com</email>
</author>
<published>2015-02-05T05:44:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c183619b63ec934110e3a173a34b414e26869f96'/>
<id>c183619b63ec934110e3a173a34b414e26869f96</id>
<content type='text'>
Enable support of IOAPIC hotplug by:
1) reintroducing ACPI based IOAPIC driver
2) enhance pci_root driver to hook hotplug events

The ACPI IOAPIC driver is always enabled if all of ACPI, PCI and IOAPIC
are enabled.

Signed-off-by: Jiang Liu &lt;jiang.liu@linux.intel.com&gt;
Cc: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: Joerg Roedel &lt;joro@8bytes.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Rafael J. Wysocki &lt;rjw@rjwysocki.net&gt;
Cc: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Yinghai Lu &lt;yinghai@kernel.org&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Len Brown &lt;lenb@kernel.org&gt;
Link: http://lkml.kernel.org/r/1414387308-27148-19-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Enable support of IOAPIC hotplug by:
1) reintroducing ACPI based IOAPIC driver
2) enhance pci_root driver to hook hotplug events

The ACPI IOAPIC driver is always enabled if all of ACPI, PCI and IOAPIC
are enabled.

Signed-off-by: Jiang Liu &lt;jiang.liu@linux.intel.com&gt;
Cc: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: Joerg Roedel &lt;joro@8bytes.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Rafael J. Wysocki &lt;rjw@rjwysocki.net&gt;
Cc: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Yinghai Lu &lt;yinghai@kernel.org&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Len Brown &lt;lenb@kernel.org&gt;
Link: http://lkml.kernel.org/r/1414387308-27148-19-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI / EC: Fix issues related to the SCI_EVT handling</title>
<updated>2015-01-23T21:06:49+00:00</updated>
<author>
<name>Lv Zheng</name>
<email>lv.zheng@intel.com</email>
</author>
<published>2015-01-14T11:28:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=74443bbed72ab22ee005ecb6ecdc657a8018e1db'/>
<id>74443bbed72ab22ee005ecb6ecdc657a8018e1db</id>
<content type='text'>
This patch fixes 2 issues related to the draining behavior. But it doesn't
implement the draining support, it only cleans up code so that further
draining support is possible.

The draining behavior is expected by some platforms (for example, Samsung)
where SCI_EVT is set only once for a set of events and might be cleared for
the very first QR_EC command issued after SCI_EVT is set. EC firmware on
such platforms will return 0x00 to indicate "no outstanding event". Thus
after seeing an SCI_EVT indication, EC driver need to fetch events until
0x00 returned (see acpi_ec_clear()).

Issue 1 - acpi_ec_submit_query():
It's reported on Samsung laptops that SCI_EVT isn't checked when the
transactions are advanced in ec_poll(), which leads to SCI_EVT triggering
source lost:
 If no EC GPE IRQs are arrived after that, EC driver cannot detect this
 event and handle it.
See comment 244/247 for kernel bugzilla 44161.
This patch fixes this issue by moving SCI_EVT checks into
advance_transaction(). So that SCI_EVT is checked each time we are going to
handle the EC firmware indications. And this check will happen for both IRQ
context and task context.
Since after doing that, SCI_EVT is also checked after completing a
transaction, ec_check_sci() and ec_check_sci_sync() can be removed.

Issue 2 - acpi_ec_complete_query():
We expect to clear EC_FLAGS_QUERY_PENDING to allow queuing another draining
QR_EC after writing a QR_EC command and before reading the event. After
reading the event, SCI_EVT might be cleared by the firmware, thus it may
not be possible to queue such a draining QR_EC at that time.
But putting the EC_FLAGS_QUERY_PENDING clearing code after
start_transaction() is wrong as there are chances that after
start_transaction(), QR_EC can fail to be sent. If this happens,
EC_FLAG_QUERY_PENDING will be cleared earlier. As a consequence, the
draining QR_EC will also be queued earlier than expected.
This patch also moves this code into advance_transaction() where QR_EC is
just sent (ACPI_EC_COMMAND_POLL flagged) to fix this issue.

Notes:
1. After introducing the 2 SCI_EVT related handlings into
   advance_transaction(), a next QR_EC can be queued right after writing
   the current QR_EC command and before reading the event. But this still
   hasn't implemented the draining behavior as the draining support
   requires:
     If a previous returned event value isn't 0x00, a draining QR_EC need
     to be issued even when SCI_EVT isn't set.
2. In this patch, acpi_os_execute() is also converted into a seperate work
   item to avoid invoking kmalloc() in the atomic context. We can do this
   because of the previous global lock fix.
3. Originally, EC_FLAGS_EVENT_PENDING is also used to avoid queuing up
   multiple work items (created by acpi_os_execute()), this can be covered
   by only using a single work item. But this patch still keeps this flag
   as there are different usages in the driver initialization steps relying
   on this flag.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161
Reported-by: Kieran Clancy &lt;clancy.kieran@gmail.com&gt;
Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch fixes 2 issues related to the draining behavior. But it doesn't
implement the draining support, it only cleans up code so that further
draining support is possible.

The draining behavior is expected by some platforms (for example, Samsung)
where SCI_EVT is set only once for a set of events and might be cleared for
the very first QR_EC command issued after SCI_EVT is set. EC firmware on
such platforms will return 0x00 to indicate "no outstanding event". Thus
after seeing an SCI_EVT indication, EC driver need to fetch events until
0x00 returned (see acpi_ec_clear()).

Issue 1 - acpi_ec_submit_query():
It's reported on Samsung laptops that SCI_EVT isn't checked when the
transactions are advanced in ec_poll(), which leads to SCI_EVT triggering
source lost:
 If no EC GPE IRQs are arrived after that, EC driver cannot detect this
 event and handle it.
See comment 244/247 for kernel bugzilla 44161.
This patch fixes this issue by moving SCI_EVT checks into
advance_transaction(). So that SCI_EVT is checked each time we are going to
handle the EC firmware indications. And this check will happen for both IRQ
context and task context.
Since after doing that, SCI_EVT is also checked after completing a
transaction, ec_check_sci() and ec_check_sci_sync() can be removed.

Issue 2 - acpi_ec_complete_query():
We expect to clear EC_FLAGS_QUERY_PENDING to allow queuing another draining
QR_EC after writing a QR_EC command and before reading the event. After
reading the event, SCI_EVT might be cleared by the firmware, thus it may
not be possible to queue such a draining QR_EC at that time.
But putting the EC_FLAGS_QUERY_PENDING clearing code after
start_transaction() is wrong as there are chances that after
start_transaction(), QR_EC can fail to be sent. If this happens,
EC_FLAG_QUERY_PENDING will be cleared earlier. As a consequence, the
draining QR_EC will also be queued earlier than expected.
This patch also moves this code into advance_transaction() where QR_EC is
just sent (ACPI_EC_COMMAND_POLL flagged) to fix this issue.

Notes:
1. After introducing the 2 SCI_EVT related handlings into
   advance_transaction(), a next QR_EC can be queued right after writing
   the current QR_EC command and before reading the event. But this still
   hasn't implemented the draining behavior as the draining support
   requires:
     If a previous returned event value isn't 0x00, a draining QR_EC need
     to be issued even when SCI_EVT isn't set.
2. In this patch, acpi_os_execute() is also converted into a seperate work
   item to avoid invoking kmalloc() in the atomic context. We can do this
   because of the previous global lock fix.
3. Originally, EC_FLAGS_EVENT_PENDING is also used to avoid queuing up
   multiple work items (created by acpi_os_execute()), this can be covered
   by only using a single work item. But this patch still keeps this flag
   as there are different usages in the driver initialization steps relying
   on this flag.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161
Reported-by: Kieran Clancy &lt;clancy.kieran@gmail.com&gt;
Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI: Add support for device specific properties</title>
<updated>2014-11-04T20:58:21+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2014-10-21T11:33:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ffdcd955c3078af3ce117edcfce80fde1a512bed'/>
<id>ffdcd955c3078af3ce117edcfce80fde1a512bed</id>
<content type='text'>
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", &lt;VALUE1&gt;},
			Package () {"name2", &lt;VALUE2&gt;},
			...
		}
	})

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 &lt;hanjun.guo@linaro.org&gt;
Reviewed-by: Josh Triplett &lt;josh@joshtriplett.org&gt;
Reviewed-by: Grant Likely &lt;grant.likely@linaro.org&gt;
Signed-off-by: Darren Hart &lt;dvhart@linux.intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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", &lt;VALUE1&gt;},
			Package () {"name2", &lt;VALUE2&gt;},
			...
		}
	})

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 &lt;hanjun.guo@linaro.org&gt;
Reviewed-by: Josh Triplett &lt;josh@joshtriplett.org&gt;
Reviewed-by: Grant Likely &lt;grant.likely@linaro.org&gt;
Signed-off-by: Darren Hart &lt;dvhart@linux.intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI / fan: use acpi_device_xxx_power instead of acpi_bus equivelant</title>
<updated>2014-10-10T05:57:12+00:00</updated>
<author>
<name>Aaron Lu</name>
<email>aaron.lu@intel.com</email>
</author>
<published>2013-11-19T07:43:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=2bb3a2bf9939f3361e25045f4ef7b136b864c3b8'/>
<id>2bb3a2bf9939f3361e25045f4ef7b136b864c3b8</id>
<content type='text'>
When we have the acpi_device pointer, there is no need to pass the
device's handle to the acpi_bus_xxx_power functions to get/set/update
the device's power state, instead, use the acpi_device_xxx_power
functions directly.

To make this happen for fan module, export acpi_device_update_power.

Signed-off-by: Aaron Lu &lt;aaron.lu@intel.com&gt;
Signed-off-by: Zhang Rui &lt;rui.zhang@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When we have the acpi_device pointer, there is no need to pass the
device's handle to the acpi_bus_xxx_power functions to get/set/update
the device's power state, instead, use the acpi_device_xxx_power
functions directly.

To make this happen for fan module, export acpi_device_update_power.

Signed-off-by: Aaron Lu &lt;aaron.lu@intel.com&gt;
Signed-off-by: Zhang Rui &lt;rui.zhang@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI: make acpi_create_platform_device() an external API</title>
<updated>2014-10-10T05:56:20+00:00</updated>
<author>
<name>Zhang Rui</name>
<email>rui.zhang@intel.com</email>
</author>
<published>2014-03-14T06:06:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=083bf668cb70e47b84db64856606e94beac87f01'/>
<id>083bf668cb70e47b84db64856606e94beac87f01</id>
<content type='text'>
Signed-off-by: Zhang Rui &lt;rui.zhang@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Zhang Rui &lt;rui.zhang@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
