public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Olbrich <m.olbrich@pengutronix.de>
To: linux-kernel@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf
Date: Mon, 18 Jul 2016 10:01:39 +0200	[thread overview]
Message-ID: <20160718080139.GA22269@pengutronix.de> (raw)
In-Reply-To: <1468599966-31988-1-git-send-email-javier@osg.samsung.com>

Hi,

On Fri, Jul 15, 2016 at 12:26:06PM -0400, Javier Martinez Canillas wrote:
> The buffer planes' dma-buf are currently mapped when buffers are queued
> from userspace but it's more appropriate to do the mapping when buffers
> are queued in the driver since that's when the actual DMA operation are
> going to happen.
> 
> Suggested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> 
> ---
> 
> Hello,
> 
> A side effect of this change is that if the dmabuf map fails for some
> reasons (i.e: a driver using the DMA contig memory allocator but CMA
> not being enabled), the fail will no longer happen on VIDIOC_QBUF but
> later (i.e: in VIDIOC_STREAMON).
> 
> I don't know if that's an issue though but I think is worth mentioning.

And for mem2mem devices? Does this mean that the second VIDIOC_STREAMON
will fail? That would make it impossible detect if the buffers on the
capture or the output side are incorrect.

It's already quite difficult to handle these issues gracefully and without
loosing any data. This would make it even worse.

Regards,
Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  parent reply	other threads:[~2016-07-18  8:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-15 16:26 [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf Javier Martinez Canillas
2016-07-15 19:42 ` Shuah Khan
2016-07-15 21:50   ` Javier Martinez Canillas
2016-07-16 12:15 ` Luis de Bethencourt
2016-07-18  8:01 ` Michael Olbrich [this message]
2016-07-18  8:34 ` Hans Verkuil
2016-07-18 13:30   ` Nicolas Dufresne
2016-07-18 14:15   ` Javier Martinez Canillas
2016-09-06 18:27   ` Nicolas Dufresne
2016-07-18 10:27 ` Marek Szyprowski
2016-09-06 18:31   ` Nicolas Dufresne
2016-07-20 13:20 ` Sakari Ailus
2016-07-20 14:06   ` Javier Martinez Canillas
2016-07-20 14:12     ` Hans Verkuil
2016-07-20 14:19       ` Javier Martinez Canillas
2016-09-06 18:34   ` Nicolas Dufresne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160718080139.GA22269@pengutronix.de \
    --to=m.olbrich@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox