1. 04 Apr, 2016 14 commits
  2. 08 Mar, 2016 1 commit
  3. 24 Feb, 2016 1 commit
  4. 21 Feb, 2016 2 commits
    • Sudeep Holla's avatar
      ACPI / sleep: move acpi_processor_sleep to sleep.c · 504997cf
      Sudeep Holla authored
      acpi_processor_sleep is neither related nor used by CPUIdle framework.
      It's used in system suspend/resume path as a syscore operation. It makes
      more sense to move it to acpi/sleep.c where all the S-state transition
      (a.k.a. Linux system suspend/hiberate) related code are present.
      
      Also make it depend on CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT so that
      it's not compiled on architecture like ARM64 where S-states are not
      yet defined in ACPI.
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      504997cf
    • Sudeep Holla's avatar
      ACPI / processor : add support for ACPI0010 processor container · db62fda3
      Sudeep Holla authored
      ACPI 6.0 adds support for optional processor container device which may
      contain child objects that are either processor devices or other processor
      containers. This allows representing hierarchical processor topologies.
      
      It is declared using the _HID of ACPI0010. It is an abstract container
      used to represent CPU topology and should not be used to hotplug
      purposes.
      
      If no matching handler is found for a device in acpi_scan_attach_handler,
      acpi_bus_attach does a default enumeration for those devices with valid
      HID in the acpi namespace. This patch adds a scan handler for these ACPI
      processor containers to avoid default that enumeration and ensures the
      platform devices are not created for them.
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      db62fda3
  5. 02 Feb, 2016 1 commit
  6. 15 Jan, 2016 3 commits
  7. 04 Jan, 2016 1 commit
    • Rafael J. Wysocki's avatar
      ACPICA: Drop Linux-specific waking vector functions · e3e9b577
      Rafael J. Wysocki authored
      Commit f06147f9 (ACPICA: Hardware: Enable firmware waking vector
      for both 32-bit and 64-bit FACS) added three functions that aren't
      present in upstream ACPICA, acpi_hw_set_firmware_waking_vectors(),
      acpi_set_firmware_waking_vectors() and acpi_set_firmware_waking_vector64(),
      to allow Linux to use the previously existing API for setting the
      platform firmware waking vector.
      
      However, that wasn't necessary, since the ACPI sleep support code
      in Linux can be modified to use the upstream ACPICA's API easily
      and the additional functions may be dropped which reduces the code
      size and puts the kernel's ACPICA code more in line with the upstream.
      
      Make the changes as per the above.  While at it, make the relevant
      function desctiption comments reflect the upstream ACPICA's ones.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarLv Zheng <lv.zheng@intel.com>
      e3e9b577
  8. 31 Dec, 2015 7 commits
  9. 14 Dec, 2015 3 commits
    • Lv Zheng's avatar
      ACPI / debugger: Add IO interface to access debugger functionalities · 8cfb0cdf
      Lv Zheng authored
      This patch adds /sys/kernel/debug/acpi/acpidbg, which can be used by
      userspace programs to access ACPICA debugger functionalities.
      
      Known issue:
      1. IO flush support
         acpi_os_notify_command_complete() and acpi_os_wait_command_ready() can
         be used by acpi_dbg module to implement .flush() filesystem operation.
         While this patch doesn't go that far. It then becomes userspace tool's
         duty now to flush old commands before executing new batch mode commands.
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8cfb0cdf
    • Lv Zheng's avatar
      ACPICA: Debugger: Fix runtime stub issues of ACPI_DEBUGGER_EXEC using different stub mechanism · 8a2a2501
      Lv Zheng authored
      ACPICA commit 11522d6b894054fc4d62dd4f9863ec151296b386
      
      The ACPI_DEBUGGER_EXEC is a problem now when the debugger code is compiled
      but runtime disabled. They actually will get executed in this situation.
      Although such executions are harmless if we can correctly make
      acpi_db_single_step() a runtime stub, users may still do not want to see the
      debugger print messages logged into OSPMs' kernel logs when a debugger
      driver is not loaded to enable the debugger during runtime.
      
      This patch fixes this issue by introducing new stub mechanism instead of
      ACPI_DEBUGGER_EXEC. Lv Zheng.
      
      Link: https://github.com/acpica/acpica/commit/11522d6bSigned-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8a2a2501
    • Lv Zheng's avatar
      ACPICA: Debugger: Convert some mechanisms to OSPM specific · f8d31489
      Lv Zheng authored
      The following mechanisms are OSPM specific:
      1. Redirect output destination to console: no file redirection will be
         needed by an in-kernel debugger, there is even no file can be accessed
         when the debugger is running in the kernel mode.
      2. Output command prompts: programs other than acpiexec can have different
         prompt characters and the prompt characters may be implemented as a
         special character sequence to form a char device IO protocol.
      3. Command ready/complete handshake: OSPM debugger may wait more conditions
         to implement OSPM specific semantics (for example, FIFO full/empty
         conditions for O_NONBLOCK or IO open/close conditions).
      Leaving such OSPM specific stuffs in the ACPICA debugger core blocks
      Linux debugger IO driver implementation.
      
      Several new OSL APIs are provided by this patch:
      1. acpi_os_initialize_command_signals: initialize command handshake mechanism
         or any other OSPM specific stuffs.
      2. acpi_os_terminate_command_signals: reversal of
         acpi_os_initialize_command_signals.
      3. acpi_os_wait_command_ready: putting debugger task into wait state when a
         command is not ready. OSPMs can terminate command loop by returning
         AE_CTRL_TERMINATE from this API. Normally, wait_event() or
         wait_for_multiple_object() may be used to implement this API.
      4. acpi_os_notify_command_complete: putting user task into running state when a
         command has been completed. OSPMs can terminate command loop by
         returning AE_CTRL_TERMINATE from this API. Normally, wake_up() or
         set_event() may be used to implement this API.
      This patch also converts current command signaling implementation into a
      generic debugger layer (osgendbg.c) to be used by the existing OSPMs or
      acpiexec, in return, Linux can have chance to implement its own command
      handshake mechanism. This patch also implements acpiexec batch mode in a
      multi-threading mode comaptible style as a demo (this can be confirmed by
      configuring acpiexec into DEBUGGER_MULTI_THREADED mode where the batch mode
      is still working). Lv Zheng.
      
      Note that the OSPM specific command handshake mechanism is required by
      Linux kernel because:
      1. Linux kernel trends to use wait queue to synchronize two threads, using
         mutexes to achieve that will cause false "dead lock" warnings.
      2. The command handshake mechanism implemented by ACPICA is implemented in
         this way because of a design issue in debugger IO streaming. Debugger IO
         outputs are simply cached using a giant buffer, this should be tuned by
         Linux in the future.
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f8d31489
  10. 09 Dec, 2015 1 commit
  11. 08 Dec, 2015 1 commit
  12. 06 Nov, 2015 3 commits
  13. 21 Oct, 2015 2 commits
    • Bob Moore's avatar
      ACPICA: Update version to 20150930 · b3196882
      Bob Moore authored
      ACPICA commit e9c75ca267262326e80d49a290e8387a5963e2d2
      
      Version 20150930.
      
      Link: https://github.com/acpica/acpica/commit/e9c75ca2Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b3196882
    • Lv Zheng's avatar
      ACPI: Enable build of AML interpreter debugger · 4d946f79
      Lv Zheng authored
      This patch enables ACPICA debugger files using a configurable
      CONFIG_ACPI_DEBUGGER configuration item. Those debugger related code that
      was originally masked as ACPI_FUTURE_USAGE now gets unmasked.
      
      Necessary OSL stubs are also added in this patch:
      1. acpi_os_readable(): This should be arch specific in Linux, while this
          patch doesn't introduce real implementation and a complex mechanism to
          allow architecture specific acpi_os_readable() to be implemented to
          validate the address. It may be done by future commits.
      2. acpi_os_get_line(): This is used to obtain debugger command input. This
          patch only introduces a simple KDB concept example in it and the
          example should be co-working with the code implemented in
          acpi_os_printf(). Since this KDB example won't be compiled unless
          ENABLE_DEBUGGER is defined and it seems Linux has already stopped to
          use ENABLE_DEBUGGER, thus do not expect it can work properly.
      
      This patch also cleans up all other ACPI_FUTURE_USAGE surroundings
      accordingly.
      1. Since linkage error can be automatically detected, declaration in the
         headers needn't be surrounded by ACPI_FUTURE_USAGE.
         So only the following separate exported fuction bodies are masked by
         this macro (other exported fucntions may have already been masked at
         entire module level via drivers/acpi/acpica/Makefile):
           acpi_install_exception_handler()
           acpi_subsystem_status()
           acpi_get_system_info()
           acpi_get_statistics()
           acpi_install_initialization_handler()
      2. Since strip can automatically zap the no-user functions, functions that
         are not marked with ACPI_EXPORT_SYMBOL() needn't get surrounded by
         ACPI_FUTURE_USAGE.
         So the following function which is not used by Linux kernel now won't
         get surrounded by this macro:
           acpi_ps_get_name()
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4d946f79