All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH] media: videobuf2-dc: set properly dma_max_segment_size
Date: Wed, 03 Jun 2015 04:15 +0300	[thread overview]
Message-ID: <2701486.3yXLn3ebOa@avalon> (raw)
In-Reply-To: <1433160857-11124-1-git-send-email-m.szyprowski@samsung.com>

Hi Marek,

Thank you for the patch.

On Monday 01 June 2015 14:14:17 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>
> ---
>  drivers/media/v4l2-core/videobuf2-dma-contig.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> b/drivers/media/v4l2-core/videobuf2-dma-contig.c index
> 644dec73d220..9d7c1814b0f3 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> @@ -862,6 +862,23 @@ 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);

I was checking how dma_parms was usually allocated and freed, and was shocked 
to find that the memory is never freed. OK, actually not shocked, I had a bad 
feeling about it already, but it's still not good :-/

This goes beyond the scope of this patch, but I think we need to clean up 
dma_parms. The structure is 8 bytes long on 32-bit systems and 16 bytes long 
on 64-bit systems. I wonder if it's really worth it to allocate it separately 
from struct device. It might if we moved more DMA-related fields to struct 
device_dma_parameters but that hasn't happened since 2008 when the structure 
was introduced (yes that's more than 7 years ago).

If we consider it's worth it (and I believe Josh Triplett might, in the 
context of the Linux kernel tinification project), we should at least handle 
allocation and free of the field coherently across drivers.

> +		if (!dev->dma_parms)
> +			return ERR_PTR(-ENOMEM);
> +	}
> +	if (dma_get_max_seg_size(dev) < DMA_BIT_MASK(32)) {
> +		err = dma_set_max_seg_size(dev, DMA_BIT_MASK(32));

What if the device has set a maximum segment size smaller than 4GB because of 
hardware limitations ?

I also wonder whether this is the correct place to solve the issue. Why is the 
default value returned by dma_get_max_seg_size() set to 64kB ?

> +		if (err)
> +			return ERR_PTR(err);
> +	}
> 
>  	conf = kzalloc(sizeof *conf, GFP_KERNEL);
>  	if (!conf)

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2015-06-03  1:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-01 12:14 [PATCH] media: videobuf2-dc: set properly dma_max_segment_size Marek Szyprowski
2015-06-03  1:15 ` Laurent Pinchart [this message]
2015-06-03  1:22 ` Laurent Pinchart
2015-06-03 11:06   ` Marek Szyprowski

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=2701486.3yXLn3ebOa@avalon \
    --to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.