OMAP:DSS:DSSCOMP: New composition module

This patch implements a new DSS composition module.

DSSCOMP allows specifying a whole composition for a DSS display:

1. set overlay information for all overlays on a manager
2. reroute the overlays to the manager (overlay must be disabled
just as when using sysfs)
3. set manager information
4. optionally call manager->apply() that programs the DISPC
4. optionally do an update (after a sync call)

DSS already implements coordinated updates by separating overlay
information setting from the applicaion of those settings (which
happens only in manager->apply()). However current users of DSS
call manager->apply() for each change, which make coordinated
change impossible.

This API also implements auto cropping of all layers to the display
region. This makes switching displays and handling display resolution
changes easier (without getting "failed to setup overlay" messages.)

DSSCOMP operates on 3 levels.

base.c contains the basic DSS operations, such as setting DSS overlay
and managers using DSSCOMP's setting structures. Theoretically,
DSSCOMP could be used via only these operations.

queue.c contains the queuing mechanism. This module maintains
compositions queued to each overlay manager (the basic DSS composition
entity). Each composition is referred to by a unique sync-id.
Queueing operations consist of creating a composition, setting/getting
manager/overlay information for the composition, applying the
composition to the display (which also displays it on manually
updated panels), waiting on various states of a composition.

For now the basic queuing mechanism of DSSCOMP is "queue and forget".
Therefore, it is not necessary to dequeue each frame queued. A
consequence of this methodology is that if one applies a composition
to a display, any prior unapplied compositions will be dropped.

The queuing interface tracks which overlay is assigned to which
manager. This is done at the DSS programming level, as that is the
most reliable place to monitor overlay ownership. Nonetheless,
the device interface uses overlay information to verify overlay
ownership - which may be slightly out of sync. The user of
DSSCOMP should maintain overlay ownership to ensure flawless
sharing of overlays between managers. (E.g. should not use an
overlay on a new manager, until the overlay has been disabled on
the previous manager, and that composition has been programmed.)

device.c contains the device hooks to operating system, and the file
interface (via /dev/dsscomp's ioctls). /dev/dsscomp works on top of
the queueing mechanism.

There are 3 levels of header files.

linux/dsscomp.h: basic dsscomp structures and ioctls
plat/dsscomp.h: kernel dsscomp interface (on top of linux/dsscomp.h)
local dsscomp.h: common implementation structures and shared methods

Note: plat/dsscomp.h defines a handle typedef that causes a
checkpatch warning. I feel that the creation of a handle typedef
is warranted.

Limitations:
- no WB support
- cannot get overlay/manager information on a composition without
first having set it
- there is a race condition in dsscomp's callback as we cannot
lock our mutex (callback is called from ISR sometimes). This will
be fixed in a later patch consistent with k39 version.

Change-Id: Ib681443d7dadae83ff9a4f4004e07a6e9a518866
Signed-off-by: Lajos Molnar <molnar@ti.com>
Signed-off-by: Sunita Nadampalli <sunitan@ti.com>
Signed-off-by: Oleksandr Lugovyk <x0158320@ti.com>
Signed-off-by: David Rodero <david@codiguiel.net>
OMAP:DSS:DSSCOMP: Add DSS composition module to build/config system

This patch links in the DSS composition (dsscomp) module into the
build and configuration system. DSS composition is enabled by default.

Change-Id: Id00e7581456a89a7ed7ce4bcac622f6904ed8e56
Signed-off-by: Lajos Molnar <molnar@ti.com>
Signed-off-by: Sunita Nadampalli <sunitan@ti.com>
Signed-off-by: David Rodero <david@codiguiel.net>