| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add global alpha settings for video 1 overlay in
_dispc_setup_global_alpha. On OMAP4 VID1 has global alpha.
Change-Id: Iaafaae6283c322a6962d24c0fefa253acd1505f0
Signed-off-by: Lajos Molnar <molnar@ti.com>
OMAP4: DSS: Fix incorrect OMAP3-alpha compatibility setting
Alpha blending is always enabled on OMAP4. The meaning of the
alpha enabled bits in DISPC_CONFIG registers now enabled OMAP3
compatibility mode which disables ZORDER settings. This is not
what we want when we set alpha blending.
This patch sets alpha blending always to true on OMAP4.
It also turns off OMAP3 compatibility mode for now, and reports
the compatibility mode results when querying dispc_alpha_blending.
Change-Id: Ie7af6835c0415681ae09bc220522e7c692c03e61
Signed-off-by: Lajos Molnar <molnar@ti.com>
OMAP: DSS2: Add DISPC VIDEO3 pipeline support
VID3 and Writeback pipeline registers have a linear relation, introduce these
registers and access these registers in DISPC functions. Add a dss_feature for
VIDEO3 pipeline.
Configure color conversion and global alpha for this new pipeline.
Also, create overlay object for the new video pipe.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Lajos Molnar <molnar@ti.com>
OMAP: DSS2: Add zorder support on OMAP4
Add zorder Support on OMAP4, this feature allows deciding the visibility order
of the overlays based on the zorder value provided as a sysfs attribute of the
overlay object.
Since this feature is not supported on OMAP3 and OMAP2, the sysfs attibutes
always return zorder as 0 and do not write to dispc registers for non OMAP4
architectures.
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Mark Tyler <mark.tyler@ti.com>
Signed-off-by: Lajos Molnar <molnar@ti.com>
OMAP4: DSS: Making the deault color format of framebuffer ARGB32
Earlier the default color format,frmamebuffer has,was xRGB24U but SGX
is producing data in ARGB32. Also,SGX,the FB driver user,doesnt negotiates
with FB driver for the format and thus FB needs to provide ARGB32 to align
with SGX format.
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=c75a7e1b83d446650b0f393746f8a810242a8739
Signed-off-by: Mark Tyler <mark.tyler@ti.com>
OMAP4:DSS: Added TILER support for DSS
Added support for displaying buffers located in the TILER 2D containers.
Buffers in TILER 1D containers can be displayed using OMAP_DSS_ROT_DMA.
Change-Id: I86b231ed5775e410acf31bb49deb817c0989c16b
Signed-off-by: Lajos Molnar <molnar@ti.com>
OMAP: DSS2: Add callback for tracking overlay/manager changes
This patch allows tracking when a particular overlay or manager
change has taken place, and when it is eclipsed (no longer used).
In DSS2 overlay/manager information travels through 4 stages:
1: (software) overlay/manager info
2: (software) cache (on manager->apply())
3: (hardware) shadow registers (on configure())
4: (hardware) DISPC (on vsync or go/enable)
Callback information for each settings can be passed as part of
the info structure (info->cb), which is the following struct:
struct omapdss_ovl_cb {
void (*fn)(void *data, int id, int status);
void *data;
};
id contains to the overlay/manager index.
If fn is NULL, no callback will take place. Otherwise, callbacks
will be generated on programming (when settings get into the
DISPC), when the settings are displayed, and on eclipse (when settings
are overwritten by newer settings). Depending on the stage where the
eclipse happens, a different callback is generated.
Status is one of the DSS_COMPLETION_... enum values specifying the event.
DSS_COMPLETION_ECLIPSED_SET - info was overwritten at stage 1
DSS_COMPLETION_ECLIPSED_CACHE - info was overwritten at stage 2
DSS_COMPLETION_ECLIPSED_SHADOW - info was overwritten at stage 3
DSS_COMPLETION_RELEASED - info was overwritten at stage 4 (after successfully
being displayed)
DSS_COMPLETION_TORN - info was overwritten at stage 4 (before it was
successfully displayed)
DSS_COMPLETION_PROGRAMMED - info moved from stage 3 to stage 4 (this follows
the prior info's callback of DSS_COMPLETION_RELEASED/TORN)
DSS_COMPLETION_DISPLAYED - info in stage 4 has been successfully displayed.
This callback is received on every frame refresh. If only the first display
is required, it needs to be filtered out in the callback.
You can use the DSS_COMPLETION_RELEASED flag to see if an info has been
eclipsed (so you don't have to check for all 5 values).
There is a fundamental issue with tracking DSS settings in the current
DSS2 framework. Pipeline/manager settings are programmed first into
an info structure that stays around. These settins can be modified
piece-by-piece - as they are done using the sysfs framework. Theoretically,
these cause the old settings to be eclipsed by the new settings. However,
sysfs interface is used to augment the other DSS2 users that would register
for these callbacks. Therefore, we need to treat these partial updates
specially. For now - if the callback function and data are the same -
a different status is used: DSS_COMPLETION_CHANGED_SET.
Now these auxiliary interfaces also apply the changes automatically, so a
similar method needs to be used at level 2. (DSS_COMPLETION_CHANGED_CACHE)
This, however, causes callback info to stay around at the level 1
interface making it not useful for tracking the status. We cannot
guarantee that the information is tracked from setting to release/eclipse
if future settings may end up reusing (ignorantly) the same callback info.
For now the callback info is cleared at level 1 when transferred to
level 2. If other - callback unaware - DSS2 users modify overlay/manager
settings, (e.g. using sysfs controls in any way), they will not reset
the callback. We err on the side of sysfs, and we will not treat a
settings application (transferring level 1 info to level 2) as eclipsed
if the level-1 callback method is empty. This works for sysfs changes,
but we will be a missed callback if V4L2 or FB is changing the base
address, and we are using the callbacks to track buffer usage.
The other issue is using sysfs to enable/disable an overlay. We may
get a RELEASED event on disable, but no usage callback is done on
subsequent enable because sysfs will not request a callback.
Change-Id: I0b7fdbeefe71e40dc86ec8401dbc7e82374eaeb5
Signed-off-by: Lajos Molnar <molnar@ti.com>
Signed-off-by: Mark Tyler <mark.tyler@ti.com>
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
- unsure whether to call sync on non-manual update panels
- cannot get overlay/manager information on a composition without
first having set it
- not fully operational - still debugging some unit test issues
Change-Id: I5826a409f4fd258c8ce86e782c5e6bdd4bf9bcf4
Signed-off-by: Lajos Molnar <molnar@ti.com>
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: I5b480dc10b17c5e37f5611baf96a20217cb6ec3e
Signed-off-by: Lajos Molnar <molnar@ti.com>
Signed-off-by: Mark Tyler <mark.tyler@ti.com>
OMAP:OMAPLFB: *HACK* Adapted to DSSCOMP
OMAPLFB must call DSSCOMP's apply so that the related overlays
are also programmed into DSS.
Change-Id: Ia8c1c181028fb7f241677e9657a1d402c8724ee8
Signed-off-by: Mark Tyler <mark.tyler@ti.com>
Signed-off-by: Lajos Molnar <molnar@ti.com>
OMAP4:DSS: Jumbo patch to enable predecimation
Includes the following fixes:
- fixed color format modes for non-GFX pipelines
- fixed NV12 support in 1D mode buffer
- added all color formats to configure_overlay()
Predecimation
- added predecimation support for NV12/YUV/rotated/SDMA buffers
- added scaling decision (predecimation)
- added conservative fclk calculation
- added sysfs controls
- tied into DSSCOMP
Signed-off-by: Lajos Molnar <molnar@ti.com>
OMAP4:DSS: Fix maxdownscale limits for OMAP4 in DISPC setup plane.
Signed-off-by: Mark Tyler <mark.tyler@ti.com>
|
