aboutsummaryrefslogtreecommitdiffstats
path: root/include/video
diff options
context:
space:
mode:
authorLajos Molnar <molnar@ti.com>2011-05-24 11:36:35 -0700
committerErik Gilling <konkers@android.com>2011-07-11 13:48:12 -0700
commitd085c10854f01ef85e68e16ae4c317fa7fa2b31b (patch)
tree93db040db93da141de614435a0ef15e47aba2b80 /include/video
parent410532371a794597aa1618a130b625a7ae10328a (diff)
downloadkernel_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.h22
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 {