Re: vb2: various cleanups and improvements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Hans,

Thank you for the patches.

For patches 1, 2, 4, 7 and 10,

Acked-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>

On Thursday 05 December 2013 09:21:39 Hans Verkuil wrote:
> This patch series does some cleanups in the qbuf/prepare_buf handling
> (the first two patches). The third patch removes the 'fileio = NULL'
> hack. That hack no longer works when dealing with asynchronous calls
> from a kernel thread so it had to be fixed.
> 
> The next three patches implement retrying start_streaming() if there are
> not enough buffers queued for the DMA engine to start. I know that there
> are more drivers that can be simplified with this feature available in
> the core. Those drivers do the retry of start_streaming in the buf_queue
> op which frankly defeats the purpose of having a central start_streaming
> op. But I leave it to the driver developers to decide whether or not to
> cleanup their drivers.
> 
> The big advantage is that apps can just call STREAMON first, then start
> queuing buffers without having to know the minimum number of buffers that
> have to be queued before the DMA engine will kick in. It always annoyed
> me that vb2 didn't take care of that for me as it is easy enough to do.
> 
> The next two patches add vb2 thread support which is necessary
> for both videobuf2-dvb (the vb2 replacement of videobuf-dvb) and for e.g.
> alsa drivers where you use the same trick as with dvb.
> 
> The thread implementation has been tested with both alsa recording and
> playback for an internal driver (sorry, I can't share the source yet).
> 
> The next patch adds a fix based on a patch from Andy that removes the
> file I/O emulation assumption that buffers are dequeued in the same
> order that they were enqueued.
> 
> The final patch fixes another race condition between QBUF/PREPARE_BUF
> and REQBUFS in the USERPTR case, also caused by the fact that __prepare_buf
> temporarily unlocks the queue lock. The race was found by Laurent.
> 
> Regards,
> 
>         Hans
> 
> New in v3:
> 
> - Added a comment to the thread_start function making it explicit that
>   it is for use with videobuf2-dvb only.
> - Added patch 10/10 to address yet another race condition.
> 
> New in v2:
> 
> - Added a PREPARING state in patch 1 to prevent a race condition that
> Laurent mentioned (two QBUF calls with the same index number at the same
> time). - Changed some minor issues in patch 4 that Laurent mentioned in his
> review. - Added the reworked version of Andy's original patch to remove the
> order assumption in the file I/O emulation.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux