OMAPDSS: DSSCOMP: New composition module

OMAPDSS: 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 clients 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).  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.

Compositions are applied asynchronously (delayed apply) so that
they can be queued from irq context.

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.)

Buffers must be displayable (e.g. TILER2D or physically contiguous).

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

An additional Android adaptation layer is also provided.  This
sits on top of DSSCOMP and allows specifying all overlays on all
managers in a single operation as required by Android's rendering
model.  Here the checking of overlays is slightly relaxed as
Android makes sure that an overlay is detached from a display
before it is attached to another one.  This interface also
uses ION/TILER to remap non-contiguous buffers into contiguous
TILER1D space - so they can be displayed by DISPC.

At the Android level buffers can be specified with a set of
pages, using offsets into FBMEM (contiguous), or by referencing
prior overlays (e.g. cloning).

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
- unsure whether to call sync on non-manual update panels
- cannot get overlay/manager information on a composition without
first having set it

Change-Id: I9e9c0fc6e5ed0bf4f077af9f755cee35d436990b
Signed-off-by: Arthur Philpott <arthur.philpott@ti.com>
Signed-off-by: Dandawate Saket <dsaket@ti.com>