[OMAP4] Add ION Memmanager support

Add a common ION file to initialize the ION memory
spaces for DUCATI, Tiler and large surfaces

Change-Id: I17e608d90c5568bd4be1285cee1976e05192950d
Signed-off-by: Dan Murphy <dmurphy@ti.com>

Conflicts:
	arch/arm/mach-omap2/Makefile
[OMAP4] OMAP4: reduce TILER ion heap to match max tiler size

The size of the tiler carveout should be no larger than the maximum
size of memory (128MB) that can be mapped into the TILER.

Change-Id: I1b6bbef196e424aa1c03f28f560600b1348a63b2
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andy Gross <andy.gross@ti.com>
omap4: relocate and resize ion carveout memories

The ion secure input heap is moved towards the end of the RAM.
It needs to be preceded by the ducati carveout memory, which is
also increased from 101MB to 103MB. IPC will be using this
additional 2MB for its IO. These changes are done to match the
corresponding memory relocations in the Blaze/Panda board files.

Change-Id: I9b0ab1789f19d39c42819e5c61c74dfe9e60ec06
Signed-off-by: Suman Anna <s-anna@ti.com>
OMAP4: Tablet2: increase ducati carveout by 2MB

The ducati carveout memory is increased by 2MB to accomodate building
additional codecs. The ION platform data addresses have also been
adjusted accordingly.

Change-Id: I0b0660aeddfdfc321d8a27d338fb417dea23ab96
Signed-off-by: Prasanna Kumar M.R. <prasanna.kumarmr@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap4: resize ion carveout memories

The ion secure input heap is increased from 30MB to 90MB to support
additional use cases such as video editor. The TILER ION heap has
been decreaed by 32MB, since 32MB of memory is pre-mapped into TILER
page mode, and that memory is coming froma  separate pool. These
changes are done to match the corresponding memory resizes in the
Blaze/Panda/Blaze Table board files.

Change-Id: Ief79f482b2eecdff86f4329b453222b05c4cb425
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP4: Add nonsecure TILER carveout

Add a 32MB nonsecure TILER carveout to be used by framebuffer.

Change-Id: I186dd37046ef731e0896e98de7c079b3af038c07
Signed-off-by: Dan Murphy <dmurphy@ti.com>
ARM: Update ION code for commonality

Created a omap4_ion.h so that multiple products can configure
the same ION support

Change-Id: Id6ac1e07f11dec14a66b8b4078a45c1ed66fe7bc
Signed-off-by: Dan Murphy <dmurphy@ti.com>

Conflicts:
	arch/arm/mach-omap2/board-4430sdp.c
	arch/arm/mach-omap2/board-44xx-tablet.c
	arch/arm/mach-omap2/board-44xx-tablet.h
	arch/arm/mach-omap2/board-omap4panda.c
	include/linux/platform_data/ram_console.h
OMAP4: SDP/Blaze/Panda: fix vram overlap with static carveouts

omap_reserve function may call into different reserve functions
that do dynamic memblock allocations, so needs to be called
absolute last after all the static memblock_remove calls are
invoked.

Also, omap_reserve function need to be invoked always, so
code has been cleaned up to move the call outside of any
conditional preprocessor macros.

Change-Id: Iceed5fb648583ac353170e9d12c109d26aeca540
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

Conflicts:
	arch/arm/mach-omap2/board-4430sdp.c
	arch/arm/mach-omap2/board-44xx-tablet.c
	arch/arm/mach-omap2/board-omap4panda.c
ARM: OMAP4: ION: Fix compile error if CONFIG_ION_OMAP is not enabled

Change-Id: I887772acfc074697fb6189f2ebb5702d9dd3c192
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
ARM: OMAP4: Move common ION #defines to omap4_ion.h

Move the #define allocations to the common omap4_ion header.
Rename OMAP_ION_HEAP_SECURE_INPUT_SIZE to OMAP4_ION_HEAP_SECURE_INPUT_SIZE
Rename OMAP_ION_HEAP_NONSECURE_TILER_SIZE to OMAP4_ION_HEAP_NONSECURE_TILER_SIZE

Change-Id: Ic6bd49fa29b21cccab47ceb4e6b5e26e4c611dd7
Signed-off-by: Dan Murphy <dmurphy@ti.com>

Conflicts:
	arch/arm/mach-omap2/board-4430sdp.c
	arch/arm/mach-omap2/board-44xx-tablet.c
	arch/arm/mach-omap2/board-omap4panda.c
ARM: OMAP4: ION:Remove large-surfaces ION carveout

The large-surfaces carveout is not used.  This gives 32M back to the system.

Change-Id: Iaecc533787e2354079c5b0bf5e132884d1cd0071
Signed-off-by: Dan Murphy <dmurphy@ti.com>
omap: ion: remove ram console memory reserve

After d7b9a8f9a6faa6265bcdc7d8da87d29d32d5e1aa RAM console
support was properly implemented and memory for the console is
reserved in omap_ram_console.c. This causes double reservation
of the same region at the begining of the second 512MB of RAM,
which triggers a "bug" in memblock_remove.

With this double removal of the same memblock region we are
getting 478MB of available RAM on IS.2.

This commit removes the double reservation avoiding the unexpected
behavior of memblock_remove, resulting in 680MB available RAM.

Change-Id: I3887b349cdb1a0552e27e9d51bcb8f23c6b691d6
Signed-off-by: Aleksandar Krsteski <x0163611@ti.com>
OMAP4: ion: move omap4_ion.h under mach/include

This is because tiler and ion is really a platform device, but
they are defined in mach, and other platform devices need to refer
to them.

Change-Id: Ifbc151b7d1dd45453dc2501419ec831f1ce585c3
Signed-off-by: Lajos Molnar <lajos@ti.com>
Signed-off-by: Dima Svetlov <svetlov@ti.com>

Conflicts:
	arch/arm/mach-omap2/board-4430sdp.c
	arch/arm/mach-omap2/board-44xx-tablet.c
	arch/arm/mach-omap2/board-omap4panda.c
omap4: tuna: update ram console registration

Updating new ram console registration interface used for omap4 in new
kernel.

Signed-off-by: Israel Cepeda <israel4c@gmail.com>
Select OMAP_RAM_CONSOLE for tuna
Remove some non-tuna boards
tuna: use the new ion allocator
Fix ION allocator values
Yeah, we shouldn't have over 800 MB avaliable RAM
omap: mailbox: enable mailbox irq per instance

The machine-specific omap2_mbox_startup is called only once
to initialize the whole mbox module. Enabling mbox irq at
startup is only enabling the irq of the very first mailbox
instance created.

The enable_irq function should be called every time a
new mbox instance is created, in the generic platform
mailbox layer.

Change-Id: I1b7148fd0342a335e3b45cfe349c43a8491ae5c1
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: iommu: apply latency constraint based on power domain

When the iommu is taken out of reset, a latency constraint is
set to avoid its power domain going to retention/off. The iommus
for DSP and M3 reside in DSP and Core power domains respectively,
and therefore the API for setting the constraints is different.
This patch uses the appropriate API depending on the iommu (power
domain) the latency constraint is being applied on.

Change-Id: I3fa4485b3c405aa10c32a3fe0b7ac694d484ee21
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>