1. 11 3月, 2009 1 次提交
  2. 11 2月, 2009 1 次提交
  3. 10 2月, 2009 1 次提交
    • B
      powerpc/pci: mmap anonymous memory when legacy_mem doesn't exist · 5b11abfd
      Benjamin Herrenschmidt 提交于
      The new legacy_mem file in sysfs is causing problems with X on machines
      that don't support legacy memory access. The way I initially implemented
      it, we would fail with -ENXIO when trying to mmap it, thus exposing to
      X that we do support the API but there is no legacy memory.
      
      Unfortunately, X poor error handling is causing it to fail to start when
      it gets this error.
      
      This implements a workaround hack that instead maps anonymous memory
      instead (using shmem if VM_SHARED is set, just like /dev/zero does).
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5b11abfd
  4. 02 2月, 2009 1 次提交
  5. 08 1月, 2009 1 次提交
    • B
      powerpc/pci: Reserve legacy regions on PCI · c1f34302
      Benjamin Herrenschmidt 提交于
      There's a problem on some embedded platforms when we re-assign
      everything on PCI, such as 44x. The generic code tries to avoid
      assigning devices to addresses overlapping the low legacy
      addresses such as VGA hard decoded areas using constants that
      are unfortunately no good for us, as they don't take into account
      the address translation we do to access PCI busses.
      
      Thus we end up allocating things like IO BARs to 0, which is
      technically legal, but will shadow hard decoded ports for use
      by things like VGA cards.
      
      This works around it by attempting to reserve legacy regions
      before we try to assign addresses.
      
      NOTE: This may have nasty side effects in cases I haven't tested
      yet:
      
       - We try to use FW mappings (ie. powermac) and the FW has allocated
      a conflicting address over those legacy regions. This will typically
      happen. I would expect the new code to just fail with an informative
      message without harm but I haven't had a chance to test that scenario
      yet.
      
       - A device with fixed BARs overlapping those legacy addresses such
      as an IDE controller in legacy mode is in the system. I don't know
      for sure yet what will happen there, I have to test :-)
      
      Ideally, we should change PCIBIOS_MIN_IO/MIN_MEM accross the board
      to take a bus pointer so they can provide appropriate per-bus translated
      values to the generic code but that's a more invasive patch. I will
      do that in the future, but in the meantime, this fixes the problem
      locally
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c1f34302
  6. 21 12月, 2008 1 次提交
    • B
      powerpc/mm: Rework usage of _PAGE_COHERENT/NO_CACHE/GUARDED · 64b3d0e8
      Benjamin Herrenschmidt 提交于
      Currently, we never set _PAGE_COHERENT in the PTEs, we just OR it in
      in the hash code based on some CPU feature bit.  We also manipulate
      _PAGE_NO_CACHE and _PAGE_GUARDED by hand in all sorts of places.
      
      This changes the logic so that instead, the PTE now contains
      _PAGE_COHERENT for all normal RAM pages thay have I = 0 on platforms
      that need it.  The hash code clears it if the feature bit is not set.
      
      It also adds some clean accessors to setup various valid combinations
      of access flags and change various bits of code to use them instead.
      
      This should help having the PTE actually containing the bit
      combinations that we really want.
      
      I also removed _PAGE_GUARDED from _PAGE_BASE on 44x and instead
      set it explicitely from the TLB miss.  I will ultimately remove it
      completely as it appears that it might not be needed after all
      but in the meantime, having it in the TLB miss makes things a
      lot easier.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      64b3d0e8
  7. 16 12月, 2008 1 次提交
  8. 06 11月, 2008 4 次提交
  9. 05 11月, 2008 4 次提交
  10. 31 10月, 2008 1 次提交
  11. 22 10月, 2008 1 次提交
  12. 21 10月, 2008 1 次提交
  13. 15 10月, 2008 1 次提交
    • B
      powerpc/pci: Improve detection of unassigned bridge resources · b5561511
      Benjamin Herrenschmidt 提交于
      When the powerpc PCI layer is not configured to re-assign everything,
      it currently fails to detect that a PCI to PCI bridge has been left
      unassigned by the firmware and tries to allocate resource for the
      default window values in the bridge (0...X) (with the notable exception
      of a hack we have in there that detects some Apple firmware unassigned
      bridge resources).
      
      This results in resource allocation failures, which are generally
      fixed up later on but it causes scary warnings in the logs and we
      have seen the fixup code fall over in some circumstances (a different
      issue to fix as well).
      
      This code improves that by providing a more complete & useful function
      to intuit that a bridge was left unassigned by the firmware, and thus
      force a full re-allocation by the PCI code without trying to allocate
      the existing useless resources first.
      
      The algorithm we use basically considers unassigned a window that
      starts at 0 (PCI address) if the corresponding address space enable
      bit is not set. In addition, for memory space, it considers such a
      resource unassigned also if the host bridge isn't configured to
      forward cycles to address 0 (ie, the resource basically overlaps
      main memory).
      
      This fixes a range of problems with things like Bare-Metal support
      on pSeries machines, or attempt to use partial firmware PCI setup.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      b5561511
  14. 07 10月, 2008 1 次提交
  15. 25 9月, 2008 1 次提交
    • B
      powerpc: Merge 32 and 64-bit dma code · 4fc665b8
      Becky Bruce 提交于
      We essentially adopt the 64-bit dma code, with some changes to support
      32-bit systems, including HIGHMEM.  dma functions on 32-bit are now
      invoked via accessor functions which call the correct op for a device based
      on archdata dma_ops.  If there is no archdata dma_ops, this defaults
      to dma_direct_ops.
      
      In addition, the dma_map/unmap_page functions are added to dma_ops
      because we can't just fall back on map/unmap_single when HIGHMEM is
      enabled. In the case of dma_direct_*, we stop using map/unmap_single
      and just use the page version - this saves a lot of ugly
      ifdeffing.  We leave map/unmap_single in the dma_ops definition,
      though, because they are needed by the iommu code, which does not
      implement map/unmap_page.  Ideally, going forward, we will completely
      eliminate map/unmap_single and just have map/unmap_page, if it's
      workable for 64-bit.
      Signed-off-by: NBecky Bruce <becky.bruce@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      4fc665b8
  16. 11 8月, 2008 1 次提交
  17. 22 7月, 2008 1 次提交
  18. 21 4月, 2008 1 次提交
  19. 13 3月, 2008 1 次提交
  20. 24 1月, 2008 2 次提交
  21. 31 12月, 2007 1 次提交
  22. 20 12月, 2007 10 次提交
  23. 11 12月, 2007 2 次提交