1. 22 4月, 2009 1 次提交
    • A
      fsl_rio: Pass the proper device to dma mapping routines · 0dbbbf1a
      Anton Vorontsov 提交于
      The driver should pass a device that specifies internal DMA ops, but
      currently NULL pointer is passed, therefore following bug appears
      during boot up:
      
        ------------[ cut here ]------------
        Kernel BUG at c0018a7c [verbose debug info unavailable]
        Oops: Exception in kernel mode, sig: 5 [#1]
        [...]
        NIP [c0018a7c] fsl_rio_doorbell_init+0x34/0x60
        LR [c0018a70] fsl_rio_doorbell_init+0x28/0x60
        Call Trace:
        [ef82bda0] [c0018a70] fsl_rio_doorbell_init+0x28/0x60 (unreliable)
        [ef82bdc0] [c0019160] fsl_rio_setup+0x6b8/0x84c
        [ef82be20] [c02d28ac] fsl_of_rio_rpn_probe+0x30/0x50
        [ef82be40] [c0234f20] of_platform_device_probe+0x5c/0x84
        [...]
        ---[ end trace 561bb236c800851f ]---
      
      This patch fixes the issue.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      0dbbbf1a
  2. 06 4月, 2009 1 次提交
  3. 01 4月, 2009 2 次提交
  4. 30 3月, 2009 2 次提交
  5. 24 3月, 2009 3 次提交
  6. 19 3月, 2009 1 次提交
  7. 09 3月, 2009 2 次提交
  8. 27 2月, 2009 1 次提交
  9. 15 2月, 2009 1 次提交
  10. 07 2月, 2009 2 次提交
  11. 29 1月, 2009 2 次提交
  12. 13 1月, 2009 2 次提交
  13. 08 1月, 2009 2 次提交
    • T
      powerpc/fsl-pci: Set relaxed ordering on prefetchable ranges · 565f3764
      Trent Piepho 提交于
      Provides a small speedup when accessing pefetchable ranges.  To indicate
      that a memory range is prefetchable, mark it in the dts file with 42000000
      instead of 02000000.
      
      A powepc pci_controller is allowed three memory ranges, any of which may be
      prefetchable.  However, the PCI-PCI bridge configuration space only has one
      field for "non-prefetchable memory behind bridge", which has a 32 bit
      address, and one field for "prefetchable memory behind bridge", which may
      have a 64 bit address.  These are PCI bus addresses, not CPU physical
      addresses.
      
      So really you're only allowed one memory range of each type.  And if you
      want the range at a PCI address above 32 bits you must make it
      prefetchable.
      Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      565f3764
    • T
      powerpc/fsl-pci: Better ATMU setup for 85xx/86xx · a097a78c
      Trent Piepho 提交于
      The code that sets up the outbound ATMU windows, which is used to map CPU
      physical addresses into PCI bus addresses where BARs will be mapped, didn't
      work so well.
      
      For one, it leaked the ioremap() of the ATMU registers.  Another small bug
      was the high 20 bits of the PCI bus address were left as zero.  It's legal
      for prefetchable memory regions to be above 32 bits, so the high 20 bits
      might not be zero.
      
      Mainly, it couldn't handle ranges that were not a power of two in size or
      were not naturally aligned.  The ATMU windows have these requirements (size
      & alignment), but the code didn't bother to check if the ranges it was
      programming met them.  If they didn't, the windows would silently be
      programmed incorrectly.
      
      This new code can handle ranges which are not power of two sized nor
      naturally aligned.  It simply splits the ranges into multiple valid ATMU
      windows.  As there are only four windows, pooly aligned or sized ranges
      (which didn't even work before) may run out of windows.  In this case an
      error is printed and an effort is made to disable the unmapped resources.
      
      An improvement that could be made would be to make use of the default
      outbound window.  Iff hose->pci_mem_offset is zero, then it's possible that
      some or all of the ranges might not need an outbound window and could just
      use the default window.
      
      The default ATMU window can support a pci_mem_offset less than zero too,
      but pci_mem_offset is unsigned.  One could say the abilities allowed a
      powerpc pci_controller is neither subset nor a superset of the abilities of
      a Freescale PCIe controller.  Thankfully, the most useful bits are in the
      intersection of the two abilities.
      Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      a097a78c
  14. 31 12月, 2008 5 次提交
  15. 21 12月, 2008 6 次提交
  16. 17 12月, 2008 1 次提交
  17. 16 12月, 2008 1 次提交
  18. 13 12月, 2008 1 次提交
  19. 04 12月, 2008 2 次提交
  20. 03 12月, 2008 1 次提交
  21. 01 12月, 2008 1 次提交
    • A
      powerpc/mpic: Don't reset affinity for secondary MPIC on boot · cc353c30
      Arnd Bergmann 提交于
      Kexec/kdump currently fails on the IBM QS2x blades when the kexec happens
      on a CPU other than the initial boot CPU.  It turns out that this is the
      result of mpic_init trying to set affinity of each interrupt vector to the
      current boot CPU.
      
      As far as I can tell,  the same problem is likely to exist on any
      secondary MPIC, because they have to deliver interrupts to the first
      output all the time. There are two potential solutions for this: either
      not set up affinity at all for secondary MPICs, or assume that a single
      CPU output is connected to the upstream interrupt controller and hardcode
      affinity to that per architecture.
      
      This patch implements the second approach, defaulting to the first output.
      Currently, all known secondary MPICs are routed to their upstream port
      using the first destination, so we hardcode that.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      cc353c30