From mboxrd@z Thu Jan 1 00:00:00 1970 From: gregory.clement@free-electrons.com (Gregory CLEMENT) Date: Tue, 04 Nov 2014 11:09:16 +0100 Subject: [PATCH 11/17] ARM: mvebu: reserve the first 10 KB of each memory bank for suspend/resume In-Reply-To: <1414151970-6626-12-git-send-email-thomas.petazzoni@free-electrons.com> References: <1414151970-6626-1-git-send-email-thomas.petazzoni@free-electrons.com> <1414151970-6626-12-git-send-email-thomas.petazzoni@free-electrons.com> Message-ID: <5458A5CC.8090409@free-electrons.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Thomas, On 24/10/2014 13:59, Thomas Petazzoni wrote: > When going out of suspend to RAM, the Marvell EBU platforms go through > the bootloader, which re-configures the DRAM controller. To achieve > this, the bootloader executes a piece of code called the "DDR3 > training code". It does some reads/writes to the memory to find out > the optimal timings for the memory chip being used. > > This has the nasty side effect that the first 10 KB of each DRAM > chip-select are overwritten by the bootloader when exiting the suspend > to RAM state. > > Therefore, this commit implements the ->reserve() hook for the 'struct > machine_desc' used on Armada XP, to reserve the 10 KB of each DRAM > chip-select using the memblock API. > > Signed-off-by: Thomas Petazzoni > --- > arch/arm/mach-mvebu/board-v7.c | 51 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 51 insertions(+) It is unfortunate to put these "holes" in the memory but it is a design constraint. However, your solution is nice and very well contained however. Acked-by: Gregory CLEMENT Thanks, Gregory -- 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 11/17] ARM: mvebu: reserve the first 10 KB of each memory bank for suspend/resume Date: Tue, 04 Nov 2014 11:09:16 +0100 Message-ID: <5458A5CC.8090409@free-electrons.com> References: <1414151970-6626-1-git-send-email-thomas.petazzoni@free-electrons.com> <1414151970-6626-12-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-12-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Thomas Petazzoni Cc: Jason Cooper , Andrew Lunn , Sebastian Hesselbarth , 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 Hi Thomas, On 24/10/2014 13:59, Thomas Petazzoni wrote: > When going out of suspend to RAM, the Marvell EBU platforms go through > the bootloader, which re-configures the DRAM controller. To achieve > this, the bootloader executes a piece of code called the "DDR3 > training code". It does some reads/writes to the memory to find out > the optimal timings for the memory chip being used. > > This has the nasty side effect that the first 10 KB of each DRAM > chip-select are overwritten by the bootloader when exiting the suspend > to RAM state. > > Therefore, this commit implements the ->reserve() hook for the 'struct > machine_desc' used on Armada XP, to reserve the 10 KB of each DRAM > chip-select using the memblock API. > > Signed-off-by: Thomas Petazzoni > --- > arch/arm/mach-mvebu/board-v7.c | 51 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 51 insertions(+) It is unfortunate to put these "holes" in the memory but it is a design constraint. However, your solution is nice and very well contained however. Acked-by: Gregory CLEMENT Thanks, Gregory -- 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