1. 14 Sep, 2017 1 commit
  2. 20 Jul, 2017 1 commit
  3. 04 Jul, 2017 1 commit
  4. 07 Jun, 2017 1 commit
  5. 05 Jun, 2017 1 commit
  6. 26 Apr, 2017 1 commit
    • Hans de Goede's avatar
      ACPI / bus: Introduce a list of ids for "always present" devices · b7ecf663
      Hans de Goede authored
      Several Bay / Cherry Trail devices (all of which ship with Windows 10) hide
      the LPSS PWM controller in ACPI, typically the _STA method looks like this:
      
          Method (_STA, 0, NotSerialized)  // _STA: Status
          {
              If (OSID == One)
              {
                  Return (Zero)
              }
      
              Return (0x0F)
          }
      
      Where OSID is some dark magic seen in all Cherry Trail ACPI tables making
      the machine behave differently depending on which OS it *thinks* it is
      booting, this gets set in a number of ways which we cannot control, on
      some newer machines it simple hardcoded to "One" aka win10.
      
      This causes the PWM controller to get hidden, which means Linux cannot
      control the backlight level on cht based tablets / laptops.
      
      Since loading the driver for this does no harm (the only in kernel user
      of it is the i915 driver, which will only uses it when it needs it), this
      commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
      for the LPSS PWM device, fixing the lack of backlight control.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      [ rjw: Rename the new file to utils.c ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b7ecf663
  7. 11 Mar, 2017 1 commit
  8. 07 Feb, 2017 1 commit
  9. 21 Dec, 2016 1 commit
  10. 30 Nov, 2016 1 commit
  11. 24 Nov, 2016 2 commits
  12. 26 Sep, 2016 1 commit
  13. 21 Sep, 2016 1 commit
  14. 12 Sep, 2016 1 commit
  15. 21 Jul, 2016 1 commit
    • Sudeep Holla's avatar
      ACPI / processor_idle: Add support for Low Power Idle(LPI) states · a36a7fec
      Sudeep Holla authored
      ACPI 6.0 introduced an optional object _LPI that provides an alternate
      method to describe Low Power Idle states. It defines the local power
      states for each node in a hierarchical processor topology. The OSPM can
      use _LPI object to select a local power state for each level of processor
      hierarchy in the system. They used to produce a composite power state
      request that is presented to the platform by the OSPM.
      
      Since multiple processors affect the idle state for any non-leaf hierarchy
      node, coordination of idle state requests between the processors is
      required. ACPI supports two different coordination schemes: Platform
      coordinated and  OS initiated.
      
      This patch adds initial support for Platform coordination scheme of LPI.
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a36a7fec
  16. 08 Jul, 2016 1 commit
  17. 06 Jul, 2016 2 commits
    • Prakash, Prashanth's avatar
      ACPI / bus: Support for platform initiated graceful shutdown · baa0c019
      Prakash, Prashanth authored
      This patch adds support for platform initited graceful shutdown as
      described in sections 5.6.6(Table-143) and 6.3.5.1 of ACPI 6.1 spec
      
      The OSPM will get a graceful shutdown request via a Notify operator
      on \_SB device with a value of 0x81 per section 5.6.6. Following the
      shutdown request from platform the OSPM needs to follow the
      processing sequence as described in section 6.2.5.1.
      
      v3
      * Switched to regular work with delays from delayed work
      * Dropped changes to actypes.h
      * Small style changes
      
      v2
      * Switched from standalone driver to a simple notify handler
      
      v1
      * Initial
      
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Signed-off-by: default avatarPrashanth Prakash <pprakash@codeaurora.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      baa0c019
    • Baoquan He's avatar
      ACPI / bus: Correct the comments about acpi_subsystem_init() · 3af03f77
      Baoquan He authored
      In acpi_subsystem_init(), function acpi_enable_subsystem() is
      called to do the real job. However with different flags passed to
      acpi_enable_subsystem(), different code is executed.
      
      In acpi_subsystem_init(), with "~ACPI_NO_ACPI_ENABLE" passed in, it
      will only switch over the platform to the ACPI mode. The remaining
      part of acpi_enable_subsystem() is done when acpi_bus_init() is
      called.
      
      So the comments above acpi_subsystem_init() is not exact, change it
      here.
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3af03f77
  18. 23 Jun, 2016 1 commit
  19. 07 Jun, 2016 1 commit
    • Lv Zheng's avatar
      ACPI / EC: Fix a boot EC regresion by restoring boot EC support for the DSDT EC · dcf15cbd
      Lv Zheng authored
      According to the Windows probing result, during the table loading, the EC
      device described in the ECDT should be used. And the ECDT EC is also
      effective during the period the namespace objects are initialized (we can
      see a separate process executing _STA/_INI on Windows before executing
      other device specific control methods, for example, EC._REG). During the
      device enumration, the EC device described in the DSDT should be used. But
      there are differences between Linux and Windows around the device probing
      order. Thus in Linux, we should enable the DSDT EC as early as possible
      before enumerating devices in order not to trigger issues related to the
      device enumeration order differences.
      
      This patch thus converts acpi_boot_ec_enable() into acpi_ec_dsdt_probe() to
      fix the gap. This also fixes a user reported regression triggered after we
      switched the "table loading"/"ECDT support" to be ACPI spec 2.0 compliant.
      
      Fixes: 59f0aa94 (ACPI 2.0 / ECDT: Remove early namespace reference from EC)
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=119261Reported-and-tested-by: default avatarGabriele Mazzotta <gabriele.mzt@gmail.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      dcf15cbd
  20. 09 Apr, 2016 1 commit
  21. 26 Mar, 2016 1 commit
    • Srinivas Pandruvada's avatar
      ACPI / processor: Request native thermal interrupt handling via _OSC · a2121167
      Srinivas Pandruvada authored
      There are several reports of freeze on enabling HWP (Hardware PStates)
      feature on Skylake-based systems by the Intel P-states driver. The root
      cause is identified as the HWP interrupts causing BIOS code to freeze.
      
      HWP interrupts use the thermal LVT which can be handled by Linux
      natively, but on the affected Skylake-based systems SMM will respond
      to it by default.  This is a problem for several reasons:
       - On the affected systems the SMM thermal LVT handler is broken (it
         will crash when invoked) and a BIOS update is necessary to fix it.
       - With thermal interrupt handled in SMM we lose all of the reporting
         features of the arch/x86/kernel/cpu/mcheck/therm_throt driver.
       - Some thermal drivers like x86-package-temp depend on the thermal
         threshold interrupts signaled via the thermal LVT.
       - The HWP interrupts are useful for debugging and tuning
         performance (if the kernel can handle them).
      The native handling of thermal interrupts needs to be enabled
      because of that.
      
      This requires some way to tell SMM that the OS can handle thermal
      interrupts.  That can be done by using _OSC/_PDC in processor
      scope very early during ACPI initialization.
      
      The meaning of _OSC/_PDC bit 12 in processor scope is whether or
      not the OS supports native handling of interrupts for Collaborative
      Processor Performance Control (CPPC) notifications.  Since on
      HWP-capable systems CPPC is a firmware interface to HWP, setting
      this bit effectively tells the firmware that the OS will handle
      thermal interrupts natively going forward.
      
      For details on _OSC/_PDC refer to:
      http://www.intel.com/content/www/us/en/standards/processor-vendor-specific-acpi-specification.html
      
      To implement the _OSC/_PDC handshake as described, introduce a new
      function, acpi_early_processor_osc(), that walks the ACPI
      namespace looking for ACPI processor objects and invokes _OSC for
      them with bit 12 in the capabilities buffer set and terminates the
      namespace walk on the first success.
      
      Also modify intel_thermal_interrupt() to clear HWP status bits in
      the HWP_STATUS MSR to acknowledge HWP interrupts (which prevents
      them from firing continuously).
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      [ rjw: Subject & changelog, function rename ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a2121167
  22. 16 Feb, 2016 1 commit
  23. 22 Dec, 2015 2 commits
  24. 14 Dec, 2015 2 commits
  25. 15 Sep, 2015 1 commit
  26. 06 Aug, 2015 1 commit
  27. 17 Jul, 2015 3 commits
  28. 08 Jul, 2015 1 commit
  29. 10 Jun, 2015 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / init: Switch over platform to the ACPI mode later · b064a8fa
      Rafael J. Wysocki authored
      Commit 73f7d1ca "ACPI / init: Run acpi_early_init() before
      timekeeping_init()" moved the ACPI subsystem initialization,
      including the ACPI mode enabling, to an earlier point in the
      initialization sequence, to allow the timekeeping subsystem
      use ACPI early.  Unfortunately, that resulted in boot regressions
      on some systems and the early ACPI initialization was moved toward
      its original position in the kernel initialization code by commit
      c4e1acbb "ACPI / init: Invoke early ACPI initialization later".
      
      However, that turns out to be insufficient, as boot is still broken
      on the Tyan S8812 mainboard.
      
      To fix that issue, split the ACPI early initialization code into
      two pieces so the majority of it still located in acpi_early_init()
      and the part switching over the platform into the ACPI mode goes into
      a new function, acpi_subsystem_init(), executed at the original early
      ACPI initialization spot.
      
      That fixes the Tyan S8812 boot problem, but still allows ACPI
      tables to be loaded earlier which is useful to the EFI code in
      efi_enter_virtual_mode().
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
      Fixes: 73f7d1ca "ACPI / init: Run acpi_early_init() before timekeeping_init()"
      Reported-and-tested-by: default avatarMarius Tolzmann <tolzmann@molgen.mpg.de>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarToshi Kani <toshi.kani@hp.com>
      Reviewed-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Reviewed-by: default avatarLee, Chun-Yi <jlee@suse.com>
      b064a8fa
  30. 26 Mar, 2015 1 commit
  31. 15 Sep, 2014 1 commit
  32. 19 Jul, 2014 1 commit
  33. 31 May, 2014 1 commit
    • Lv Zheng's avatar
      ACPI: Fix x86 regression related to early mapping size limitation · 4fc0a7e8
      Lv Zheng authored
      The following warning message is triggered:
       WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:136 __early_ioremap+0x11f/0x1f2()
       Modules linked in:
       CPU: 0 PID: 0 Comm: swapper Not tainted 3.15.0-rc1-00017-g86dfc6f3-dirty #298
       Hardware name: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x036.091920111209 09/19/2011
        0000000000000009 ffffffff81b75c40 ffffffff817c627b 0000000000000000
        ffffffff81b75c78 ffffffff81067b5d 000000000000007b 8000000000000563
        00000000b96b20dc 0000000000000001 ffffffffff300e0c ffffffff81b75c88
       Call Trace:
        [<ffffffff817c627b>] dump_stack+0x45/0x56
        [<ffffffff81067b5d>] warn_slowpath_common+0x7d/0xa0
        [<ffffffff81067c3a>] warn_slowpath_null+0x1a/0x20
        [<ffffffff81d4b9d5>] __early_ioremap+0x11f/0x1f2
        [<ffffffff81d4bc5b>] early_ioremap+0x13/0x15
        [<ffffffff81d2b8f3>] __acpi_map_table+0x13/0x18
        [<ffffffff817b8d1a>] acpi_os_map_memory+0x26/0x14e
        [<ffffffff813ff018>] acpi_tb_acquire_table+0x42/0x70
        [<ffffffff813ff086>] acpi_tb_validate_table+0x27/0x37
        [<ffffffff813ff0e5>] acpi_tb_verify_table+0x22/0xd8
        [<ffffffff813ff6a8>] acpi_tb_install_non_fixed_table+0x60/0x1c9
        [<ffffffff81d61024>] acpi_tb_parse_root_table+0x218/0x26a
        [<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120
        [<ffffffff81d610cd>] acpi_initialize_tables+0x57/0x59
        [<ffffffff81d5f25d>] acpi_table_init+0x1b/0x99
        [<ffffffff81d2bca0>] acpi_boot_table_init+0x1e/0x85
        [<ffffffff81d23043>] setup_arch+0x99d/0xcc6
        [<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120
        [<ffffffff81d1bbbe>] start_kernel+0x8b/0x415
        [<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120
        [<ffffffff81d1b5ee>] x86_64_start_reservations+0x2a/0x2c
        [<ffffffff81d1b72e>] x86_64_start_kernel+0x13e/0x14d
       ---[ end trace 11ae599a1898f4e7 ]---
      when installing the following table during early stage:
       ACPI: SSDT 0x00000000B9638018 07A0C4 (v02 INTEL  S2600CP  00004000 INTL 20100331)
      The regression is caused by the size limitation of the x86 early IO mapping.
      
      The root cause is:
       1. ACPICA doesn't split IO memory mapping and table mapping;
       2. Linux x86 OSL implements acpi_os_map_memory() using a size limited fix-map
          mechanism during early boot stage, which is more suitable for only IO
          mappings.
      
      This patch fixes this issue by utilizing acpi_gbl_verify_table_checksum to
      disable the table mapping during early stage and enabling it again for the
      late stage. In this way, the normal code path is not affected. Then after
      the code related to the root cause is cleaned up, the early checksum
      verification can be easily re-enabled.
      
      A new boot parameter - acpi_force_table_verification is introduced for
      the platforms that require the checksum verification to stop loading bad
      tables.
      
      This fix also covers the checksum verification for the table overrides. Now
      large tables can also be overridden using the initrd override mechanism.
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Reported-and-tested-by: default avatarYuanhan Liu <yuanhan.liu@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4fc0a7e8
  34. 26 May, 2014 1 commit