Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756838AbbGQIkI (ORCPT ); Fri, 17 Jul 2015 04:40:08 -0400 Received: from mail.skyhub.de ([78.46.96.112]:57711 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755962AbbGQIkD (ORCPT ); Fri, 17 Jul 2015 04:40:03 -0400 Date: Fri, 17 Jul 2015 10:39:53 +0200 From: Borislav Petkov To: Laura Abbott Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, Peter Zijlstra , Andy Lutomirski Subject: Re: [RFC][PATCH] x86, CPU: Restore MSR_IA32_ENERGY_PERF_BIAS after resume Message-ID: <20150717083953.GA27348@nazgul.tnic> References: <1437084561-18679-1-git-send-email-labbott@fedoraproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1437084561-18679-1-git-send-email-labbott@fedoraproject.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2719 Lines: 87 On Thu, Jul 16, 2015 at 03:09:21PM -0700, Laura Abbott wrote: > MSR_IA32_ENERGY_PERF_BIAS is lost after suspend/resume: > > x86_energy_perf_policy -r before > > cpu0: 0x0000000000000006 > cpu1: 0x0000000000000006 > cpu2: 0x0000000000000006 > cpu3: 0x0000000000000006 > cpu4: 0x0000000000000006 > cpu5: 0x0000000000000006 > cpu6: 0x0000000000000006 > cpu7: 0x0000000000000006 > > after > > cpu0: 0x0000000000000000 Yap, I see it here too on an IVB laptop when doing s2r. > cpu1: 0x0000000000000006 > cpu2: 0x0000000000000006 > cpu3: 0x0000000000000006 > cpu4: 0x0000000000000006 > cpu5: 0x0000000000000006 > cpu6: 0x0000000000000006 > cpu7: 0x0000000000000006 > > This register is set via init_intel at bootup. During resume, the > secondary CPUs are brought online again and init_intel is callled which > re-initializes the register. The boot cpu however never reinitializes > the register. Add a syscore callback to reinitialize the register for > the boot CPU. > > Signed-off-by: Laura Abbott > --- > RFC because I'm not that familiar with x86 suspend/resume inner workings. > --- > arch/x86/kernel/cpu/common.c | 18 ++++++++++++++++++ > arch/x86/kernel/cpu/cpu.h | 1 + > arch/x86/kernel/cpu/intel.c | 36 +++++++++++++++++++++--------------- > 3 files changed, 40 insertions(+), 15 deletions(-) > > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index 922c5e0..dc9f1e5 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -13,6 +13,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -1488,3 +1489,20 @@ inline bool __static_cpu_has_safe(u16 bit) > return boot_cpu_has(bit); > } > EXPORT_SYMBOL_GPL(__static_cpu_has_safe); > + > +static void cpu_custom_resume(void) Let's call this bsp_resume() as it is run only on the boot CPU. > +{ > + if (this_cpu->c_resume) > + this_cpu->c_resume(&boot_cpu_data); > +} So giving boot_cpu_data means, this is the boot CPU but you're assigning it to c_resume() which means, every CPU. What you could do is call the function ptr ->c_bsp_resume like the ->c_bsp_init which we already have so that it is clear that it is run only on the BSP. Rest looks ok to me, unless tip guys have a better idea... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/