video: driver: fix buffer tracking logic at reverse path

fw sent FBD with RO and host didn't requeue same buffer again,
but firmware still holds RO reference. In that case, if stop
cmd issued at output port, firmware will FBD once again w/o
RO. So at that time wrong buffer will be picked from list, if
tracking is based on index.

To handle that special case, for decoder alone using device
addr & data_offset for identifying the node in reverse path.

Change-Id: I3d8cb0b4b100fd44be30e576ae602950650747a4
Signed-off-by: Govindaraj Rajagopal <[email protected]>

driver/vidc/src/venus_hfi_response.c

@@ -613,10 +613,14 @@ static int handle_output_buffer(struct msm_vidc_inst *inst,
 
 	found = false;
 	list_for_each_entry(buf, &buffers->list, list) {
-		if (buf->index == buffer->index) {
-			found = true;
+		if (is_decode_session(inst))
+			found = (buf->device_addr == buffer->base_address &&
+				buf->data_offset == buffer->data_offset);
+		else
+			found = (buf->index == buffer->index);
+
+		if (found)
 			break;
-		}
 	}
 	if (!found) {
 		i_vpr_e(inst, "%s: invalid idx %d daddr %#x data_offset %d\n",