linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Jonathan Marek <jonathan@marek.ca>
Cc: Christoph Hellwig <hch@infradead.org>,
	freedreno@lists.freedesktop.org, Rob Clark <robdclark@gmail.com>,
	Sean Paul <sean@poorly.run>, David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel@ffwll.ch>,
	"open list:DRM DRIVER FOR MSM ADRENO GPU" 
	<linux-arm-msm@vger.kernel.org>,
	"open list:DRM DRIVER FOR MSM ADRENO GPU" 
	<dri-devel@lists.freedesktop.org>,
	open list <linux-kernel@vger.kernel.org>,
	iommu@lists.linux-foundation.org, Joerg Roedel <joro@8bytes.org>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
Date: Tue, 6 Oct 2020 08:23:06 +0100	[thread overview]
Message-ID: <20201006072306.GA12834@infradead.org> (raw)
In-Reply-To: <3e0b91be-e4a4-4ea5-7d58-6e71b8d51932@marek.ca>

On Mon, Oct 05, 2020 at 10:35:43AM -0400, Jonathan Marek wrote:
> The cache synchronization doesn't have anything to do with IOMMU (for
> example: cache synchronization would be useful in cases where drm/msm
> doesn't use IOMMU).

It has to do with doing DMA.  And we have two frameworks for doing DMA:
either the DMA API which is for general driver use, and which as part of
the design includes cache maintainance hidden behind the concept of
ownership transfers.  And we have the much more bare bones IOMMU API.

If people want to use the "raw" IOMMU API with not cache coherent
devices we'll need a cache maintainance API that goes along with it.
It could either be formally part of the IOMMU API or be separate.

> What is needed is to call arch_sync_dma_for_{cpu,device} (which is what I
> went with initially, but then decided to re-use drm/msm's
> sync_for_{cpu,device}). But you are also saying those functions aren't for
> driver use, and I doubt IOMMU maintainers will want to add wrappers for
> these functions just to satisfy this "not for driver use" requirement.

arch_sync_dma_for_{cpu,device} are low-level helpers (and not very
great ones at that).  The definitively should not be used by drivers.
They would be very useful buildblocks for a IOMMU cache maintainance
API.

Of course the best outcome would be if we could find a way for the MSM
drm driver to just use DMA API and not deal with the lower level
abstractions.  Do you remember why the driver went for use of the IOMMU
API?

  reply	other threads:[~2020-10-06  7:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01  0:27 [PATCH 0/3] drm/msm: support for host-cached BOs Jonathan Marek
2020-10-01  0:27 ` [PATCH 1/3] drm/msm: add MSM_BO_CACHED_COHERENT Jonathan Marek
2020-10-01 23:47   ` Jordan Crouse
2020-10-01  0:27 ` [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance Jonathan Marek
2020-10-01 23:29   ` [Freedreno] " Jordan Crouse
2020-10-02  7:53   ` Christoph Hellwig
2020-10-02 12:46     ` Jonathan Marek
2020-10-05  8:29       ` Christoph Hellwig
2020-10-05 14:35         ` Jonathan Marek
2020-10-06  7:23           ` Christoph Hellwig [this message]
2020-10-06 13:19             ` Jonathan Marek
2020-10-07  6:25               ` Christoph Hellwig
2020-10-13 13:42                 ` Robin Murphy
2020-10-13 16:11                   ` Rob Clark
2020-10-15  6:55                   ` Christoph Hellwig
2020-10-15 15:33                     ` Daniel Vetter
2020-10-15 15:43                       ` Christoph Hellwig
2020-10-23  6:48                         ` Christoph Hellwig
2020-10-08  8:27             ` Joerg Roedel
2020-10-01  0:27 ` [PATCH 3/3] drm/msm: bump up the uapi version Jonathan Marek

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=20201006072306.GA12834@infradead.org \
    --to=hch@infradead.org \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jonathan@marek.ca \
    --cc=joro@8bytes.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robdclark@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=sean@poorly.run \
    /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;
as well as URLs for NNTP newsgroup(s).