Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 4 年多

通知 15
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 06 2月, 2018 2 次提交
  3. 05 1月, 2018 1 次提交
  5. 27 11月, 2017 3 次提交
  7. 04 10月, 2017 1 次提交
  9. 04 8月, 2017 1 次提交
  11. 20 7月, 2017 2 次提交
  13. 28 6月, 2017 1 次提交
  15. 29 4月, 2017 1 次提交
  17. 09 2月, 2017 2 次提交
  19. 05 1月, 2017 1 次提交
  21. 21 12月, 2016 2 次提交
    • L
      ACPI / osl: Remove deprecated acpi_get_table_with_size()/early_acpi_os_unmap_memory() · 8d3523fb
      由 Lv Zheng 提交于 
      Since all users are cleaned up, remove the 2 deprecated APIs due to no
users.
As a Linux variable rather than an ACPICA variable, acpi_gbl_permanent_mmap
is renamed to acpi_permanent_mmap to have a consistent coding style across
entire Linux ACPI subsystem.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8d3523fb
    • L
      ACPICA: Tables: Back port acpi_get_table_with_size() and... · 174cc718
      由 Lv Zheng 提交于 
      ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

ACPICA commit cac6790954d4d752a083e6122220b8a22febcd07

This patch back ports Linux acpi_get_table_with_size() and
early_acpi_os_unmap_memory() into ACPICA upstream to reduce divergences.

The 2 APIs are used by Linux as table management APIs for long time, it
contains a hidden logic that during the early stage, the mapped tables
should be unmapped before the early stage ends.

During the early stage, tables are handled by the following sequence:
 acpi_get_table_with_size();
 parse the table
 early_acpi_os_unmap_memory();
During the late stage, tables are handled by the following sequence:
 acpi_get_table();
 parse the table
Linux uses acpi_gbl_permanent_mmap to distinguish the early stage and the
late stage.

The reasoning of introducing acpi_get_table_with_size() is: ACPICA will
remember the early mapped pointer in acpi_get_table() and Linux isn't able to
prevent ACPICA from using the wrong early mapped pointer during the late
stage as there is no API provided from ACPICA to be an inverse of
acpi_get_table() to forget the early mapped pointer.

But how ACPICA can work with the early/late stage requirement? Inside of
ACPICA, tables are ensured to be remained in "INSTALLED" state during the
early stage, and they are carefully not transitioned to "VALIDATED" state
until the late stage. So the same logic is in fact implemented inside of
ACPICA in a different way. The gap is only that the feature is not provided
to the OSPMs in an accessible external API style.

It then is possible to fix the gap by providing an inverse of
acpi_get_table() from ACPICA, so that the two Linux sequences can be
combined:
 acpi_get_table();
 parse the table
 acpi_put_table();
In order to work easier with the current Linux code, acpi_get_table() and
acpi_put_table() is implemented in a usage counting based style:
 1. When the usage count of the table is increased from 0 to 1, table is
    mapped and .Pointer is set with the mapping address (VALIDATED);
 2. When the usage count of the table is decreased from 1 to 0, .Pointer
    is unset and the mapping address is unmapped (INVALIDATED).
So that we can deploy the new APIs to Linux with minimal effort by just
invoking acpi_get_table() in acpi_get_table_with_size() and invoking
acpi_put_table() in early_acpi_os_unmap_memory(). Lv Zheng.

Link: https://github.com/acpica/acpica/commit/cac67909Signed-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>
      174cc718
  23. 21 10月, 2016 2 次提交
  25. 10 9月, 2016 2 次提交
    • B
      ACPICA: Update version to 20160831 · cb7d668f
      由 Bob Moore 提交于 
      ACPICA commit 3c8c04c2e8a371018b3a29f5cfe27a241caea48d

Version 20160831

Link: https://github.com/acpica/acpica/commit/3c8c04c2Signed-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>
      cb7d668f
    • L
      ACPICA: Interpreter: Fix MLC issues by switching to new term_list grammar for table loading · de56ba95
      由 Lv Zheng 提交于 
      ACPICA commit 0e24fb67cde08d7df7671d7d7b183490dc79707e

The MLC (Module Level Code) is an ACPICA terminology describing the AML
code out of any control method, its support is an indication of the
interpreter behavior during the table loading.

The original implementation of MLC in ACPICA had several issues:
1. Out of any control method, besides of the object creating opcodes, only
   the code blocks wrapped by "If/Else/While" opcodes were supported.
2. The supported MLC code blocks were executed after loading the table
   rather than being executed right in place.
   ============================================================
   The demo of this order issue is as follows:
     Name (OBJ1, 1)
     If (CND1 == 1)
     {
       Name (OBJ2, 2)
     }
     Name (OBJ3, 3)
   The original MLC support created OBJ2 after OBJ3's creation.
   ============================================================
