1. 21 5月, 2009 6 次提交
  2. 19 5月, 2009 29 次提交
  3. 15 5月, 2009 5 次提交
    • 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
    • G
      powerpc/cell: Make ptcal more reliable · 37cd8ed9
      Gerhard Stenzel 提交于
      There have been a series of checkstops on QS21 related to
      ptcal being set up incorrectly. On systems that only
      have memory on a single node, ptcal fails when it gets
      a pointer to memory on the remote node.
      
      Moreover, agressive prefetching in memcpy and other
      functions may accidentally touch the first cache line
      of the page that we reserve for ptcal, which causes
      an ECC checkstop.
      
      We now allocate pages only from the specified node, moves the
      ptcal area into the middle of the allocated page to avoid
      potential prefetch problems and prints the address of the
      ptcal area to facilitate diagnostics.
      Signed-off-by: NGerhard Stenzel <gerhard.stenzel@de.ibm.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      37cd8ed9
    • 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
    • K
      powerpc/mpic: Fix incorrect allocation of interrupt rev-map · 31207dab
      Kumar Gala 提交于
      Before when we were setting up the irq host map for mpic we passed in
      just isu_size for the size of the linear map.  However, for a number of
      mpic implementations we have no isu (thus pass in 0) and will end up
      with a no linear map (size = 0).  This causes us to always call
      irq_find_mapping() from mpic_get_irq().
      
      By moving the allocation of the host map to after we've determined the
      number of sources we can actually benefit from having a linear map for
      the non-isu users that covers all the interrupt sources.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      31207dab