linux-toradex.git/mm/memblock.c, branch v3.2.22

mm/memblock.c: quiet sparse noise

2011-11-01T00:30:50+00:00

Quiet the following sparse noise in this file:

warning: symbol 'memblock_overlaps_region' was not declared. Should it be static?

Signed-off-by: H Hartley Sweeten 
Cc: Yinghai Lu 
Cc: "H. Peter Anvin" 
Cc: Benjamin Herrenschmidt 
Cc: Tomi Valkeinen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/memblock.c: small function definition fixes

2011-11-01T00:30:48+00:00

warning: function 'memblock_memory_can_coalesce'
with external linkage has definition.

Signed-off-by: Jonghwan Choi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memblock: add memblock_start_of_DRAM()

2011-11-01T00:30:47+00:00

SPARC32 require access to the start address.  Add a new helper
memblock_start_of_DRAM() to give access to the address of the first
memblock - which contains the lowest address.

The awkward name was chosen to match the already present
memblock_end_of_DRAM().

Signed-off-by: Sam Ravnborg 
Cc: "David S. Miller" 
Cc: Yinghai Lu 
Acked-by: Tejun Heo 
Cc: "H. Peter Anvin" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/memblock.c: avoid abuse of RED_INACTIVE

2011-07-26T03:57:09+00:00

RED_INACTIVE is a slab thing, and reusing it for memblock was
inappropriate, because memblock is dealing with phys_addr_t's which have a
Kconfigurable sizeof().

Create a new poison type for this application.  Fixes the sparse warning

    warning: cast truncates bits from constant value (9f911029d74e35b becomes 9d74e35b)

Reported-by: H Hartley Sweeten 
Tested-by: H Hartley Sweeten 
Acked-by: Pekka Enberg 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/memblock: properly handle overlaps and fix error path

2011-03-23T00:44:09+00:00

Currently memblock_reserve() or memblock_free() don't handle overlaps of
any kind.  There is some special casing for coalescing exactly adjacent
regions but that's about it.

This is annoying because typically memblock_reserve() is used to mark
regions passed by the firmware as reserved and we all know how much we can
trust our firmwares...

Also, with the current code, if we do something it doesn't handle right
such as trying to memblock_reserve() a large range spanning multiple
existing smaller reserved regions for example, or doing overlapping
reservations, it can silently corrupt the internal region array, causing
odd errors much later on, such as allocations returning reserved regions
etc...

This patch rewrites the underlying functions that add or remove a region
to the arrays.  The new code is a lot more robust as it fully handles
overlapping regions.  It's also, imho, simpler than the previous
implementation.

In addition, while doing so, I found a bug where if we fail to double the
array while adding a region, we would remove the last region of the array
rather than the region we just allocated.  This fixes it too.

Signed-off-by: Benjamin Herrenschmidt 
Acked-by: Yinghai Lu 
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memblock: don't adjust size in memblock_find_base()

2011-02-12T00:12:20+00:00

While applying patch to use memblock to find aperture for 64bit x86.
Ingo found system with 1g + force_iommu

> No AGP bridge found
> Node 0: aperture @ 38000000 size 32 MB
> Aperture pointing to e820 RAM. Ignoring.
> Your BIOS doesn't leave a aperture memory hole
> Please enable the IOMMU option in the BIOS setup
> This costs you 64 MB of RAM
> Cannot allocate aperture memory hole (0,65536K)

the corresponding code:

	addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
	if (addr == MEMBLOCK_ERROR || addr + aper_size > 0xffffffff) {
		printk(KERN_ERR
			"Cannot allocate aperture memory hole (%lx,%uK)\n",
				addr, aper_size>>10);
		return 0;
	}
	memblock_x86_reserve_range(addr, addr + aper_size, "aperture64")

fails because memblock core code align the size with 512M.  That could
make size way too big.

So don't align the size in that case.

actually __memblock_alloc_base, the another caller already align that
before calling that function.

BTW. x86 does not use __memblock_alloc_base...

