fmem: interact properly with DMM

On a system with both FMEM and DMM, FMEM must veto
memory hotremove of section(s) FMEM occupies when
in C-state and allow it (after cleaning up metadata)
in T-state (and then change to O-state).

It must also change back to T-state when all sections
FMEM uses have been powered on.

Change-Id: I9766a07305d1e3e2c6ff48e1cbf6933765b751f8
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
fmem: hotplug notifier should do nothing if fmem is inactive

If fmem discovers it has no memory to manage, it will
stay in an uninitialized state. However, this is
not discovered until long after the hotplug notifier
is set up (which must be in the fmem_init function).

Since fmem has not been initialized, the hotplug notifier
runs and incorrectly causes memory hotremove to fail, as
it bases its decision on uninitialized data.

The fix is for the hotplug notifier to just return
immediately if fmem is in the uninitialized state.

Change-Id: Ia647470d64fe1926be404af419f5f516e6b59c05
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
ion: support creation of mm heap in a fixed place

The multimedia firmware on 8960 will always be
loaded into a fixed address, and all callers into
this firmware must be no more than 256M above the
start of this firmware.

This implies that the the mm ION heap and its associated heaps
(mm_fw and mfc) must also be created in a fixed place.

This version of the patch keeps the mm fw heap size
to 2M for compatibility with the current tip. This
will eventually be reduced to 1M.

Change-Id: I35f89b8c60165fb0adbb9d04412e0e200117beb9
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/board-8960.c
	include/linux/ion.h
FMEM: allocate non-fixed FMEM from memory pool

On platforms whose FMEM is not at a fixed place
and which don't have DMM (such as 7x27a), FMEM
and the EBI memory pool would incorrectly overlap,
and the same memory would be used both as FMEM
and as memory allocated by allocate_contiguous_memory()
at the same time leading to crashes and strange behavior.

There are some unsolved problems related to
allocating FMEM from unstable memory, so we have
decided not to do this any longer. This decision allows
us to simply allocate non-fixed FMEM from the
EBI memory pool (this will prevent FMEM's memory
from being used by another allocator at the same time).
In this case FMEM will appear to "overlap" with
the memory pool, but this now OK as FMEM is allocated
from it.

This also re-enables FMEM on 7x27a and 8625, which
had been disabled due to the above-mentioned bug.

CRs-Fixed: 354254
Change-Id: I8e0bba332c7ddcac1d280de9642078fdfe61bbcc
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/board-8960.c
	arch/arm/mach-msm/board-msm7x27a.c
	arch/arm/mach-msm/memory.c

Conflicts:
	arch/arm/mach-msm/board-8960.c
	arch/arm/mach-msm/memory.c
msm: memory: Fix section mismatch warning

WARNING: vmlinux.o(.text+0x16eb8): Section mismatch in reference
from the function alloc_bootmem_aligned() to the function
.init.text:__alloc_bootmem()
The function alloc_bootmem_aligned() references
the function __init __alloc_bootmem().
This is often because alloc_bootmem_aligned lacks a __init
annotation or the annotation of __alloc_bootmem is wrong.

Change-Id: Ib9786b5a9d405854c9f6df57b7711b5b03e6fcc9
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>