On Thu, Oct 18, 2018 at 7:03 PM Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote: > > Hi Laurent, > > On Wed, Oct 17, 2018 at 10:34 PM Laurent Pinchart > <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > > > > Hi Tomasz, > > > > Thank you for the patch. > > Thanks for your comments! Please see my replies inline. > > > > > On Tuesday, 24 July 2018 17:06:20 EEST Tomasz Figa wrote: [snip] > > > +4. At this point, decoding is paused and the driver will accept, but not > > > + process any newly queued ``OUTPUT`` buffers until the client issues > > > + ``V4L2_DEC_CMD_START`` or restarts streaming on any queue. > > > + > > > +* Once the drain sequence is initiated, the client needs to drive it to > > > + completion, as described by the above steps, unless it aborts the process > > > + by issuing :c:func:`VIDIOC_STREAMOFF` on ``OUTPUT`` queue. The client > > > + is not allowed to issue ``V4L2_DEC_CMD_START`` or ``V4L2_DEC_CMD_STOP`` > > > + again while the drain sequence is in progress and they will fail with > > > + -EBUSY error code if attempted. > > > > While this seems OK to me, I think drivers will need help to implement all the > > corner cases correctly without race conditions. > > We went through the possible list of corner cases and concluded that > there is no use in handling them, especially considering how much they > would complicate both the userspace and the drivers. Not even > mentioning some hardware, like s5p-mfc, which actually has a dedicated > flush operation, that needs to complete before the decoder can switch > back to normal mode. Actually I misread your comment. Agreed that the decoder commands are a bit tricky to implement properly. That's one of the reasons I decided to make the return -EBUSY while an existing drain is in progress. Do you have any particular simplification in mind that could avoid some corner cases? Best regards, Tomasz
