linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Marek Szyprowski <m.szyprowski@samsung.com>, linux-media@vger.kernel.org
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH v2] media: videobuf2-dc: set properly dma_max_segment_size
Date: Thu, 13 Aug 2015 14:40:46 +0200	[thread overview]
Message-ID: <55CC904E.4040907@metafoo.de> (raw)
In-Reply-To: <1439373533-23299-1-git-send-email-m.szyprowski@samsung.com>

On 08/12/2015 11:58 AM, Marek Szyprowski wrote:
> If device has no DMA max_seg_size set, we assume that there is no limit
> and it is safe to force it to use DMA_BIT_MASK(32) as max_seg_size to
> let DMA-mapping API always create contiguous mappings in DMA address
> space. This is essential for all devices, which use dma-contig
> videobuf2 memory allocator.
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> Changelog:
> v2:
> - set max segment size only if a new dma params structure has been
>   allocated, as suggested by Laurent Pinchart
> ---
>  drivers/media/v4l2-core/videobuf2-dma-contig.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> index 94c1e64..455e925 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> @@ -862,6 +862,21 @@ EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
>  void *vb2_dma_contig_init_ctx(struct device *dev)
>  {
>  	struct vb2_dc_conf *conf;
> +	int err;
> +
> +	/*
> +	 * if device has no max_seg_size set, we assume that there is no limit
> +	 * and force it to DMA_BIT_MASK(32) to always use contiguous mappings
> +	 * in DMA address space
> +	 */
> +	if (!dev->dma_parms) {
> +		dev->dma_parms = kzalloc(sizeof(*dev->dma_parms), GFP_KERNEL);
> +		if (!dev->dma_parms)
> +			return ERR_PTR(-ENOMEM);
> +		err = dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
> +		if (err)
> +			return ERR_PTR(err);
> +	}

I'm not sure if this is such a good idea. The DMA provider is responsible
for setting this up. We shouldn't be overwriting this here on the DMA
consumer side. This will just mask the bug that the provider didn't setup
this correctly and might cause bugs on its own if it is not correct. It will
lead to conflicts with DMA providers that have multiple consumers (e.g.
shared DMA core). And also the current assumption is that if a driver
doesn't set this up explicitly the maximum segement size is 65536.

>  
>  	conf = kzalloc(sizeof *conf, GFP_KERNEL);
>  	if (!conf)
> 


  reply	other threads:[~2015-08-13 12:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-12  9:58 [PATCH v2] media: videobuf2-dc: set properly dma_max_segment_size Marek Szyprowski
2015-08-13 12:40 ` Lars-Peter Clausen [this message]
2015-08-13 13:49   ` Marek Szyprowski
2015-08-13 14:22     ` Shuah Khan
2015-08-13 14:53     ` Lars-Peter Clausen
2015-10-13  0:36       ` Laurent Pinchart

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=55CC904E.4040907@metafoo.de \
    --to=lars@metafoo.de \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    /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;
as well as URLs for NNTP newsgroup(s).