1. 09 6月, 2009 6 次提交
  2. 02 6月, 2009 5 次提交
  3. 27 5月, 2009 1 次提交
    • B
      powerpc: Fix up dma_alloc_coherent() on platforms without cache coherency. · 8b31e49d
      Benjamin Herrenschmidt 提交于
      The implementation we just revived has issues, such as using a
      Kconfig-defined virtual address area in kernel space that nothing
      actually carves out (and thus will overlap whatever is there),
      or having some dependencies on being self contained in a single
      PTE page which adds unnecessary constraints on the kernel virtual
      address space.
      
      This fixes it by using more classic PTE accessors and automatically
      locating the area for consistent memory, carving an appropriate hole
      in the kernel virtual address space, leaving only the size of that
      area as a Kconfig option. It also brings some dma-mask related fixes
      from the ARM implementation which was almost identical initially but
      grew its own fixes.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8b31e49d
  4. 21 5月, 2009 11 次提交
  5. 18 5月, 2009 3 次提交
  6. 15 5月, 2009 3 次提交
    • B
      powerpc: Fix PCI ROM access · ad892a63
      Benjamin Herrenschmidt 提交于
      A couple of issues crept in since about 2.6.27 related to accessing PCI
      device ROMs on various powerpc machines.
      
      First, historically, we don't allocate the ROM resource in the resource
      tree. I'm not entirely certain of why, I susepct they often contained
      garbage on x86 but it's hard to tell. This causes the current generic
      code to always call pci_assign_resource() when trying to access the said
      ROM from sysfs, which will try to re-assign some new address regardless
      of what the ROM BAR was already set to at boot time. This can be a
      problem on hypervisor platforms like pSeries where we aren't supposed
      to move PCI devices around (and in fact probably can't).
      
      Second, our code that generates the PCI tree from the OF device-tree
      (instead of doing config space probing) which we mostly use on pseries
      at the moment, didn't set the (new) flag IORESOURCE_SIZEALIGN on any
      resource. That means that any attempt at re-assigning such a resource
      with pci_assign_resource() would fail due to resource_alignment()
      returning 0.
      
      This fixes this by doing these two things:
      
       - The code that calculates resource flags based on the OF device-node
      is improved to set IORESOURCE_SIZEALIGN on any valid BAR, and while at
      it also set IORESOURCE_READONLY for ROMs since we were lacking that too
      
       - We now allocate ROM resources as part of the resource tree. However
      to limit the chances of nasty conflicts due to busted firmwares, we
      only do it on the second pass of our two-passes allocation scheme,
      so that all valid and enabled BARs get precedence.
      
      This brings pSeries back the ability to access PCI ROMs via sysfs (and
      thus initialize various video cards from X etc...).
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ad892a63
    • B
      powerpc/pseries: Really fix the oprofile CPU type on pseries · b173f03d
      Benjamin Herrenschmidt 提交于
      My previous pach for fixing the oprofile CPU type got somewhat mismerged
      (by my fault) when it collided with another related patch. This should
      finally (fingers crossed) fix the whole thing.
      
      We make sure we keep the -old- oprofile type and CPU type whenever
      one of them was specified in the first pass through the function.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      b173f03d
    • B
      powerpc: Allow mem=x cmdline to work with 4G+ · 49a84965
      Becky Bruce 提交于
      We're currently choking on mem=4g (and above) due to memory_limit
      being specified as an unsigned long. Make memory_limit
      phys_addr_t to fix this.
      Signed-off-by: NBecky Bruce <beckyb@kernel.crashing.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      49a84965
  7. 01 5月, 2009 2 次提交
  8. 29 4月, 2009 1 次提交
  9. 28 4月, 2009 1 次提交
  10. 27 4月, 2009 1 次提交
  11. 23 4月, 2009 1 次提交
  12. 22 4月, 2009 1 次提交
  13. 21 4月, 2009 1 次提交
  14. 07 4月, 2009 3 次提交