1. 13 1月, 2009 1 次提交
  2. 31 10月, 2008 2 次提交
    • M
      powerpc: Update remaining dma_mapping_ops to use map/unmap_page · f9226d57
      Mark Nelson 提交于
      After the merge of the 32 and 64bit DMA code, dma_direct_ops lost
      their map/unmap_single() functions but gained map/unmap_page().  This
      caused a problem for Cell because Cell's dma_iommu_fixed_ops called
      the dma_direct_ops if the fixed linear mapping was to be used or the
      iommu ops if the dynamic window was to be used.  So in order to fix
      this problem we need to update the 64bit DMA code to use
      map/unmap_page.
      
      First, we update the generic IOMMU code so that iommu_map_single()
      becomes iommu_map_page() and iommu_unmap_single() becomes
      iommu_unmap_page().  Then we propagate these changes up through all
      the callers of these two functions and in the process update all the
      dma_mapping_ops so that they have map/unmap_page rahter than
      map/unmap_single.  We can do this because on 64bit there is no HIGHMEM
      memory so map/unmap_page ends up performing exactly the same function
      as map/unmap_single, just taking different arguments.
      
      This has no affect on drivers because the dma_map_single_attrs() just
      ends up calling the map_page() function of the appropriate
      dma_mapping_ops and similarly the dma_unmap_single_attrs() calls
      unmap_page().
      
      This fixes an oops on Cell blades, which oops on boot without this
      because they call dma_direct_ops.map_single, which is NULL.
      Signed-off-by: NMark Nelson <markn@au1.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      f9226d57
    • M
      powerpc: Use is_kdump_kernel() · 62a8bd6c
      Milton Miller 提交于
      linux/crash_dump.h defines is_kdump_kernel() to be used by code that
      needs to know if the previous kernel crashed instead of a (clean) boot
      or reboot.
      
      This updates the just added powerpc code to use it.  This is needed
      for the next commit, which will remove __kdump_flag.
      Signed-off-by: NMilton Miller <miltonm@bga.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      62a8bd6c
  3. 22 10月, 2008 1 次提交
    • M
      powerpc: Support for relocatable kdump kernel · 54622f10
      Mohan Kumar M 提交于
      This adds relocatable kernel support for kdump. With this one can
      use the same regular kernel to capture the kdump. A signature (0xfeed1234)
      is passed in r6 from panic code to the next kernel through kexec_sequence
      and purgatory code. The signature is used to differentiate between
      kdump kernel and non-kdump kernels.
      
      The purgatory code compares the signature and sets the __kdump_flag in
      head_64.S.  During the boot up, kernel code checks __kdump_flag and if it
      is set, the kernel will behave as relocatable kdump kernel. This kernel
      will boot at the address where it was loaded by kexec-tools ie. at the
      address reserved through crashkernel boot parameter.
      
      CONFIG_CRASH_DUMP depends on CONFIG_RELOCATABLE option to build kdump
      kernel as relocatable. So the same kernel can be used as production and
      kdump kernel.
      
      This patch incorporates the changes suggested by Paul Mackerras to avoid
      GOT use and to avoid two copies of the code.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NMohan Kumar M <mohan@in.ibm.com>
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      54622f10
  4. 17 10月, 2008 2 次提交
  5. 25 7月, 2008 1 次提交
    • R
      powerpc/pseries: iommu enablement for CMO · 6490c490
      Robert Jennings 提交于
      To support Cooperative Memory Overcommitment (CMO), we need to check
      for failure from some of the tce hcalls.
      
      These changes for the pseries platform affect the powerpc architecture;
      patches for the other affected platforms are included in this patch.
      
      pSeries platform IOMMU code changes:
       * platform TCE functions must handle H_NOT_ENOUGH_RESOURCES errors and
         return an error.
      
      Architecture IOMMU code changes:
       * Calls to ppc_md.tce_build need to check return values and return
         DMA_MAPPING_ERROR for transient errors.
      
      Architecture changes:
       * struct machdep_calls for tce_build*_pSeriesLP functions need to change
         to indicate failure.
       * all other platforms will need updates to iommu functions to match the new
         calling semantics; they will return 0 on success.  The other platforms
         default configs have been built, but no further testing was performed.
      Signed-off-by: NRobert Jennings <rcj@linux.vnet.ibm.com>
      Acked-by: NOlof Johansson <olof@lixom.net>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      6490c490
  6. 22 7月, 2008 1 次提交
  7. 09 7月, 2008 2 次提交
  8. 01 4月, 2008 1 次提交
  9. 06 2月, 2008 3 次提交
  10. 15 1月, 2008 1 次提交
    • B
      [POWERPC] Workaround for iommu page alignment · d262c32a
      Benjamin Herrenschmidt 提交于
      Commit 5d2efba6 changed our iommu code
      so that it always uses an iommu page size of 4kB.  That means with our
      current code, drivers may do a dma_map_sg() of a 64kB page and obtain
      a dma_addr_t that is only 4k aligned.
      
      This works fine in most cases except for some infiniband HW it seems,
      where they tell the HW about the page size and it ignores the low bits
      of the DMA address.
      
      This works around it by making our IOMMU code enforce a PAGE_SIZE alignment
      for mappings of objects that are page aligned in the first place and whose
      size is larger or equal to a page.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d262c32a
  11. 11 12月, 2007 1 次提交
  12. 23 10月, 2007 1 次提交
  13. 16 10月, 2007 1 次提交
  14. 17 8月, 2007 1 次提交
  15. 26 4月, 2007 1 次提交
  16. 13 4月, 2007 1 次提交
    • J
      [POWERPC] DMA 4GB boundary protection · 56997559
      Jake Moilanen 提交于
      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: NJake Moilanen <moilanen@austin.ibm.com>
      Acked-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      56997559
  17. 09 3月, 2007 1 次提交
    • J
      [POWERPC] DMA 4GB boundary protection · 618d3adc
      Jake Moilanen 提交于
      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: NJake Moilanen <moilanen@austin.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      618d3adc
  18. 04 12月, 2006 1 次提交
    • B
      [POWERPC] Refactor 64 bits DMA operations · 12d04eef
      Benjamin Herrenschmidt 提交于
      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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      12d04eef
  19. 01 11月, 2006 1 次提交
    • L
      [POWERPC] Use 4kB iommu pages even on 64kB-page systems · 5d2efba6
      Linas Vepstas 提交于
      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: NLinas Vepstas <linas@austin.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NOlof Johansson <olof@lixom.net>
      Acked-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      5d2efba6
  20. 06 10月, 2006 1 次提交
  21. 01 7月, 2006 1 次提交
  22. 28 6月, 2006 1 次提交
    • H
      [POWERPC] kdump: Reserve the existing TCE mappings left by the first kernel · 5f50867b
      Haren Myneni 提交于
      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: NHaren Myneni <haren@us.ibm.com>
      Acked-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      5f50867b
  23. 15 6月, 2006 1 次提交
  24. 10 6月, 2006 1 次提交
  25. 09 6月, 2006 1 次提交
  26. 21 4月, 2006 1 次提交
  27. 10 2月, 2006 1 次提交
  28. 07 2月, 2006 1 次提交
    • J
      [PATCH] powerpc: IOMMU SG paranoia · a958a264
      Jake Moilanen 提交于
      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: NJake Moilanen <moilanen@austin.ibm.com>
      Acked-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a958a264
  29. 14 11月, 2005 1 次提交
  30. 09 10月, 2005 1 次提交
  31. 09 9月, 2005 1 次提交
    • P
      [PATCH] Separate pci bits out of struct device_node · 1635317f
      Paul Mackerras 提交于
      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: NPaul Mackerras <paulus@samba.org>
      1635317f
  32. 18 8月, 2005 1 次提交
  33. 20 6月, 2005 1 次提交
    • J
      [PATCH] initialize TCE tables · d3588ba9
      John Rose 提交于
      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: NJohn Rose <johnrose@austin.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d3588ba9
  34. 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