1. 06 5月, 2013 1 次提交
    • B
      powerpc/pci: Support per-aperture memory offset · 3fd47f06
      Benjamin Herrenschmidt 提交于
      The PCI core supports an offset per aperture nowadays but our arch
      code still has a single offset per host bridge representing the
      difference betwen CPU memory addresses and PCI MMIO addresses.
      
      This is a problem as new machines and hypervisor versions are
      coming out where the 64-bit windows will have a different offset
      (basically mapped 1:1) from the 32-bit windows.
      
      This fixes it by using separate offsets. In the long run, we probably
      want to get rid of that intermediary struct pci_controller and have
      those directly stored into the pci_host_bridge as they are parsed
      but this will be a more invasive change.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      3fd47f06
  2. 30 4月, 2013 2 次提交
    • M
      powerpc: Fix usage of setup_pci_atmu() · d5bbe659
      Michael Neuling 提交于
      Linux next is currently failing to compile mpc85xx_defconfig with:
        arch/powerpc/sysdev/fsl_pci.c:944:2: error: too many arguments to function 'setup_pci_atmu'
      
      This is caused by (from Kumar's next branch):
        commit 34642bbb
        Author: Kumar Gala <galak@kernel.crashing.org>
        powerpc/fsl-pci: Keep PCI SoC controller registers in pci_controller
      
      Which changed definition of setup_pci_atmu() but didn't update one of
      the callers.  Below fixes this.
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Reviewed-by: NKim Phillips <kim.phillips@freescale.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      d5bbe659
    • K
      powerpc/fsl-pci: don't unmap the PCI SoC controller registers in setup_pci_atmu · 04aa99cd
      Kevin Hao 提交于
      In patch 34642bbb (powerpc/fsl-pci: Keep PCI SoC controller registers in
      pci_controller) we choose to keep the map of the PCI SoC controller
      registers. But we missed to delete the unmap in setup_pci_atmu
      function. This will cause the following call trace once we access
      the PCI SoC controller registers later.
      
      Unable to handle kernel paging request for data at address 0x8000080080040f14
      Faulting instruction address: 0xc00000000002ea58
      Oops: Kernel access of bad area, sig: 11 [#1]
      SMP NR_CPUS=24 T4240 QDS
      Modules linked in:
      NIP: c00000000002ea58 LR: c00000000002eaf4 CTR: c00000000002eac0
      REGS: c00000017e10b4a0 TRAP: 0300   Not tainted  (3.9.0-rc1-00052-gfa3529f-dirty)
      MSR: 0000000080029000 <CE,EE,ME>  CR: 28adbe22  XER: 00000000
      SOFTE: 0
      DEAR: 8000080080040f14, ESR: 0000000000000000
      TASK = c00000017e100000[1] 'swapper/0' THREAD: c00000017e108000 CPU: 2
      GPR00: 0000000000000000 c00000017e10b720 c0000000009928d8 c00000017e578e00
      GPR04: 0000000000000000 000000000000000c 0000000000000001 c00000017e10bb40
      GPR08: 0000000000000000 8000080080040000 0000000000000000 0000000000000016
      GPR12: 0000000088adbe22 c00000000fffa800 c000000000001ba0 0000000000000000
      GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR20: 0000000000000000 0000000000000000 0000000000000000 c0000000008a5b70
      GPR24: c0000000008af938 c0000000009a28d8 c0000000009bb5dc c00000017e10bb40
      GPR28: c00000017e32a400 c00000017e10bc00 c00000017e32a400 c00000017e578e00
      NIP [c00000000002ea58] .fsl_pcie_check_link+0x88/0xf0
      LR [c00000000002eaf4] .fsl_indirect_read_config+0x34/0xb0
      Call Trace:
      [c00000017e10b720] [c00000017e10b7a0] 0xc00000017e10b7a0 (unreliable)
      [c00000017e10ba30] [c00000000002eaf4] .fsl_indirect_read_config+0x34/0xb0
      [c00000017e10bad0] [c00000000033aa08] .pci_bus_read_config_byte+0x88/0xd0
      [c00000017e10bb90] [c00000000088d708] .pci_apply_final_quirks+0x9c/0x18c
      [c00000017e10bc40] [c0000000000013dc] .do_one_initcall+0x5c/0x1f0
      [c00000017e10bcf0] [c00000000086ebac] .kernel_init_freeable+0x180/0x26c
      [c00000017e10bdb0] [c000000000001bbc] .kernel_init+0x1c/0x460
      [c00000017e10be30] [c000000000000880] .ret_from_kernel_thread+0x64/0xe4
      Instruction dump:
      38210310 2b800015 4fdde842 7c600026 5463fffe e8010010 7c0803a6 4e800020
      60000000 60000000 e92301d0 7c0004ac <80690f14> 0c030000 4c00012c 38210310
      ---[ end trace 7a8fe0cbccb7d992 ]---
      
      Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      Signed-off-by: NKevin Hao <haokexin@gmail.com>
      Acked-by: NRoy Zang <tie-fei.zang@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      04aa99cd
  3. 10 4月, 2013 2 次提交
  4. 04 4月, 2013 1 次提交
  5. 06 3月, 2013 1 次提交
  6. 16 2月, 2013 1 次提交
    • V
      powerpc/fsl_pci: Store the pci ctlr device ptr in the pci ctlr struct · 52c5affc
      Varun Sethi 提交于
      The pci controller structure has a provision to store the device structure
      pointer of the corresponding platform device. Currently this information is
      not stored during fsl pci controller initialization. This information is
      required while dealing with iommu groups for pci devices connected to the
      fsl pci controller. For the case where the pci devices can't be paritioned,
      they would fall under the same device group as the pci controller.
      
      This patch stores the platform device information in the pci controller
      structure during initialization.
      Signed-off-by: NVarun Sethi <Varun.Sethi@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      52c5affc
  7. 13 2月, 2013 1 次提交
    • T
      powerpc/85xx: fix various PCI node compatible strings · 14bdc913
      Timur Tabi 提交于
      Fix and/or improve the compatible strings of the PCI device tree nodes for
      some Freescale SOCs.  This fixes some issues and improves consistency among
      the SOCs.
      
      Specifically:
      
      1) The P1022 has a v1 PCIe controller, so the compatible property should just
      say "fsl,mpc8548-pcie".  U-Boot does not look for "fsl,p1022-pcie", so it
      wasn't fixing up the node.
      
      2) The P4080 has a v2.1 PCIe controller, so add that version-specific string
      to the device tree.  Update the kernel to also look for that string.
      Currently, the kernel looks for "fsl,p4080-pcie" specifically, but
      eventually that check should be deleted.
      
      3) The P1010 device tree claims compatibility with v2.2 and v2.3, but that's
      redundant.  No other device tree does this.  Remove the v2.2 string.
      
      4) The kernel looks for both "fsl,p1023-pcie" and "fsl,qoriq-pcie-v2.2",
      even though the P1023 device trees has always included both strings.  Remove
      the search for "fsl,p1023-pcie".
      Signed-off-by: NTimur Tabi <timur@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      14bdc913
  8. 04 1月, 2013 1 次提交
    • G
      POWERPC: drivers: remove __dev* attributes. · cad5cef6
      Greg Kroah-Hartman 提交于
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitdata,
      __devinitconst, and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cad5cef6
  9. 25 11月, 2012 1 次提交
  10. 17 11月, 2012 1 次提交
  11. 27 9月, 2012 1 次提交
  12. 19 9月, 2012 1 次提交
  13. 13 9月, 2012 4 次提交
  14. 03 8月, 2012 1 次提交
  15. 11 7月, 2012 1 次提交
    • S
      powerpc/fsl-pci: get PCI init out of board files · 07e4f801
      Scott Wood 提交于
      As an alternative incremental starting point to Jia Hongtao's patchset,
      get the FSL PCI init out of the board files, but do not yet convert to a
      platform driver.
      
      Rather than having each board supply a magic register offset for
      determining the "primary" bus, we look for which PCI host bridge
      contains an ISA node within its subtree.  If there is no ISA node,
      normally that would mean there is no primary bus, but until certain
      bugs are fixed we arbitrarily designate a primary in this case.
      
      Conversion to a platform driver and related improvements can happen
      after this, as the ordering issues are sorted out.
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      07e4f801
  16. 10 7月, 2012 1 次提交
  17. 17 6月, 2012 1 次提交
  18. 16 2月, 2012 1 次提交
  19. 18 1月, 2012 1 次提交
  20. 05 1月, 2012 2 次提交
    • T
      powerpc/fsl: add MSI support for the Freescale hypervisor · 446bc1ff
      Timur Tabi 提交于
      Add support for vmpic-msi nodes to the fsl_msi driver.  The MSI is
      virtualized by the hypervisor, so the vmpic-msi does not contain a 'reg'
      property.  Instead, the driver uses hcalls.
      
      Add support for the "msi-address-64" property to the fsl_pci driver.
      The Freescale hypervisor typically puts the virtualized MSIIR register
      in the page after the end of DDR, so we extend the DDR ATMU to cover it.
      Any other location for MSIIR is not supported, for now.
      Signed-off-by: NTimur Tabi <timur@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      446bc1ff
    • K
      powerpc/fsl-pci: Allow 64-bit PCIe devices to DMA to any memory address · 96ea3b4a
      Kumar Gala 提交于
      There is an issue on FSL-BookE 64-bit devices (P5020) in which PCIe
      devices that are capable of doing 64-bit DMAs (like an Intel e1000) do
      not function and crash the kernel if we have >4G of memory in the system.
      
      The reason is that the existing code only sets up one inbound window for
      access to system memory across PCIe.  That window is limited to a 32-bit
      address space.  So on systems we'll end up utilizing SWIOTLB for dma
      mappings.  However SWIOTLB dma ops implement dma_alloc_coherent() as
      dma_direct_alloc_coherent().  Thus we can end up with dma addresses that
      are not accessible because of the inbound window limitation.
      
      We could possibly set the SWIOTLB alloc_coherent op to
      swiotlb_alloc_coherent() however that does not address the issue since
      the swiotlb_alloc_coherent() will behave almost identical to
      dma_direct_alloc_coherent() since the devices coherent_dma_mask will be
      greater than any address allocated by swiotlb_alloc_coherent() and thus
      we'll never bounce buffer it into a range that would be dma-able.
      
      The easiest and best solution is to just make it so that a 64-bit
      capable device is able to DMA to any internal system address.
      
      We accomplish this by opening up a second inbound window that maps all
      of memory above the internal SoC address width so we can set it up to
      access all of the internal SoC address space if needed.
      
      We than fixup the dma_ops and dma_offset for PCIe devices with a dma
      mask greater than the maximum internal SoC address.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      96ea3b4a
  21. 12 7月, 2011 1 次提交
  22. 27 6月, 2011 1 次提交
  23. 23 6月, 2011 1 次提交
  24. 10 6月, 2011 1 次提交
  25. 12 4月, 2011 1 次提交
  26. 15 3月, 2011 1 次提交
  27. 14 10月, 2010 2 次提交
  28. 01 9月, 2010 1 次提交
  29. 05 8月, 2010 1 次提交
  30. 14 7月, 2010 1 次提交
  31. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  32. 10 12月, 2009 1 次提交
    • A
      powerpc/fsl_pci: Fix P2P bridge handling for MPC83xx PCIe controllers · f93611fa
      Anton Vorontsov 提交于
      It appears that we wrongly calculate dev_base for type1 config cycles.
      The thing is: we shouldn't subtract hose->first_busno because PCI core
      sets PCI primary, secondary and subordinate bus numbers, and PCIe
      controller actually takes the registers into account. So we should use
      just bus->number.
      
      Also, according to MPC8315 reference manual, primary bus number should
      always remain 0. We have PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS quirk
      in indirect_pci.c, but since 83xx is somewhat special, it doesn't use
      indirect_pci.c routines, so we have to implement the quirk specifically
      for 83xx PCIe controllers.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      f93611fa
  33. 21 11月, 2009 1 次提交