diff options
author | Lajos Molnar <molnar@ti.com> | 2011-05-24 11:36:35 -0700 |
---|---|---|
committer | Erik Gilling <konkers@android.com> | 2011-07-11 13:48:12 -0700 |
commit | d085c10854f01ef85e68e16ae4c317fa7fa2b31b (patch) | |
tree | 93db040db93da141de614435a0ef15e47aba2b80 /include/video | |
parent | 410532371a794597aa1618a130b625a7ae10328a (diff) | |
download | kernel_samsung_tuna-d085c10854f01ef85e68e16ae4c317fa7fa2b31b.zip kernel_samsung_tuna-d085c10854f01ef85e68e16ae4c317fa7fa2b31b.tar.gz kernel_samsung_tuna-d085c10854f01ef85e68e16ae4c317fa7fa2b31b.tar.bz2 |
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: Iebc2551ad1d5bce94bd668cf2c885c895809d416
Signed-off-by: Lajos Molnar <molnar@ti.com>
Signed-off-by: Mark Tyler <mark.tyler@ti.com>
Diffstat (limited to 'include/video')
-rw-r--r-- | include/video/omapdss.h | 22 |
1 files changed, 22 insertions, 0 deletions
diff --git a/include/video/omapdss.h b/include/video/omapdss.h index c4a18dd..e2f1d60 100644 --- a/include/video/omapdss.h +++ b/include/video/omapdss.h @@ -319,6 +319,24 @@ extern const struct omap_video_timings omap_dss_pal_timings; extern const struct omap_video_timings omap_dss_ntsc_timings; #endif +enum omapdss_completion_status { + DSS_COMPLETION_PROGRAMMED = 0, + DSS_COMPLETION_DISPLAYED = 4, + DSS_COMPLETION_CHANGED_SET, + DSS_COMPLETION_CHANGED_CACHE, + DSS_COMPLETION_RELEASED = 8, + DSS_COMPLETION_ECLIPSED_SET, + DSS_COMPLETION_ECLIPSED_CACHE, + DSS_COMPLETION_ECLIPSED_SHADOW, + DSS_COMPLETION_TORN, +}; + +struct omapdss_ovl_cb { + /* optional callback method */ + void (*fn)(void *data, int id, int status); + void *data; +}; + struct omap_overlay_info { bool enabled; @@ -340,6 +358,8 @@ struct omap_overlay_info { u8 global_alpha; u8 pre_mult_alpha; enum omap_overlay_zorder zorder; + + struct omapdss_ovl_cb cb; }; struct omap_overlay { @@ -379,6 +399,8 @@ struct omap_overlay_manager_info { bool trans_enabled; bool alpha_enabled; + + struct omapdss_ovl_cb cb; }; struct omap_overlay_manager { |