On Wed, Nov 14, 2018 at 3:54 AM Nicolas Dufresne <nico...@ndufresne.ca> wrote:
>
>
>
> Le mar. 13 nov. 2018 04 h 30, Alexandre Courbot <acour...@chromium.org> a
> écrit :
>>
>> The last buffer is often signaled by an empty buffer with the
>> V4L2_BUF_FLAG_LAST flag set. Such buffers were returned with the
>> bytesused field set to the full size of the OPB, which leads
>> user-space to believe that the buffer actually contains useful data. Fix
>> this by passing the number of bytes reported used by the firmware.
>
>
> That means the driver does not know on time which one is last. Why not just
> returned EPIPE to userspace on DQBUF and ovoid this useless roundtrip ?
Sorry, I don't understand what you mean. EPIPE is supposed to be
returned after a buffer with V4L2_BUF_FLAG_LAST is made available for
dequeue. This patch amends the code that prepares this LAST-flagged
buffer. How could we avoid a roundtrip in this case?
>
>>
>> Signed-off-by: Alexandre Courbot <acour...@chromium.org>
>> ---
>> drivers/media/platform/qcom/venus/vdec.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/venus/vdec.c
>> b/drivers/media/platform/qcom/venus/vdec.c
>> index 189ec975c6bb..282de21cf2e1 100644
>> --- a/drivers/media/platform/qcom/venus/vdec.c
>> +++ b/drivers/media/platform/qcom/venus/vdec.c
>> @@ -885,10 +885,8 @@ static void vdec_buf_done(struct venus_inst *inst,
>> unsigned int buf_type,
>> vbuf->field = V4L2_FIELD_NONE;
>>
>> if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
>> - unsigned int opb_sz = venus_helper_get_opb_size(inst);
>> -
>> vb = &vbuf->vb2_buf;
>> - vb2_set_plane_payload(vb, 0, bytesused ? : opb_sz);
>> + vb2_set_plane_payload(vb, 0, bytesused);
>> vb->planes[0].data_offset = data_offset;
>> vb->timestamp = timestamp_us * NSEC_PER_USEC;
>> vbuf->sequence = inst->sequence_cap++;
>> --
>> 2.19.1.930.g4563a0d9d0-goog
>>
