From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [Linaro-acpi] [PATCH 2/2] ACPI / scan: Parse _CCA and setup device coherency
Date: Thu, 30 Apr 2015 12:07:18 +0100 [thread overview]
Message-ID: <20150430110718.GE32373@arm.com> (raw)
In-Reply-To: <2575874.Qzlb7P3t1y@wuerfel>
On Thu, Apr 30, 2015 at 11:47:46AM +0100, Arnd Bergmann wrote:
> On Thursday 30 April 2015 11:41:02 Will Deacon wrote:
> > - 0x0: The device is not coherent. Therefore:
> > * Cache maintenance is required for memory shared with the
> > device that is mapped on CPUs as IWB-OWB-ISH.
>
> This still seems insufficient. I guess this excludes having to
> synchronize external bridges or write buffers, but it does not specify
> what cache maintenance is required. Should there be an "outer-flush"?
> Should the CPU cache be invalidated or flushed (or both), and do
> we need to care about caches inside of the device or just inside of
> the CPU?
See the note below:
> > [1] Note: Caching operations described in this document apply to the CPU
> > caches and any other caches in the system where device memory accesses
> > can hit.'
So for the CPU caches we'd do the usual clean to push dirty lines to the device
and (clean+)invalidate before reading data from the device. For the "other
caches in the system" we currently assume (for ARM64) that cache maintenance
will be broadcast and therefore I wouldn't anticipate doing anything extra.
If people want to build system caches that don't respect broadcast cache
maintenance and require explicit management (e.g outer_flush), then I
consider that a broken system and we should try to disable the cache before
entering the kernel. ARMv8 explicitly prohibits this type of cache in the
architecture (type 1 below):
`Conceptually, three classes of system cache can be envisaged:
1. System caches which lie before the point of coherency and cannot
be managed by any cache maintenance instructions. Such systems
fundamentally undermine the concept of cache maintenance
instructions operating to the point of coherency, as they imply
the use of non-architecture mechanisms to manage coherency. The
use of such systems in the ARM architecture is explicitly
prohibited.
2. System caches which lie before the point of coherency and can be
managed by cache maintenance by address instructions that apply to
the point of coherency, but cannot be managed by cache maintenance
by set/way instructions. Where maintenance of the entirety of such
a cache must be performed, as in the case for power management, it
must be performed using non-architectural mechanisms.
3. System caches which lie beyond the point of coherency and so are
invisible to the software. The management of such caches is
outside the scope of the architecture.'
(sorry to keep throwing the book at you!)
Will
next prev parent reply other threads:[~2015-04-30 11:07 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 [this message]
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
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=20150430110718.GE32373@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).