From: Christoph Hellwig <hch@lst.de>
To: Christoph Hellwig <hch@lst.de>,
"Clark, Rob" <robdclark@gmail.com>,
Dave Airlie <airlied@linux.ie>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Tomasz Figa <tfiga@chromium.org>,
Sean Paul <seanpaul@chromium.org>,
vivek.gautam@codeaurora.org,
freedreno <freedreno@lists.freedesktop.org>,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v3 1/1] drm: msm: Replace dma_map_sg with dma_sync_sg*
Date: Thu, 29 Nov 2018 17:57:15 +0100 [thread overview]
Message-ID: <20181129165715.GA27786@lst.de> (raw)
In-Reply-To: <20181129162807.GL21184@phenom.ffwll.local>
On Thu, Nov 29, 2018 at 05:28:07PM +0100, Daniel Vetter wrote:
> Just spend a bit of time reading through the implementations already
> merged. Is the struct device *dev parameter actually needed anywhere?
> dma-api definitely needs it, because we need that to pick the right iommu.
> But for cache management from what I've seen the target device doesn't
> matter, all the target specific stuff will be handled by the iommu.
It looks like only mips every uses the dev argument, and even there
the function it passes dev to ignores it. So it could probably be removed.
>
> Dropping the dev parameter would make this a perfect fit for coherency
> management of buffers used by multiple devices. Right now there's all
> kinds of nasty tricks for that use cases needed to avoid redundant
> flushes.
Note that one thing I'd like to avoid is exposing these funtions directly
to drivers, as that will get us into all kinds of abuses.
So I'd much prefer if we could have iommu APIs wrapping these that are
specific to actual uses cases that we understand well.
As for the buffer sharing: at least for the DMA API side I want to
move the current buffer sharing users away from dma_alloc_coherent
(and coherent dma_alloc_attrs users) and the remapping done in there
required for non-coherent architectures. Instead I'd like to allocate
plain old pages, and then just dma map them for each device separately,
with DMA_ATTR_SKIP_CPU_SYNC passed for all but the first user to map
or last user to unmap. On the iommu side it could probably work
similar.
I have done some preliminary work on this, and want to get it into this
merge window, but there is a few other bits I need to sort out first.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
---end quoted text---
next prev parent reply other threads:[~2018-11-29 16:57 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-29 14:03 [PATCH v3 1/1] drm: msm: Replace dma_map_sg with dma_sync_sg* Vivek Gautam
2018-11-29 14:14 ` Christoph Hellwig
2018-11-29 14:25 ` Rob Clark
2018-11-29 14:42 ` Rob Clark
2018-11-29 15:54 ` Christoph Hellwig
2018-11-29 18:48 ` Rob Clark
2018-11-29 19:40 ` Jordan Crouse
2018-11-29 19:57 ` Tomasz Figa
2018-11-29 20:03 ` Robin Murphy
2018-11-30 0:23 ` Tomasz Figa
2018-12-01 2:05 ` Tomasz Figa
2018-12-01 11:46 ` Rob Clark
2018-12-03 0:12 ` Tomasz Figa
2018-11-29 14:43 ` Daniel Vetter
2018-11-29 15:57 ` Christoph Hellwig
2018-11-29 16:28 ` Daniel Vetter
2018-11-29 16:57 ` Christoph Hellwig [this message]
2018-11-29 17:09 ` Daniel Vetter
2018-11-29 17:24 ` Tomasz Figa
2018-11-29 18:35 ` Christoph Hellwig
2018-11-29 18:57 ` Rob Clark
2018-11-30 9:40 ` Daniel Vetter
2018-11-30 9:35 ` Daniel Vetter
2018-11-30 9:44 ` Christoph Hellwig
2018-11-29 18:33 ` Christoph Hellwig
2018-11-30 9:46 ` Daniel Vetter
2018-12-07 1:38 ` Christoph Hellwig
2018-12-07 14:29 ` Rob Clark
2018-11-29 17:33 ` Brian Starkey
2018-11-29 18:35 ` Christoph Hellwig
2018-11-30 1:15 ` Rob Clark
2018-11-30 9:35 ` Christoph Hellwig
2018-11-29 15:53 ` Christoph Hellwig
2018-11-29 18:44 ` Rob Clark
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=20181129165715.GA27786@lst.de \
--to=hch@lst.de \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robdclark@gmail.com \
--cc=robin.murphy@arm.com \
--cc=seanpaul@chromium.org \
--cc=tfiga@chromium.org \
--cc=vivek.gautam@codeaurora.org \
/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