On 02/08/2016 11:23 AM, Andrey Utkin wrote: > On Mon, Feb 8, 2016 at 11:58 AM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >> Hi Andrey, >> >> Hmm, it looks like I forgot to reply. Sorry about that. > > Thank you very much anyway. > >> I wouldn't change the memcpy: in my experience it is very useful to get a >> well-formed compressed stream out of the hardware. And the overhead of >> having to do a memcpy is a small price to pay and on modern CPUs should >> be barely noticeable for SDTV inputs. > > So there's no usecase for scatter-gather approach, right? The only advantage scatter-gather would bring is more efficient memory usage: dma-contig requires physically contiguous memory, dma-sg doesn't. If you need a lot of contiguous memory you can run into out-of-memory situations. The alternative is to build a kernel with CMA enabled and reserve memory that way. dma-sg doesn't have these problems, so that can be a good alternative, but it comes at the price of higher complexity. > >> I don't believe that the lockups you see are related to the memcpy as >> such. The trace says that a cpu is stuck for 22s, no way that is related >> to something like that. It looks more like a deadlock somewhere. > > There was a locking issue (lack of _irqsave) and was fixed since then. > >> Regarding the compliance tests: don't pass VB2_USERPTR (doesn't work well >> with videobuf2-dma-contig). Also add vidioc_expbuf = vb2_ioctl_expbuf for >> the DMABUF support. That should clear up some of the errors you see. > > Thank you! > 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
