1. 14 6月, 2006 1 次提交
    • B
      ACPI: ACPICA 20060331 · 793c2388
      Bob Moore 提交于
      Implemented header file support for the following
      additional ACPI tables: ASF!, BOOT, CPEP, DBGP, MCFG, SPCR,
      SPMI, TCPA, and WDRT. With this support, all current and
      known ACPI tables are now defined in the ACPICA headers and
      are available for use by device drivers and other software.
      
      Implemented support to allow tables that contain ACPI
      names with invalid characters to be loaded. Previously,
      this would cause the table load to fail, but since
      there are several known cases of such tables on
      existing machines, this change was made to enable
      ACPI support for them. Also, this matches the
      behavior of the Microsoft ACPI implementation.
      https://bugzilla.novell.com/show_bug.cgi?id=147621
      
      Fixed a couple regressions introduced during the memory
      optimization in the 20060317 release. The namespace
      node definition required additional reorganization and
      an internal datatype that had been changed to 8-bit was
      restored to 32-bit. (Valery Podrezov)
      
      Fixed a problem where a null pointer passed to
      acpi_ut_delete_generic_state() could be passed through
      to acpi_os_release_object which is unexpected. Such
      null pointers are now trapped and ignored, matching
      the behavior of the previous implementation before the
      deployment of acpi_os_release_object().  (Valery Podrezov,
      Fiodor Suietov)
      
      Fixed a memory mapping leak during the deletion of
      a SystemMemory operation region where a cached memory
      mapping was not deleted. This became a noticeable problem
      for operation regions that are defined within frequently
      used control methods. (Dana Meyers)
      
      Reorganized the ACPI table header files into two main
      files: one for the ACPI tables consumed by the ACPICA core,
      and another for the miscellaneous ACPI tables that are
      consumed by the drivers and other software. The various
      FADT definitions were merged into one common section and
      three different tables (ACPI 1.0, 1.0+, and 2.0)
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      793c2388
  2. 20 1月, 2006 1 次提交
    • B
      [ACPI] ACPICA 20060113 · 4a90c7e8
      Bob Moore 提交于
      Added 2006 copyright.
      
      At SuSE's suggestion, enabled all error messages
      without enabling function tracing, ie with CONFIG_ACPI_DEBUG=n
      
      Replaced all instances of the ACPI_DEBUG_PRINT macro invoked at
      the ACPI_DB_ERROR and ACPI_DB_WARN debug levels with
      the ACPI_REPORT_ERROR and ACPI_REPORT_WARNING macros,
      respectively. This preserves all error and warning messages
      in the non-debug version of the ACPICA code (this has been
      referred to as the "debug lite" option.) Over 200 cases
      were converted to create a total of over 380 error/warning
      messages across the ACPICA code. This increases the code
      and data size of the default non-debug version by about 13K.
      Added ACPI_NO_ERROR_MESSAGES flag to enable deleting all messages.
      The size of the debug version remains about the same.
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      4a90c7e8
  3. 05 8月, 2005 1 次提交
  4. 14 7月, 2005 1 次提交
    • R
      ACPICA 20050708 from Bob Moore <robert.moore@intel.com> · f9f4601f
      Robert Moore 提交于
      The use of the CPU stack in the debug version of the
      subsystem has been considerably reduced.  Previously, a
      debug structure was declared in every function that used
      the debug macros.  This structure has been removed in
      favor of declaring the individual elements as parameters
      to the debug functions.  This reduces the cumulative stack
      use during nested execution of ACPI function calls at the
      cost of a small increase in the code size of the debug
      version of the subsystem.  With assistance from Alexey
      Starikovskiy and Len Brown.
      
      Added the ACPI_GET_FUNCTION_NAME macro to enable the
      compiler-dependent headers to define a macro that will
      return the current function name at runtime (such as
      __FUNCTION__ or _func_, etc.) The function name is used
      by the debug trace output.  If ACPI_GET_FUNCTION_NAME
      is not defined in the compiler-dependent header, the
      function name is saved on the CPU stack (one pointer per
      function.) This mechanism is used because apparently there
      exists no standard ANSI-C defined macro that that returns
      the function name.
      
      Alexey Starikovskiy redesigned and reimplemented the
      "Owner ID" mechanism used to track namespace objects
      created/deleted by ACPI tables and control method
      execution.  A bitmap is now used to allocate and free the
      IDs, thus solving the wraparound problem present in the
      previous implementation.  The size of the namespace node
      descriptor was reduced by 2 bytes as a result.
      
      Removed the UINT32_BIT and UINT16_BIT types that were used
      for the bitfield flag definitions within the headers for
      the predefined ACPI tables.  These have been replaced by
      UINT8_BIT in order to increase the code portability of
      the subsystem.  If the use of UINT8 remains a problem,
      we may be forced to eliminate bitfields entirely because
      of a lack of portability.
      
      Alexey Starikovksiy enhanced the performance of
      acpi_ut_update_object_reference.  This is a frequently used
      function and this improvement increases the performance
      of the entire subsystem.
      
      Alexey Starikovskiy fixed several possible memory leaks
      and the inverse - premature object deletion.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      f9f4601f
  5. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4