1. 28 9月, 2008 1 次提交
  2. 25 9月, 2008 3 次提交
    • F
      x86 gart: remove unnecessary initialization · 1615965e
      FUJITA Tomonori 提交于
      There is no point to have such initialization in struct dma_mapping_ops.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1615965e
    • F
      x86: restore old GART alloc_coherent behavior · 1d990882
      FUJITA Tomonori 提交于
      Currently, GART alloc_coherent tries to allocate pages with GFP_DMA32
      for a device having dma_masks > 24bit < 32bits. If GART gets an
      address that a device can't access to, GART try to map the address to
      a virtual I/O address that the device can access to.
      
      But Andi pointed out, "The GART is somewhere in the 4GB range so you
      cannot use it to map anything < 4GB. Also GART is pretty small."
      
      http://lkml.org/lkml/2008/9/12/43
      
      That is, it's possible that GART doesn't have virtual I/O address
      space that a device can access to. The above behavior doesn't work for
      a device having dma_masks > 24bit < 32bits.
      
      This patch restores old GART alloc_coherent behavior (before the
      alloc_coherent rewrite).
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1d990882
    • F
      revert "x86: make GART to respect device's dma_mask about virtual mappings" · ecef533e
      FUJITA Tomonori 提交于
      This reverts:
      
      commit bee44f29
      Author: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Date:   Fri Sep 12 19:42:35 2008 +0900
      
          x86: make GART to respect device's dma_mask about virtual mappings
      
      I wrote the above commit to fix a GART alloc_coherent regression, that
      can't handle a device having dma_masks > 24bit < 32bits, introduced by
      the alloc_coherent rewrite:
      
        http://lkml.org/lkml/2008/8/12/200
      
      After the alloc_coherent rewrite, GART alloc_coherent tried to
      allocate pages with GFP_DMA32. If GART got an address that a device
      can't access to, GART mapped the address to a virtual I/O address. But
      GART mapping mechanism didn't take account of dma mask, so GART could
      use a virtual I/O address that the device can't access to again.
      
      Alan pointed out:
      
      " This is indeed a specific problem found with things like older
        AACRAID where control blocks must be below 31bits and the GART
        is above 0x80000000. "
      
      The above commit modified GART mapping mechanism to take care of dma
      mask. But Andi pointed out, "The GART is somewhere in the 4GB range so
      you cannot use it to map anything < 4GB. Also GART is pretty small."
      
      http://lkml.org/lkml/2008/9/12/43
      
      That means it's possible that GART doesn't have virtual I/O address
      space that a device can access to. The above commit (to modify GART
      mapping mechanism to take care of dma mask) can't fix the regression
      reliably so let's avoid making GART more complicated.
      
      We need a solution that always works for dma_masks > 24bit <
      32bits. That's how GART worked before the alloc_coherent rewrite.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Acked-by: NJoerg Roedel <joerg.roedel@amd.com>
      Acked-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ecef533e
  3. 23 9月, 2008 1 次提交
  4. 22 9月, 2008 1 次提交
  5. 19 9月, 2008 1 次提交
  6. 14 9月, 2008 2 次提交
  7. 10 9月, 2008 1 次提交
  8. 05 9月, 2008 1 次提交
  9. 22 8月, 2008 5 次提交
  10. 18 8月, 2008 1 次提交
  11. 27 7月, 2008 1 次提交
    • F
      dma-mapping: add the device argument to dma_mapping_error() · 8d8bb39b
      FUJITA Tomonori 提交于
      Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
      architecture does:
      
      This enables us to cleanly fix the Calgary IOMMU issue that some devices
      are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423).
      
      I think that per-device dma_mapping_ops support would be also helpful for
      KVM people to support PCI passthrough but Andi thinks that this makes it
      difficult to support the PCI passthrough (see the above thread).  So I
      CC'ed this to KVM camp.  Comments are appreciated.
      
      A pointer to dma_mapping_ops to struct dev_archdata is added.  If the
      pointer is non NULL, DMA operations in asm/dma-mapping.h use it.  If it's
      NULL, the system-wide dma_ops pointer is used as before.
      
      If it's useful for KVM people, I plan to implement a mechanism to register
      a hook called when a new pci (or dma capable) device is created (it works
      with hot plugging).  It enables IOMMUs to set up an appropriate
      dma_mapping_ops per device.
      
      The major obstacle is that dma_mapping_error doesn't take a pointer to the
      device unlike other DMA operations.  So x86 can't have dma_mapping_ops per
      device.  Note all the POWER IOMMUs use the same dma_mapping_error function
      so this is not a problem for POWER but x86 IOMMUs use different
      dma_mapping_error functions.
      
      The first patch adds the device argument to dma_mapping_error.  The patch
      is trivial but large since it touches lots of drivers and dma-mapping.h in
      all the architecture.
      
      This patch:
      
      dma_mapping_error() doesn't take a pointer to the device unlike other DMA
      operations.  So we can't have dma_mapping_ops per device.
      
      Note that POWER already has dma_mapping_ops per device but all the POWER
      IOMMUs use the same dma_mapping_error function.  x86 IOMMUs use device
      argument.
      
      [akpm@linux-foundation.org: fix sge]
      [akpm@linux-foundation.org: fix svc_rdma]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix bnx2x]
      [akpm@linux-foundation.org: fix s2io]
      [akpm@linux-foundation.org: fix pasemi_mac]
      [akpm@linux-foundation.org: fix sdhci]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix sparc]
      [akpm@linux-foundation.org: fix ibmvscsi]
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Muli Ben-Yehuda <muli@il.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Avi Kivity <avi@qumranet.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8d8bb39b
  12. 26 7月, 2008 1 次提交
  13. 23 7月, 2008 1 次提交
  14. 22 7月, 2008 1 次提交
  15. 14 7月, 2008 1 次提交
  16. 13 7月, 2008 1 次提交
    • Y
      x86: max_low_pfn_mapped fix, #1 · 7ab073b6
      Yinghai Lu 提交于
      fix crash on Ingo's big box:
      
      calling  pci_iommu_init+0x0/0x17
      PCI-DMA: Disabling AGP.
      PCI-DMA: aperture base @ d0000000 size 65536 KB
      PCI-DMA: using GART IOMMU.
      PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
      BUG: unable to handle kernel paging request at ffff88000003be88
      IP: [<ffffffff8026d377>] __alloc_pages_internal+0xc3/0x3f2
      PGD 202063 PUD 206063 PMD 22fc00163 PTE 3b162
      Oops: 0000 [1] SMP
      
      and e820 is:
      
       BIOS-e820: 0000000000000000 - 000000000009ac00 (usable)
       BIOS-e820: 000000000009ac00 - 00000000000a0000 (reserved)
       BIOS-e820: 00000000000ca000 - 0000000000100000 (reserved)
       BIOS-e820: 0000000000100000 - 000000007ff70000 (usable)
       BIOS-e820: 000000007ff70000 - 000000007ff86000 (ACPI data)
       BIOS-e820: 000000007ff86000 - 0000000080000000 (ACPI NVS)
       BIOS-e820: 0000000080000000 - 00000000cfe00000 (usable)
       BIOS-e820: 00000000cfe00000 - 00000000d0000000 (reserved)
       BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
       BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
       BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
       BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
       BIOS-e820: 0000000100000000 - 0000000830000000 (usable)
      
      system has 32 GB RAM installed.
      
      max_low_pfn_mapped is 0xcfe00, and GART aperture is not mapped.
      
      So try to use init_memory_mapping to map that area, because the iommu
      thinks that area is ram ...
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7ab073b6
  17. 11 7月, 2008 1 次提交
  18. 08 7月, 2008 1 次提交
  19. 30 6月, 2008 1 次提交
  20. 26 6月, 2008 1 次提交
  21. 12 6月, 2008 1 次提交
  22. 04 6月, 2008 1 次提交
  23. 02 6月, 2008 1 次提交
  24. 13 5月, 2008 2 次提交
  25. 20 4月, 2008 1 次提交
  26. 05 4月, 2008 1 次提交
  27. 15 2月, 2008 1 次提交
  28. 06 2月, 2008 2 次提交
  29. 04 2月, 2008 2 次提交
  30. 30 1月, 2008 1 次提交