From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: linux-media@vger.kernel.org
Cc: Pawel Osciak <pawel@osciak.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>
Subject: [RFC] videobuf2-dma-contig broken for IOMMU + USERPTR buffers without struct page mapping
Date: Mon, 10 Mar 2014 14:27:13 +0100 [thread overview]
Message-ID: <8402247.KhzdAKyPLE@avalon> (raw)
Hello,
On some platforms (namely ARM) IOMMUs are handled transparently by the DMA
mapping implementation. This requires mapping and unmapping all USERPTR
buffers for DMA, regardless of whether they're backed by struct page or not.
videobuf2-dma-contig is broken in that regard, as it call dma_map_sg() and
dma_unmap_sg() only for buffers backed with struct page.
The page-less USERPTR dma-contig support was mostly intended (if I'm not
mistaken) to support "exporters" (in the dmabuf sense, but through mmap() on
the exporter side and USERPTR on the V4L2 side) that required large physically
contiguous buffers. Allocating such buffers required reserving memory at boot
time and resulted in no struct page mappings for that memory.
Now that CMA is available I believe that most (if not all) drivers have been
converted to CMA using the dma_alloc_* API. My original test case for page-
less USERPTR buffers with the OMAP3 ISP, capturing to mmap()ed fbdev memory,
now has the memory backed by struct page.
I wonder whether we should drop support for this broken feature altogether, or
fix it. A fix won't be easy, given that dma_map_sg() assumes that the memory
is backed by struct page at least on some platforms. On ARM, for instance, it
calls page_to_phys(sg_page()) on sglist entries.
Does anyone still have a test case for this features ?
--
Regards,
Laurent Pinchart
reply other threads:[~2014-03-10 13:25 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=8402247.KhzdAKyPLE@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=pawel@osciak.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