video: driver: buffer flow changes

When client queued a buffer, v4l2 framework
compares the client Dmabuf with the existing
dmabuf in the bufs array at the same index.
If the dmabuf is different then v4l2 framework
would call unmap_dmabuf, detach_dmabuf callbacks
for the old buffer and then calls attach_dmabuf,
map_dmabuf callbacks for the new buffer before
qbuf callback is made to driver. If the dmabuf
is same then qbuf callback will be made directly.

V4l2 framework expects that clients recycles the
same buffers in the same indices so that when
v4l2 framework compares dmabuf it won't unmap
or map buffers.

If client recycle the buffers in different indices
still usecase works but there will be unnecessary
unmap, map overhead will be incurred.

If client does not recycle the buffers at all,
meaning every time client queues new buffers
then special handling is required for decoder
output buffers which are used for reference by
video hardware.If any buffers are used by video
hardware as reference buffers then firmware returns
those buffers with READ_ONLY flag and they are kept
in read_only list and when read_only grows beyond
some limit then driver would ask firmware to release
those READ_ONLY buffers and when firmware responds
driver would delete these READ_ONLY buffers.

Change-Id: I8a0b11c986dd0b9464895498efd8c1831a754198
Signed-off-by: Darshana Patil <quic_darshana@quicinc.com>

driver/vidc/inc/venus_hfi_response.h

@@ -19,5 +19,7 @@ bool is_valid_hfi_buffer_type(struct msm_vidc_inst *inst,
 int handle_system_error(struct msm_vidc_core *core,
 	struct hfi_packet *pkt);
 void fw_coredump(struct msm_vidc_core *core);
+int handle_release_output_buffer(struct msm_vidc_inst *inst,
+	struct hfi_buffer *buffer);
 
 #endif // __VENUS_HFI_RESPONSE_H__