The dma_heap is introduced in kernel 5.10.
Change-Id: Id3c116d996da461467fe380a79434ba5ea875033
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
1. Move mpp_log.h to inc for external user.
2. Add mpp_debug.h for mpp internal logging.
3. Fix some warning.
4. Add log level setup function.
5. Check env log_level value in mpp_get_log_level call.
NOTE:
1. mpp internal module should use mpp_debug.h and mpp external user
should use mpp_log.h
2. Use mpp_get_log_level to update mpp_log_level when the env changed.
Change-Id: I90a55a02a72db177533013280dfe111ca3479229
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Add a new ioctl mode for kernel-4.19 or later.
Tips:
1. There will be only one device /dev/mpp_service in kernel.
User should use client type to distinguish different device.
2. Each codec use the same function as before.
3. Ioctl magic changes from VPU_IOC to MPP_IOC.
4. Update structure for ioctl argument.
Original structure:
data_ptr | size
In this mode has many sortcommings:
a) Need many ioctl cmd for different requirements.
b) Data_ptr not to differ library for 32 or 64 system.
c) Contain only one info ioctl once.
New data structure:
cmd_type | flags | size | offset | data_ptr
a) Cmd_type works like previous ioctl cmd.
b) Flags is extend to mark current data for any purpose.
c) Size is the same as before.
d) Data_ptr use 32 bits build in 32 system while 64 bits in 64 system.
kernel-4.19 related commit:
ib94ac0df876dfcc786b25ed3de6a68d861d2ef1e
cda9d27c62017309519bcbf8fe91057dfdc21076
Change-Id: I13d54a2e4823b7378265f100540916a22f62b9d4
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
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>
