Hello, On Monday, June 20, 2011 5:49 PM Jonathan Corbet wrote: > On Mon, 20 Jun 2011 07:30:11 +0200 > Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote: > > > Because of that I decided to call start_streaming first, before the > > __enqueue_in_driver() to ensure the drivers will get their methods > > called always in the same order, whatever used does. > > It still seems like the "wrong" order to me; it means that > start_streaming() can't actually start streaming. But, as has been > pointed out, the driver can't count on the buffers being there in any > case. This ordering does, at least, expose situations where the driver > author didn't think that buffers might not have been queued yet. > > (BTW, lest people think I'm complaining too much, let it be said that vb2 > is, indeed, a big improvement over its predecessor.) I'm aware of this issue and I definitely don't threat your comments as complaining. Right now there are just a few drivers that use vb2 so it is quite easy to fix or change some design ideas. I've thought a bit more about the current design and I must confess that in fact it is suboptimal. Probably during vb2 development I've focused too much on vivi and mem2mem devices which were used for testing the framework. Usually for mem2mem case streamon() operations don't touch DMA engines, so I've missed the point that DMA engine for typical capture or output device should be activated there with some buffers already queued. Now we also know that there are drivers that may need to start dma engine in buffer_queue and stop it in the isr (before buffer_done). Capturing a single frame with camera sensor (taking a picture) is one of such examples. I have an idea to introduce a new flags to let device driver tell vb2 weather it supports 'streaming without buffers' or not. This way the order of operations in vb2_streamon() function can be switched and vb2 can also return an error if one will try to enable streaming on device that cannot do it without buffers pre-queued. This way most of typical capture and output drivers will be happy. They will just use the 'overwrite last frame' technique to guarantee that there is at least one buffer for the dma engine all the time when streaming is enable. Mem2mem (and these special 'streaming without buffers' capable) drivers will just set these flags and continue enabling/disabling dma engine per-frame basis. I will try to post the patches soon. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- 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
