Hi Vikash, On 05/04/2018 02:09 PM, Vikash Garodia wrote: > Hi Stanimir, > > On 2018-05-03 17:06, Stanimir Varbanov wrote: >> Hi Vikash, >> >> Thanks for the comments! >> >> On 2.05.2018 09:26, Vikash Garodia wrote: >>> Hello Stanimir, >>> >>> On 2018-04-24 18:14, Stanimir Varbanov wrote: >>>> Call session_continue for Venus 4xx version even when the event >>>> says that the buffer resources are not sufficient. Leaving a >>>> comment with more information about the workaround. >>>> >>>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@xxxxxxxxxx> >>>> --- >>>> drivers/media/platform/qcom/venus/vdec.c | 8 ++++++++ >>>> 1 file changed, 8 insertions(+) >>>> >>>> diff --git a/drivers/media/platform/qcom/venus/vdec.c >>>> b/drivers/media/platform/qcom/venus/vdec.c >>>> index c45452634e7e..91c7384ff9c8 100644 >>>> --- a/drivers/media/platform/qcom/venus/vdec.c >>>> +++ b/drivers/media/platform/qcom/venus/vdec.c >>>> @@ -873,6 +873,14 @@ static void vdec_event_notify(struct venus_inst >>>> *inst, u32 event, >>>> >>>> dev_dbg(dev, "event not sufficient resources (%ux%u)\n", >>>> data->width, data->height); >>>> + /* >>>> + * Workaround: Even that the firmware send and event for >>>> + * insufficient buffer resources it is safe to call >>>> + * session_continue because actually the event says that >>>> + * the number of capture buffers is lower. >>>> + */ >>>> + if (IS_V4(core)) >>>> + hfi_session_continue(inst); >>>> break; >>>> case HFI_EVENT_RELEASE_BUFFER_REFERENCE: >>>> venus_helper_release_buf_ref(inst, data->tag); >>> >>> Insufficient event from video firmware could be sent either, >>> 1. due to insufficient buffer resources >>> 2. due to lower capture buffers >>> >>> It cannot be assumed that the event received by the host is due to >>> lower capture >>> buffers. Incase the buffer resource is insufficient, let say there is >>> a bitstream >>> resolution switch from 720p to 1080p, capture buffers needs to be >>> reallocated. >> >> I agree with you. I will rework this part and call session_continue >> only for case #2. > > Even if the capture buffers are lower, driver should consider > reallocation of capture > buffers with required higher count. Without this, it may happen that for > a given video > frame, the decoded output will not be generated. Thanks for the comments, I realized that this workaround is not needed anymore, so I will drop the patch. -- regards, Stan -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
