From: Robin Murphy <robin.murphy@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>, Arnd Bergmann <arnd@arndb.de>
Cc: "linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
Will Deacon <Will.Deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
Charles Garcia-Tobin <Charles.Garcia-Tobin@arm.com>,
"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: Mon, 11 May 2015 18:24:02 +0100 [thread overview]
Message-ID: <5550E5B2.1030407@arm.com> (raw)
In-Reply-To: <20150511171045.GJ18655@e104818-lin.cambridge.arm.com>
On 11/05/15 18:10, Catalin Marinas wrote:
> On Fri, May 08, 2015 at 04:08:53PM +0200, Arnd Bergmann wrote:
>> On Friday 01 May 2015 12:06:44 Catalin Marinas wrote:
>>>> If we just disallow DMA to devices that are marked with _CCA=0
>>>> in ACPI, we can avoid this case, or discuss it by the time someone has hardware
>>>> that wants it, and then make a more informed decision about it.
>>>
>>> I don't think we should disallow DMA to devices with _CCA == 0 (only to
>>> those that don't have a _CCA property at all) as long as _CCA == 0 has
>>> clear semantics like only architected cache maintenance required (and
>>> that's what the ARMv8 ARM requires from compliant system caches).
>>
>> Even if we exclude all cases in which the behavior may be unexpected,
>> there is still the other point I raised initially:
>>
>> what would that be good for?
>>
>> Can you think of a case where a server system has a reason to use
>> a device in noncoherent mode? I think it's more likely to be a case
>> where a device got misconfigured accidentally by the firmware, and
>> we're better off warning about that in the kernel than trying to prepare
>> for an unknown hardware that might use an obscure feature of the spec.
>
> Maybe some of the people involved in arm64 servers can give a better
> answer, I'm not familiar with their hardware (plans).
>
> I would expect most DMA-capable devices to be cache coherent. However,
> for (system) performance reasons, some of them could be configured as
> non-coherent. An example, though unlikely on servers, is a display
> device continuously accessing a framebuffer. You may not want to
> overload the coherent interconnect.
FWIW, I've also had much the same argument put to me for IOMMUs, i.e.
they want to make the page table walk interface non-coherent because
they'd rather pay the cost of flushing the page tables once to save a
few extra cycles of latency for cache snooping on every TLB miss.
Robin.
WARNING: multiple messages have this Message-ID (diff)
From: robin.murphy@arm.com (Robin Murphy)
To: linux-arm-kernel@lists.infradead.org
Subject: [Linaro-acpi] [PATCH 2/2] ACPI / scan: Parse _CCA and setup device coherency
Date: Mon, 11 May 2015 18:24:02 +0100 [thread overview]
Message-ID: <5550E5B2.1030407@arm.com> (raw)
In-Reply-To: <20150511171045.GJ18655@e104818-lin.cambridge.arm.com>
On 11/05/15 18:10, Catalin Marinas wrote:
> On Fri, May 08, 2015 at 04:08:53PM +0200, Arnd Bergmann wrote:
>> On Friday 01 May 2015 12:06:44 Catalin Marinas wrote:
>>>> If we just disallow DMA to devices that are marked with _CCA=0
>>>> in ACPI, we can avoid this case, or discuss it by the time someone has hardware
>>>> that wants it, and then make a more informed decision about it.
>>>
>>> I don't think we should disallow DMA to devices with _CCA == 0 (only to
>>> those that don't have a _CCA property at all) as long as _CCA == 0 has
>>> clear semantics like only architected cache maintenance required (and
>>> that's what the ARMv8 ARM requires from compliant system caches).
>>
>> Even if we exclude all cases in which the behavior may be unexpected,
>> there is still the other point I raised initially:
>>
>> what would that be good for?
>>
>> Can you think of a case where a server system has a reason to use
>> a device in noncoherent mode? I think it's more likely to be a case
>> where a device got misconfigured accidentally by the firmware, and
>> we're better off warning about that in the kernel than trying to prepare
>> for an unknown hardware that might use an obscure feature of the spec.
>
> Maybe some of the people involved in arm64 servers can give a better
> answer, I'm not familiar with their hardware (plans).
>
> I would expect most DMA-capable devices to be cache coherent. However,
> for (system) performance reasons, some of them could be configured as
> non-coherent. An example, though unlikely on servers, is a display
> device continuously accessing a framebuffer. You may not want to
> overload the coherent interconnect.
FWIW, I've also had much the same argument put to me for IOMMUs, i.e.
they want to make the page table walk interface non-coherent because
they'd rather pay the cost of flushing the page tables once to save a
few extra cycles of latency for cache snooping on every TLB miss.
Robin.
next prev parent reply other threads:[~2015-05-11 17:24 UTC|newest]
Thread overview: 83+ 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 ` Suravee Suthikulpanit
2015-04-29 13:44 ` Suravee Suthikulpanit
2015-04-29 13:44 ` [PATCH 1/2] arm/arm64: ACPI: Introduce CONFIG_ACPI_MUST_HAVE_CCA Suravee Suthikulpanit
2015-04-29 13:44 ` Suravee Suthikulpanit
2015-04-29 13:44 ` Suravee Suthikulpanit
2015-04-29 14:04 ` Catalin Marinas
2015-04-29 14:04 ` Catalin Marinas
2015-04-29 14:31 ` Suravee Suthikulpanit
2015-04-29 14:31 ` Suravee Suthikulpanit
2015-04-29 14:31 ` Suravee Suthikulpanit
2015-04-29 14:42 ` Catalin Marinas
2015-04-29 14:42 ` Catalin Marinas
2015-04-29 14:44 ` Suravee Suthikulpanit
2015-04-29 14:44 ` Suravee Suthikulpanit
2015-04-29 14:44 ` Suravee Suthikulpanit
2015-04-30 13:47 ` Hanjun Guo
2015-04-30 13:47 ` Hanjun Guo
2015-04-30 13:47 ` Hanjun Guo
2015-04-30 13:50 ` Will Deacon
2015-04-30 13:50 ` Will Deacon
2015-04-30 13:50 ` Will Deacon
2015-04-30 14:14 ` Hanjun Guo
2015-04-30 14:14 ` Hanjun Guo
2015-04-30 14:14 ` Hanjun Guo
2015-04-30 15:01 ` Lorenzo Pieralisi
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 13:44 ` Suravee Suthikulpanit
2015-04-29 13:44 ` Suravee Suthikulpanit
2015-04-29 14:03 ` Arnd Bergmann
2015-04-29 14:03 ` Arnd Bergmann
2015-04-29 14:45 ` Suravee Suthikulpanit
2015-04-29 14:45 ` Suravee Suthikulpanit
2015-04-29 14:45 ` Suravee Suthikulpanit
2015-04-29 14:47 ` [Linaro-acpi] " Arnd Bergmann
2015-04-29 14:47 ` Arnd Bergmann
2015-04-29 14:57 ` Suthikulpanit, Suravee
2015-04-29 14:57 ` Suthikulpanit, Suravee
2015-04-29 15:39 ` Al Stone
2015-04-29 15:39 ` Al Stone
2015-04-29 16:15 ` Arnd Bergmann
2015-04-29 16:15 ` Arnd Bergmann
2015-04-29 15:54 ` Arnd Bergmann
2015-04-29 15:54 ` Arnd Bergmann
2015-05-01 11:06 ` Catalin Marinas
2015-05-01 11:06 ` Catalin Marinas
2015-05-08 14:08 ` Arnd Bergmann
2015-05-08 14:08 ` Arnd Bergmann
2015-05-11 17:10 ` Catalin Marinas
2015-05-11 17:10 ` Catalin Marinas
2015-05-11 17:24 ` Robin Murphy [this message]
2015-05-11 17:24 ` Robin Murphy
2015-04-29 16:25 ` Arnd Bergmann
2015-04-29 16:25 ` Arnd Bergmann
2015-04-29 21:53 ` Suravee Suthikulpanit
2015-04-29 21:53 ` Suravee Suthikulpanit
2015-04-29 21:53 ` Suravee Suthikulpanit
2015-04-30 8:23 ` [Linaro-acpi] " Arnd Bergmann
2015-04-30 8:23 ` Arnd Bergmann
2015-04-30 10:41 ` Will Deacon
2015-04-30 10:41 ` Will Deacon
2015-04-30 10:47 ` Arnd Bergmann
2015-04-30 10:47 ` Arnd Bergmann
2015-04-30 11:07 ` Will Deacon
2015-04-30 11:07 ` Will Deacon
2015-04-30 11:24 ` Arnd Bergmann
2015-04-30 11:24 ` Arnd Bergmann
2015-04-30 11:46 ` Will Deacon
2015-04-30 11:46 ` Will Deacon
2015-04-30 13:03 ` Arnd Bergmann
2015-04-30 13:03 ` Arnd Bergmann
2015-04-30 13:13 ` Will Deacon
2015-04-30 13:13 ` Will Deacon
2015-04-30 13:52 ` Arnd Bergmann
2015-04-30 13:52 ` Arnd Bergmann
2015-04-30 15:55 ` Catalin Marinas
2015-04-30 15:55 ` Catalin Marinas
2015-05-08 14:01 ` Arnd Bergmann
2015-05-08 14:01 ` Arnd Bergmann
2015-04-30 23:39 ` Suravee Suthikulanit
2015-04-30 23:39 ` Suravee Suthikulanit
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=5550E5B2.1030407@arm.com \
--to=robin.murphy@arm.com \
--cc=Charles.Garcia-Tobin@arm.com \
--cc=Will.Deacon@arm.com \
--cc=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=suravee.suthikulpanit@amd.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 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.