[Zesty][PATCH 1/1] powerpc/perf: Avoid spurious PMU interrupts after idle

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Zesty][PATCH 1/1] powerpc/perf: Avoid spurious PMU interrupts after idle

Rodrigo R. Galvao
From: Nicholas Piggin <[hidden email]>

BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1709352

POWER9 DD2 can see spurious PMU interrupts after state-loss idle in
some conditions.

A solution is to save and reload MMCR0 over state-loss idle.

Signed-off-by: Nicholas Piggin <[hidden email]>
Acked-by: Madhavan Srinivasan <[hidden email]>
Tested-by: Anton Blanchard <[hidden email]>
Signed-off-by: Michael Ellerman <[hidden email]>
(cherry picked from commit 101dd590a7fa37954540cf3149a1c502c0acc524)
Signed-off-by: Rodrigo R. Galvao <[hidden email]>
---
 arch/powerpc/kernel/idle_book3s.S | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/idle_book3s.S b/arch/powerpc/kernel/idle_book3s.S
index fb762ee..e003fb9 100644
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -29,6 +29,7 @@
  * Use unused space in the interrupt stack to save and restore
  * registers for winkle support.
  */
+#define _MMCR0 GPR0
 #define _SDR1 GPR3
 #define _RPR GPR4
 #define _SPURR GPR5
@@ -282,6 +283,14 @@ power_enter_stop:
  b pnv_wakeup_noloss
 
 .Lhandle_esl_ec_set:
+ /*
+ * POWER9 DD2 can incorrectly set PMAO when waking up after a
+ * state-loss idle. Saving and restoring MMCR0 over idle is a
+ * workaround.
+ */
+ mfspr r4,SPRN_MMCR0
+ std r4,_MMCR0(r1)
+
 /*
  * Check if the requested state is a deep idle state.
  */
@@ -434,10 +443,14 @@ FTR_SECTION_ELSE_NESTED(70)
 ALT_FTR_SECTION_END_NESTED_IFSET(CPU_FTR_POWER9_DD1, 70)
  /*
  * Workaround for POWER9, if we lost resources, the ERAT
- * might have been mixed up and needs flushing.
+ * might have been mixed up and needs flushing. We also need
+ * to reload MMCR0 (see comment above).
  */
  blt cr3,1f
  PPC_INVALIDATE_ERAT
+ ld r1,PACAR1(r13)
+ ld r4,_MMCR0(r1)
+ mtspr SPRN_MMCR0,r4
 1:
  /*
  * POWER ISA 3. Use PSSCR to determine if we
--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ACK/cmt / APPLIED[artful]: [Zesty][PATCH 1/1] powerpc/perf: Avoid spurious PMU interrupts after idle

Seth Forshee
On Wed, Aug 09, 2017 at 10:44:56AM -0300, Rodrigo R. Galvao wrote:

> From: Nicholas Piggin <[hidden email]>
>
> BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1709352
>
> POWER9 DD2 can see spurious PMU interrupts after state-loss idle in
> some conditions.
>
> A solution is to save and reload MMCR0 over state-loss idle.
>
> Signed-off-by: Nicholas Piggin <[hidden email]>
> Acked-by: Madhavan Srinivasan <[hidden email]>
> Tested-by: Anton Blanchard <[hidden email]>
> Signed-off-by: Michael Ellerman <[hidden email]>
> (cherry picked from commit 101dd590a7fa37954540cf3149a1c502c0acc524)
> Signed-off-by: Rodrigo R. Galvao <[hidden email]>

This patch had some context differences when I tried to apply it to
4.12 so I cherry picked it directly. That makes me wonder whether you
had to fix it up for zesty though; if so the "cherry picked" should be
changed to "backported".

Otherwise the patch looks fine to me.

Acked-by: Seth Forshee <[hidden email]>

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ACK: [Zesty][PATCH 1/1] powerpc/perf: Avoid spurious PMU interrupts after idle

Kleber Souza
In reply to this post by Rodrigo R. Galvao
On 08/09/17 15:44, Rodrigo R. Galvao wrote:

> From: Nicholas Piggin <[hidden email]>
>
> BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1709352
>
> POWER9 DD2 can see spurious PMU interrupts after state-loss idle in
> some conditions.
>
> A solution is to save and reload MMCR0 over state-loss idle.
>
> Signed-off-by: Nicholas Piggin <[hidden email]>
> Acked-by: Madhavan Srinivasan <[hidden email]>
> Tested-by: Anton Blanchard <[hidden email]>
> Signed-off-by: Michael Ellerman <[hidden email]>
> (cherry picked from commit 101dd590a7fa37954540cf3149a1c502c0acc524)
> Signed-off-by: Rodrigo R. Galvao <[hidden email]>
> ---
>  arch/powerpc/kernel/idle_book3s.S | 15 ++++++++++++++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/idle_book3s.S b/arch/powerpc/kernel/idle_book3s.S
> index fb762ee..e003fb9 100644
> --- a/arch/powerpc/kernel/idle_book3s.S
> +++ b/arch/powerpc/kernel/idle_book3s.S
> @@ -29,6 +29,7 @@
>   * Use unused space in the interrupt stack to save and restore
>   * registers for winkle support.
>   */
> +#define _MMCR0 GPR0
>  #define _SDR1 GPR3
>  #define _RPR GPR4
>  #define _SPURR GPR5
> @@ -282,6 +283,14 @@ power_enter_stop:
>   b pnv_wakeup_noloss
>  
>  .Lhandle_esl_ec_set:
> + /*
> + * POWER9 DD2 can incorrectly set PMAO when waking up after a
> + * state-loss idle. Saving and restoring MMCR0 over idle is a
> + * workaround.
> + */
> + mfspr r4,SPRN_MMCR0
> + std r4,_MMCR0(r1)
> +
>  /*
>   * Check if the requested state is a deep idle state.
>   */
> @@ -434,10 +443,14 @@ FTR_SECTION_ELSE_NESTED(70)
>  ALT_FTR_SECTION_END_NESTED_IFSET(CPU_FTR_POWER9_DD1, 70)
>   /*
>   * Workaround for POWER9, if we lost resources, the ERAT
> - * might have been mixed up and needs flushing.
> + * might have been mixed up and needs flushing. We also need
> + * to reload MMCR0 (see comment above).
>   */
>   blt cr3,1f
>   PPC_INVALIDATE_ERAT
> + ld r1,PACAR1(r13)
> + ld r4,_MMCR0(r1)
> + mtspr SPRN_MMCR0,r4
>  1:
>   /*
>   * POWER ISA 3. Use PSSCR to determine if we
>

Clean cherry-pick (applies cleanly to zesty/master-next), scope limited
to POWER9.

Acked-by: Kleber Sacilotto de Souza <[hidden email]>

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Loading...