All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
To: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Subject: Re: [PATCH 4/4] drm/nouveau: introduce CPU cache flushing macro
Date: Mon, 19 May 2014 12:27:50 +0200	[thread overview]
Message-ID: <20140519102750.GI8790@phenom.ffwll.local> (raw)
In-Reply-To: <20140519100316.GE7138@ulmo>

On Mon, May 19, 2014 at 12:03:17PM +0200, Thierry Reding wrote:
> On Mon, May 19, 2014 at 11:22:11AM +0200, Lucas Stach wrote:
> > Am Montag, den 19.05.2014, 11:02 +0200 schrieb Thierry Reding:
> > > On Mon, May 19, 2014 at 04:10:58PM +0900, Alexandre Courbot wrote:
> > > > Some architectures (e.g. ARM) need the CPU buffers to be explicitely
> > > > flushed for a memory write to take effect. Not doing so results in
> > > > synchronization issues, especially after writing to BOs.
> > > 
> > > It seems to me that the above is generally true for all architectures,
> > > not just ARM.
> > > 
> > No, on PCI coherent arches, like x86 and some PowerPCs, the GPU will
> > snoop the CPU caches and therefore an explicit cache flush is not
> > required.
> 
> I was criticizing the wording in the commit message. Perhaps it could be
> enhanced with what you just said.

Shouldn't this be done in the dma mapping layer? I know that i915 does all
the cpu cache flushing itself, but that's because the x86 dma layer
refuses to believe that there are non-coherent platforms on x86. But on
arm it can cope.

This is somewhat important for dma-buf buffer sharing since if the cpu
cache control is done in drivers you must do double-flushing on shared
buffers. Atm you have to do that anyway, but at least this would make it
easier. The other problem is that ttm reinvents half of the dma mapping
functions.

Just my 2 cents.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>,
	nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, Ben Skeggs <bskeggs@redhat.com>,
	linux-tegra@vger.kernel.org
Subject: Re: [Nouveau] [PATCH 4/4] drm/nouveau: introduce CPU cache flushing macro
Date: Mon, 19 May 2014 12:27:50 +0200	[thread overview]
Message-ID: <20140519102750.GI8790@phenom.ffwll.local> (raw)
In-Reply-To: <20140519100316.GE7138@ulmo>

On Mon, May 19, 2014 at 12:03:17PM +0200, Thierry Reding wrote:
> On Mon, May 19, 2014 at 11:22:11AM +0200, Lucas Stach wrote:
> > Am Montag, den 19.05.2014, 11:02 +0200 schrieb Thierry Reding:
> > > On Mon, May 19, 2014 at 04:10:58PM +0900, Alexandre Courbot wrote:
> > > > Some architectures (e.g. ARM) need the CPU buffers to be explicitely
> > > > flushed for a memory write to take effect. Not doing so results in
> > > > synchronization issues, especially after writing to BOs.
> > > 
> > > It seems to me that the above is generally true for all architectures,
> > > not just ARM.
> > > 
> > No, on PCI coherent arches, like x86 and some PowerPCs, the GPU will
> > snoop the CPU caches and therefore an explicit cache flush is not
> > required.
> 
> I was criticizing the wording in the commit message. Perhaps it could be
> enhanced with what you just said.

Shouldn't this be done in the dma mapping layer? I know that i915 does all
the cpu cache flushing itself, but that's because the x86 dma layer
refuses to believe that there are non-coherent platforms on x86. But on
arm it can cope.

This is somewhat important for dma-buf buffer sharing since if the cpu
cache control is done in drivers you must do double-flushing on shared
buffers. Atm you have to do that anyway, but at least this would make it
easier. The other problem is that ttm reinvents half of the dma mapping
functions.

Just my 2 cents.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2014-05-19 10:27 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-19  7:10 [PATCH 0/4] drm/ttm: nouveau: memory coherency fixes for ARM Alexandre Courbot
2014-05-19  7:10 ` Alexandre Courbot
2014-05-19  7:10 ` [PATCH 1/4] drm/ttm: recognize ARM arch in ioprot handler Alexandre Courbot
2014-05-19  7:10   ` Alexandre Courbot
2014-05-19  7:10 ` [PATCH 3/4] drm/nouveau: hook up cache sync functions Alexandre Courbot
2014-05-19  7:10   ` Alexandre Courbot
     [not found]   ` <1400483458-9648-4-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-05-19  8:46     ` Thierry Reding
2014-05-19  8:46       ` Thierry Reding
2014-05-19  9:44       ` Lucas Stach
2014-05-19  9:44         ` Lucas Stach
2014-05-23  6:00       ` Alexandre Courbot
2014-05-23  6:00         ` Alexandre Courbot
2014-05-19  9:31     ` Lucas Stach
2014-05-19  9:31       ` Lucas Stach
     [not found]       ` <1400491887.8467.15.camel-WzVe3FnzCwFR6QfukMTsflXZhhPuCNm+@public.gmane.org>
2014-05-23  6:01         ` Alexandre Courbot
2014-05-23  6:01           ` Alexandre Courbot
     [not found] ` <1400483458-9648-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-05-19  7:10   ` [PATCH 2/4] drm/ttm: introduce dma cache sync helpers Alexandre Courbot
2014-05-19  7:10     ` Alexandre Courbot
2014-05-19  8:33     ` Thierry Reding
2014-05-19  8:33       ` Thierry Reding
2014-05-23  5:49       ` Alexandre Courbot
2014-05-23  5:49         ` Alexandre Courbot
2014-05-23  7:31         ` Thierry Reding
2014-05-23  7:31           ` Thierry Reding
2014-05-19  7:10   ` [PATCH 4/4] drm/nouveau: introduce CPU cache flushing macro Alexandre Courbot
2014-05-19  7:10     ` Alexandre Courbot
     [not found]     ` <1400483458-9648-5-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-05-19  9:02       ` Thierry Reding
2014-05-19  9:02         ` Thierry Reding
2014-05-19  9:22         ` Lucas Stach
2014-05-19  9:22           ` Lucas Stach
     [not found]           ` <1400491331.8467.8.camel-WzVe3FnzCwFR6QfukMTsflXZhhPuCNm+@public.gmane.org>
2014-05-19 10:03             ` Thierry Reding
2014-05-19 10:03               ` Thierry Reding
2014-05-19 10:27               ` Daniel Vetter [this message]
2014-05-19 10:27                 ` [Nouveau] " Daniel Vetter
2014-05-23  6:58               ` Alexandre Courbot
2014-05-23  6:58                 ` Alexandre Courbot
2014-06-09 10:41             ` Alexandre Courbot
2014-06-09 10:41               ` Alexandre Courbot
     [not found]               ` <CAAVeFu+KZ9AqB5ji5-AA+qzEFDWd7y0=J1eSEPqQ-OyhmXufig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-06-12 13:50                 ` Alexandre Courbot
2014-06-12 13:50                   ` Alexandre Courbot
     [not found]                   ` <CAAVeFuJYe5wVH_gTok80hT=4GbwhYq4C9c7S5No_V11qjs3brQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-06-12 18:15                     ` Roy Spliet

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=20140519102750.GI8790@phenom.ffwll.local \
    --to=daniel-/w4ywyx8dfk@public.gmane.org \
    --cc=bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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 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.