Other than these limitations, MLC support in ACPICA looks correct. And
supporting this should be easy/natural for ACPICA, but enabling of this was
blocked by some ACPICA internal and OSPM specific initialization order
issues we've fixed recently. The wrong support started from the following
false bug fixing commit:
  Commit: 7f0c826a
  Subject: ACPICA: Add support for module-level executable AML code
  Commit: 9a884ab6
  Subject: ACPICA: Add additional module-level code support
  ...

We can confirm Windows interpreter behavior via reverse engineering means.
It can be proven that not only If/Else/While wrapped code blocks, all
opcodes can be executed at the module level, including operation region
accesses. And it can be proven that the MLC should be executed right in
place, not in such a deferred way executed after loading the table.

And the above facts indeed reflect the spec words around ACPI definition
block tables (DSDT/SSDT/...), the entire table and the Scope object is
defined by the AML specification in BNF style as:
  AMLCode := def_block_header term_list
  def_scope := scope_op pkg_length name_string term_list
The bodies of the scope opening terms (AMLCode/Scope) are all term_list,
thus the table loading should be no difference than the control method
evaluations as the body of the Method is also defined by the AML
specification as term_list:
  def_method := method_op pkg_length name_string method_flags term_list
The only difference is: after evaluating control method, created named
objects may be freed due to no reference, while named objects created by
the table loading should only be freed after unloading the table.

So this patch follows the spec and the de-facto standard behavior, enables
the new grammar (term_list) for the table loading.

By doing so, beyond the fixes to the above issues, we can see additional
differences comparing to the old grammar based table loading:
1. Originally, beyond the scope opening terms (AMLCode/Scope),
   If/Else/While wrapped code blocks under the scope creating terms
   (Device/power_resource/Processor/thermal_zone) are also supported as
   deferred MLC, which violates the spec defined grammar where object_list
   is enforced. With MLC support improved as non-deferred, the interpreter
   parses such scope creating terms as term_list rather object_list like the
   scope opening terms.
   After probing the Windows behavior and proving that it also parses these
   terms as term_list, we submitted an ECR (Engineering Change Request) to
   the ASWG (ACPI Specification Working Group) to clarify this. The ECR is
   titled as "ASL Grammar Clarification for Executable AML Opcodes" and has
   been accepted by the ASWG. The new grammar will appear in ACPI
   specification 6.2.
2. Originally, Buffer/Package/operation_region/create_XXXField/bank_field
   arguments are evaluated in a deferred way after loading the table. With
   MLC support improved, they are also parsed right in place during the
   table loading.
   This is also Windows compliant and the only difference is the removal
   of the debugging messages implemented before acpi_ds_execute_arguments(),
   see Link # [1] for the details. A previous commit should have ensured
   that acpi_check_address_range() won't regress.

Note that enabling this feature may cause regressions due to long term
Linux ACPI support on top of the wrong grammar. So this patch also prepares
a global option to be used to roll back to the old grammar during the
period between a regression is reported and the regression is
root-cause-fixed. Lv Zheng.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=112911 # [1]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=117671 # [1]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=153541 # [1]
Link: https://github.com/acpica/acpica/issues/122
Link: https://bugs.acpica.org/show_bug.cgi?id=963
Link: https://github.com/acpica/acpica/commit/0e24fb67Reported-and-tested-by: NChris Bainbridge <chris.bainbridge@gmail.com>
Reported-by: NEhsan <dashesy@gmail.com>
Reported-and-tested-by: NDutch Guy <lucht_piloot@gmx.net>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
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>
      de56ba95
  27. 13 8月, 2016 4 次提交
  29. 11 7月, 2016 1 次提交
  31. 05 5月, 2016 2 次提交
  33. 09 4月, 2016 1 次提交
  35. 05 4月, 2016 1 次提交
  37. 24 2月, 2016 1 次提交
  39. 16 1月, 2016 2 次提交
  41. 05 1月, 2016 1 次提交
    • R
      ACPICA: Drop Linux-specific waking vector functions · e3e9b577
      由 Rafael J. Wysocki 提交于 
      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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NLv Zheng <lv.zheng@intel.com>
      e3e9b577
  43. 01 1月, 2016 3 次提交
  45. 15 12月, 2015 2 次提交
    • L
      ACPICA: Debugger: Fix runtime stub issues of ACPI_DEBUGGER_EXEC using different stub mechanism · 8a2a2501
      由 Lv Zheng 提交于 
      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: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8a2a2501
    • 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
  47. 22 10月, 2015 1 次提交