1. 23 Jul, 2018 6 commits
  2. 06 Jun, 2018 1 commit
  3. 24 Apr, 2018 1 commit
  4. 11 Oct, 2017 1 commit
    • Srinivas Pandruvada's avatar
      ACPI / LPIT: Add Low Power Idle Table (LPIT) support · eeb2d80d
      Srinivas Pandruvada authored
      Add functionality to read LPIT table, which provides:
      
       - Sysfs interface to read residency counters via
         /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
         /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
      
      Here the count "low_power_idle_cpu_residency_us" shows the time spent
      by CPU package in low power state.  This is read via MSR interface,
      which points to MSR for PKG C10.
      
      Here the count "low_power_idle_system_residency_us" show the count the
      system was in low power state. This is read via MMIO interface. This
      is mapped to SLP_S0 residency on modern Intel systems. This residency
      is achieved only when CPU is in PKG C10 and all functional blocks are
      in low power state.
      
      It is possible that none of the above counters present or anyone of the
      counter present or all counters present.
      
      For example: On my Kabylake system both of the above counters present.
      After suspend to idle these counts updated and prints:
      
       6916179
       6998564
      
      This counter can be read by tools like turbostat to display. Or it can
      be used to debug, if modern systems are reaching desired low power state.
      
       - Provides an interface to read residency counter memory address
      
         This address can be used to get the base address of PMC memory
         mapped IO.  This is utilized by intel_pmc_core driver to print
         more debug information.
      
      In addition, to avoid code duplication to read iomem, removed the read of
      iomem from acpi_os_read_memory() in osl.c and made a common function
      acpi_os_read_iomem(). This new function is used for reading iomem in
      in both osl.c and acpi_lpit.c.
      
      Link: http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdfSigned-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      eeb2d80d
  5. 29 May, 2017 1 commit
  6. 12 May, 2017 1 commit
    • Lv Zheng's avatar
      Revert "ACPI / button: Remove lid_init_state=method mode" · f369fdf4
      Lv Zheng authored
      This reverts commit ecb10b69.
      
      The only expected ACPI control method lid device's usage model is
      
       1. Listen to the lid notification,
       2. Evaluate _LID after being notified by BIOS,
       3. Suspend the system (if users configure to do so) after seeing "close".
      
      It's not ensured that BIOS will notify OS after boot/resume, and
      it's not ensured that BIOS will always generate "open" event upon
      opening the lid.
      
      But there are 2 wrong usage models:
      
       1. When the lid device is responsible for suspend/resume the system,
          userspace requires to see "open" event to be paired with "close" after
          the system is resumed, or it will suspend the system again.
      
       2. When an external monitor connects to the laptop attached docks,
          userspace requires to see "close" event after the system is resumed so
          that it can determine whether the internal display should remain dark
          and the external display should be lit on.
      
      After we made default kernel behavior to be suitable for usage model 1,
      users of usage model 2 start to report regressions for such behavior
      change.
      
      Reversion of button.lid_init_state=method doesn't actually reverts to old
      default behavior as doing so can enter a regression loop, but facilitates
      users to work the reported regressions around with
      button.lid_init_state=method.
      
      Fixes: ecb10b69 (ACPI / button: Remove lid_init_state=method mode)
      Cc: 4.11+ <stable@vger.kernel.org> # 4.11+
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=195455
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=1430259Tested-by: default avatarSteffen Weber <steffen.weber@gmail.com>
      Tested-by: default avatarJulian Wiedmann <julian.wiedmann@jwi.name>
      Reported-by: default avatarJoachim Frieben <jfrieben@hotmail.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f369fdf4
  7. 19 Apr, 2017 1 commit
  8. 28 Mar, 2017 1 commit
  9. 17 Mar, 2017 1 commit
  10. 28 Feb, 2017 2 commits
  11. 31 Jan, 2017 1 commit
  12. 06 Dec, 2016 1 commit
  13. 03 Dec, 2016 1 commit
  14. 24 Oct, 2016 4 commits
  15. 29 Sep, 2016 1 commit
  16. 30 Aug, 2016 1 commit
  17. 08 Jul, 2016 5 commits
  18. 18 Apr, 2016 1 commit
    • Lv Zheng's avatar
      ACPI / tables: Convert initrd table override to table upgrade mechanism · 5d881327
      Lv Zheng authored
      This patch converts the initrd table override mechanism to the table
      upgrade mechanism by restricting its usage to the tables released with
      compatibility and more recent revision.
      
      This use case has been encouraged by the ACPI specification:
      
       1. OEMID:
          An OEM-supplied string that identifies the OEM.
      
       2. OEM Table ID:
          An OEM-supplied string that the OEM uses to identify the particular data
          table. This field is particularly useful when defining a definition
          block to distinguish definition block functions. OEM assigns each
          dissimilar table a new OEM Table Id.
      
       3. OEM Revision:
          An OEM-supplied revision number. Larger numbers are assumed to be newer
          revisions.
      
      For OEMs, good practices will ensure consistency when assigning OEMID and
      OEM Table ID fields in any table. The intent of these fields is to allow
      for a binary control system that support services can use. Because many
      support function can be automated, it is useful when a tool can
      programatically determine which table release is a compatible and more
      recent revision of a prior table on the same OEMID and OEM Table ID.
      
      The facility can now be used by the vendors to upgrade wrong tables for bug
      fixing purpose, thus lockdep disabling taint is not suitable for it and it
      should be a default 'y' option to implement the spec encouraged use case.
      
      Note that, by implementing table upgrade inside of ACPICA itself, it is
      possible to remove acpi_table_initrd_override() and tables can be upgraded
      by acpi_install_table() automatically. Though current ACPICA impelentation
      hasn't implemented this, this patched changes the table flag setting timing
      to allow this to be implemented in ACPICA without changing the code here.
      
      Documentation of initrd override mechanism is upgraded accordingly.
      Original-by: default avatarOctavian Purdila <octavian.purdila@intel.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5d881327
  19. 26 Oct, 2015 1 commit
  20. 25 Oct, 2015 1 commit
    • Dustin Byford's avatar
      i2c: add ACPI support for I2C mux ports · 8eb5c87a
      Dustin Byford authored
      Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
      device property compatible string match), enumerating I2C client devices
      connected through an I2C mux needs a little extra work.
      
      This change implements a method for describing an I2C device hierarchy that
      includes mux devices by using an ACPI Device() for each mux channel along
      with an _ADR to set the channel number for the device.  See
      Documentation/acpi/i2c-muxes.txt for a simple example.
      
      To make this work the ismt, i801, and designware pci/platform devs now
      share an ACPI companion with their I2C adapter dev similar to how it's done
      in OF.  This is done on the assumption that power management functions will
      not be called directly on the I2C dev that is sharing the ACPI node.
      Acked-by: Mika Westerberg's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: Mika Westerberg's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarDustin Byford <dustin@cumulusnetworks.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      8eb5c87a
  21. 23 Oct, 2015 1 commit
  22. 07 Aug, 2015 1 commit
  23. 18 Jun, 2015 2 commits
  24. 04 May, 2015 1 commit
  25. 30 Apr, 2015 1 commit
  26. 18 Mar, 2015 1 commit