2017-11-01 17:09:13 +03:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
|
2012-10-04 21:21:50 +04:00
|
|
|
/* exynos_drm.h
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2011 Samsung Electronics Co., Ltd.
|
|
|
|
|
* Authors:
|
|
|
|
|
* Inki Dae <inki.dae@samsung.com>
|
|
|
|
|
* Joonyoung Shim <jy0922.shim@samsung.com>
|
|
|
|
|
* Seung-Woo Kim <sw0312.kim@samsung.com>
|
|
|
|
|
*
|
2012-12-17 21:30:17 +04:00
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
|
* under the terms of the GNU General Public License as published by the
|
|
|
|
|
* Free Software Foundation; either version 2 of the License, or (at your
|
|
|
|
|
* option) any later version.
|
2012-10-04 21:21:50 +04:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _UAPI_EXYNOS_DRM_H_
|
|
|
|
|
#define _UAPI_EXYNOS_DRM_H_
|
|
|
|
|
|
2015-11-30 17:10:45 +03:00
|
|
|
#include "drm.h"
|
2012-10-04 21:21:50 +04:00
|
|
|
|
2016-04-07 20:58:35 +03:00
|
|
|
#if defined(__cplusplus)
|
|
|
|
|
extern "C" {
|
|
|
|
|
#endif
|
|
|
|
|
|
2012-10-04 21:21:50 +04:00
|
|
|
/**
|
|
|
|
|
* User-desired buffer creation information structure.
|
|
|
|
|
*
|
|
|
|
|
* @size: user-desired memory allocation size.
|
|
|
|
|
* - this size value would be page-aligned internally.
|
|
|
|
|
* @flags: user request for setting memory type or cache attributes.
|
|
|
|
|
* @handle: returned a handle to created gem object.
|
|
|
|
|
* - this handle will be set by gem module of kernel side.
|
|
|
|
|
*/
|
|
|
|
|
struct drm_exynos_gem_create {
|
2014-08-31 15:07:31 +04:00
|
|
|
__u64 size;
|
2016-02-12 15:13:59 +03:00
|
|
|
__u32 flags;
|
|
|
|
|
__u32 handle;
|
2012-10-04 21:21:50 +04:00
|
|
|
};
|
|
|
|
|
|
2016-03-08 08:12:59 +03:00
|
|
|
/**
|
|
|
|
|
* A structure for getting a fake-offset that can be used with mmap.
|
|
|
|
|
*
|
|
|
|
|
* @handle: handle of gem object.
|
|
|
|
|
* @reserved: just padding to be 64-bit aligned.
|
|
|
|
|
* @offset: a fake-offset of gem object.
|
|
|
|
|
*/
|
|
|
|
|
struct drm_exynos_gem_map {
|
|
|
|
|
__u32 handle;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
__u64 offset;
|
|
|
|
|
};
|
|
|
|
|
|
2012-10-04 21:21:50 +04:00
|
|
|
/**
|
|
|
|
|
* A structure to gem information.
|
|
|
|
|
*
|
|
|
|
|
* @handle: a handle to gem object created.
|
|
|
|
|
* @flags: flag value including memory type and cache attribute and
|
|
|
|
|
* this value would be set by driver.
|
|
|
|
|
* @size: size to memory region allocated by gem and this size would
|
|
|
|
|
* be set by driver.
|
|
|
|
|
*/
|
|
|
|
|
struct drm_exynos_gem_info {
|
2016-02-12 15:13:59 +03:00
|
|
|
__u32 handle;
|
|
|
|
|
__u32 flags;
|
2014-08-31 15:07:31 +04:00
|
|
|
__u64 size;
|
2012-10-04 21:21:50 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* A structure for user connection request of virtual display.
|
|
|
|
|
*
|
|
|
|
|
* @connection: indicate whether doing connetion or not by user.
|
|
|
|
|
* @extensions: if this value is 1 then the vidi driver would need additional
|
|
|
|
|
* 128bytes edid data.
|
|
|
|
|
* @edid: the edid data pointer from user side.
|
|
|
|
|
*/
|
|
|
|
|
struct drm_exynos_vidi_connection {
|
2016-02-12 15:13:59 +03:00
|
|
|
__u32 connection;
|
|
|
|
|
__u32 extensions;
|
2014-08-31 15:07:31 +04:00
|
|
|
__u64 edid;
|
2012-10-04 21:21:50 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* memory type definitions. */
|
|
|
|
|
enum e_drm_exynos_gem_mem_type {
|
|
|
|
|
/* Physically Continuous memory and used as default. */
|
|
|
|
|
EXYNOS_BO_CONTIG = 0 << 0,
|
|
|
|
|
/* Physically Non-Continuous memory. */
|
|
|
|
|
EXYNOS_BO_NONCONTIG = 1 << 0,
|
|
|
|
|
/* non-cachable mapping and used as default. */
|
|
|
|
|
EXYNOS_BO_NONCACHABLE = 0 << 1,
|
|
|
|
|
/* cachable mapping. */
|
|
|
|
|
EXYNOS_BO_CACHABLE = 1 << 1,
|
|
|
|
|
/* write-combine mapping. */
|
|
|
|
|
EXYNOS_BO_WC = 1 << 2,
|
|
|
|
|
EXYNOS_BO_MASK = EXYNOS_BO_NONCONTIG | EXYNOS_BO_CACHABLE |
|
|
|
|
|
EXYNOS_BO_WC
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct drm_exynos_g2d_get_ver {
|
|
|
|
|
__u32 major;
|
|
|
|
|
__u32 minor;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct drm_exynos_g2d_cmd {
|
|
|
|
|
__u32 offset;
|
|
|
|
|
__u32 data;
|
|
|
|
|
};
|
|
|
|
|
|
drm/exynos: add userptr feature for g2d module
This patch adds userptr feautre for G2D module.
The userptr means user space address allocated by malloc().
And the purpose of this feature is to make G2D's dma able
to access the user space region.
To user this feature, user should flag G2D_BUF_USRPTR to
offset variable of struct drm_exynos_g2d_cmd and fill
struct drm_exynos_g2d_userptr with user space address
and size for it and then should set a pointer to
drm_exynos_g2d_userptr object to data variable of struct
drm_exynos_g2d_cmd. The last bit of offset variable is used
to check if the cmdlist's buffer type is userptr or not.
If userptr, the g2d driver gets user space address and size
and then gets pages through get_user_pages().
(another case is counted as gem handle)
Below is sample codes:
static void set_cmd(struct drm_exynos_g2d_cmd *cmd,
unsigned long offset, unsigned long data)
{
cmd->offset = offset;
cmd->data = data;
}
static int solid_fill_test(int x, int y, unsigned long userptr)
{
struct drm_exynos_g2d_cmd cmd_gem[5];
struct drm_exynos_g2d_userptr g2d_userptr;
unsigned int gem_nr = 0;
...
g2d_userptr.userptr = userptr;
g2d_userptr.size = x * y * 4;
set_cmd(&cmd_gem[gem_nr++], DST_BASE_ADDR_REG |
G2D_BUF_USERPTR,
(unsigned long)&g2d_userptr);
...
}
int main(int argc, char **argv)
{
unsigned long addr;
...
addr = malloc(x * y * 4);
...
solid_fill_test(x, y, addr);
...
}
And next, the pages are mapped with iommu table and the device
address is set to cmdlist so that G2D's dma can access it.
As you may know, the pages from get_user_pages() are pinned.
In other words, they CAN NOT be migrated and also swapped out.
So the dma access would be safe.
But the use of userptr feature has performance overhead so
this patch also has memory pool to the userptr feature.
Please, assume that user sends cmdlist filled with userptr
and size every time to g2d driver, and the get_user_pages
funcion will be called every time.
The memory pool has maximum 64MB size and the userptr that
user had ever sent, is holded in the memory pool.
This meaning is that if the userptr from user is same as one
in the memory pool, device address to the userptr in the memory
pool is set to cmdlist.
And last, the pages from get_user_pages() will be freed once
user calls free() and the dma access is completed. Actually,
get_user_pages() takes 2 reference counts if the user process
has never accessed user region allocated by malloc(). Then, if
the user calls free(), the page reference count becomes 1 and
becomes 0 with put_page() call. And the reverse holds as well.
This means how the pages backed are used by dma and freed.
This patch is based on "drm/exynos: add iommu support for g2d",
https://patchwork.kernel.org/patch/1629481/
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-11-04 17:48:52 +04:00
|
|
|
enum drm_exynos_g2d_buf_type {
|
|
|
|
|
G2D_BUF_USERPTR = 1 << 31,
|
|
|
|
|
};
|
|
|
|
|
|
2012-10-04 21:21:50 +04:00
|
|
|
enum drm_exynos_g2d_event_type {
|
|
|
|
|
G2D_EVENT_NOT,
|
|
|
|
|
G2D_EVENT_NONSTOP,
|
|
|
|
|
G2D_EVENT_STOP, /* not yet */
|
|
|
|
|
};
|
|
|
|
|
|
drm/exynos: add userptr feature for g2d module
This patch adds userptr feautre for G2D module.
The userptr means user space address allocated by malloc().
And the purpose of this feature is to make G2D's dma able
to access the user space region.
To user this feature, user should flag G2D_BUF_USRPTR to
offset variable of struct drm_exynos_g2d_cmd and fill
struct drm_exynos_g2d_userptr with user space address
and size for it and then should set a pointer to
drm_exynos_g2d_userptr object to data variable of struct
drm_exynos_g2d_cmd. The last bit of offset variable is used
to check if the cmdlist's buffer type is userptr or not.
If userptr, the g2d driver gets user space address and size
and then gets pages through get_user_pages().
(another case is counted as gem handle)
Below is sample codes:
static void set_cmd(struct drm_exynos_g2d_cmd *cmd,
unsigned long offset, unsigned long data)
{
cmd->offset = offset;
cmd->data = data;
}
static int solid_fill_test(int x, int y, unsigned long userptr)
{
struct drm_exynos_g2d_cmd cmd_gem[5];
struct drm_exynos_g2d_userptr g2d_userptr;
unsigned int gem_nr = 0;
...
g2d_userptr.userptr = userptr;
g2d_userptr.size = x * y * 4;
set_cmd(&cmd_gem[gem_nr++], DST_BASE_ADDR_REG |
G2D_BUF_USERPTR,
(unsigned long)&g2d_userptr);
...
}
int main(int argc, char **argv)
{
unsigned long addr;
...
addr = malloc(x * y * 4);
...
solid_fill_test(x, y, addr);
...
}
And next, the pages are mapped with iommu table and the device
address is set to cmdlist so that G2D's dma can access it.
As you may know, the pages from get_user_pages() are pinned.
In other words, they CAN NOT be migrated and also swapped out.
So the dma access would be safe.
But the use of userptr feature has performance overhead so
this patch also has memory pool to the userptr feature.
Please, assume that user sends cmdlist filled with userptr
and size every time to g2d driver, and the get_user_pages
funcion will be called every time.
The memory pool has maximum 64MB size and the userptr that
user had ever sent, is holded in the memory pool.
This meaning is that if the userptr from user is same as one
in the memory pool, device address to the userptr in the memory
pool is set to cmdlist.
And last, the pages from get_user_pages() will be freed once
user calls free() and the dma access is completed. Actually,
get_user_pages() takes 2 reference counts if the user process
has never accessed user region allocated by malloc(). Then, if
the user calls free(), the page reference count becomes 1 and
becomes 0 with put_page() call. And the reverse holds as well.
This means how the pages backed are used by dma and freed.
This patch is based on "drm/exynos: add iommu support for g2d",
https://patchwork.kernel.org/patch/1629481/
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-11-04 17:48:52 +04:00
|
|
|
struct drm_exynos_g2d_userptr {
|
|
|
|
|
unsigned long userptr;
|
|
|
|
|
unsigned long size;
|
|
|
|
|
};
|
|
|
|
|
|
2012-10-04 21:21:50 +04:00
|
|
|
struct drm_exynos_g2d_set_cmdlist {
|
|
|
|
|
__u64 cmd;
|
drm/exynos: add userptr feature for g2d module
This patch adds userptr feautre for G2D module.
The userptr means user space address allocated by malloc().
And the purpose of this feature is to make G2D's dma able
to access the user space region.
To user this feature, user should flag G2D_BUF_USRPTR to
offset variable of struct drm_exynos_g2d_cmd and fill
struct drm_exynos_g2d_userptr with user space address
and size for it and then should set a pointer to
drm_exynos_g2d_userptr object to data variable of struct
drm_exynos_g2d_cmd. The last bit of offset variable is used
to check if the cmdlist's buffer type is userptr or not.
If userptr, the g2d driver gets user space address and size
and then gets pages through get_user_pages().
(another case is counted as gem handle)
Below is sample codes:
static void set_cmd(struct drm_exynos_g2d_cmd *cmd,
unsigned long offset, unsigned long data)
{
cmd->offset = offset;
cmd->data = data;
}
static int solid_fill_test(int x, int y, unsigned long userptr)
{
struct drm_exynos_g2d_cmd cmd_gem[5];
struct drm_exynos_g2d_userptr g2d_userptr;
unsigned int gem_nr = 0;
...
g2d_userptr.userptr = userptr;
g2d_userptr.size = x * y * 4;
set_cmd(&cmd_gem[gem_nr++], DST_BASE_ADDR_REG |
G2D_BUF_USERPTR,
(unsigned long)&g2d_userptr);
...
}
int main(int argc, char **argv)
{
unsigned long addr;
...
addr = malloc(x * y * 4);
...
solid_fill_test(x, y, addr);
...
}
And next, the pages are mapped with iommu table and the device
address is set to cmdlist so that G2D's dma can access it.
As you may know, the pages from get_user_pages() are pinned.
In other words, they CAN NOT be migrated and also swapped out.
So the dma access would be safe.
But the use of userptr feature has performance overhead so
this patch also has memory pool to the userptr feature.
Please, assume that user sends cmdlist filled with userptr
and size every time to g2d driver, and the get_user_pages
funcion will be called every time.
The memory pool has maximum 64MB size and the userptr that
user had ever sent, is holded in the memory pool.
This meaning is that if the userptr from user is same as one
in the memory pool, device address to the userptr in the memory
pool is set to cmdlist.
And last, the pages from get_user_pages() will be freed once
user calls free() and the dma access is completed. Actually,
get_user_pages() takes 2 reference counts if the user process
has never accessed user region allocated by malloc(). Then, if
the user calls free(), the page reference count becomes 1 and
becomes 0 with put_page() call. And the reverse holds as well.
This means how the pages backed are used by dma and freed.
This patch is based on "drm/exynos: add iommu support for g2d",
https://patchwork.kernel.org/patch/1629481/
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-11-04 17:48:52 +04:00
|
|
|
__u64 cmd_buf;
|
2012-10-04 21:21:50 +04:00
|
|
|
__u32 cmd_nr;
|
drm/exynos: add userptr feature for g2d module
This patch adds userptr feautre for G2D module.
The userptr means user space address allocated by malloc().
And the purpose of this feature is to make G2D's dma able
to access the user space region.
To user this feature, user should flag G2D_BUF_USRPTR to
offset variable of struct drm_exynos_g2d_cmd and fill
struct drm_exynos_g2d_userptr with user space address
and size for it and then should set a pointer to
drm_exynos_g2d_userptr object to data variable of struct
drm_exynos_g2d_cmd. The last bit of offset variable is used
to check if the cmdlist's buffer type is userptr or not.
If userptr, the g2d driver gets user space address and size
and then gets pages through get_user_pages().
(another case is counted as gem handle)
Below is sample codes:
static void set_cmd(struct drm_exynos_g2d_cmd *cmd,
unsigned long offset, unsigned long data)
{
cmd->offset = offset;
cmd->data = data;
}
static int solid_fill_test(int x, int y, unsigned long userptr)
{
struct drm_exynos_g2d_cmd cmd_gem[5];
struct drm_exynos_g2d_userptr g2d_userptr;
unsigned int gem_nr = 0;
...
g2d_userptr.userptr = userptr;
g2d_userptr.size = x * y * 4;
set_cmd(&cmd_gem[gem_nr++], DST_BASE_ADDR_REG |
G2D_BUF_USERPTR,
(unsigned long)&g2d_userptr);
...
}
int main(int argc, char **argv)
{
unsigned long addr;
...
addr = malloc(x * y * 4);
...
solid_fill_test(x, y, addr);
...
}
And next, the pages are mapped with iommu table and the device
address is set to cmdlist so that G2D's dma can access it.
As you may know, the pages from get_user_pages() are pinned.
In other words, they CAN NOT be migrated and also swapped out.
So the dma access would be safe.
But the use of userptr feature has performance overhead so
this patch also has memory pool to the userptr feature.
Please, assume that user sends cmdlist filled with userptr
and size every time to g2d driver, and the get_user_pages
funcion will be called every time.
The memory pool has maximum 64MB size and the userptr that
user had ever sent, is holded in the memory pool.
This meaning is that if the userptr from user is same as one
in the memory pool, device address to the userptr in the memory
pool is set to cmdlist.
And last, the pages from get_user_pages() will be freed once
user calls free() and the dma access is completed. Actually,
get_user_pages() takes 2 reference counts if the user process
has never accessed user region allocated by malloc(). Then, if
the user calls free(), the page reference count becomes 1 and
becomes 0 with put_page() call. And the reverse holds as well.
This means how the pages backed are used by dma and freed.
This patch is based on "drm/exynos: add iommu support for g2d",
https://patchwork.kernel.org/patch/1629481/
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-11-04 17:48:52 +04:00
|
|
|
__u32 cmd_buf_nr;
|
2012-10-04 21:21:50 +04:00
|
|
|
|
|
|
|
|
/* for g2d event */
|
|
|
|
|
__u64 event_type;
|
|
|
|
|
__u64 user_data;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct drm_exynos_g2d_exec {
|
|
|
|
|
__u64 async;
|
|
|
|
|
};
|
|
|
|
|
|
drm/exynos: add ipp subsystem
This patch adds Image Post Processing(IPP) support for exynos drm driver.
IPP supports image scaler/rotator and input/output DMA operations
using IPP subsystem framework to control FIMC, Rotator and GSC hardware
and supports some user interfaces for user side.
And each IPP-based drivers support Memory to Memory operations
with various converting. And in case of FIMC hardware, it also supports
Writeback and Display output operations through local path.
Features:
- Memory to Memory operation support.
- Various pixel formats support.
- Image scaling support.
- Color Space Conversion support.
- Image crop operation support.
- Rotate operation support to 90, 180 or 270 degree.
- Flip operation support to vertical, horizontal or both.
- Writeback operation support to display blended image of FIMD fifo on screen
A summary to IPP Subsystem operations:
First of all, user should get property capabilities from IPP subsystem
and set these properties to hardware registers for desired operations.
The properties could be pixel format, position, rotation degree and
flip operation.
And next, user should set source and destination buffer data using
DRM_EXYNOS_IPP_QUEUE_BUF ioctl command with gem handles to source and
destinition buffers.
And next, user can control user-desired hardware with desired operations
such as play, stop, pause and resume controls.
And finally, user can aware of dma operation completion and also get
destination buffer that it contains user-desried result through dequeue
command.
IOCTL commands:
- DRM_EXYNOS_IPP_GET_PROPERTY
. get ipp driver capabilitis and id.
- DRM_EXYNOS_IPP_SET_PROPERTY
. set format, position, rotation, flip to source and destination buffers
- DRM_EXYNOS_IPP_QUEUE_BUF
. enqueue/dequeue buffer and make event list.
- DRM_EXYNOS_IPP_CMD_CTRL
. play/stop/pause/resume control.
Event:
- DRM_EXYNOS_IPP_EVENT
. a event to notify dma operation completion to user side.
Basic control flow:
Open -> Get properties -> User choose desired IPP sub driver(FIMC, Rotator
or GSCALER) -> Set Property -> Create gem handle -> Enqueue to source and
destination buffers -> Command control(Play) -> Event is notified to User
-> User gets destinition buffer complated -> (Enqueue to source and
destination buffers -> Event is notified to User) * N -> Queue/Dequeue to
source and destination buffers -> Command control(Stop) -> Free gem handle
-> Close
Changelog v1 ~ v5:
- added comments, code fixups and cleanups.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Jinyoung Jeon <jy0.jeon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-12-14 13:10:31 +04:00
|
|
|
enum drm_exynos_ops_id {
|
|
|
|
|
EXYNOS_DRM_OPS_SRC,
|
|
|
|
|
EXYNOS_DRM_OPS_DST,
|
|
|
|
|
EXYNOS_DRM_OPS_MAX,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct drm_exynos_sz {
|
|
|
|
|
__u32 hsize;
|
|
|
|
|
__u32 vsize;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct drm_exynos_pos {
|
|
|
|
|
__u32 x;
|
|
|
|
|
__u32 y;
|
|
|
|
|
__u32 w;
|
|
|
|
|
__u32 h;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum drm_exynos_flip {
|
|
|
|
|
EXYNOS_DRM_FLIP_NONE = (0 << 0),
|
|
|
|
|
EXYNOS_DRM_FLIP_VERTICAL = (1 << 0),
|
|
|
|
|
EXYNOS_DRM_FLIP_HORIZONTAL = (1 << 1),
|
2012-12-22 12:49:24 +04:00
|
|
|
EXYNOS_DRM_FLIP_BOTH = EXYNOS_DRM_FLIP_VERTICAL |
|
|
|
|
|
EXYNOS_DRM_FLIP_HORIZONTAL,
|
drm/exynos: add ipp subsystem
This patch adds Image Post Processing(IPP) support for exynos drm driver.
IPP supports image scaler/rotator and input/output DMA operations
using IPP subsystem framework to control FIMC, Rotator and GSC hardware
and supports some user interfaces for user side.
And each IPP-based drivers support Memory to Memory operations
with various converting. And in case of FIMC hardware, it also supports
Writeback and Display output operations through local path.
Features:
- Memory to Memory operation support.
- Various pixel formats support.
- Image scaling support.
- Color Space Conversion support.
- Image crop operation support.
- Rotate operation support to 90, 180 or 270 degree.
- Flip operation support to vertical, horizontal or both.
- Writeback operation support to display blended image of FIMD fifo on screen
A summary to IPP Subsystem operations:
First of all, user should get property capabilities from IPP subsystem
and set these properties to hardware registers for desired operations.
The properties could be pixel format, position, rotation degree and
flip operation.
And next, user should set source and destination buffer data using
DRM_EXYNOS_IPP_QUEUE_BUF ioctl command with gem handles to source and
destinition buffers.
And next, user can control user-desired hardware with desired operations
such as play, stop, pause and resume controls.
And finally, user can aware of dma operation completion and also get
destination buffer that it contains user-desried result through dequeue
command.
IOCTL commands:
- DRM_EXYNOS_IPP_GET_PROPERTY
. get ipp driver capabilitis and id.
- DRM_EXYNOS_IPP_SET_PROPERTY
. set format, position, rotation, flip to source and destination buffers
- DRM_EXYNOS_IPP_QUEUE_BUF
. enqueue/dequeue buffer and make event list.
- DRM_EXYNOS_IPP_CMD_CTRL
. play/stop/pause/resume control.
Event:
- DRM_EXYNOS_IPP_EVENT
. a event to notify dma operation completion to user side.
Basic control flow:
Open -> Get properties -> User choose desired IPP sub driver(FIMC, Rotator
or GSCALER) -> Set Property -> Create gem handle -> Enqueue to source and
destination buffers -> Command control(Play) -> Event is notified to User
-> User gets destinition buffer complated -> (Enqueue to source and
destination buffers -> Event is notified to User) * N -> Queue/Dequeue to
source and destination buffers -> Command control(Stop) -> Free gem handle
-> Close
Changelog v1 ~ v5:
- added comments, code fixups and cleanups.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Jinyoung Jeon <jy0.jeon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-12-14 13:10:31 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum drm_exynos_degree {
|
|
|
|
|
EXYNOS_DRM_DEGREE_0,
|
|
|
|
|
EXYNOS_DRM_DEGREE_90,
|
|
|
|
|
EXYNOS_DRM_DEGREE_180,
|
|
|
|
|
EXYNOS_DRM_DEGREE_270,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum drm_exynos_planer {
|
|
|
|
|
EXYNOS_DRM_PLANAR_Y,
|
|
|
|
|
EXYNOS_DRM_PLANAR_CB,
|
|
|
|
|
EXYNOS_DRM_PLANAR_CR,
|
|
|
|
|
EXYNOS_DRM_PLANAR_MAX,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* A structure for ipp supported property list.
|
|
|
|
|
*
|
|
|
|
|
* @version: version of this structure.
|
|
|
|
|
* @ipp_id: id of ipp driver.
|
|
|
|
|
* @count: count of ipp driver.
|
|
|
|
|
* @writeback: flag of writeback supporting.
|
|
|
|
|
* @flip: flag of flip supporting.
|
|
|
|
|
* @degree: flag of degree information.
|
|
|
|
|
* @csc: flag of csc supporting.
|
|
|
|
|
* @crop: flag of crop supporting.
|
|
|
|
|
* @scale: flag of scale supporting.
|
|
|
|
|
* @refresh_min: min hz of refresh.
|
|
|
|
|
* @refresh_max: max hz of refresh.
|
|
|
|
|
* @crop_min: crop min resolution.
|
|
|
|
|
* @crop_max: crop max resolution.
|
|
|
|
|
* @scale_min: scale min resolution.
|
|
|
|
|
* @scale_max: scale max resolution.
|
|
|
|
|
*/
|
|
|
|
|
struct drm_exynos_ipp_prop_list {
|
|
|
|
|
__u32 version;
|
|
|
|
|
__u32 ipp_id;
|
|
|
|
|
__u32 count;
|
|
|
|
|
__u32 writeback;
|
|
|
|
|
__u32 flip;
|
|
|
|
|
__u32 degree;
|
|
|
|
|
__u32 csc;
|
|
|
|
|
__u32 crop;
|
|
|
|
|
__u32 scale;
|
|
|
|
|
__u32 refresh_min;
|
|
|
|
|
__u32 refresh_max;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
struct drm_exynos_sz crop_min;
|
|
|
|
|
struct drm_exynos_sz crop_max;
|
|
|
|
|
struct drm_exynos_sz scale_min;
|
|
|
|
|
struct drm_exynos_sz scale_max;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* A structure for ipp config.
|
|
|
|
|
*
|
|
|
|
|
* @ops_id: property of operation directions.
|
|
|
|
|
* @flip: property of mirror, flip.
|
|
|
|
|
* @degree: property of rotation degree.
|
|
|
|
|
* @fmt: property of image format.
|
|
|
|
|
* @sz: property of image size.
|
|
|
|
|
* @pos: property of image position(src-cropped,dst-scaler).
|
|
|
|
|
*/
|
|
|
|
|
struct drm_exynos_ipp_config {
|
2016-02-12 15:13:59 +03:00
|
|
|
__u32 ops_id;
|
|
|
|
|
__u32 flip;
|
|
|
|
|
__u32 degree;
|
drm/exynos: add ipp subsystem
This patch adds Image Post Processing(IPP) support for exynos drm driver.
IPP supports image scaler/rotator and input/output DMA operations
using IPP subsystem framework to control FIMC, Rotator and GSC hardware
and supports some user interfaces for user side.
And each IPP-based drivers support Memory to Memory operations
with various converting. And in case of FIMC hardware, it also supports
Writeback and Display output operations through local path.
Features:
- Memory to Memory operation support.
- Various pixel formats support.
- Image scaling support.
- Color Space Conversion support.
- Image crop operation support.
- Rotate operation support to 90, 180 or 270 degree.
- Flip operation support to vertical, horizontal or both.
- Writeback operation support to display blended image of FIMD fifo on screen
A summary to IPP Subsystem operations:
First of all, user should get property capabilities from IPP subsystem
and set these properties to hardware registers for desired operations.
The properties could be pixel format, position, rotation degree and
flip operation.
And next, user should set source and destination buffer data using
DRM_EXYNOS_IPP_QUEUE_BUF ioctl command with gem handles to source and
destinition buffers.
And next, user can control user-desired hardware with desired operations
such as play, stop, pause and resume controls.
And finally, user can aware of dma operation completion and also get
destination buffer that it contains user-desried result through dequeue
command.
IOCTL commands:
- DRM_EXYNOS_IPP_GET_PROPERTY
. get ipp driver capabilitis and id.
- DRM_EXYNOS_IPP_SET_PROPERTY
. set format, position, rotation, flip to source and destination buffers
- DRM_EXYNOS_IPP_QUEUE_BUF
. enqueue/dequeue buffer and make event list.
- DRM_EXYNOS_IPP_CMD_CTRL
. play/stop/pause/resume control.
Event:
- DRM_EXYNOS_IPP_EVENT
. a event to notify dma operation completion to user side.
Basic control flow:
Open -> Get properties -> User choose desired IPP sub driver(FIMC, Rotator
or GSCALER) -> Set Property -> Create gem handle -> Enqueue to source and
destination buffers -> Command control(Play) -> Event is notified to User
-> User gets destinition buffer complated -> (Enqueue to source and
destination buffers -> Event is notified to User) * N -> Queue/Dequeue to
source and destination buffers -> Command control(Stop) -> Free gem handle
-> Close
Changelog v1 ~ v5:
- added comments, code fixups and cleanups.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Jinyoung Jeon <jy0.jeon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-12-14 13:10:31 +04:00
|
|
|
__u32 fmt;
|
|
|
|
|
struct drm_exynos_sz sz;
|
|
|
|
|
struct drm_exynos_pos pos;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum drm_exynos_ipp_cmd {
|
|
|
|
|
IPP_CMD_NONE,
|
|
|
|
|
IPP_CMD_M2M,
|
|
|
|
|
IPP_CMD_WB,
|
|
|
|
|
IPP_CMD_OUTPUT,
|
|
|
|
|
IPP_CMD_MAX,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* A structure for ipp property.
|
|
|
|
|
*
|
|
|
|
|
* @config: source, destination config.
|
|
|
|
|
* @cmd: definition of command.
|
|
|
|
|
* @ipp_id: id of ipp driver.
|
|
|
|
|
* @prop_id: id of property.
|
|
|
|
|
* @refresh_rate: refresh rate.
|
|
|
|
|
*/
|
|
|
|
|
struct drm_exynos_ipp_property {
|
|
|
|
|
struct drm_exynos_ipp_config config[EXYNOS_DRM_OPS_MAX];
|
2016-02-12 15:13:59 +03:00
|
|
|
__u32 cmd;
|
drm/exynos: add ipp subsystem
This patch adds Image Post Processing(IPP) support for exynos drm driver.
IPP supports image scaler/rotator and input/output DMA operations
using IPP subsystem framework to control FIMC, Rotator and GSC hardware
and supports some user interfaces for user side.
And each IPP-based drivers support Memory to Memory operations
with various converting. And in case of FIMC hardware, it also supports
Writeback and Display output operations through local path.
Features:
- Memory to Memory operation support.
- Various pixel formats support.
- Image scaling support.
- Color Space Conversion support.
- Image crop operation support.
- Rotate operation support to 90, 180 or 270 degree.
- Flip operation support to vertical, horizontal or both.
- Writeback operation support to display blended image of FIMD fifo on screen
A summary to IPP Subsystem operations:
First of all, user should get property capabilities from IPP subsystem
and set these properties to hardware registers for desired operations.
The properties could be pixel format, position, rotation degree and
flip operation.
And next, user should set source and destination buffer data using
DRM_EXYNOS_IPP_QUEUE_BUF ioctl command with gem handles to source and
destinition buffers.
And next, user can control user-desired hardware with desired operations
such as play, stop, pause and resume controls.
And finally, user can aware of dma operation completion and also get
destination buffer that it contains user-desried result through dequeue
command.
IOCTL commands:
- DRM_EXYNOS_IPP_GET_PROPERTY
. get ipp driver capabilitis and id.
- DRM_EXYNOS_IPP_SET_PROPERTY
. set format, position, rotation, flip to source and destination buffers
- DRM_EXYNOS_IPP_QUEUE_BUF
. enqueue/dequeue buffer and make event list.
- DRM_EXYNOS_IPP_CMD_CTRL
. play/stop/pause/resume control.
Event:
- DRM_EXYNOS_IPP_EVENT
. a event to notify dma operation completion to user side.
Basic control flow:
Open -> Get properties -> User choose desired IPP sub driver(FIMC, Rotator
or GSCALER) -> Set Property -> Create gem handle -> Enqueue to source and
destination buffers -> Command control(Play) -> Event is notified to User
-> User gets destinition buffer complated -> (Enqueue to source and
destination buffers -> Event is notified to User) * N -> Queue/Dequeue to
source and destination buffers -> Command control(Stop) -> Free gem handle
-> Close
Changelog v1 ~ v5:
- added comments, code fixups and cleanups.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Jinyoung Jeon <jy0.jeon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-12-14 13:10:31 +04:00
|
|
|
__u32 ipp_id;
|
|
|
|
|
__u32 prop_id;
|
|
|
|
|
__u32 refresh_rate;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum drm_exynos_ipp_buf_type {
|
|
|
|
|
IPP_BUF_ENQUEUE,
|
|
|
|
|
IPP_BUF_DEQUEUE,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* A structure for ipp buffer operations.
|
|
|
|
|
*
|
|
|
|
|
* @ops_id: operation directions.
|
|
|
|
|
* @buf_type: definition of buffer.
|
|
|
|
|
* @prop_id: id of property.
|
|
|
|
|
* @buf_id: id of buffer.
|
|
|
|
|
* @handle: Y, Cb, Cr each planar handle.
|
|
|
|
|
* @user_data: user data.
|
|
|
|
|
*/
|
|
|
|
|
struct drm_exynos_ipp_queue_buf {
|
2016-02-12 15:13:59 +03:00
|
|
|
__u32 ops_id;
|
|
|
|
|
__u32 buf_type;
|
drm/exynos: add ipp subsystem
This patch adds Image Post Processing(IPP) support for exynos drm driver.
IPP supports image scaler/rotator and input/output DMA operations
using IPP subsystem framework to control FIMC, Rotator and GSC hardware
and supports some user interfaces for user side.
And each IPP-based drivers support Memory to Memory operations
with various converting. And in case of FIMC hardware, it also supports
Writeback and Display output operations through local path.
Features:
- Memory to Memory operation support.
- Various pixel formats support.
- Image scaling support.
- Color Space Conversion support.
- Image crop operation support.
- Rotate operation support to 90, 180 or 270 degree.
- Flip operation support to vertical, horizontal or both.
- Writeback operation support to display blended image of FIMD fifo on screen
A summary to IPP Subsystem operations:
First of all, user should get property capabilities from IPP subsystem
and set these properties to hardware registers for desired operations.
The properties could be pixel format, position, rotation degree and
flip operation.
And next, user should set source and destination buffer data using
DRM_EXYNOS_IPP_QUEUE_BUF ioctl command with gem handles to source and
destinition buffers.
And next, user can control user-desired hardware with desired operations
such as play, stop, pause and resume controls.
And finally, user can aware of dma operation completion and also get
destination buffer that it contains user-desried result through dequeue
command.
IOCTL commands:
- DRM_EXYNOS_IPP_GET_PROPERTY
. get ipp driver capabilitis and id.
- DRM_EXYNOS_IPP_SET_PROPERTY
. set format, position, rotation, flip to source and destination buffers
- DRM_EXYNOS_IPP_QUEUE_BUF
. enqueue/dequeue buffer and make event list.
- DRM_EXYNOS_IPP_CMD_CTRL
. play/stop/pause/resume control.
Event:
- DRM_EXYNOS_IPP_EVENT
. a event to notify dma operation completion to user side.
Basic control flow:
Open -> Get properties -> User choose desired IPP sub driver(FIMC, Rotator
or GSCALER) -> Set Property -> Create gem handle -> Enqueue to source and
destination buffers -> Command control(Play) -> Event is notified to User
-> User gets destinition buffer complated -> (Enqueue to source and
destination buffers -> Event is notified to User) * N -> Queue/Dequeue to
source and destination buffers -> Command control(Stop) -> Free gem handle
-> Close
Changelog v1 ~ v5:
- added comments, code fixups and cleanups.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Jinyoung Jeon <jy0.jeon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-12-14 13:10:31 +04:00
|
|
|
__u32 prop_id;
|
|
|
|
|
__u32 buf_id;
|
|
|
|
|
__u32 handle[EXYNOS_DRM_PLANAR_MAX];
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
__u64 user_data;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum drm_exynos_ipp_ctrl {
|
|
|
|
|
IPP_CTRL_PLAY,
|
|
|
|
|
IPP_CTRL_STOP,
|
|
|
|
|
IPP_CTRL_PAUSE,
|
|
|
|
|
IPP_CTRL_RESUME,
|
|
|
|
|
IPP_CTRL_MAX,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* A structure for ipp start/stop operations.
|
|
|
|
|
*
|
|
|
|
|
* @prop_id: id of property.
|
|
|
|
|
* @ctrl: definition of control.
|
|
|
|
|
*/
|
|
|
|
|
struct drm_exynos_ipp_cmd_ctrl {
|
|
|
|
|
__u32 prop_id;
|
2016-02-12 15:13:59 +03:00
|
|
|
__u32 ctrl;
|
drm/exynos: add ipp subsystem
This patch adds Image Post Processing(IPP) support for exynos drm driver.
IPP supports image scaler/rotator and input/output DMA operations
using IPP subsystem framework to control FIMC, Rotator and GSC hardware
and supports some user interfaces for user side.
And each IPP-based drivers support Memory to Memory operations
with various converting. And in case of FIMC hardware, it also supports
Writeback and Display output operations through local path.
Features:
- Memory to Memory operation support.
- Various pixel formats support.
- Image scaling support.
- Color Space Conversion support.
- Image crop operation support.
- Rotate operation support to 90, 180 or 270 degree.
- Flip operation support to vertical, horizontal or both.
- Writeback operation support to display blended image of FIMD fifo on screen
A summary to IPP Subsystem operations:
First of all, user should get property capabilities from IPP subsystem
and set these properties to hardware registers for desired operations.
The properties could be pixel format, position, rotation degree and
flip operation.
And next, user should set source and destination buffer data using
DRM_EXYNOS_IPP_QUEUE_BUF ioctl command with gem handles to source and
destinition buffers.
And next, user can control user-desired hardware with desired operations
such as play, stop, pause and resume controls.
And finally, user can aware of dma operation completion and also get
destination buffer that it contains user-desried result through dequeue
command.
IOCTL commands:
- DRM_EXYNOS_IPP_GET_PROPERTY
. get ipp driver capabilitis and id.
- DRM_EXYNOS_IPP_SET_PROPERTY
. set format, position, rotation, flip to source and destination buffers
- DRM_EXYNOS_IPP_QUEUE_BUF
. enqueue/dequeue buffer and make event list.
- DRM_EXYNOS_IPP_CMD_CTRL
. play/stop/pause/resume control.
Event:
- DRM_EXYNOS_IPP_EVENT
. a event to notify dma operation completion to user side.
Basic control flow:
Open -> Get properties -> User choose desired IPP sub driver(FIMC, Rotator
or GSCALER) -> Set Property -> Create gem handle -> Enqueue to source and
destination buffers -> Command control(Play) -> Event is notified to User
-> User gets destinition buffer complated -> (Enqueue to source and
destination buffers -> Event is notified to User) * N -> Queue/Dequeue to
source and destination buffers -> Command control(Stop) -> Free gem handle
-> Close
Changelog v1 ~ v5:
- added comments, code fixups and cleanups.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Jinyoung Jeon <jy0.jeon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-12-14 13:10:31 +04:00
|
|
|
};
|
|
|
|
|
|
2012-10-04 21:21:50 +04:00
|
|
|
#define DRM_EXYNOS_GEM_CREATE 0x00
|
2016-03-08 08:12:59 +03:00
|
|
|
#define DRM_EXYNOS_GEM_MAP 0x01
|
2012-10-04 21:21:50 +04:00
|
|
|
/* Reserved 0x03 ~ 0x05 for exynos specific gem ioctl */
|
|
|
|
|
#define DRM_EXYNOS_GEM_GET 0x04
|
|
|
|
|
#define DRM_EXYNOS_VIDI_CONNECTION 0x07
|
|
|
|
|
|
|
|
|
|
/* G2D */
|
|
|
|
|
#define DRM_EXYNOS_G2D_GET_VER 0x20
|
|
|
|
|
#define DRM_EXYNOS_G2D_SET_CMDLIST 0x21
|
|
|
|
|
#define DRM_EXYNOS_G2D_EXEC 0x22
|
|
|
|
|
|
drm/exynos: add ipp subsystem
This patch adds Image Post Processing(IPP) support for exynos drm driver.
IPP supports image scaler/rotator and input/output DMA operations
using IPP subsystem framework to control FIMC, Rotator and GSC hardware
and supports some user interfaces for user side.
And each IPP-based drivers support Memory to Memory operations
with various converting. And in case of FIMC hardware, it also supports
Writeback and Display output operations through local path.
Features:
- Memory to Memory operation support.
- Various pixel formats support.
- Image scaling support.
- Color Space Conversion support.
- Image crop operation support.
- Rotate operation support to 90, 180 or 270 degree.
- Flip operation support to vertical, horizontal or both.
- Writeback operation support to display blended image of FIMD fifo on screen
A summary to IPP Subsystem operations:
First of all, user should get property capabilities from IPP subsystem
and set these properties to hardware registers for desired operations.
The properties could be pixel format, position, rotation degree and
flip operation.
And next, user should set source and destination buffer data using
DRM_EXYNOS_IPP_QUEUE_BUF ioctl command with gem handles to source and
destinition buffers.
And next, user can control user-desired hardware with desired operations
such as play, stop, pause and resume controls.
And finally, user can aware of dma operation completion and also get
destination buffer that it contains user-desried result through dequeue
command.
IOCTL commands:
- DRM_EXYNOS_IPP_GET_PROPERTY
. get ipp driver capabilitis and id.
- DRM_EXYNOS_IPP_SET_PROPERTY
. set format, position, rotation, flip to source and destination buffers
- DRM_EXYNOS_IPP_QUEUE_BUF
. enqueue/dequeue buffer and make event list.
- DRM_EXYNOS_IPP_CMD_CTRL
. play/stop/pause/resume control.
Event:
- DRM_EXYNOS_IPP_EVENT
. a event to notify dma operation completion to user side.
Basic control flow:
Open -> Get properties -> User choose desired IPP sub driver(FIMC, Rotator
or GSCALER) -> Set Property -> Create gem handle -> Enqueue to source and
destination buffers -> Command control(Play) -> Event is notified to User
-> User gets destinition buffer complated -> (Enqueue to source and
destination buffers -> Event is notified to User) * N -> Queue/Dequeue to
source and destination buffers -> Command control(Stop) -> Free gem handle
-> Close
Changelog v1 ~ v5:
- added comments, code fixups and cleanups.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Jinyoung Jeon <jy0.jeon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-12-14 13:10:31 +04:00
|
|
|
/* IPP - Image Post Processing */
|
|
|
|
|
#define DRM_EXYNOS_IPP_GET_PROPERTY 0x30
|
|
|
|
|
#define DRM_EXYNOS_IPP_SET_PROPERTY 0x31
|
|
|
|
|
#define DRM_EXYNOS_IPP_QUEUE_BUF 0x32
|
|
|
|
|
#define DRM_EXYNOS_IPP_CMD_CTRL 0x33
|
|
|
|
|
|
2012-10-04 21:21:50 +04:00
|
|
|
#define DRM_IOCTL_EXYNOS_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + \
|
|
|
|
|
DRM_EXYNOS_GEM_CREATE, struct drm_exynos_gem_create)
|
2016-03-08 08:12:59 +03:00
|
|
|
#define DRM_IOCTL_EXYNOS_GEM_MAP DRM_IOWR(DRM_COMMAND_BASE + \
|
|
|
|
|
DRM_EXYNOS_GEM_MAP, struct drm_exynos_gem_map)
|
2012-10-04 21:21:50 +04:00
|
|
|
#define DRM_IOCTL_EXYNOS_GEM_GET DRM_IOWR(DRM_COMMAND_BASE + \
|
|
|
|
|
DRM_EXYNOS_GEM_GET, struct drm_exynos_gem_info)
|
|
|
|
|
|
|
|
|
|
#define DRM_IOCTL_EXYNOS_VIDI_CONNECTION DRM_IOWR(DRM_COMMAND_BASE + \
|
|
|
|
|
DRM_EXYNOS_VIDI_CONNECTION, struct drm_exynos_vidi_connection)
|
|
|
|
|
|
|
|
|
|
#define DRM_IOCTL_EXYNOS_G2D_GET_VER DRM_IOWR(DRM_COMMAND_BASE + \
|
|
|
|
|
DRM_EXYNOS_G2D_GET_VER, struct drm_exynos_g2d_get_ver)
|
|
|
|
|
#define DRM_IOCTL_EXYNOS_G2D_SET_CMDLIST DRM_IOWR(DRM_COMMAND_BASE + \
|
|
|
|
|
DRM_EXYNOS_G2D_SET_CMDLIST, struct drm_exynos_g2d_set_cmdlist)
|
|
|
|
|
#define DRM_IOCTL_EXYNOS_G2D_EXEC DRM_IOWR(DRM_COMMAND_BASE + \
|
|
|
|
|
DRM_EXYNOS_G2D_EXEC, struct drm_exynos_g2d_exec)
|
|
|
|
|
|
drm/exynos: add ipp subsystem
This patch adds Image Post Processing(IPP) support for exynos drm driver.
IPP supports image scaler/rotator and input/output DMA operations
using IPP subsystem framework to control FIMC, Rotator and GSC hardware
and supports some user interfaces for user side.
And each IPP-based drivers support Memory to Memory operations
with various converting. And in case of FIMC hardware, it also supports
Writeback and Display output operations through local path.
Features:
- Memory to Memory operation support.
- Various pixel formats support.
- Image scaling support.
- Color Space Conversion support.
- Image crop operation support.
- Rotate operation support to 90, 180 or 270 degree.
- Flip operation support to vertical, horizontal or both.
- Writeback operation support to display blended image of FIMD fifo on screen
A summary to IPP Subsystem operations:
First of all, user should get property capabilities from IPP subsystem
and set these properties to hardware registers for desired operations.
The properties could be pixel format, position, rotation degree and
flip operation.
And next, user should set source and destination buffer data using
DRM_EXYNOS_IPP_QUEUE_BUF ioctl command with gem handles to source and
destinition buffers.
And next, user can control user-desired hardware with desired operations
such as play, stop, pause and resume controls.
And finally, user can aware of dma operation completion and also get
destination buffer that it contains user-desried result through dequeue
command.
IOCTL commands:
- DRM_EXYNOS_IPP_GET_PROPERTY
. get ipp driver capabilitis and id.
- DRM_EXYNOS_IPP_SET_PROPERTY
. set format, position, rotation, flip to source and destination buffers
- DRM_EXYNOS_IPP_QUEUE_BUF
. enqueue/dequeue buffer and make event list.
- DRM_EXYNOS_IPP_CMD_CTRL
. play/stop/pause/resume control.
Event:
- DRM_EXYNOS_IPP_EVENT
. a event to notify dma operation completion to user side.
Basic control flow:
Open -> Get properties -> User choose desired IPP sub driver(FIMC, Rotator
or GSCALER) -> Set Property -> Create gem handle -> Enqueue to source and
destination buffers -> Command control(Play) -> Event is notified to User
-> User gets destinition buffer complated -> (Enqueue to source and
destination buffers -> Event is notified to User) * N -> Queue/Dequeue to
source and destination buffers -> Command control(Stop) -> Free gem handle
-> Close
Changelog v1 ~ v5:
- added comments, code fixups and cleanups.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Jinyoung Jeon <jy0.jeon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-12-14 13:10:31 +04:00
|
|
|
#define DRM_IOCTL_EXYNOS_IPP_GET_PROPERTY DRM_IOWR(DRM_COMMAND_BASE + \
|
|
|
|
|
DRM_EXYNOS_IPP_GET_PROPERTY, struct drm_exynos_ipp_prop_list)
|
|
|
|
|
#define DRM_IOCTL_EXYNOS_IPP_SET_PROPERTY DRM_IOWR(DRM_COMMAND_BASE + \
|
|
|
|
|
DRM_EXYNOS_IPP_SET_PROPERTY, struct drm_exynos_ipp_property)
|
|
|
|
|
#define DRM_IOCTL_EXYNOS_IPP_QUEUE_BUF DRM_IOWR(DRM_COMMAND_BASE + \
|
|
|
|
|
DRM_EXYNOS_IPP_QUEUE_BUF, struct drm_exynos_ipp_queue_buf)
|
|
|
|
|
#define DRM_IOCTL_EXYNOS_IPP_CMD_CTRL DRM_IOWR(DRM_COMMAND_BASE + \
|
|
|
|
|
DRM_EXYNOS_IPP_CMD_CTRL, struct drm_exynos_ipp_cmd_ctrl)
|
|
|
|
|
|
2012-10-04 21:21:50 +04:00
|
|
|
/* EXYNOS specific events */
|
|
|
|
|
#define DRM_EXYNOS_G2D_EVENT 0x80000000
|
drm/exynos: add ipp subsystem
This patch adds Image Post Processing(IPP) support for exynos drm driver.
IPP supports image scaler/rotator and input/output DMA operations
using IPP subsystem framework to control FIMC, Rotator and GSC hardware
and supports some user interfaces for user side.
And each IPP-based drivers support Memory to Memory operations
with various converting. And in case of FIMC hardware, it also supports
Writeback and Display output operations through local path.
Features:
- Memory to Memory operation support.
- Various pixel formats support.
- Image scaling support.
- Color Space Conversion support.
- Image crop operation support.
- Rotate operation support to 90, 180 or 270 degree.
- Flip operation support to vertical, horizontal or both.
- Writeback operation support to display blended image of FIMD fifo on screen
A summary to IPP Subsystem operations:
First of all, user should get property capabilities from IPP subsystem
and set these properties to hardware registers for desired operations.
The properties could be pixel format, position, rotation degree and
flip operation.
And next, user should set source and destination buffer data using
DRM_EXYNOS_IPP_QUEUE_BUF ioctl command with gem handles to source and
destinition buffers.
And next, user can control user-desired hardware with desired operations
such as play, stop, pause and resume controls.
And finally, user can aware of dma operation completion and also get
destination buffer that it contains user-desried result through dequeue
command.
IOCTL commands:
- DRM_EXYNOS_IPP_GET_PROPERTY
. get ipp driver capabilitis and id.
- DRM_EXYNOS_IPP_SET_PROPERTY
. set format, position, rotation, flip to source and destination buffers
- DRM_EXYNOS_IPP_QUEUE_BUF
. enqueue/dequeue buffer and make event list.
- DRM_EXYNOS_IPP_CMD_CTRL
. play/stop/pause/resume control.
Event:
- DRM_EXYNOS_IPP_EVENT
. a event to notify dma operation completion to user side.
Basic control flow:
Open -> Get properties -> User choose desired IPP sub driver(FIMC, Rotator
or GSCALER) -> Set Property -> Create gem handle -> Enqueue to source and
destination buffers -> Command control(Play) -> Event is notified to User
-> User gets destinition buffer complated -> (Enqueue to source and
destination buffers -> Event is notified to User) * N -> Queue/Dequeue to
source and destination buffers -> Command control(Stop) -> Free gem handle
-> Close
Changelog v1 ~ v5:
- added comments, code fixups and cleanups.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Jinyoung Jeon <jy0.jeon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-12-14 13:10:31 +04:00
|
|
|
#define DRM_EXYNOS_IPP_EVENT 0x80000001
|
2012-10-04 21:21:50 +04:00
|
|
|
|
|
|
|
|
struct drm_exynos_g2d_event {
|
|
|
|
|
struct drm_event base;
|
|
|
|
|
__u64 user_data;
|
|
|
|
|
__u32 tv_sec;
|
|
|
|
|
__u32 tv_usec;
|
|
|
|
|
__u32 cmdlist_no;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
};
|
|
|
|
|
|
drm/exynos: add ipp subsystem
This patch adds Image Post Processing(IPP) support for exynos drm driver.
IPP supports image scaler/rotator and input/output DMA operations
using IPP subsystem framework to control FIMC, Rotator and GSC hardware
and supports some user interfaces for user side.
And each IPP-based drivers support Memory to Memory operations
with various converting. And in case of FIMC hardware, it also supports
Writeback and Display output operations through local path.
Features:
- Memory to Memory operation support.
- Various pixel formats support.
- Image scaling support.
- Color Space Conversion support.
- Image crop operation support.
- Rotate operation support to 90, 180 or 270 degree.
- Flip operation support to vertical, horizontal or both.
- Writeback operation support to display blended image of FIMD fifo on screen
A summary to IPP Subsystem operations:
First of all, user should get property capabilities from IPP subsystem
and set these properties to hardware registers for desired operations.
The properties could be pixel format, position, rotation degree and
flip operation.
And next, user should set source and destination buffer data using
DRM_EXYNOS_IPP_QUEUE_BUF ioctl command with gem handles to source and
destinition buffers.
And next, user can control user-desired hardware with desired operations
such as play, stop, pause and resume controls.
And finally, user can aware of dma operation completion and also get
destination buffer that it contains user-desried result through dequeue
command.
IOCTL commands:
- DRM_EXYNOS_IPP_GET_PROPERTY
. get ipp driver capabilitis and id.
- DRM_EXYNOS_IPP_SET_PROPERTY
. set format, position, rotation, flip to source and destination buffers
- DRM_EXYNOS_IPP_QUEUE_BUF
. enqueue/dequeue buffer and make event list.
- DRM_EXYNOS_IPP_CMD_CTRL
. play/stop/pause/resume control.
Event:
- DRM_EXYNOS_IPP_EVENT
. a event to notify dma operation completion to user side.
Basic control flow:
Open -> Get properties -> User choose desired IPP sub driver(FIMC, Rotator
or GSCALER) -> Set Property -> Create gem handle -> Enqueue to source and
destination buffers -> Command control(Play) -> Event is notified to User
-> User gets destinition buffer complated -> (Enqueue to source and
destination buffers -> Event is notified to User) * N -> Queue/Dequeue to
source and destination buffers -> Command control(Stop) -> Free gem handle
-> Close
Changelog v1 ~ v5:
- added comments, code fixups and cleanups.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Jinyoung Jeon <jy0.jeon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-12-14 13:10:31 +04:00
|
|
|
struct drm_exynos_ipp_event {
|
|
|
|
|
struct drm_event base;
|
|
|
|
|
__u64 user_data;
|
|
|
|
|
__u32 tv_sec;
|
|
|
|
|
__u32 tv_usec;
|
|
|
|
|
__u32 prop_id;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
__u32 buf_id[EXYNOS_DRM_OPS_MAX];
|
|
|
|
|
};
|
|
|
|
|
|
2016-04-07 20:58:35 +03:00
|
|
|
#if defined(__cplusplus)
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2012-10-04 21:21:50 +04:00
|
|
|
#endif /* _UAPI_EXYNOS_DRM_H_ */
|
