When doing ion / drm detection use access is a better idea. For open
will introduce some unnecessary kernel operation. And access is more
flexible to use library on different stage of boot up.
Change-Id: Ib6e98d26cb59dd1c8b0899cfa43911fc25097bd4
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Each of the different alloctor has different alloctor modes,
such as allocating physical continuous memory, secure memory,
etc.
Change-Id: Ib032689f0cfd36b494843dcc176a22c6c9587b6a
Signed-off-by: Rimon Xu <rimon.xu@rock-chips.com>
This buffer type is used for the buffer coming from the
application, the application should make sure those
buffers are the dma buffer.
Change-Id: I2c8491f4dea77e5d7ae8d9157b0a1eda204f4bd6
Signed-off-by: Randy Li <randy.li@rock-chips.com>
As we found that simple ion / drm device detectioin can not cover all the
case. For example on some 3368 platform kernel provide both ion and drm
device. We have better to use allocator chosen in dts.
But later kernel patch from Randy will bring unified dma-fd translation in
kernel then this detection will be removed.
Change-Id: I2746142d1c3d0f36791bacaadb231dc2001a5aa7
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Due to complexity of different kernel and usespace combination
we have to detect drm and ion allocator on runtime. The HAVE_DRM
flag may not be trust at all time. So we add a simple detection
function on first run.
Change-Id: Id4f6b2278ee0fe50ffc9806fffc5b01267f723da
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
The "[drm]: fix runtime error for 32bit library" is hack way,
it won't work at GNU Linux platform. Also you need to check
_FILE_OFFSET_BITS and _LARGEFILE64_SOURCE before use the
mmap64().
For the normal mmap() with glibc, we only request to
check offset is aligned with page size but not the lenght.
But that doesn't apply for the memory from the drm device,
also the android use a different rule.
I decide not to map all the buffer to cpu at beginning
since most of them won't be access by the cpu.
Change-Id: I74ac7b5b63d45029cae076985a3d0b4526c62bbc
Signed-off-by: Randy Li <randy.li@rock-chips.com>
