1. 09 12月, 2010 3 次提交
  2. 29 11月, 2010 2 次提交
  3. 24 8月, 2010 1 次提交
    • A
      powerpc: Fix bogus it_blocksize in VIO iommu code · 7aa241fd
      Anton Blanchard 提交于
      When looking at some issues with the virtual ethernet driver I noticed
      that TCE allocation was following a very strange pattern:
      
      address 00e9000 length 2048
      address 0409000 length 2048 <-----
      address 0429000 length 2048
      address 0449000 length 2048
      address 0469000 length 2048
      address 0489000 length 2048
      address 04a9000 length 2048
      address 04c9000 length 2048
      address 04e9000 length 2048
      address 4009000 length 2048 <-----
      address 4029000 length 2048
      
      Huge unexplained gaps in what should be an empty TCE table. It turns out
      it_blocksize, the amount we want to align the next allocation to, was
      c0000000fe903b20. Completely bogus.
      
      Initialise it to something reasonable in the VIO IOMMU code, and use kzalloc
      everywhere to protect against this when we next add a non compulsary
      field to iommu code and forget to initialise it.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7aa241fd
  4. 14 7月, 2010 1 次提交
  5. 19 5月, 2010 1 次提交
    • G
      of: eliminate of_device->node and dev_archdata->{of,prom}_node · 58f9b0b0
      Grant Likely 提交于
      This patch eliminates the node pointer from struct of_device and the
      of_node (or prom_node) pointer from struct dev_archdata since the node
      pointer is now part of struct device proper when CONFIG_OF is set, and
      all users of the old pointer locations have already been converted over
      to use device->of_node.
      
      Also remove dev_archdata_{get,set}_node() as it is no longer used by
      anything.
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      58f9b0b0
  6. 24 9月, 2009 1 次提交
  7. 09 6月, 2009 1 次提交
  8. 13 1月, 2009 1 次提交
  9. 31 10月, 2008 1 次提交
  10. 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
  11. 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
  12. 22 7月, 2008 1 次提交
  13. 14 5月, 2008 1 次提交
  14. 24 4月, 2008 1 次提交
  15. 11 12月, 2007 3 次提交
  16. 10 5月, 2007 1 次提交
  17. 02 5月, 2007 1 次提交
    • L
      [POWERPC] pseries: Handle null iommu dma-window property correctly · 650f7b3b
      Linas Vepstas 提交于
      Some versions of pSeries firmware fail to set up a
      dma-window property for PCI slots that are unoccupied.
      As a result, the loop searching for this propery, in
      pci_dma_dev_setup_pSeriesLP(), can run to the end, resulting
      in a NULL pointer dereference later in the routine. This
      patch prevents the crash, and prints a warning message.
      
      This is theoretically a rare error, as it occurs on what
      is hopefully just beta levels of firmware. But just in case
      this firmware escapes into the wild, this patch will avoid
      the crash.
      Signed-off-by: NLinas Vepstas <linas@austin.ibm.com>
      650f7b3b
  18. 13 4月, 2007 1 次提交
  19. 09 3月, 2007 2 次提交
  20. 22 1月, 2007 1 次提交
    • L
      [POWERPC] Fix broken DMA on non-LPAR pSeries · 77319254
      Linas Vepstas 提交于
      It appears that the iommu table address is never stored, and thus
      never found, on non-lpar systems. Thus, for example, during boot:
      
      <7>[   93.067916] PCI: Scanning bus 0001:41
      <7>[   93.068542] PCI: Found 0001:41:01.0 [8086/100f] 000200 00
      <7>[   93.068550] PCI: Calling quirk c0000000007822e0 for 0001:41:01.0
      <7>[   93.069815] PCI: Fixups for bus 0001:41
      <4>[   93.070167] iommu: Device 0001:41:01.0 has no iommu table
      <7>[   93.070251] PCI: Bus scan for 0001:41 returning with max=41
      
      No iommu table? How can that be? Well, circa line 471 of
      arch/powerpc/platforms/pseries/iommu.c we see the code:
      
         while (dn && PCI_DN(dn) && PCI_DN(dn)->iommu_table == NULL)
            dn = dn->parent;
      
      and a few lines later is the surprising print statement about
      the missing table.  Seems that this loop ran unto the end, never
      once finding a non-null PCI_DN(dn)->iommu_table.
      
      The problem can be found a few lines earlier: it sems that the
      value of PCI_DN(dn)->iommu_table is never ever set. Thus, the
      patch sets it.
      
      The patch was tested on a Power4 system running in full system
      partition mode, which is where I saw the problem. It works; I've
      not done any wider testing. Had a brief discussion on this on irc.
      Signed-off-by: NLinas Vepstas <linas@austin.ibm.com>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      77319254
  21. 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
  22. 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
  23. 06 10月, 2006 1 次提交
    • N
      [POWERPC] linux,tce-size property is 32 bits · 9938c474
      Nathan Lynch 提交于
      The "linux,tce-size" property is only 32 bits (see
      prom_initialize_tce_table() in arch/powerpc/kernel/prom_init.c).
      Treating it as an unsigned long in iommu_table_setparms() leads to
      access beyond the end of the property's buffer, so we pass garbage to
      the memset() in that function.
      
      [boot]0020 XICS Init
      i8259 legacy interrupt controller initialized
      [boot]0021 XICS Done
      PID hash table entries: 4096 (order: 12, 32768 bytes)
      cpu 0x0: Vector: 300 (Data Access) at [c0000000fe783850]
          pc: c000000000035e90: .memset+0x60/0xfc
          lr: c000000000044fa4: .iommu_table_setparms+0xb0/0x158
          sp: c0000000fe783ad0
         msr: 9000000000009032
         dar: c000000100000000
       dsisr: 42010000
        current = 0xc00000000450e810
        paca    = 0xc000000000411580
          pid   = 1, comm = swapper
      enter ? for help
      [link register   ] c000000000044fa4 .iommu_table_setparms+0xb0/0x158
      [c0000000fe783ad0] c000000000044f4c .iommu_table_setparms+0x58/0x158
      (unreliable)
      [c0000000fe783b70] c00000000004529c
      .iommu_bus_setup_pSeries+0x1c4/0x254
      [c0000000fe783c00] c00000000002b8ac .do_bus_setup+0x3c/0xe4
      [c0000000fe783c80] c00000000002c924 .pcibios_fixup_bus+0x64/0xd8
      [c0000000fe783d00] c0000000001a2d5c .pci_scan_child_bus+0x6c/0x10c
      [c0000000fe783da0] c00000000002be28 .scan_phb+0x17c/0x1b4
      [c0000000fe783e40] c0000000003cfa00 .pcibios_init+0x58/0x19c
      [c0000000fe783ec0] c0000000000094b4 .init+0x1e8/0x3d8
      [c0000000fe783f90] c000000000026e54 .kernel_thread+0x4c/0x68
      Signed-off-by: NNathan Lynch <ntl@pobox.com>
      Acked-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      9938c474
  24. 31 7月, 2006 1 次提交
  25. 01 7月, 2006 1 次提交
  26. 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
  27. 21 6月, 2006 1 次提交
  28. 15 6月, 2006 1 次提交
  29. 19 5月, 2006 1 次提交
  30. 29 4月, 2006 1 次提交
  31. 22 3月, 2006 1 次提交
  32. 10 2月, 2006 1 次提交
  33. 12 1月, 2006 1 次提交
  34. 09 1月, 2006 1 次提交