[LINUX] Expose API to lock and Unlock IO Buffers
authorSaurabh Bipin Chandra <a0131926@ti.com>
Fri, 30 Aug 2013 11:58:19 +0000 (17:28 +0530)
committerSaurabh Bipin Chandra <a0131926@ti.com>
Wed, 4 Sep 2013 12:38:50 +0000 (18:08 +0530)
commitfde931439600e9be8f4556960230f6b62a474ade
tree3300cbf744abe9f8cd9584f9891c3b045af81a94
parentbd95703493320275efe5b3d0db6d75e783a88414
[LINUX] Expose API to lock and Unlock IO Buffers

This patch exposes APIs:
   dce_buf_lock(int num, size_t *handle)
   dce_buf_unlock(int num, size_t *handle)
to lock and unlock the Input/Output Buffers respectively.

The change is specific to GLP.
The DRM driver pins and unpins tiler address for the
IO Buffers whenever the rpmsg_rpc driver calls
map_attachment and unmap_attachment() respectively.
As the rpmsg_rpc driver invokes these calls during every
process call, the reference buffer addresses (address of
past locked buffers) held by the codec gets invalidated.
That is, these addresses will not continue to map to the
same memory region (YUV reference buffer) as before.

Most often, these virtual addresses may point to the
next YUV Buffer translated from the MPU.

These APIs put a condition on the map and unmap() within
rpmsg_rpc.

The expectation from the application is to
call dce_buf_lock() for the inArgs.inputID buffer
and dce_buf_unlock() for the outArgs.freeBufID buffer.

Change-Id: Ic749c6b18385f9052a2eeb4e16959063c5efab5e
Signed-off-by: Saurabh Bipin Chandra <a0131926@ti.com>
libdce.c
libdce.h