From: Christoph Hellwig <hch@lst.de>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Thierry Escande <thierry.escande@collabora.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Sakari Ailus <sakari.ailus@iki.fi>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
Pawel Osciak <pawel@osciak.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Christoph Hellwig <hch@lst.de>, Hans Verkuil <hverkuil@xs4all.nl>,
Shuah Khan <shuahkh@osg.samsung.com>,
Russell King <rmk+kernel@arm.linux.org.uk>
Subject: Re: [PATCH v3 0/2] [media] videobuf2-dc: Add support for cacheable MMAP
Date: Wed, 5 Jul 2017 19:33:27 +0200 [thread overview]
Message-ID: <20170705173327.GD5417@lst.de> (raw)
In-Reply-To: <f829886e-4842-a500-6b10-9a46e1b763f5@samsung.com>
On Mon, Jul 03, 2017 at 11:27:32AM +0200, Marek Szyprowski wrote:
> The main question here if we want to merge incomplete solution or not. As
> for now, there is no support in ARM/ARM64 for NON_CONSISTENT attribute.
> Also none of the v4l2 drivers use it. Sadly support for NON_CONSISTENT
> attribute is not fully implemented nor even defined in mainline.
>
DMA_ATTR_NON_CONSISTENT is the way to get the dma_alloc_noncoherent
semantics through the dma_alloc_attr API, and as such I think it is
pretty well defined, although the documentation in
Documentation/DMA-attributes.txt is really bad and we need to improve
it, by merging it with the dma_alloc_noncoherent description in
Documentation/DMA-API.txt. My series to remove dma_alloc_noncoherent
updates the latter to mention DMA_ATTR_NON_CONSISTENT, but
we should probably merge Documentation/DMA-API.txt,
Documentation/DMA-attributes.txt and Documentation/DMA-API-HOWTO.txt
into a single coherent document.
> I know that it works fine for some vendor kernel trees, but supporting it in
> mainline was a bit controversial. There is no proper way to sync cache for
> such
> buffers. Calling dma_sync_sg worked so far, but it has to be first agreed as
> a proper DMA API.
As documented in Documentation/DMA-API.txt the proper way to sync
noncoherent/nonconsistent regions is to call dma_cache_sync. It seems
like it generally is the same as dma_sync_range/sg so if we could
eventually merge these APIs that should reduce the confusion further.
next prev parent reply other threads:[~2017-07-05 17:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20161026085228epcas3p3895ea279d5538750a3b1c59715ad3761@epcas3p3.samsung.com>
2016-10-26 8:52 ` [PATCH v3 0/2] [media] videobuf2-dc: Add support for cacheable MMAP Thierry Escande
2016-10-26 8:52 ` [PATCH v3 1/2] [media] videobuf2-dc: Move vb2_dc_get_base_sgt() above mmap callbacks Thierry Escande
2016-10-26 8:52 ` [PATCH v3 2/2] [media] videobuf2-dc: Support cacheable MMAP Thierry Escande
2018-09-17 14:41 ` Hans Verkuil
2018-09-18 9:41 ` Tomasz Figa
2017-07-03 9:27 ` [PATCH v3 0/2] [media] videobuf2-dc: Add support for " Marek Szyprowski
2017-07-05 17:33 ` Christoph Hellwig [this message]
2017-07-13 11:13 ` Marek Szyprowski
2017-07-13 13:21 ` Russell King - ARM Linux
2017-07-13 13:36 ` Christoph Hellwig
2017-07-13 13:36 ` Christoph Hellwig
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=20170705173327.GD5417@lst.de \
--to=hch@lst.de \
--cc=hverkuil@xs4all.nl \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mchehab@kernel.org \
--cc=pawel@osciak.com \
--cc=rmk+kernel@arm.linux.org.uk \
--cc=sakari.ailus@iki.fi \
--cc=shuahkh@osg.samsung.com \
--cc=thierry.escande@collabora.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.