1. 17 7月, 2012 2 次提交
  2. 18 1月, 2012 1 次提交
  3. 17 1月, 2012 1 次提交
  4. 19 1月, 2011 1 次提交
  5. 02 11月, 2010 1 次提交
  6. 23 1月, 2010 1 次提交
  7. 29 8月, 2009 4 次提交
  8. 27 8月, 2009 1 次提交
  9. 04 4月, 2009 1 次提交
  10. 31 12月, 2008 1 次提交
  11. 23 10月, 2008 1 次提交
  12. 17 7月, 2008 2 次提交
  13. 24 4月, 2008 1 次提交
  14. 23 4月, 2008 3 次提交
  15. 22 10月, 2007 1 次提交
    • K
      Intel IOMMU: DMAR detection and parsing logic · 10e5247f
      Keshavamurthy, Anil S 提交于
      This patch supports the upcomming Intel IOMMU hardware a.k.a.  Intel(R)
      Virtualization Technology for Directed I/O Architecture and the hardware spec
      for the same can be found here
      http://www.intel.com/technology/virtualization/index.htm
      
      FAQ! (questions from akpm, answers from ak)
      
      > So...  what's all this code for?
      >
      > I assume that the intent here is to speed things up under Xen, etc?
      
      Yes in some cases, but not this code.  That would be the Xen version of this
      code that could potentially assign whole devices to guests.  I expect this to
      be only useful in some special cases though because most hardware is not
      virtualizable and you typically want an own instance for each guest.
      
      Ok at some point KVM might implement this too; i likely would use this code
      for this.
      
      > Do we
      > have any benchmark results to help us to decide whether a merge would be
      > justified?
      
      The main advantage for doing it in the normal kernel is not performance, but
      more safety.  Broken devices won't be able to corrupt memory by doing random
      DMA.
      
      Unfortunately that doesn't work for graphics yet, for that need user space
      interfaces for the X server are needed.
      
      There are some potential performance benefits too:
      
      - When you have a device that cannot address the complete address range an
        IOMMU can remap its memory instead of bounce buffering.  Remapping is likely
        cheaper than copying.
      
      - The IOMMU can merge sg lists into a single virtual block.  This could
        potentially speed up SG IO when the device is slow walking SG lists.  [I
        long ago benchmarked 5% on some block benchmark with an old MPT Fusion; but
        it probably depends a lot on the HBA]
      
      And you get better driver debugging because unexpected memory accesses from
      the devices will cause a trappable event.
      
      >
      > Does it slow anything down?
      
      It adds more overhead to each IO so yes.
      
      This patch:
      
      Add support for early detection and parsing of DMAR's (DMA Remapping) reported
      to OS via ACPI tables.
      
      DMA remapping(DMAR) devices support enables independent address translations
      for Direct Memory Access(DMA) from Devices.  These DMA remapping devices are
      reported via ACPI tables and includes pci device scope covered by these DMA
      remapping device.
      
      For detailed info on the specification of "Intel(R) Virtualization Technology
      for Directed I/O Architecture" please see
      http://www.intel.com/technology/virtualization/index.htmSigned-off-by: NAnil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Muli Ben-Yehuda <muli@il.ibm.com>
      Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Christoph Lameter <clameter@sgi.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Len Brown <lenb@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      10e5247f
  16. 03 2月, 2007 6 次提交
  17. 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
  18. 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
  19. 05 8月, 2005 1 次提交
  20. 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
  21. 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