1. 29 4月, 2008 3 次提交
  2. 14 3月, 2008 1 次提交
    • J
      avoid endless loops in lib/swiotlb.c · b15a3891
      Jan Beulich 提交于
      Commit 681cc5cd ("iommu sg merging:
      swiotlb: respect the segment boundary limits") introduced two
      possibilities for entering an endless loop in lib/swiotlb.c:
      
       - if max_slots is zero (possible if mask is ~0UL)
       - if the number of slots requested fits into a swiotlb segment, but is
         too large for the part of a segment which remains after considering
         offset_slots
      
      This fixes them
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b15a3891
  3. 06 2月, 2008 1 次提交
  4. 23 10月, 2007 1 次提交
  5. 17 10月, 2007 1 次提交
  6. 16 10月, 2007 1 次提交
  7. 13 10月, 2007 1 次提交
  8. 22 7月, 2007 1 次提交
  9. 09 5月, 2007 1 次提交
  10. 07 3月, 2007 1 次提交
  11. 13 2月, 2007 1 次提交
    • A
      [PATCH] swiotlb uninlinings · be6b0267
      Andrew Morton 提交于
      Optimise swiotlb.c for size.
      
         text    data     bss     dec     hex filename
         5009      89      64    5162    142a lib/swiotlb.o-before
         4666      89      64    4819    12d3 lib/swiotlb.o-after
      
      For some reason my gcc (4.0.2) doesn't want to tailcall these things.
      
      swiotlb_sync_sg_for_device:
      	pushq	%rbp	#
      	movl	$1, %r8d	#,
      	movq	%rsp, %rbp	#,
      	call	swiotlb_sync_sg	#
      	leave
      	ret
      	.size	swiotlb_sync_sg_for_device, .-swiotlb_sync_sg_for_device
      	.section	.text.swiotlb_sync_sg_for_cpu,"ax",@progbits
      .globl swiotlb_sync_sg_for_cpu
      	.type	swiotlb_sync_sg_for_cpu, @function
      swiotlb_sync_sg_for_cpu:
      	pushq	%rbp	#
      	xorl	%r8d, %r8d	#
      	movq	%rsp, %rbp	#,
      	call	swiotlb_sync_sg	#
      	leave
      	ret
      
      Cc: Jan Beulich <jbeulich@novell.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      be6b0267
  12. 06 2月, 2007 4 次提交
  13. 25 3月, 2006 1 次提交
  14. 12 1月, 2006 1 次提交
    • M
      [PATCH] x86_64: Use function pointers to call DMA mapping functions · 17a941d8
      Muli Ben-Yehuda 提交于
      AK: I hacked Muli's original patch a lot and there were a lot
      of changes - all bugs are probably to blame on me now.
      There were also some changes in the fall back behaviour
      for swiotlb - in particular it doesn't try to use GFP_DMA
      now anymore. Also all DMA mapping operations use the
      same core dma_alloc_coherent code with proper fallbacks now.
      And various other changes and cleanups.
      
      Known problems: iommu=force swiotlb=force together breaks
                      needs more testing.
      
      This patch cleans up x86_64's DMA mapping dispatching code. Right now
      we have three possible IOMMU types: AGP GART, swiotlb and nommu, and
      in the future we will also have Xen's x86_64 swiotlb and other HW
      IOMMUs for x86_64. In order to support all of them cleanly, this
      patch:
      
      - introduces a struct dma_mapping_ops with function pointers for each
        of the DMA mapping operations of gart (AMD HW IOMMU), swiotlb
        (software IOMMU) and nommu (no IOMMU).
      
      - gets rid of:
      
        if (swiotlb)
            return swiotlb_xxx();
      
      - PCI_DMA_BUS_IS_PHYS is now checked against the dma_ops being set
      This makes swiotlb faster by avoiding double copying in some cases.
      Signed-Off-By: NMuli Ben-Yehuda <mulix@mulix.org>
      Signed-Off-By: NJon D. Mason <jdmason@us.ibm.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      17a941d8
  15. 07 1月, 2006 1 次提交
  16. 21 12月, 2005 1 次提交
  17. 30 9月, 2005 6 次提交
  18. 15 9月, 2005 1 次提交
    • A
      [IA64] more robust zx1/sx1000 machvec support · 0b9afede
      Alex Williamson 提交于
      Machine vector selection has always been a bit of a hack given how
      early in system boot it needs to be done.  Services like ACPI namespace
      are not available and there are non-trivial problems to moving them to
      early boot.  However, there's no reason we can't change to a different
      machvec later in boot when the services we need are available.  By
      adding a entry point for later initialization of the swiotlb, we can add
      an error path for the hpzx1 machevec initialization and fall back to the
      DIG machine vector if IOMMU hardware isn't found in the system.  Since
      ia64 uses 4GB for zone DMA (no ISA support), it's trivial to allocate a
      contiguous range from the slab for bounce buffer usage.
      Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      0b9afede
  19. 19 8月, 2005 1 次提交
    • A
      [IA64, X86_64] fix swiotlb sizing · e8579e72
      Alex Williamson 提交于
         Fix swiotlb sizing to match what the comments and the kernel
      parameters documentation indicate.  Given a default 16k page size kernel
      (ia64) and a 2k swiotlb page size, we're off by a multiple of 8 trying
      to size the swiotlb.  When specified on the boot line, the swiotlb is
      made 8x bigger than requested.  When left to the default value, it's 8x
      smaller than the comments indicate.  For x86_64 the multiplier would be
      2x.  The patch below fixes this.  Now, what's a good default swiotlb
      size?  Apparently we don't really need 64MB.
      Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      e8579e72
  20. 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