ARM: 7298/1: realview: fix mapping of MPCore private memory region
authorMarc Zyngier <Marc.Zyngier@arm.com>
Tue, 24 Jan 2012 10:56:02 +0000 (11:56 +0100)
committerRussell King <rmk+kernel@arm.linux.org.uk>
Wed, 25 Jan 2012 09:24:36 +0000 (09:24 +0000)
commit34ae6c96a6a7db4ed8ec0524bf7fa1086b9ab2ba
tree9795fe4203ec655830abf22334b4547e3bec4afd
parent171cf94ccb4b476d1d7d694a31d0820558375132
ARM: 7298/1: realview: fix mapping of MPCore private memory region

Since commit 0536bdf33faf (ARM: move iotable mappings within
the vmalloc region), the RealView PB11MP cannot boot anymore.

This is caused by the way the mappings are described on this
platform (define replaced by hex values for clarity):

{ /* GIC CPU interface mapping */
        .virtual        = IO_ADDRESS(0x1F000100),
        .pfn            = __phys_to_pfn(0x1F000100),
        .length         = SZ_4K,
        .type           = MT_DEVICE,
}, { /* GIC distributor mapping */
        .virtual        = IO_ADDRESS(0x1F001000),
        .pfn            = __phys_to_pfn(0x1F001000),
        .length         = SZ_4K,
        .type           = MT_DEVICE,
}

The first mapping ends up reserving two pages, and clashes with
the second one, which triggers a BUG_ON in vm_area_add_early().

In order to solve this problem, treat the MPCore private memory
region (containing the SCU, the GIC and the TWD) as a single region,
as described in the TRM:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/CACGDJJC.html

The EB11MP is converted the same way, even if it manages to avoid
the problem.

Tested on both PB11MP and EB11MP.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
arch/arm/mach-realview/include/mach/board-eb.h
arch/arm/mach-realview/include/mach/board-pb11mp.h
arch/arm/mach-realview/realview_eb.c
arch/arm/mach-realview/realview_pb11mp.c