public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: 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 19:33:34 +0100	[thread overview]
Message-ID: <20181129183334.GB30281@lst.de> (raw)
In-Reply-To: <CAKMK7uECLeTbEjG6=unWZSKakpiYkmBVbCEKKY2xv=vVjF-pBQ@mail.gmail.com>

On Thu, Nov 29, 2018 at 06:09:05PM +0100, Daniel Vetter wrote:
> What kind of abuse do you expect? It could very well be that gpu folks
> call that "standard use case" ... At least on x86 with the i915 driver
> we pretty much rely on architectural guarantees for how cache flushes
> work very much. Down to userspace doing the cache flushing for
> mappings the kernel has set up.

Mostly the usual bypasses of the DMA API because people know better
(and with that I don't mean low-level IOMMU API users, but "creative"
direct mappings).

> > 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 think this is what's often done. Except then there's also the issue
> of how to get at the cma allocator if your device needs something
> contiguous. There's a lot of that still going on in graphics/media.

Being able to dip into CMA and mayb iommu coalescing if we want to
get fancy is indeed the only reason for this API.  If we just wanted
to map pages we could already do that now with just a little bit
of boilerplate code (and quite a few drivers do - just adding this
new API will remove tons of code).

  parent reply	other threads:[~2018-11-29 18:33 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
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 [this message]
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=20181129183334.GB30281@lst.de \
    --to=hch@lst.de \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --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