Linux IOMMU Development
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@iki.fi>
To: Tim Nordell <tim.nordell@logicpd.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	linux-media@vger.kernel.org, iommu@lists.linux-foundation.org
Subject: Re: [PATCH v2 25/26] omap3isp: Move to videobuf2
Date: Wed, 18 Mar 2015 23:44:25 +0200	[thread overview]
Message-ID: <20150318214425.GL11954@valkosipuli.retiisi.org.uk> (raw)
In-Reply-To: <5509E6DF.4080900@logicpd.com>

Hi Tim,

On Wed, Mar 18, 2015 at 03:58:07PM -0500, Tim Nordell wrote:
> Laurent -
> 
> On 03/18/15 14:49, Tim Nordell wrote:
> >Digging through to find who is responsible for assigning the virtual
> >addresses, I find that it's buried inside
> >arch/arm/mm/dma-mapping.c:__alloc_iova(...).  This call is called
> >individually for each entry in the scatter-gather table via
> >__map_sg_chunk from iommu_map_sg(...).  If this is supposed to allocate
> >a contiguous virtual memory region, it seems that __iommu_map_sg(...)
> >should be considering the full buffer range rather than parts of the
> >buffer at a time for the virtual allocation, similar to how
> >__iommu_create_mapping(...) works in the same file.
> >
> >- Tim
> >
> 
> I've confirmed that this code is the culprit for allocating a
> non-contiguous space (called via the dma_map_sg_attrs(...) back down
> in the videobuf2-dma-contig).  I've reworked it for testing so that
> it does an __alloc_iova(...) on the entire region rather than a
> chunk at a time, however, I don't think what I have locally is
> completely the right approach for the generic case since I think
> technically a given entry in the scatterlist could end up with the
> end of a page partially used (the per list entry ->offset and such).
> 
> Looks like code (the specific functions in mm/dma-mapping.c) in
> question was last touched in 2012 with a quick git-blame, but I
> don't know how long the OMAP 3 ISP code has been using this common
> code.  I'm guessing it's only been since the virtual memory manager
> internal to the IOMMU code was removed in July of last year.

I don't think omap3isp has been using this very long. A few minor versions
perhaps.

> Do you know if this common code is supposed to guarantee a
> physically contiguous memory region?  The documentation for the
> function doesn't indicate that it should, and it certainly doesn't
> as-is.  It seems like hitting this issue is highly dependent on the
> size of the buffer one is allocating.

I guess there aren't too many drivers that may map large areas of memory
pinned using get_user_pages() to IOMMU. If dma_map_sg() couldn't be used to
allocate virtually contiguous memory, then what could be? This looks like a
bug in __iommu_map_sg() to me.

Cc the iommu list.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

       reply	other threads:[~2015-03-18 21:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1398083352-8451-1-git-send-email-laurent.pinchart@ideasonboard.com>
     [not found] ` <2315546.eR07gyadH5@avalon>
     [not found]   ` <55099773.2010809@logicpd.com>
     [not found]     ` <2250003.9yO29CjKoc@avalon>
     [not found]       ` <5509D6BC.6080006@logicpd.com>
     [not found]         ` <5509E6DF.4080900@logicpd.com>
2015-03-18 21:44           ` Sakari Ailus [this message]
2015-03-18 22:43             ` [PATCH v2 25/26] omap3isp: Move to videobuf2 Tim Nordell

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=20150318214425.GL11954@valkosipuli.retiisi.org.uk \
    --to=sakari.ailus@iki.fi \
    --cc=iommu@lists.linux-foundation.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=tim.nordell@logicpd.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