1. 05 4月, 2016 1 次提交
  2. 24 2月, 2016 1 次提交
  3. 16 1月, 2016 1 次提交
  4. 01 1月, 2016 2 次提交
  5. 15 12月, 2015 1 次提交
    • L
      ACPICA: Debugger: Convert some mechanisms to OSPM specific · f8d31489
      Lv Zheng 提交于
      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: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f8d31489
  6. 22 10月, 2015 3 次提交
    • L
      ACPICA: Debugger: Add thread ID support so that single step mode can only... · f988f24e
      Lv Zheng 提交于
      ACPICA: Debugger: Add thread ID support so that single step mode can only apply to the debugger thread
      
      When the debugger is running in the kernel mode, acpi_db_single_step() may
      also be invoked by the kernel runtime code path but the single stepping
      command prompt may be erronously logged as the kernel logs and runtime code
      path cannot proceed.
      
      This patch fixes this issue by adding acpi_gbl_db_thread_id for the debugger
      thread and preventing acpi_db_single_step() to be invoked from other threads.
      
      It is not suitable to add acpi_thread_id parameter for acpi_os_execute() as
      the function may be implemented as work queue on some hosts. So it is
      better to let the hosts invoke acpi_set_debugger_thread_id(). Currently
      acpiexec is not configured as DEBUGGER_MULTI_THREADED, but we can do this.
      When we do this, it is better to invoke acpi_set_debugger_thread_id() in
      acpi_os_execute() when the execution type is OSL_DEBUGGER_MAIN_THREAD. The
      support should look like:
        create_thread(&tid);
        if (type == OSL_DEBUGGER_MAIN_THREAD)
            acpi_set_debugger_thread_id(tid);
        resume_thread(tid);
      Similarly, semop() may be used for pthread implementation. But this patch
      simply skips debugger thread ID check for application instead of
      introducing such complications as there is no need to skip
      acpi_db_single_step() for an application debugger - acpiexec.
      
      Note that the debugger thread ID can also be used by acpi_os_printf() to
      filter out debugger output. Lv Zheng.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f988f24e
    • L
      ACPICA: Debugger: Fix "quit/exit" command by cleaning up user commands termination logic · af08f9cc
      Lv Zheng 提交于
      ACPICA commit 0dd68e16274cd38224aa4781eddc57dc2cbaa108
      
      The quit/exit commands shouldn't invoke acpi_terminate_debugger() and
      acpi_terminate() right in the user command loop, because when the debugger
      exits, the kernel ACPI subsystem shouldn't be terminated (acpi_terminate())
      and the debugger should only be terminated by its users
      (acpi_terminate_debugger()) rather than being terminated itself. Leaving such
      invocations causes kernel panic when the debugger is shipped in the Linux
      kernel.
      
      This patch fixes this issue. Lv Zheng.
      
      Link: https://github.com/acpica/acpica/commit/0dd68e16Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      af08f9cc
    • B
      ACPICA: Debugger: Update mutexes used for multithreaded debugger · cd64bbf8
      Bob Moore 提交于
      ACPICA commit 6b2701f619040e803313363f516b200e362a9100
      
      Make these mutex objects independent of the deadlock detection mechanism.
      This mechanism caused failures with the multithread debugger.
      
      This patch doesn't affect Linux kernel as debugger is currently not fully
      functioning in the Linux kernel. And the further debugger cleanups will
      take care of handling debugger command signalling correctly instead of
      using such kind of mutexes. So it is safe to leave this patch as it is.
      
      Link: https://github.com/acpica/acpica/commit/6b2701f6Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      cd64bbf8
  7. 15 10月, 2015 1 次提交
  8. 26 8月, 2015 7 次提交
  9. 24 7月, 2015 2 次提交
  10. 02 7月, 2015 1 次提交
    • L
      ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS · f06147f9
      Lv Zheng 提交于
      ACPICA commit 368eb60778b27b6ae94d3658ddc902ca1342a963
      ACPICA commit 70f62a80d65515e1285fdeeb50d94ee6f07df4bd
      ACPICA commit a04dbfa308a48ab0b2d10519c54a6c533c5c8949
      ACPICA commit ebd544ed24c5a4faba11f265e228b7a821a729f5
      
      The following commit is reported to have broken s2ram on some platforms:
       Commit: 0249ed24
       ACPICA: Add option to favor 32-bit FADT addresses.
      The platform reports 2 FACS tables (which is not allowed by ACPI
      specification) and the new 32-bit address favor rule forces OSPMs to use
      the FACS table reported via FADT's X_FIRMWARE_CTRL field.
      
      The root cause of the reported bug might be one of the followings:
      1. BIOS may favor the 64-bit firmware waking vector address when the
         version of the FACS is greater than 0 and Linux currently only supports
         resuming from the real mode, so the 64-bit firmware waking vector has
         never been set and might be invalid to BIOS while the commit enables
         higher version FACS.
      2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the
         FADT while the commit doesn't set the firmware waking vector address of
         the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking
         vector address of the FACS reported by "X_FIRMWARE_CTRL".
      
      This patch excludes the cases that can trigger the bugs caused by the root
      cause 2.
      
      There is no handshaking mechanism can be used by OSPM to tell BIOS which
      FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still
      be used by BIOS and the 0 value of the 32-bit firmware waking vector might
      trigger such failure.
      
      This patch enables the firmware waking vectors for both 32bit/64bit FACS
      tables in order to ensure we can exclude the cases that trigger the bugs
      caused by the root cause 2. The exclusion is split into 2 commits so that
      if it turns out not to be necessary, this single commit can be reverted
      without affecting the useful one. Lv Zheng, Bob Moore.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021
      Link: https://github.com/acpica/acpica/commit/368eb607
      Link: https://github.com/acpica/acpica/commit/70f62a80
      Link: https://github.com/acpica/acpica/commit/a04dbfa3
      Link: https://github.com/acpica/acpica/commit/ebd544edReported-and-tested-by: NOswald Buddenhagen <ossi@kde.org>
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f06147f9
  11. 14 4月, 2015 2 次提交
  12. 05 2月, 2015 1 次提交
  13. 28 11月, 2014 1 次提交
  14. 08 7月, 2014 2 次提交
    • L
      ACPICA: Utilities: Add formatted printing APIs · 80a648c1
      Lv Zheng 提交于
      This patch introduces formatted printing APIs to handle ACPICA specific
      formatted print requirements. Currently only specific OSPMs will use this
      customized printing support, Linux kernel doesn't use these APIs at this
      time. It will be enabled for Linux kernel resident ACPICA after being well
      tested. So currently this patch is a no-op.
      
      The specific formatted printing APIs are useful to ACPICA as:
       1. Some portable applications do not link standard C library, so they
          cannot use standard formatted print APIs directly.
       2. Platform specific printing format may differ and thus not portable, for
          example, u64 is %ull for Linux kernel and is %uI64 for some MSVC
          versions.
       3. Platform specific printing format may conflict with ACPICA's usages
          while it is not possible for ACPICA developers to test their code for
          all platforms. For example, developers may generate %pRxxx while Linux
          kernel treats %pR as structured resource printing and decodes variable
          argument as a "struct resource" pointer.
      This patch solves above issues by introducing the new APIs.
      
      Note that users of such APIs are not introduced in this patch. Users of
      acpi_os_file_vprintf()/acpi_ut_file_printf() need to invoke acpi_os_initialize(),
      this should be taken care by the further patches where such users are
      introduced. Lv Zheng.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      80a648c1
    • L
      ACPICA: OSL: Clean up acpi_os_printf()/acpi_os_vprintf() stubs · 83b80bac
      Lv Zheng 提交于
      This patch is mainly for acpidump where there are redundant
      acpi_os_printf()/acpi_os_vprintf() stubs implemented. This patch cleans up such
      specific implementation by linking acpidump to osunixxf.c/oswinxf.c.
      
      To make acpi_os_printf() exported by osunixxf.c/oswinxf.c to behave as the
      old acpidump specific ones, applications need to:
       1. Initialize acpi_gbl_db_output_flags to ACPI_DB_CONSOLE_OUTPUT.
          This is automatically done by ACPI_INIT_GLOBAL(), applications need to
          link utglobal.o to utilize this mechanism.
       2. Initialize acpi_gbl_output_file to stdout.
          For GCC, assigning stdout to acpi_gbl_output_file using ACPI_INIT_GLOBAL()
          is not possible as stdout is not a constant in GCC environment. As an
          alternative solution, stdout assignment is put into acpi_os_initialize().
          Thus acpi_os_initialize() need to be invoked very early by the
          applications to initialize the default output of acpi_os_printf().
      
      This patch also releases osunixxf.c to the Linux kernel. Lv Zheng.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      83b80bac
  15. 13 5月, 2014 1 次提交
  16. 07 5月, 2014 2 次提交
  17. 21 4月, 2014 4 次提交
  18. 26 3月, 2014 3 次提交
  19. 18 3月, 2014 2 次提交
  20. 27 2月, 2014 1 次提交
  21. 11 2月, 2014 1 次提交