1. 15 9月, 2015 1 次提交
    • R
      ACPI / property: Add support for data-only subnodes · 445b0eb0
      Rafael J. Wysocki 提交于
      In some cases, the information expressed via device properties is
      hierarchical by nature.  For example, the properties of a composite
      device consisting of multiple semi-dependent components may need
      to be represented in the form of a tree of property data sets
      corresponding to specific components of the device.
      
      Unfortunately, using ACPI device objects for this purpose turns out
      to be problematic, mostly due to the assumption made by some operating
      systems (that platform firmware generally needs to work with) that
      each device object in the ACPI namespace represents a device requiring
      a separate driver.  That assumption leads to complications which
      reportedly are impractically difficult to overcome and a different
      approach is needed for the sake of interoperability.
      
      The approach implemented here is based on extending _DSD via pointers
      (links) to additional ACPI objects returning data packages formatted
      in accordance with the _DSD formatting rules defined by Section 6.2.5
      of ACPI 6.  Those additional objects are referred to as data-only
      subnodes of the device object containing the _DSD pointing to them.
      
      The links to them need to be located in a separate section of the
      _DSD data package following UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b
      referred to as the Hierarchical Data Extension UUID as defined in [1].
      Each of them is represented by a package of two strings.  The first
      string in that package (the key) is regarded as the name of the
      data-only subnode pointed to by the link.  The second string in it
      (the target) is expected to hold the ACPI namespace path (possibly
      utilizing the usual ACPI namespace search rules) of an ACPI object
      evaluating to a data package extending the _DSD.
      
      The device properties initialization code follows those links,
      creates a struct acpi_data_node object for each of them to store
      the data returned by the ACPI object pointed to by it and processes
      those data recursively (which may lead to the creation of more
      struct acpi_data_node objects if the returned data package contains
      the Hierarchical Data Extension UUID section with more links in it).
      
      All of the struct acpi_data_node objects are present until the the
      ACPI device object containing the _DSD with links to them is deleted
      and they are deleted along with that object.
      
      [1]: http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdfSigned-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      445b0eb0
  2. 26 8月, 2015 8 次提交
  3. 25 8月, 2015 2 次提交
    • A
      ACPI: Decouple ACPI idle and ACPI processor drivers · 5f05586c
      Ashwin Chaugule 提交于
      This patch introduces a new Kconfig symbol, ACPI_PROCESSOR_IDLE,
      which is auto selected by architectures which support the ACPI
      based C states for CPU Idle management.
      
      The processor_idle driver in its present form contains declarations
      specific to X86 and IA64. Since there are no reasonable defaults
      for other architectures e.g. ARM64, the driver is selected only for
      X86 or IA64.
      
      This helps in decoupling the ACPI processor_driver from the ACPI
      processor_idle driver which is useful for the upcoming alternative
      patchwork for controlling CPU Performance (CPPC) and CPU Idle (LPI).
      Signed-off-by: NAshwin Chaugule <ashwin.chaugule@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5f05586c
    • A
      ACPI: Split out ACPI PSS from ACPI Processor driver · 239708a3
      Ashwin Chaugule 提交于
      The ACPI processor driver is currently tied too closely
      to the ACPI P-states (PSS) and other related constructs
      for controlling CPU performance.
      
      The newer ACPI specification (v5.1 onwards) introduces
      alternative methods to PSS. These new mechanisms are
      described within each ACPI Processor object and so they
      need to be scanned whenever a new Processor object is detected.
      This patch introduces a new Kconfig symbol to allow for
      finer configurability among the two options for controlling
      performance states. There is no change in functionality and
      the option is auto-selected by the architectures which support it.
      
      A future commit will introduce support for CPPC: A newer method of
      controlling CPU performance. The OS is not expected to support
      CPPC and PSS at the same time, so the Kconfig option lets us make
      the two mutually exclusive at compile time.
      Signed-off-by: NAshwin Chaugule <ashwin.chaugule@linaro.org>
      [ rjw: Changelog ]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      239708a3
  4. 24 7月, 2015 8 次提交
  5. 23 7月, 2015 1 次提交
  6. 08 7月, 2015 1 次提交
  7. 02 7月, 2015 14 次提交
  8. 25 6月, 2015 2 次提交
  9. 23 6月, 2015 1 次提交
  10. 19 6月, 2015 2 次提交