1. 19 May, 2009 24 commits
  2. 15 May, 2009 10 commits
    • Jason Wessel's avatar
      kgdb,i386: use address that SP register points to in the exception frame · 33ab1979
      Jason Wessel authored
      The treatment of the SP register is different on x86_64 and i386.
      This is a regression fix that lived outside the mainline kernel from
      2.6.27 to now.  The regression was a result of the original merge
      consolidation of the i386 and x86_64 archs to x86.
      The incorrectly reported SP on i386 prevented stack tracebacks from
      working correctly in gdb.
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
    • David Brownell's avatar
      ASoC: DaVinci EVM board support buildfixes · f492ec9f
      David Brownell authored
      This is a build fix, resyncing the DaVinci EVM ASoC board code
      with the version in the DaVinci tree.  That resync includes
      support for the DM355 EVM, although that board isn't yet in
      (NOTE:  also includes a bugfix to the platform_add_resources
      call, recently sent by Chaithrika U S <chaithrika@ti.com> but
      not yet merged into the DaVinci tree.)
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
    • Benjamin Herrenschmidt's avatar
      powerpc: Fix PCI ROM access · ad892a63
      Benjamin Herrenschmidt authored
      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: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Benjamin Herrenschmidt's avatar
      powerpc/pseries: Really fix the oprofile CPU type on pseries · b173f03d
      Benjamin Herrenschmidt authored
      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: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Gerhard Stenzel's avatar
      powerpc/cell: Make ptcal more reliable · 37cd8ed9
      Gerhard Stenzel authored
      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: default avatarGerhard Stenzel <gerhard.stenzel@de.ibm.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Becky Bruce's avatar
      powerpc: Allow mem=x cmdline to work with 4G+ · 49a84965
      Becky Bruce authored
      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: default avatarBecky Bruce <beckyb@kernel.crashing.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Kumar Gala's avatar
      powerpc/mpic: Fix incorrect allocation of interrupt rev-map · 31207dab
      Kumar Gala authored
      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: default avatarKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Maynard Johnson's avatar
      powerpc: Fix oprofile sampling of marked events on POWER7 · e5fc948b
      Maynard Johnson authored
      Change ppc64 oprofile kernel driver to use the SLOT bits (MMCRA[37:39]only on
      older processors where those bits are defined.
      The performance monitor unit of the 64-bit POWER processor family has the
      ability to collect accurate instruction-level samples when profiling on marked
      events (i.e., "PM_MRK_<event-name>").  In processors prior to POWER6, the MMCRA
      register contained "slot information" that the oprofile kernel driver used to
      adjust the value latched in the SIAR at the time of a PMU interrupt.  But as of
      POWER6, these slot bits in MMCRA are no longer necessary for oprofile to use,
      since the SIAR itself holds the accurate sampled instruction address.  With
      POWER6, these MMCRA slot bits were zero'ed out by hardware so oprofile's use of
      these slot bits was, in effect, a NOP.  But with POWER7, these bits are no
      longer zero'ed out; however, they serve some other purpose rather than slot
      information.  Thus, using these bits on POWER7 to adjust the SIAR value results
      in samples being attributed to the wrong instructions.  The attached patch
      changes the oprofile kernel driver to ignore these slot bits on all newer
      processors starting with POWER6.
      Signed-off-by: default avatarMaynard Johnson <maynardj@us.ibm.com>
      Signed-off-by: default avatarMichael Wolf <mjw@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Stephen Rothwell  x's avatar
      powerpc/iseries: Fix pci breakage due to bad dma_data initialization · 397717c5
      Stephen Rothwell x authored
      Commit 4fc665b8 "powerpc: Merge 32 and
      64-bit dma code" made changes to the PCI initialisation code that added
      an assignment to archdata.dma_data but only for 32 bit code.  Commit
       "powerpc/pci: Cosmetic cleanups
      of pci-common.c" removed the conditional compilation.  Unfortunately,
      the iSeries code setup the archdata.dma_data before that assignment was
      done - effectively overwriting the dma_data with NULL.
      Fix this up by moving the iSeries setup of dma_data into a
      pci_dma_dev_setup callback.
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Timur Tabi's avatar
      powerpc: Fix mktree build error on Mac OS X host · 93f1cc60
      Timur Tabi authored
      The mktree utility defines some variables as "uint", although this is not a
      standard C type, and so cross-compiling on Mac OS X fails.  Change this to
      "unsigned int".
      Signed-off-by: default avatarTimur Tabi <timur@freescale.com>
      Acked-by: default avatarJosh Boyer <jwboyer@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
  3. 14 May, 2009 6 commits