1. 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
  2. 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
  3. 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
  4. 25 11月, 2012 1 次提交
  5. 17 11月, 2012 1 次提交
  6. 27 9月, 2012 1 次提交
  7. 19 9月, 2012 1 次提交
  8. 13 9月, 2012 4 次提交
  9. 03 8月, 2012 1 次提交
  10. 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
  11. 10 7月, 2012 1 次提交
  12. 17 6月, 2012 1 次提交
  13. 16 2月, 2012 1 次提交
  14. 18 1月, 2012 1 次提交
  15. 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
  16. 12 7月, 2011 1 次提交
  17. 27 6月, 2011 1 次提交
  18. 23 6月, 2011 1 次提交
  19. 10 6月, 2011 1 次提交
  20. 12 4月, 2011 1 次提交
  21. 15 3月, 2011 1 次提交
  22. 14 10月, 2010 2 次提交
  23. 01 9月, 2010 1 次提交
  24. 05 8月, 2010 1 次提交
  25. 14 7月, 2010 1 次提交
  26. 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
  27. 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
  28. 21 11月, 2009 2 次提交
  29. 21 5月, 2009 1 次提交
  30. 19 5月, 2009 4 次提交
  31. 29 1月, 2009 1 次提交