| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
In order to decouple the LCD FB and the ext display buffers, sDMA copy
based solution is implemented in dsscomp.
This patch adds the support for parsing ION handles for buffer addresses and
copying FB into user provide buffers (for ext display cloning).
Change-Id: I84cfa249e86b863aef9fd9685e1854649f25afc8
Signed-off-by: Sunita Nadampalli <sunitan@ti.com>
Signed-off-by: Lajos Molnar <lajos@ti.com>
Signed-off-by: Dima Svetlov <svetlov@ti.com>
|
| |
|
|
|
|
|
|
|
| |
This is used by android-display to set up default tiler1d slot
size.
Change-Id: Ic6fe49b9338d8ce41c2ac2b444d8ef018ee5fc7a
Signed-off-by: Lajos Molnar <lajos@ti.com>
Signed-off-by: Dima Svetlov <svetlov@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Different devices will have varying requirements on tiler resources. This
change moves the platform device registration for dsscomp to the omap
platform level so at device initialization time we can set the appropriate
Tiler1D slot size.
Change-Id: I5edf5b7cfb056a45ab038b244d2efc758a840b00
Signed-off-by: Tony Lofthouse <a0741364@ti.com>
Signed-off-by: Lajos Molnar <lajos@ti.com>
|
| |
|
|
|
|
|
|
|
|
| |
SGX flip commands, whether ProcessFlipV1 or ProcessFlipV2, need
to be completed in order. gralloc_queue implements in-order
completion of SGX flip commands, so use it for both V1 and V2
flips.
Change-Id: I8bc0ae9d6ea62486ada1ae11be959b0d3d811158
Signed-off-by: Lajos Molnar <molnar@ti.com>
|
| |
|
|
|
|
|
|
|
|
| |
Switch android support and SGX Post2 rendering to use
struct dsscomp_setup_dispc_data.
Also added check for size of user data in Post2 so that
we don't dereference random structure.
Signed-off-by: Lajos Molnar <molnar@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In preparation for HDMI cloning support, simplify queueing in
DSSCOMP queue.c.
dsscomp_t objects are no longer maintained on queues. Instead,
compositions waiting to be applied are on the apply workqueue.
Any other compositions (not yet queued to be applied, or
already applied) are not tracked. Compositions are also
deleted on the RELEASED callback.
Therefore, wait operations are moved to device.c that
maintains the state of compositions queued via ioctls.
Gralloc compositions are tracked in gralloc.c, and they are
on a FIFO queue to guarantee in-order completion. This also
allows such compositions to depend on multiple DSS compositions
queued to different displays.
Change-Id: I60de75bb0ee6024fb072f939cdaf2845bbe68bf9
Signed-off-by: Lajos Molnar <molnar@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We may want to delay apply() as it is blocking. However, we will
not get the error code if the apply failed, only an ECLIPSED_SET
callback. This should be enough to handle the lifecycle of this
composition.
dsscomp_gralloc_queue() now calls delayed apply.
Change-Id: I494073a338b75fc85d570a7f030a9bb73dcec6a3
Signed-off-by: Lajos Molnar <molnar@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added dsscomp_gralloc_queue() to queue a DSS composition from gralloc.
This allows passing page list information for non-contiguous buffers,
and a callback funtion.
This gralloc layer automatically uses TILER1D areas to pin
non-contiguous buffers, so that they become contiguous and can
can be displayed by DSS. We only use dsscomp_gralloc_queue() for
displaying a composition, so set the mode for DISPLAY.
Also added new ioctl to test gralloc adaptaion layer.
dsscomp_gralloc_init() does two things: it receives pointer to
the device, and allocates TILER container areas.
DSSCOMP is initialized before TILER, which causes problems.
Thus, dsscomp_gralloc_init() stores the device pointer separately
from allocating the memory. This way each part can fail
independently.
Added dsscomp_gralloc_init() within dsscomp_gralloc_queue() as
it may be called before using the dsscomp device vs the file
pointer.
Using semaphore to keep track of available tiler slots. This
is needed because we are releasing tiler slots in a work
queue, that may get scheduled too late:
- we release tiler slots when a composition is eclipsed in a
work queue, as tiler_unpin_memory may be blocking.
- we also release tiler slots if a composition has failed to
be set.
PVRSVC's callback is called when the composition is first
displayed or eclipsed. It also gets called if a composition
fails to queue to avoid a similar check and call from the
called of queue().
Change-Id: I69d0a0c9fe452f05d846c6a38e314c5ac52d70e6
Signed-off-by: Lajos Molnar <molnar@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Removed sync_id because compositions will be specified at once.
Moved to simple queue as all compositions will get displayed.
Delete composition in dsscomp_drop()
Print composition address instead of sync-id, which is now 0.
Change-Id: Ic5078f3da4d10d0d5a27c3df0d33e9ad5de362b6
Signed-off-by: Lajos Molnar <molnar@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: Ie62e8eeccfd6f3cae9e39e30d5105fa2bad68c62
Signed-off-by: Lajos Molnar <molnar@ti.com>
|
| |
|
|
|
|
|
|
| |
This will be reapplied using individual patches.
This reverts commit a7e96985ea15176a46ed3d767c58baf3c36d510e.
Signed-off-by: Lajos Molnar <molnar@ti.com>
|
|
|
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>
|
