From mboxrd@z Thu Jan 1 00:00:00 1970 From: gregory.clement@free-electrons.com (Gregory CLEMENT) Date: Mon, 10 Nov 2014 15:05:21 +0100 Subject: [PATCH 13/17] ARM: mvebu: make sure MMU is disabled in armada_370_xp_cpu_resume In-Reply-To: <1414151970-6626-14-git-send-email-thomas.petazzoni@free-electrons.com> References: <1414151970-6626-1-git-send-email-thomas.petazzoni@free-electrons.com> <1414151970-6626-14-git-send-email-thomas.petazzoni@free-electrons.com> Message-ID: <5460C621.9010506@free-electrons.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 24/10/2014 13:59, Thomas Petazzoni wrote: > The armada_370_xp_cpu_resume() until now was used only as the function > called by the SoC when returning from a deep idle state (as used in > cpuidle, or when the CPU is brought offline using CPU hotplug). > > However, it is now also used when exiting the suspend to RAM state. In > this case, it is the bootloader that calls back into this function, > with the MMU left enabled by the BootROM. Having the MMU enabled when > entering this function confuses the kerrnel because we are not using kernel > the kernel page tables at this point, but in other mvebu functions we > use the information on whether the MMU is enabled or not to find out > whether we should talk to the coherency fabric using a physical > address or a virtual address. To fix that, we simply disable the MMU > when entering this function, so that the kernel is in an expected > situation. > Acked-by: Gregory CLEMENT > Signed-off-by: Thomas Petazzoni > --- > arch/arm/mach-mvebu/pmsu_ll.S | 8 ++++++++ > 1 file changed, 8 insertions(+) -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gregory CLEMENT Subject: Re: [PATCH 13/17] ARM: mvebu: make sure MMU is disabled in armada_370_xp_cpu_resume Date: Mon, 10 Nov 2014 15:05:21 +0100 Message-ID: <5460C621.9010506@free-electrons.com> References: <1414151970-6626-1-git-send-email-thomas.petazzoni@free-electrons.com> <1414151970-6626-14-git-send-email-thomas.petazzoni@free-electrons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <1414151970-6626-14-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Thomas Petazzoni , Jason Cooper , Andrew Lunn , Sebastian Hesselbarth Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Tawfik Bayouk , Nadav Haklai , Lior Amsalem , Ezequiel Garcia , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: devicetree@vger.kernel.org On 24/10/2014 13:59, Thomas Petazzoni wrote: > The armada_370_xp_cpu_resume() until now was used only as the function > called by the SoC when returning from a deep idle state (as used in > cpuidle, or when the CPU is brought offline using CPU hotplug). > > However, it is now also used when exiting the suspend to RAM state. In > this case, it is the bootloader that calls back into this function, > with the MMU left enabled by the BootROM. Having the MMU enabled when > entering this function confuses the kerrnel because we are not using kernel > the kernel page tables at this point, but in other mvebu functions we > use the information on whether the MMU is enabled or not to find out > whether we should talk to the coherency fabric using a physical > address or a virtual address. To fix that, we simply disable the MMU > when entering this function, so that the kernel is in an expected > situation. > Acked-by: Gregory CLEMENT > Signed-off-by: Thomas Petazzoni > --- > arch/arm/mach-mvebu/pmsu_ll.S | 8 ++++++++ > 1 file changed, 8 insertions(+) -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html