Signed-off-by: Yinghai Lu 
Cc: Ingo Molnar 
Cc: David Miller 
Cc: "H. Peter Anvin" 
Cc: Benjamin Herrenschmidt 
Cc: Dave Airlie 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memblock: fix memblock_is_region_memory()

2011-01-21T01:02:05+00:00

memblock_is_region_memory() uses reserved memblocks to search for the
given region, while it should use the memory memblocks.

I encountered the problem with OMAP's framebuffer ram allocation.
Normally the ram is allocated dynamically, and this function is not
called.  However, if we want to pass the framebuffer from the bootloader
to the kernel (to retain the boot image), this function is used to check
the validity of the kernel parameters for the framebuffer ram area.

Signed-off-by: Tomi Valkeinen 
Acked-by: Yinghai Lu 
Cc: Benjamin Herrenschmidt 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memblock: Annotate memblock functions with __init_memblock

2010-10-11T23:00:52+00:00

Stephen found

WARNING: mm/built-in.o(.text+0x25ab8): Section mismatch in reference from the function memblock_find_base() to the function .init.text:memblock_find_region()
The function memblock_find_base() references
the function __init memblock_find_region().
This is often because memblock_find_base lacks a __init
annotation or the annotation of memblock_find_region is wrong.

So let memblock_find_region() to use __init_memblock instead of __init
directly.

Also fix one function that did not have __init* to be __init_memblock.

Reported-by: Stephen Rothwell 
Signed-off-by: Yinghai Lu 
LKML-Reference: <4CB366B1.40405@kernel.org>
Signed-off-by: H. Peter Anvin

memblock: Allow memblock_init to be called early

2010-10-11T22:59:01+00:00

The Xen setup code needs to call memblock_x86_reserve_range() very early,
so allow it to initialize the memblock subsystem before doing so.  The
second memblock_init() is ignored.

Signed-off-by: Jeremy Fitzhardinge 
Cc: Yinghai Lu 
Cc: Benjamin Herrenschmidt 
LKML-Reference: <4CACFDAD.3090900@goop.org>
Signed-off-by: H. Peter Anvin

memblock: Fix wraparound in find_region()

2010-10-06T04:45:35+00:00

When trying to find huge range for crashkernel, get

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at arch/x86/mm/memblock.c:248 memblock_x86_reserve_range+0x40/0x7a()
[    0.000000] Hardware name: Sun Fire x4800
[    0.000000] memblock_x86_reserve_range: wrong range [0xffffffff37000000, 0x137000000)
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper Not tainted 2.6.36-rc5-tip-yh-01876-g1cac214-dirty #59
[    0.000000] Call Trace:
[    0.000000]  [] ? memblock_x86_reserve_range+0x40/0x7a
[    0.000000]  [] warn_slowpath_common+0x85/0x9e
[    0.000000]  [] warn_slowpath_fmt+0x6e/0x70
[    0.000000]  [] ? memblock_find_region+0x40/0x78
[    0.000000]  [] ? memblock_find_base+0x9a/0xb9
[    0.000000]  [] memblock_x86_reserve_range+0x40/0x7a
[    0.000000]  [] setup_arch+0x99d/0xb2a
[    0.000000]  [] ? trace_hardirqs_off+0xd/0xf
[    0.000000]  [] ? _raw_spin_unlock_irqrestore+0x3d/0x4c
[    0.000000]  [] start_kernel+0xde/0x3f1
[    0.000000]  [] x86_64_start_reservations+0xa0/0xa4
[    0.000000]  [] x86_64_start_kernel+0x106/0x10d
[    0.000000] ---[ end trace a7919e7f17c0a725 ]---
[    0.000000] Reserving 8192MB of memory at 17592186041200MB for crashkernel (System RAM: 526336MB)

This is caused by a wraparound in the test due to size > end;
explicitly check for this condition and fail.

Signed-off-by: Yinghai Lu 
LKML-Reference: <4CAA4DD3.1080401@kernel.org>
Signed-off-by: H. Peter Anvin