On 12/04/2013 05:33 PM, Laurent Pinchart wrote: > Hi Hans, > > On Wednesday 04 December 2013 08:47:25 Hans Verkuil wrote: >> On 12/04/2013 02:17 AM, Laurent Pinchart wrote: >>> On Tuesday 03 December 2013 10:56:07 Hans Verkuil wrote: >>>> On 11/29/13 19:21, Laurent Pinchart wrote: >>>>> On Friday 29 November 2013 10:58:42 Hans Verkuil wrote: >>>>>> From: Hans Verkuil <hans.verkuil@xxxxxxxxx> >>>>>> >>>>>> In order to implement vb2 DVB or ALSA support you need to be able to >>>>>> start a kernel thread that queues and dequeues buffers, calling a >>>>>> callback function for every captured/displayed buffer. This patch adds >>>>>> support for that. >>>>>> >>>>>> It's based on drivers/media/v4l2-core/videobuf-dvb.c, but with all the >>>>>> DVB specific stuff stripped out, thus making it much more generic. >>>>> >>>>> Do you see any use for this outside of videobuf2-dvb ? If not I wonder >>>>> whether the code shouldn't be moved there. The sync objects framework >>>>> being developed for KMS will in my opinion cover the other use cases, >>>>> and >>>>> I'd like to discourage non-DVB drivers to use vb2 threads in the >>>>> meantime. >>>> >>>> I'm using it for ALSA drivers which, at least in my case, require almost >>>> identical functionality as that needed by DVB. >>> >>> You're using videobuf2 for audio ? >> >> For this particular board the audio DMA is just another DMA channel. >> Handling audio DMA is identical to video DMA. Why reinvent the wheel? > > videobuf2 is more about buffer management than DMA management. As the code is > based around a two-dimensional, possibly multiplanar, buffer it's quite > hackish to reuse it for audio. I disagree with that. vb2 has all the right hooks to start/stop DMA and queue/dequeue buffers. It's used for VBI as well and can just as easily support meta data. For this particular board there is no difference between audio and video DMA. > Doesn't ALSA offer a buffer management library? Yes it does. But due to the peculiarities of the particular board it wasn't sufficient. Specifically I must copy the audio data from the alsa buffers to vb2 buffers since the layout of the data differs. As mentioned I will also work on a different board where the audio DMA is much more standard (i.e. the same buffer layout can be used), and I want to investigate if using vb2 in that case makes sense or not. > >> The board I developed this for has somewhat peculiar audio handling (sorry, >> it's an internal product and I can't go into details), but I'll do the same >> exercise for another board that I can open source and there audio handling >> is standard. I want to see if I can use that to develop a videobuf2-alsa.c >> module that takes care of most of the alsa complexity. I don't know yet how >> that will work out, I'll have to experiment a bit. >> >>>> But regardless of that, I really don't like the way it was done in the >>>> old videobuf framework, mixing low-level videobuf calls/data structure >>>> accesses with DVB code. That should be separate. >>>> >>>> The vb2 core framework should provide the low-level functionality that is >>>> needed by the videobuf2-dvb to build on. >>> >>> Right, but I want to make sure that drivers will not start using this >>> directly. >> >> What sort of use-cases were you thinking of, other than DVB and ALSA? I >> don't off-hand see one. > > That's the thing, I don't see any valid use case, I just want to make sure we > won't get crazy use cases implemented with vb2 threads in the future :-) > >>> It should be an internal videobuf2 API. >> >> I happily add comments to the source and header mentioning that it is for >> core use only and that for any other uses the mailinglist should be >> contacted, but I really don't want to mix core vb2 code with DVB code. That >> should remain separate. > > OK, that sounds good with me. > > What about moving thread support to videobuf2-thread.c ? I tried that originally, but in order to do that I had to make a number of low-level vb2 functions extern instead of static, and that was quite messy. So I decided against that. It's not that much code (106 lines), after all. That said, it might be interesting at some point to split off the fileio and thread handling into a separate file. Regards, Hans -- 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
