Hi Vikash,
Please write the comments for the chunk of code for which they are refer to.
On 2.05.2018 10:40, Vikash Garodia wrote:
Hello Stanimir,
On 2018-04-24 18:14, Stanimir Varbanov wrote:
This is implementing a multi-stream decoder support. The multi
stream gives an option to use the secondary decoder output
with different raw format (or the same in case of crop).
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@xxxxxxxxxx>
---
drivers/media/platform/qcom/venus/core.h | 1 +
drivers/media/platform/qcom/venus/helpers.c | 204
+++++++++++++++++++++++++++-
drivers/media/platform/qcom/venus/helpers.h | 6 +
drivers/media/platform/qcom/venus/vdec.c | 91 ++++++++++++-
drivers/media/platform/qcom/venus/venc.c | 1 +
5 files changed, 299 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/core.h
b/drivers/media/platform/qcom/venus/core.h
index 4d6c05f156c4..85e66e2dd672 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -259,6 +259,7 @@ struct venus_inst {
struct list_head list;
struct mutex lock;
struct venus_core *core;
+ struct list_head dpbbufs;
struct list_head internalbufs;
struct list_head registeredbufs;
struct list_head delayed_process;
<snip>
The dpb buffers queued to hardware will be returned back to host either
during flush
or when the session is stopped. Host should not send these buffers to
client.
That's correct.
vdec_buf_done should be handling in a way to drop dpb buffers from
sending to client.
That is also correct, vdec_buf_done is trying to find the buffer by
index from a list of queued buffers from v4l2 clients. See
venus_helper_vb2_buf_queue where it is calling v4l2_m2m_buf_queue.
So for the dpb buffers venus_helper_find_buf() will return NULL.
regards,
Stan
