linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linaro-acpi@lists.linaro.org
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Linaro-acpi] [PATCH 2/2] ACPI / scan: Parse _CCA and setup device coherency
Date: Fri, 08 May 2015 16:01:31 +0200	[thread overview]
Message-ID: <7474451.VIDhPoBiY2@wuerfel> (raw)
In-Reply-To: <20150430155513.GC27755@e104818-lin.cambridge.arm.com>

On Thursday 30 April 2015 16:55:14 Catalin Marinas wrote:
> On Thu, Apr 30, 2015 at 03:52:17PM +0200, Arnd Bergmann wrote:
> > On Thursday 30 April 2015 14:13:45 Will Deacon wrote:
> > > On Thu, Apr 30, 2015 at 02:03:00PM +0100, Arnd Bergmann wrote:
> > > > On Thursday 30 April 2015 12:46:15 Will Deacon wrote:
> > > > > Cache sync doesn't exist in the ARM/arm64architecture, what are the
> > > > > semantics supposed to be? Maybe it's just DSB for us (complete all pending
> > > > > maintenance).
> > > > 
> > > > It ensures that a state of a buffer as observed by CPU and device is
> > > > identical. It's possible that we removed all platforms that did something
> > > > interesting here, so it's one of these:
> > > > 
> > > > a) On architectures that are mostly coherent, it's a barrier
> > > >    that is broadcast to all devices, like I assume DSB is. IA64
> > > >    currently does this for all machines, but IIRC it used to 
> > > >    access some cluster interconnect at some point to enforce a
> > > >    flush.
> > > >    The ARM32 based ArmadaXP also falls into this model if the cache
> > > >    coherency fabric is enabled, as that needs to be synchronized
> 
> I'm getting confused by the ArmadaXP case. IIRC, the point of the
> arm,io-coherent property to the PL310 was precisely to make the
> outer_sync a no-op when the coherency is enabled. So basically an mb()
> would only issue a DSB on such platform without the PL310 cache sync.
> 
> On coherent systems, devices usually snoop the inner/CPU cache and not
> the system cache, that's further down the line. So a DSB would ensure
> the visibility at the coherent interconnect level before the system
> cache. I don't think it needs to be broadcast all the way to devices.

Sorry for the late reply. IIRC, the sync on Armada XP was not required
for the cache controller, but rather for the bus fabric, to ensure
that a DMA has made it into the memory controller.

> > > > b) On architectures where the device may not see the state of the cache,
> > > >    but the CPU is always aware of anything the device sends it,
> > > >    it flushes the cache. This seems to be the case on parisc,
> > > >    and in particular, there are some variants that do not support
> > > >    dma_alloc_coherent but only dma_alloc_noncoherent.
> > > > c) On architectures that need the synchronization both ways,
> > > >    it does (almost) the same invalidate/clean/flush thing as
> > > >    ARM, except it doesn't have to worry about cache lines from
> > > >    speculative prefetch which make it impossible to implement on
> > > >    ARM.
> > > 
> > > Okey doke, thanks for the explanation. It sounds like we can just build
> > > the primitive out of the existing cache maintenance routines if we need
> > > to implement it.
> > 
> > Cases a) and b) yes, but not c), otherwise we could simplify
> > the ARM dma-mapping implementation and just merge __dma_page_cpu_to_dev
> > and __dma_page_dev_to_cpu into one function.
> 
> I don't fully understand c) or b). Wouldn't the non-coherent ops cover
> them both, though potentially not as efficient?

Turning off caches usually makes everything coherent, but the performance
cost can be gigantic. Also, it might not help if the problem with coherency
is the completion of the DMA as opposed to the caching.

> > > > I guess we could handle that case as well, by requiring any ACPI based
> > > > firmware to turn off the coherency fabric on that system and just making
> > > > it dog slow.
> > > 
> > > We already require something similar in Documentation/arm64/booting.txt:
> > > 
> > >   `System caches which do not respect architected cache maintenance by VA
> > >    operations (not recommended) must be configured and disabled.'
> > 
> > Hmm, does that rule really get violated here? I think it fully respects
> > the cache maintenance (flush/invalidate/clean) operations, but it does
> > not fully respect the dsb/dmb instructions, which is something else.
> 
> If it fully respects the cache maintenance, it should also respect the
> completion and ordering requirements of the cache maintenance
> operations. That means that a DSB guarantees completion of such
> operations.

Ok.

	Arnd

  reply	other threads:[~2015-05-08 14:02 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-29 13:44 [PATCH 0/2] ACPI : Introduce support for _CCA object Suravee Suthikulpanit
2015-04-29 13:44 ` [PATCH 1/2] arm/arm64: ACPI: Introduce CONFIG_ACPI_MUST_HAVE_CCA Suravee Suthikulpanit
2015-04-29 14:04   ` Catalin Marinas
2015-04-29 14:31     ` Suravee Suthikulpanit
2015-04-29 14:42       ` Catalin Marinas
2015-04-29 14:44         ` Suravee Suthikulpanit
2015-04-30 13:47         ` Hanjun Guo
2015-04-30 13:50           ` Will Deacon
2015-04-30 14:14             ` Hanjun Guo
2015-04-30 15:01             ` Lorenzo Pieralisi
2015-04-29 13:44 ` [PATCH 2/2] ACPI / scan: Parse _CCA and setup device coherency Suravee Suthikulpanit
2015-04-29 14:03   ` Arnd Bergmann
2015-04-29 14:45     ` Suravee Suthikulpanit
2015-04-29 14:47       ` [Linaro-acpi] " Arnd Bergmann
2015-04-29 14:57         ` Suthikulpanit, Suravee
2015-04-29 15:39           ` Al Stone
2015-04-29 16:15             ` Arnd Bergmann
2015-04-29 15:54           ` Arnd Bergmann
2015-05-01 11:06             ` Catalin Marinas
2015-05-08 14:08               ` Arnd Bergmann
2015-05-11 17:10                 ` Catalin Marinas
2015-05-11 17:24                   ` Robin Murphy
2015-04-29 16:25   ` Arnd Bergmann
2015-04-29 21:53     ` Suravee Suthikulpanit
2015-04-30  8:23       ` [Linaro-acpi] " Arnd Bergmann
2015-04-30 10:41         ` Will Deacon
2015-04-30 10:47           ` Arnd Bergmann
2015-04-30 11:07             ` Will Deacon
2015-04-30 11:24               ` Arnd Bergmann
2015-04-30 11:46                 ` Will Deacon
2015-04-30 13:03                   ` Arnd Bergmann
2015-04-30 13:13                     ` Will Deacon
2015-04-30 13:52                       ` Arnd Bergmann
2015-04-30 15:55                         ` Catalin Marinas
2015-05-08 14:01                           ` Arnd Bergmann [this message]
2015-04-30 23:39         ` Suravee Suthikulanit

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=7474451.VIDhPoBiY2@wuerfel \
    --to=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=lenb@kernel.org \
    --cc=linaro-acpi@lists.linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=will.deacon@arm.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 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).