1. 17 Dec, 2015 10 commits
    • Michael Ellerman's avatar
      powerpc/kernel: Open code HMT_MEDIUM_LOW_HAS_PPR · d030a4b5
      Michael Ellerman authored
      HMT_MEDIUM_LOW_HAS_PPR is only used in once place, open code it.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      d030a4b5
    • Michael Ellerman's avatar
      powerpc/kernel: Drop HMT_MEDIUM_PPR_DISCARD · d6265aea
      Michael Ellerman authored
      HMT_MEDIUM_PPR_DISCARD is a macro which is present at the start of most
      of our first level exception handlers. It conditionally executes a
      HMT_MEDIUM instruction, which sets the processor priority to medium.
      
      On on modern systems, ie. Power7 and later, it is nop'ed out at boot.
      All it does is make the exception vectors more cramped, and consume 4
      bytes of icache.
      
      On old systems it has the effect of boosting the processor priority at
      the start of exception processing. If we were previously in the idle
      loop for example, we may be at low or very low priority. This is
      desirable as we want to process the exception as fast as possible.
      
      However looking closely at the generated code, we see that in all cases
      we execute another HMT_MEDIUM just four instructions later. With code
      patching applied, the final code on an old (Power6) system will look
      like, eg:
      
        c000000000000300 <data_access_pSeries>:
        c000000000000300:	7c 42 13 78	mr	r2,r2		<-
        c000000000000304:	7d b2 43 a6	mtsprg	2,r13
        c000000000000308:	7d b1 42 a6	mfsprg	r13,1
        c00000000000030c:	f9 2d 00 80	std	r9,128(r13)
        c000000000000310:	60 00 00 00	nop
        c000000000000314:	7c 42 13 78	mr	r2,r2		<-
      
      So I suggest that the added code complexity of HMT_MEDIUM_PPR_DISCARD is
      not justified by the benefit of boosting the processor priority for the
      duration of four instructions, and therefore we drop it.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      d6265aea
    • Michael Ellerman's avatar
      powerpc/rtas: Make enter_rtas() private · cd5cdeb6
      Michael Ellerman authored
      There are no longer any users of enter_rtas() outside of rtas.c, so make
      it "private", by moving the declaration inside rtas.c. Hopefully this
      will encourage people to use one of the wrappers which takes the sharp
      edges off the RTAS calling sequence.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      cd5cdeb6
    • Michael Ellerman's avatar
      powerpc/rtas: Use rtas_call_unlocked() in call_rtas_display_status() · 4456f452
      Michael Ellerman authored
      Although call_rtas_display_status() does actually want to use the
      regular RTAS locking, it doesn't want the extra logic that is in
      rtas_call(), so currently it open codes the logic.
      
      Instead we can use rtas_call_unlocked(), after taking the RTAS lock.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      4456f452
    • Michael Ellerman's avatar
      powerpc/pseries: Use rtas_call_unlocked() in pseries hotplug · b2e8590f
      Michael Ellerman authored
      Avoid open coding the logic by using rtas_call_unlocked().
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      b2e8590f
    • Michael Ellerman's avatar
      powerpc/xmon: Use rtas_call_unlocked() in xmon · 08eb105a
      Michael Ellerman authored
      Avoid open coding the logic by using rtas_call_unlocked().
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      08eb105a
    • Michael Ellerman's avatar
      powerpc/rtas: Add rtas_call_unlocked() · 209eb4e5
      Michael Ellerman authored
      Most users of RTAS (Run-Time Abstraction Services) use rtas_call(),
      which deals with locking as well as endian handling.
      
      However we have two users outside of rtas.c that can't use rtas_call()
      because they have different locking requirements.
      
      The hotplug CPU code can't take the RTAS lock because the CPU would go
      offline with the lock held and no other CPUs would be able to call RTAS
      until the CPU came back online.
      
      The xmon code doesn't want to take the lock because it would risk dead
      locking when we are trying to recover from a crash.
      
      Both sites required multiple patches when we added little endian
      support, proving that programmers can't do endian right.
      
      Although that ship has sailed, we can still clean the code up by
      providing an unlocked version of rtas_call() which avoids the need to
      open code the logic elsewhere.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      209eb4e5
    • Stewart Smith's avatar
      powerpc/powernv: remove FW_FEATURE_OPALv3 and just use FW_FEATURE_OPAL · e4d54f71
      Stewart Smith authored
      Long ago, only in the lab, there was OPALv1 and OPALv2. Now there is
      just OPALv3, with nobody ever expecting anything on pre-OPALv3 to
      be cared about or supported by mainline kernels.
      
      So, let's remove FW_FEATURE_OPALv3 and instead use FW_FEATURE_OPAL
      exclusively.
      Signed-off-by: default avatarStewart Smith <stewart@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      e4d54f71
    • Stewart Smith's avatar
      powerpc/powernv: Remove OPALv2 firmware define and references · 7261aafc
      Stewart Smith authored
      OPALv2 only ever existed in the lab and didn't escape to the world.
      All OPAL systems in the wild are OPALv3.
      
      The probability of there being an OPALv2 system still powered on
      anywhere inside IBM is approximately zero, let alone anyone
      expecting to run mainline kernels.
      
      So, start to remove references to OPALv2.
      Signed-off-by: default avatarStewart Smith <stewart@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      7261aafc
    • Stewart Smith's avatar
      powerpc/powernv: panic() on OPAL < V3 · 786842b6
      Stewart Smith authored
      The OpenPower Abstraction Layer firmware went through a couple
      of iterations in the lab before being released. What we now know
      as OPAL advertises itself as OPALv3.
      
      OPALv2 and OPALv1 never made it outside the lab, and the possibility
      of anyone at all ever building a mainline kernel today and expecting
      it to boot on such hardware is zero.
      Signed-off-by: default avatarStewart Smith <stewart@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      786842b6
  2. 16 Dec, 2015 6 commits
  3. 14 Dec, 2015 24 commits