From patchwork Wed Sep 12 05:51:57 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: R Sricharan X-Patchwork-Id: 1441001 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 9839B3FE79 for ; Wed, 12 Sep 2012 05:52:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753995Ab2ILFwK (ORCPT ); Wed, 12 Sep 2012 01:52:10 -0400 Received: from bear.ext.ti.com ([192.94.94.41]:32933 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752125Ab2ILFwJ (ORCPT ); Wed, 12 Sep 2012 01:52:09 -0400 Received: from dbdp20.itg.ti.com ([172.24.170.38]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id q8C5q6ej026197; Wed, 12 Sep 2012 00:52:06 -0500 Received: from DBDE71.ent.ti.com (localhost [127.0.0.1]) by dbdp20.itg.ti.com (8.13.8/8.13.8) with ESMTP id q8C5q5bA008841; Wed, 12 Sep 2012 11:22:05 +0530 (IST) Received: from dbdp33.itg.ti.com (172.24.170.252) by DBDE71.ent.ti.com (172.24.170.149) with Microsoft SMTP Server id 14.1.323.3; Wed, 12 Sep 2012 11:22:05 +0530 Received: from localhost.localdomain (smtpvbd.itg.ti.com [172.24.170.250]) by dbdp33.itg.ti.com (8.13.8/8.13.8) with ESMTP id q8C5q5Fa027966; Wed, 12 Sep 2012 11:22:05 +0530 From: R Sricharan To: , CC: , Subject: [PATCH] ARM: OMAP2+: TEMP: Round of the carve out memory requested to section_size Date: Wed, 12 Sep 2012 11:21:57 +0530 Message-ID: <1347429117-10919-1-git-send-email-r.sricharan@ti.com> X-Mailer: git-send-email 1.7.9.5 MIME-Version: 1.0 Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org 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. Signed-off-by: R Sricharan --- arch/arm/mach-omap2/omap-secure.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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; }