| Message ID | 1347434053-11431-1-git-send-email-r.sricharan@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Sep 12, 2012 at 12:44 PM, R Sricharan <r.sricharan@ti.com> wrote: > memblock_steal tries to reserve physical memory during boot. > When the requested size is not aligned on the section size > then, the remaining memory available for lowmem becomes > unaligned on the section boundary. There is a issue with this, > which is discussed in the thread below. > > https://lkml.org/lkml/2012/6/28/112 > > The final conclusion from the thread seems to > be align the memblock_steal calls on the SECTION boundary. > The issue comes out when LPAE is enabled, where the > section size is 2MB. > > Boot tested this on OMAP5 evm with and without LPAE. > > Signed-off-by: R Sricharan <r.sricharan@ti.com> > --- > [V2] Corrected the subject and added one more description line. > Looks good. Acked-by : Santosh Shilimkar <santosh.shilimkar@ti.com> Tony, Can you take this into your next "fixes-noncritical" queue please ? Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Shilimkar, Santosh <santosh.shilimkar@ti.com> [120927 23:35]: > On Wed, Sep 12, 2012 at 12:44 PM, R Sricharan <r.sricharan@ti.com> wrote: > > memblock_steal tries to reserve physical memory during boot. > > When the requested size is not aligned on the section size > > then, the remaining memory available for lowmem becomes > > unaligned on the section boundary. There is a issue with this, > > which is discussed in the thread below. > > > > https://lkml.org/lkml/2012/6/28/112 > > > > The final conclusion from the thread seems to > > be align the memblock_steal calls on the SECTION boundary. > > The issue comes out when LPAE is enabled, where the > > section size is 2MB. > > > > Boot tested this on OMAP5 evm with and without LPAE. > > > > Signed-off-by: R Sricharan <r.sricharan@ti.com> > > --- > > [V2] Corrected the subject and added one more description line. > > > Looks good. > Acked-by : Santosh Shilimkar <santosh.shilimkar@ti.com> > > Tony, > Can you take this into your next "fixes-noncritical" queue please ? Applying it now into fixes for the -rc cycle. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c index d9ae4a5..26edfec 100644 --- a/arch/arm/mach-omap2/omap-secure.c +++ b/arch/arm/mach-omap2/omap-secure.c @@ -61,8 +61,8 @@ int __init omap_secure_ram_reserve_memblock(void) { u32 size = OMAP_SECURE_RAM_STORAGE; - size = ALIGN(size, SZ_1M); - omap_secure_memblock_base = arm_memblock_steal(size, SZ_1M); + size = ALIGN(size, SECTION_SIZE); + omap_secure_memblock_base = arm_memblock_steal(size, SECTION_SIZE); return 0; }
memblock_steal tries to reserve physical memory during boot. When the requested size is not aligned on the section size then, the remaining memory available for lowmem becomes unaligned on the section boundary. There is a issue with this, which is discussed in the thread below. https://lkml.org/lkml/2012/6/28/112 The final conclusion from the thread seems to be align the memblock_steal calls on the SECTION boundary. The issue comes out when LPAE is enabled, where the section size is 2MB. Boot tested this on OMAP5 evm with and without LPAE. Signed-off-by: R Sricharan <r.sricharan@ti.com> --- [V2] Corrected the subject and added one more description line. arch/arm/mach-omap2/omap-secure.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)