On Thu, Sep 20, 2018 at 12:53 AM Nicolas Dufresne <nicolas@xxxxxxxxxxxx> wrote: > > Le mercredi 19 septembre 2018 à 18:02 +0300, Stanimir Varbanov a > écrit : > > > --- a/drivers/media/platform/qcom/venus/vdec.c > > > +++ b/drivers/media/platform/qcom/venus/vdec.c > > > @@ -943,8 +943,7 @@ static void vdec_buf_done(struct venus_inst > > > *inst, > > > unsigned int buf_type, > > > unsigned int opb_sz = > > > venus_helper_get_opb_size(inst); > > > > > > vb = &vbuf->vb2_buf; > > > - vb->planes[0].bytesused = > > > - max_t(unsigned int, opb_sz, bytesused); > > > + vb2_set_plane_payload(vb, 0, bytesused ? : > > > opb_sz); > > > vb->planes[0].data_offset = data_offset; > > > vb->timestamp = timestamp_us * NSEC_PER_USEC; > > > vbuf->sequence = inst->sequence_cap++; > > > > > > It works fine for me, and should not return 0 more often than it > > > did > > > before (i.e. never). In practice I also never see the firmware > > > reporting a payload of zero on SDM845, but maybe older chips > > > differ? > > > > yes, it looks fine. Let me test it with older versions. > > What about removing the allow_zero_bytesused flag on this specific > queue ? Then you can leave it to 0, and the framework will change it to > the buffer size. First of all, why we would ever have 0 in bytesused? That should never happen normally in the middle of decoding and if it happens, then perhaps such buffer should be returned by the driver with ERROR state or maybe just silently reused for further decoding. The only cases where the value of 0 could happen could be EOS or end of the drain sequence (explicit by STOP command or by resolution change). In both cases, having 0 bytesused returned from the driver to vb2 is perfectly fine, because such buffer would have the V4L2_BUF_FLAG_LAST flag set anyway. Best regards, Tomasz
