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
next parent 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