[PATCH] ARM: fix ioremap to allow mapping some specific RAM areas

Creating more than one mapping on ARMv6+ might cause unspecified behavior,
so ioremap() should fail if it was called with area that matches low memory.
However if the board code removes the specific area from low memory
mapping on boot (for example by calling memblock_remove()), then creating
a mapping with ioremap might be desired.

This patch enables creating mapping for RAM by ioremap call, but only if
the target area has no low memory mapping yet. This enables board code to
reserve particular memory areas with memblock_remove() and provide them to
device drivers with a declare_coherent_memory() call.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 arch/arm/mm/ioremap.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index ab50627..d3fcc05 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c

@@ -25,6 +25,7 @@
 #include <linux/mm.h>
 #include <linux/vmalloc.h>
 #include <linux/io.h>
+#include <linux/memblock.h>
 
 #include <asm/cputype.h>
 #include <asm/cacheflush.h>

@@ -202,9 +203,10 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
 		return NULL;
 
 	/*
-	 * Don't allow RAM to be mapped - this causes problems with ARMv6+
+	 * Don't allow low memory to be mapped again - this causes problems
+	 * with ARMv6+
 	 */
-	if (WARN_ON(pfn_valid(pfn)))
+	if (WARN_ON(memblock_is_memory(pfn << PAGE_SHIFT)))
 		return NULL;
 
 	type = get_mem_type(mtype);

-- 
1.7.1.569.g6f426

On Tue, Jun 07, 2011 at 09:12:25AM +0200, Marek Szyprowski wrote:

Creating more than one mapping on ARMv6+ might cause unspecified behavior,
so ioremap() should fail if it was called with area that matches low memory.
However if the board code removes the specific area from low memory
mapping on boot (for example by calling memblock_remove()), then creating
a mapping with ioremap might be desired.

This patch enables creating mapping for RAM by ioremap call, but only if
the target area has no low memory mapping yet. This enables board code to
reserve particular memory areas with memblock_remove() and provide them to
device drivers with a declare_coherent_memory() call.

NAK.  pfn_valid is already defined like this:

int pfn_valid(unsigned long pfn)
{
        return memblock_is_memory(pfn << PAGE_SHIFT);
}

provided you enable ARCH_HAS_HOLES_MEMORYMODEL, which you must do if
you're punching holes in the memory map.

Hello,

On Tuesday, June 07, 2011 10:06 AM Russell King - ARM Linux wrote:

On Tue, Jun 07, 2011 at 09:12:25AM +0200, Marek Szyprowski wrote:

quoted

Creating more than one mapping on ARMv6+ might cause unspecified behavior,
so ioremap() should fail if it was called with area that matches low

memory.

quoted

However if the board code removes the specific area from low memory
mapping on boot (for example by calling memblock_remove()), then creating
a mapping with ioremap might be desired.

This patch enables creating mapping for RAM by ioremap call, but only if
the target area has no low memory mapping yet. This enables board code to
reserve particular memory areas with memblock_remove() and provide them

to

quoted

device drivers with a declare_coherent_memory() call.

NAK.  pfn_valid is already defined like this:

int pfn_valid(unsigned long pfn)
{
        return memblock_is_memory(pfn << PAGE_SHIFT);
}

provided you enable ARCH_HAS_HOLES_MEMORYMODEL, which you must do if
you're punching holes in the memory map.

Ok, I see the point in ARCH_HAS_HOLES_MEMORYMODEL, but it doesn't solve my
problem. In case of Samsung Exynos4 and S5PV210 platforms we use SPARSEMEM,
but the above definition of pfn_valid() function is correct only if SPARSEMEM
is not enabled.

How do you suggest to solve this issue in case of SPARSEMEM platforms?

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center

On Tue, Jun 07, 2011 at 10:44:15AM +0200, Marek Szyprowski wrote:

On Tuesday, June 07, 2011 10:06 AM Russell King - ARM Linux wrote:

quoted

NAK.  pfn_valid is already defined like this:

int pfn_valid(unsigned long pfn)
{
        return memblock_is_memory(pfn << PAGE_SHIFT);
}

provided you enable ARCH_HAS_HOLES_MEMORYMODEL, which you must do if
you're punching holes in the memory map.

Ok, I see the point in ARCH_HAS_HOLES_MEMORYMODEL, but it doesn't solve my
problem. In case of Samsung Exynos4 and S5PV210 platforms we use SPARSEMEM,
but the above definition of pfn_valid() function is correct only if SPARSEMEM
is not enabled.

Sparsemem has been fixed recently (during the merge window) so that this
is now correct.

Hello,

On Tuesday, June 07, 2011 10:55 AM Russell King - ARM Linux wrote:

On Tue, Jun 07, 2011 at 10:44:15AM +0200, Marek Szyprowski wrote:

quoted

On Tuesday, June 07, 2011 10:06 AM Russell King - ARM Linux wrote:

quoted

NAK.  pfn_valid is already defined like this:

int pfn_valid(unsigned long pfn)
{
        return memblock_is_memory(pfn << PAGE_SHIFT);
}

provided you enable ARCH_HAS_HOLES_MEMORYMODEL, which you must do if
you're punching holes in the memory map.

Ok, I see the point in ARCH_HAS_HOLES_MEMORYMODEL, but it doesn't solve

my

quoted

problem. In case of Samsung Exynos4 and S5PV210 platforms we use

SPARSEMEM,

quoted

but the above definition of pfn_valid() function is correct only if

SPARSEMEM

quoted

is not enabled.

Sparsemem has been fixed recently (during the merge window) so that this
is now correct.

OK, thanks for help.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center