1. 30 Nov, 2008 1 commit
    • Arnd Bergmann's avatar
      powerpc/cell/axon-msi: Retry on missing interrupt · d015fe99
      Arnd Bergmann authored
      
      
      The MSI capture logic for the axon bridge can sometimes
      lose interrupts in case of high DMA and interrupt load,
      when it signals an MSI interrupt to the MPIC interrupt
      controller while we are already handling another MSI.
      
      Each MSI vector gets written into a FIFO buffer in main
      memory using DMA, and that DMA access is normally flushed
      by the actual interrupt packet on the IOIF.  An MMIO
      register in the MSIC holds the position of the last
      entry in the FIFO buffer that was written.  However,
      reading that position does not flush the DMA, so that
      we can observe stale data in the buffer.
      
      In a stress test, we have observed the DMA to arrive
      up to 14 microseconds after reading the register.
      
      This patch works around this problem by retrying the
      access to the FIFO buffer.
      
      We can reliably detect the conditioning by writing
      an invalid MSI vector into the FIFO buffer after
      reading from it, assuming that all MSIs we get
      are valid.  After detecting an invalid MSI vector,
      we udelay(1) in the interrupt cascade for up to
      100 times before giving up.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      d015fe99
  2. 20 Nov, 2008 1 commit
    • Jeremy Kerr's avatar
      powerpc/spufs: Fix spinning in spufs_ps_fault on signal · 60657263
      Jeremy Kerr authored
      
      
      Currently, we can end up in an infinite loop if we get a signal
      while the kernel has faulted in spufs_ps_fault. Eg:
      
       alarm(1);
      
       write(fd, some_spu_psmap_register_address, 4);
      
      - the write's copy_from_user will fault on the ps mapping, and
      signal_pending will be non-zero. Because returning from the fault
      handler will never clear TIF_SIGPENDING, so we'll just keep faulting,
      resulting in an unkillable process using 100% of CPU.
      
      This change returns VM_FAULT_SIGBUS if there's a fatal signal pending,
      letting us escape the loop.
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      60657263
  3. 05 Nov, 2008 1 commit
  4. 31 Oct, 2008 2 commits
    • Mark Nelson's avatar
      powerpc: Update remaining dma_mapping_ops to use map/unmap_page · f9226d57
      Mark Nelson authored
      
      
      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: default avatarMark Nelson <markn@au1.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      f9226d57
    • Milton Miller's avatar
      powerpc: Use is_kdump_kernel() · 62a8bd6c
      Milton Miller authored
      
      
      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: default avatarMilton Miller <miltonm@bga.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      62a8bd6c
  5. 23 Oct, 2008 1 commit
  6. 22 Oct, 2008 1 commit
    • Mohan Kumar M's avatar
      powerpc: Support for relocatable kdump kernel · 54622f10
      Mohan Kumar M authored
      
      
      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: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarMohan Kumar M <mohan@in.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      54622f10
  7. 21 Oct, 2008 9 commits
  8. 14 Oct, 2008 1 commit
  9. 13 Oct, 2008 1 commit
  10. 10 Oct, 2008 3 commits
  11. 24 Sep, 2008 1 commit
  12. 07 Sep, 2008 1 commit
  13. 05 Sep, 2008 2 commits
    • Jeremy Kerr's avatar
      powerpc/spufs: Fix race for a free SPU · b65fe035
      Jeremy Kerr authored
      
      
      We currently have a race for a free SPE. With one thread doing a
      spu_yield(), and another doing a spu_activate():
      
      thread 1				thread 2
      spu_yield(oldctx)			spu_activate(ctx)
        __spu_deactivate(oldctx)
        spu_unschedule(oldctx, spu)
        spu->alloc_state = SPU_FREE
      					spu = spu_get_idle(ctx)
      					    - searches for a SPE in
      					      state SPU_FREE, gets
      					      the context just
      					      freed by thread 1
      					spu_schedule(ctx, spu)
      					  spu->alloc_state = SPU_USED
      spu_schedule(newctx, spu)
        - assumes spu is still free
        - tries to schedule context on
          already-used spu
      
      This change introduces a 'free_spu' flag to spu_unschedule, to indicate
      whether or not the function should free the spu after descheduling the
      context. We only set this flag if we're not going to re-schedule
      another context on this SPU.
      
      Add a comment to document this behaviour.
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      b65fe035
    • Jeremy Kerr's avatar
      powerpc/spufs: Fix multiple get_spu_context() · 9f43e391
      Jeremy Kerr authored
      Commit 8d5636fb
      
       introduced a reference
      count on SPU contexts during find_victim, but this may cause a leak in
      the reference count if we later find a better contender for a context to
      unschedule.
      
      Change the reference to after we've found our victim context, so we
      don't do the extra get_spu_context().
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      9f43e391
  14. 19 Aug, 2008 1 commit
  15. 14 Aug, 2008 1 commit
  16. 13 Aug, 2008 1 commit
    • Jeremy Kerr's avatar
      powerpc/spufs: fix npc setting for NOSCHED contexts · d9dd421f
      Jeremy Kerr authored
      
      
      Currently, spu_run ignores the npc argument for contexts created with
      SPU_CREATE_NOSCHED. While this is correct for isolated contexts,
      there's no need to enforce the npc restriction on non-isolated NOSCHED
      contexts.
      
      This means that NOSCHED contexts can only ever run with an entry point
      of 0x0.
      
      This change to spu_run_init allows setting of the npc (and, while we're
      at it, the privcntl) for non-isolated NOSCHED contexts. This allows
      us to run NOSCHED contexts from any entry point.
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      d9dd421f
  17. 30 Jul, 2008 1 commit
  18. 26 Jul, 2008 2 commits
    • Alexey Dobriyan's avatar
      SL*B: drop kmem cache argument from constructor · 51cc5068
      Alexey Dobriyan authored
      
      
      Kmem cache passed to constructor is only needed for constructors that are
      themselves multiplexeres.  Nobody uses this "feature", nor does anybody uses
      passed kmem cache in non-trivial way, so pass only pointer to object.
      
      Non-trivial places are:
      	arch/powerpc/mm/init_64.c
      	arch/powerpc/mm/hugetlbpage.c
      
      This is flag day, yes.
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Acked-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      Acked-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Jon Tollefson <kniht@linux.vnet.ibm.com>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Cc: Matt Mackall <mpm@selenic.com>
      [akpm@linux-foundation.org: fix arch/powerpc/mm/hugetlbpage.c]
      [akpm@linux-foundation.org: fix mm/slab.c]
      [akpm@linux-foundation.org: fix ubifs]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      51cc5068
    • FUJITA Tomonori's avatar
      dma-mapping: add the device argument to dma_mapping_error() · 8d8bb39b
      FUJITA Tomonori authored
      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: default avatarFUJITA 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8d8bb39b
  19. 25 Jul, 2008 2 commits
    • Robert Jennings's avatar
      powerpc/pseries: iommu enablement for CMO · 6490c490
      Robert Jennings authored
      
      
      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: default avatarRobert Jennings <rcj@linux.vnet.ibm.com>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Acked-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      6490c490
    • Mark Nelson's avatar
      powerpc/cell: Fixed IOMMU mapping uses weak ordering for a pcie endpoint · 7886250e
      Mark Nelson authored
      
      
      At the moment the fixed mapping is by default strongly ordered (the
      iommu_fixed=weak boot option must be used to make the fixed mapping weakly
      ordered). If we're on a setup where the southbridge is being used in
      endpoint mode (triblade and CAB boards) the default should be a weakly
      ordered fixed mapping.
      
      This adds a check so that if a node of type pcie-endpoint can be found in
      the device tree the fixed mapping is set to be weak by default (but can be
      overridden using iommu_fixed=strong).
      Signed-off-by: default avatarMark Nelson <markn@au1.ibm.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7886250e
  20. 24 Jul, 2008 3 commits
  21. 22 Jul, 2008 4 commits