1. 22 Oct, 2007 1 commit
  2. 16 Oct, 2007 1 commit
  3. 16 Aug, 2007 1 commit
  4. 26 Apr, 2007 1 commit
  5. 12 Apr, 2007 1 commit
    • Jake Moilanen's avatar
      [POWERPC] DMA 4GB boundary protection · 56997559
      Jake Moilanen authored
      
      There are many adapters which cannot handle DMAing across any 4 GB
      boundary.  For instance, the latest Emulex adapters.
      
      This normally is not an issue as firmware gives dma-windows under
      4gigs.  However, some of the new System-P boxes have dma-windows above
      4gigs, and this present a problem.
      
      During initialization of the IOMMU tables, the last entry at each 4GB
      boundary is marked as used.  Thus no mappings can cross the boundary.
      If a table ends at a 4GB boundary, the entry is not marked as used.
      
      A boot option to remove this 4GB protection is given w/ protect4gb=off.
      This exposes the potential issue for driver and hardware development
      purposes.
      Signed-off-by: default avatarJake Moilanen <moilanen@austin.ibm.com>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      56997559
  6. 08 Mar, 2007 1 commit
    • Jake Moilanen's avatar
      [POWERPC] DMA 4GB boundary protection · 618d3adc
      Jake Moilanen authored
      
      There are many adapters which can not handle DMAing acrosss any 4 GB
      boundary.  For instance the latest Emulex adapters.
      
      This normally is not an issue as firmware gives us dma-windows under
      4gigs.  However, some of the new System-P boxes have dma-windows above
      4gigs, and this present a problem.
      
      I propose fixing it in the IOMMU allocation instead of making each
      driver protect against it as it is more efficient, and won't require
      changing every driver which has not considered this issue.
      
      This patch checks to see if the mapping spans a 4 gig boundary, and if
      it does, retries the allocation.  It tries the next allocation at the
      start of the crossed 4 gig boundary.
      Signed-off-by: default avatarJake Moilanen <moilanen@austin.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      618d3adc
  7. 04 Dec, 2006 1 commit
    • Benjamin Herrenschmidt's avatar
      [POWERPC] Refactor 64 bits DMA operations · 12d04eef
      Benjamin Herrenschmidt authored
      
      This patch completely refactors DMA operations for 64 bits powerpc. 32 bits
      is untouched for now.
      
      We use the new dev_archdata structure to add the dma operations pointer
      and associated data to struct device. While at it, we also add the OF node
      pointer and numa node. In the future, we might want to look into merging
      that with pci_dn as well.
      
      The old vio, pci-iommu and pci-direct DMA ops are gone. They are now replaced
      by a set of generic iommu and direct DMA ops (non PCI specific) that can be
      used by bus types. The toplevel implementation is now inline.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      12d04eef
  8. 31 Oct, 2006 1 commit
    • Linas Vepstas's avatar
      [POWERPC] Use 4kB iommu pages even on 64kB-page systems · 5d2efba6
      Linas Vepstas authored
      
      The 10Gigabit ethernet device drivers appear to be able to chew
      up all 256MB of TCE mappings on pSeries systems, as evidenced by
      numerous error messages:
      
       iommu_alloc failed, tbl c0000000010d5c48 vaddr c0000000d875eff0 npages 1
      
      Some experimentation indicates that this is essentially because
      one 1500 byte ethernet MTU gets mapped as a 64K DMA region when
      the large 64K pages are enabled. Thus, it doesn't take much to
      exhaust all of the available DMA mappings for a high-speed card.
      
      This patch changes the iommu allocator to work with its own
      unique, distinct page size. Although the patch is long, its
      actually quite simple: it just #defines a distinct IOMMU_PAGE_SIZE
      and then uses this in all the places that matter.
      
      As a side effect, it also dramatically improves network performance
      on platforms with H-calls on iommu translation inserts/removes (since
      we no longer call it 16 times for a 1500 bytes packet when the iommu HW
      is still 4k).
      
      In the future, we might want to make the IOMMU_PAGE_SIZE a variable
      in the iommu_table instance, thus allowing support for different HW
      page sizes in the iommu itself.
      Signed-off-by: default avatarLinas Vepstas <linas@austin.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Acked-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      5d2efba6
  9. 06 Oct, 2006 1 commit
  10. 30 Jun, 2006 1 commit
  11. 27 Jun, 2006 1 commit
    • Haren Myneni's avatar
      [POWERPC] kdump: Reserve the existing TCE mappings left by the first kernel · 5f50867b
      Haren Myneni authored
      
      During kdump boot, noticed some machines checkstop on dma protection
      fault for ongoing DMA left in the first kernel. Instead of initializing
      TCE entries in iommu_init() for the kdump boot, this patch fixes this
      issue by walking through the each TCE table and checks whether the
      entries are in use by the first kernel. If so, reserve those entries by
      setting the corresponding bit in tbl->it_map such that these entries
      will not be available for the kdump boot.
      
      However it could be possible that all TCE entries might be used up due
      to the driver bug that does continuous mapping. My observation is around
      1700 TCE  entries are used on some systems (Ex: P4) at some point of
      time during kdump boot and saving dump (either write into the disk or
      sending to remote machine). Hence, this patch will make sure that
      minimum of 2048 entries will be available such that kdump boot could be
      successful in some cases.
      Signed-off-by: default avatarHaren Myneni <haren@us.ibm.com>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      5f50867b
  12. 15 Jun, 2006 1 commit
  13. 10 Jun, 2006 1 commit
  14. 09 Jun, 2006 1 commit
  15. 21 Apr, 2006 1 commit
  16. 10 Feb, 2006 1 commit
  17. 07 Feb, 2006 1 commit
    • Jake Moilanen's avatar
      [PATCH] powerpc: IOMMU SG paranoia · a958a264
      Jake Moilanen authored
      
      This addresses two items, which are unlikely to be hit if we
      trust drivers.
      
      The first is moving a memory barrier below where the vmerged SG count
      is passed back, but before the list is set to end.  If those
      instructions were reordered, there could be an issue in iommu_unmap_sg().
      
      The second is making sure we terminate the list on the failure case of
      iommu_map_sg().  If a driver does not look at the failure return code,
      it could pass a ill-formed SG list to iommu_unmap_sg().
      Signed-off-by: default avatarJake Moilanen <moilanen@austin.ibm.com>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      a958a264
  18. 14 Nov, 2005 1 commit
  19. 08 Oct, 2005 1 commit
  20. 09 Sep, 2005 1 commit
    • Paul Mackerras's avatar
      [PATCH] Separate pci bits out of struct device_node · 1635317f
      Paul Mackerras authored
      
      This patch pulls the PCI-related junk out of struct device_node and
      puts it in a separate structure, struct pci_dn.  The device_node now
      just has a void * pointer in it, which points to a struct pci_dn for
      nodes that represent PCI devices.  It could potentially be used in
      future for device-specific data for other sorts of devices, such as
      virtual I/O devices.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      1635317f
  21. 17 Aug, 2005 1 commit
  22. 20 Jun, 2005 1 commit
    • John Rose's avatar
      [PATCH] initialize TCE tables · d3588ba9
      John Rose authored
      
      A fairly recent platform requirement states that the OS must clear the
      whole TCE table at setup time, in case firmware left any active
      mappings in it.  Without this initialization, dynamic bus removes can
      fail.  Firmware rejects these requests if active mappings still exist 
      for a slot that has been deallocated by the OS.
      Signed-off-by: default avatarJohn Rose <johnrose@austin.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      d3588ba9
  23. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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