Hi Dave,
some questions.
On Mon, 2020-05-04 at 12:25 +0300, Laurent Pinchart wrote:
> From: Dave Stevenson <dave.stevenson@xxxxxxxxxxxxxxx>
>
> 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@xxxxxxxxxxxxxxx>
>
> 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@xxxxxxxxxxxxxxx>
> Signed-off-by: Jacopo Mondi <jacopo@xxxxxxxxxx>
> ---
[...]
> @@ -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
Attachment:
signature.asc
Description: This is a digitally signed message part
