IMX Scaler / CSC m2m driver.

[Ian Molton]

On 25/03/15 11:36, Nicolas Dufresne wrote:

> The thread name does not mean this element is doing the copy. The thread
> name simply say which element is running a streaming thread.

I'm not sure I follow that.

> The remaining copy happens in ximagesink, because we need to copy to
> shared X11 server memory. Unless your converter driver can do
> capture-io-mode=userptr,

Hm. have I got this the wrong way around? does this mean "capture-to-userspace".

ie. this would refer to data coming /from/ v4l2videoconvert to userspace?

I had been thinking in terms of the element "capturing" from the previous
element in the chain, kind of the opposite meaning.

> there is nothing GStreamer can do about this
> copy. It's X11 design that you get X11 to allocate the memory (even
> though it's often normal vmalloc memory, and that the server often need
> to copy again).

Attempting to use capture-io-mode=userptr on the v4l2videoconvert element
resulted in a kernel oops due to circular locking.

commenting out

//      dst_vq->lock = &ctx->ipu_scaler->dev_mutex;

in drivers/media/platform/imx/imx-ipu-scaler.c

prevents the oops, but doesn't help much - gstreamer sits there with a blank
output window. The problem seems to be:

On one CPU:
mm->mmap_sem is locked in vm_mmap_pgoff() followed by [what ammounts to]
dst_vq->lock in v4l2_m2m_fop_mmap().

On the other:

v4l2_ioctl() takes dst_vq->lock, and later, __buf_prepare() takes mm->mm_sem.

But I'm unclear on how to solve this. My gut feeling is that __buf_prepare()
is wrong somehow.

> Nicolas
>
> p.s. perf have this -g option, that let you see a callgraph

Thanks - I've just tried this. How on earth is it meant to be interpreted?
It looks like the total % of events is in the several-hundreds, if not
thousands...

-Ian