Hi Dave,
some questions.

On Mon, 2020-05-04 at 12:25 +0300, Laurent Pinchart wrote:
> From: Dave Stevenson <dave.stevenson@raspberrypi.org>
> 
> With the vc-sm-cma driver we can support zero copy of buffers between
> the kernel and VPU. Add this support to vchiq-mmal.
> 
> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
> 
> staging: vc-sm-cma: Use a void* pointer as the handle within the kernel
> 
> The driver was using an unsigned int as the handle to the outside world,
> and doing a nasty cast to the struct dmabuf when handed it back.
> This breaks badly with a 64 bit kernel where the pointer doesn't fit
> in an unsigned int.
> 
> Switch to using a void* within the kernel. Reality is that it is
> a struct dma_buf*, but advertising it as such to other drivers seems
> to encourage the use of it as such, and I'm not sure on the implications
> of that.
> 
> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> ---

[...]

> @@ -419,8 +422,13 @@ buffer_from_host(struct vchiq_mmal_instance *instance,
>  
>  	/* buffer header */
>  	m.u.buffer_from_host.buffer_header.cmd = 0;
> -	m.u.buffer_from_host.buffer_header.data =
> -		(u32)(unsigned long)buf->buffer;
> +	if (port->zero_copy) {
> +		m.u.buffer_from_host.buffer_header.data = buf->vc_handle;
> +	} else {
> +		m.u.buffer_from_host.buffer_header.data =
> +			(u32)(unsigned long)buf->buffer;
> +	}

Just for my education, where exactly does the copying happen, IIUC this headers
are copied into a vchiq slot and then it's up to vc4 to do whatever it pleases
with the buffer. Also, what happens while importing a dmabuf on vc4's side and
why is the buffer import needed before queueing this?

Regards,
Nicolas