3b0e8f1281
3 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Eunchul Kim
|
cb471f14b5 |
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> |
||
|
Inki Dae
|
2a3098ff6c |
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>
|
||
|
David Howells
|
718dcedd7e |
UAPI: (Scripted) Disintegrate include/drm
Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Michael Kerrisk <mtk.manpages@gmail.com> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com> |