Skip to content
  1. Feb 15, 2013
  2. Feb 08, 2013
    • Ian Munsie's avatar
      powerpc: Add support for context switching the TAR register · 2468dcf6
      Ian Munsie authored
      
      
      This patch adds support for enabling and context switching the Target
      Address Register in Power8. The TAR is a new special purpose register
      that can be used for computed branches with the bctar[l] (branch
      conditional to TAR) instruction in the same manner as the count and link
      registers.
      
      Signed-off-by: default avatarIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: default avatarMatt Evans <matt@ozlabs.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2468dcf6
    • Nishanth Aravamudan's avatar
      pseries/iommu: Remove DDW on kexec · 14b6f00f
      Nishanth Aravamudan authored
      pseries/iommu: remove DDW on kexec
      
      We currently insert a property in the device-tree when we successfully
      configure DDW for a given slot. This was meant to be an optimization to
      speed up kexec/kdump, so that we don't need to make the RTAS calls again
      to re-configured DDW in the new kernel.
      
      However, we end up tripping a plpar_tce_stuff failure on kexec/kdump
      because we unconditionally parse the ibm,dma-window property for the
      node at bus/dev setup time. This property contains the 32-bit DMA window
      LIOBN, which is distinct from the DDW window's. We pass that LIOBN (via
      iommu_table_init -> iommu_table_clear -> tce_free ->
      tce_freemulti_pSeriesLP) to plpar_tce_stuff, which fails because that
      32-bit window is no longer present after
      25ebc45b
      
       ("powerpc/pseries/iommu: remove
      default window before attempting DDW manipulation").
      
      I believe the simplest, easiest-to-maintain fix is to just change our
      initcall to, rather than detecting and updating the new kernel's DDW
      knowledge, just remove all DDW configurations. When the drivers
      re-initialize, we will set everything back up as it was before.
      
      Signed-off-by: default avatarNishanth Aravamudan <nacc@us.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      14b6f00f
    • Nishanth Aravamudan's avatar
      pseries/iommu: Restore_default_window does not use liobn parameter · a1dabade
      Nishanth Aravamudan authored
      
      
      The parameter is unused, and complicates a following fix. Just remove
      it.
      
      Signed-off-by: default avatarNishanth Aravamudan <nacc@us.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a1dabade
    • Daniel Borkmann's avatar
      powerpc: fix ics_rtas_init and start_secondary section mismatch · 174ea471
      Daniel Borkmann authored
      
      
      It seems, we're fine with just annotating the two functions.
      Thus, this fixes the following build warnings on ppc64:
      
      WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1664):
      The function .ics_rtas_init() references
      the function __init .xics_register_ics().
      This is often because .ics_rtas_init lacks a __init
      annotation or the annotation of .xics_register_ics is wrong.
      
      WARNING: arch/powerpc/sysdev/built-in.o(.text+0x6044):
      The function .ics_rtas_init() references
      the function __init .xics_register_ics().
      This is often because .ics_rtas_init lacks a __init
      annotation or the annotation of .xics_register_ics is wrong.
      
      WARNING: arch/powerpc/kernel/built-in.o(.text+0x2db30):
      The function .start_secondary() references
      the function __cpuinit .vdso_getcpu_init().
      This is often because .start_secondary lacks a __cpuinit
      annotation or the annotation of .vdso_getcpu_init is wrong.
      
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      174ea471
  3. Jan 29, 2013