OMAPDSS: DSSCOMP: Added platform_info and getter

Get platform information from dss2 driver and android_display,
instead of it being hardcoded in dsscomp clients.

Change-Id: Icc23245ec93d93dd0d9b9fcd791e546720699dcc
Signed-off-by: Lajos Molnar <lajos@ti.com>
Signed-off-by: Dima Svetlov <svetlov@ti.com>
OMAP2: generic Android display configuration setup

Added android_display methods to allow runtime configuration of
Android display resources, such as:

- FB0's vram is dynamically calculated from the number of
  buffers SGX requires in VRAM (swap chain and/or composition
  buffers), and the FB0 display size.
- OMAP VRAM is calculated from FB0's vram need + any other
  specified FB's vram.  (If command line is used to specify
  FB vrams, omap vram must also be specified.)
- TILER1D area reserved for use as DSS MMU by DSSCOMP is
  calculated from default display size.  It can be overriden
  by board file.
- TILER2D carveout size is reduced by TILER1D area (if coallocated
  with TILER2D) and by the TILER2D SGX buffers (swapchain and/or
  composition buffers)
- nonsecure TILER2D carveout size is set to the backpages needed
  by TILER2D SGX buffers.

All of this is coordinated by omap_android_display_setup.  It
takes pointers to the DSS board info, FB platform data, and
optionally to the ION, SGX and DSSCOMP platform data.  It should
be called in board_reserve before omap_ion_init.

If SGX data is provided, it is set as the SGX platform data for
FB0.  Similarly, if DSSCOMP platform data is provided it is
also set.  This can be used to set a preferred tiler1d slot size.
If ION platform data is provided, it is updated with the required
tiler2d carveout sizes.

NOTE:

To maximize TILER2D space, the TILER1D area reserved for android
display is not aligned to 1MB, but is aligned to 32 pages as the
smallest 2D allocation needs a 32-page band.  We further reduce
TILER2D space by the container space lost by the SGX buffers,
which may be larger than the actual backpages bneeded for the
SGX buffers.

Therefore the sum of secure + nonsecure + 1D tiler space may
be smaller than the available container space.

Ported to latest SGX DDK by Dima Svetlov.

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

Conflicts:
	arch/arm/plat-omap/Makefile
[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>
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>

Conflicts:
	arch/arm/mach-omap2/omap4_ion.c
 ARM: Update ION code for commonality

Created a omap4_ion.h so that multiple products can configure
the same ION support
 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-tuna.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>
 OMAP4: Tuna/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.
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.
tuna/board-config , fix errors from prev commits
add  arch/arm/plat-omap/omap_dsscomp.c
Revert "OMAP2: generic Android display configuration setup"

This reverts commit d27ad7b562225865a7ffe2d1c3d760c13fa3faa0.
Revert "add  arch/arm/plat-omap/omap_dsscomp.c"

This reverts commit beac56bd820a779003ab10564d5b35f8977ce56a.
fix build
more stuff
Revert " OMAPDSS: DSSCOMP: Added platform_info and getter"

This reverts commit d39f1e6657ea73a91681a92d727bfe2285c5d192.
SGX-KM (hack): Workaround for kernel panic due to invalid sync objects

This fixes a problem when invalid syncobjects are accessed after the
swap chain has been destroyed. Should be reverted when final fix
is in place.

Change-Id: Iff4c23534e16f6a2ff86bfdf3a9c5dd33320e5cb
Author:    Kostiantyn Luzan <kostiantyn.luzan@ti.com>
Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
Signed-off-by: Tate Hornbeck <tate.hornbeck@ti.com>