From: Tom Lendacky <thomas.lendacky@amd.com>
To: Will Deacon <will.deacon@arm.com>, Arnd Bergmann <arnd@arndb.de>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Mark Rutland <Mark.Rutland@arm.com>,
linaro-acpi <linaro-acpi@lists.linaro.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Yijing Wang <wangyijing@huawei.com>,
Rob Herring <robh@kernel.org>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
Timur Tabi <timur@codeaurora.org>,
ACPI Devel Mailing List <linux-acpi@vger.kernel.org>,
"grant.likely@linaro.org" <grant.likely@linaro.org>,
Charles Garcia-Tobin <Charles.Garcia-Tobin@arm.com>,
"phoenix.liyi@huawei.com" <phoenix.liyi@huawei.com>,
Robert Richter <rric@kernel.org>,
Jason Cooper <jason@lakedaemon.net>,
Marc Zyngier <Marc.Zyngier@arm.com>,
"jcm@redhat.com" <jcm@redhat.com>,
Mark Brown <broonie@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
"graeme.gregory@linaro.org" <graeme.gregory@linaro.org>,
Randy Dunlap <rdunlap@infradead.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"hanjun.guo@linaro.org" <hanjun.guo@linaro.org>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
Sudeep Holla <Sudeep.Holla@arm.com>,
"Olof Johansson" <olof@lixom.net>
Subject: Re: [PATCH v7 00/17] Introduce ACPI for ARM64 based on ACPI 5.1
Date: Fri, 16 Jan 2015 11:12:20 -0600 [thread overview]
Message-ID: <54B94674.10206@amd.com> (raw)
In-Reply-To: <20150116154913.GW7091@arm.com>
On 01/16/2015 09:49 AM, Will Deacon wrote:
> On Fri, Jan 16, 2015 at 03:40:28PM +0000, Arnd Bergmann wrote:
>> On Friday 16 January 2015 15:33:20 Will Deacon wrote:
>>> On Fri, Jan 16, 2015 at 03:14:13PM +0000, Arnd Bergmann wrote:
>>>> On Friday 16 January 2015 14:55:45 Will Deacon wrote:
>>>>> On Fri, Jan 16, 2015 at 02:45:30PM +0000, Tom Lendacky wrote:
>>>>>> I have tested ACPI-enablement patches for the amd-xgbe/amd-xgbe-phy
>>>>>> drivers that I'm about to submit upstream with the V7 patch series
>>>>>> on the AMD Seattle server platform. There does not appear to be support
>>>>>> for the _CCA attribute in this patch series. The amd-xgbe driver will
>>>>>> setup the device domain and cache attributes based on the presence of
>>>>>> this attribute, but it requires the arch support to assign the proper
>>>>>> DMA operations in order for it to all work correctly.
>>>>>>
>>>>>> Overriding the _CCA attribute in the driver, I was able to successfully
>>>>>> test the driver and this patch series.
>>>>>
>>>>> Hopefully this will all be addressed when the IORT parts of ACPI have
>>>>> settled down (the current proposal allows for these attributes to be
>>>>> described as well as their interaction with things like IOMMUs).
>>>>>
>>>>> In the meantime, are you falling back to non-coherent DMA? If so, what
>>>>> attributes have you settled on? We need to be really careful not to
>>>>> corrupt data during cache invalidatation when mapping a non-coherent
>>>>> buffer for the CPU.
>>>>
>>>> I think in case of ACPI we should use cache-coherent as the default,
>>>> as this is what all servers will use for DMA masters.
>>>
>>> I don't agree. The dma-coherent we have for device-tree isn't nearly
>>> expressive enough for the kind of things we want to describe and there's
>>> no reason to make the same mistake in ACPI, especially as it *is* being
>>> addressed by IORT. If we run with _CCA, then we're going to be stuck
>>> supporting something that isn't fit for purpose and which will likely be
>>> abused to describe both fixed features of the system and software
>>> configuration preferences. It also opens up a can of worms if we have to
>>> support a mixture of _CCA and IORT in the future.
>>>
>>> Or are you suggesting that we ignore _CCA and just assume cache-coherency?
>>> In that case, how do we support systems that aren't cache coherent, where
>>> not being cache coherent includes devices that require either device or
>>> IOMMU configuration to enable cacheable transactions?
>>
>> I was thinking we'd ignore _CCA because as you say a simple on/off flag
>> would not be enough to describe what we have to do for noncoherent
>> devices. I can't think of any reason why a server hardware would include
>> noncoherent devices, so if they are configurable they should be configured
>> into coherent mode by the firmware.
>
> The on-board ethernet on Seattle requires the driver to program its AXI
> attributes, so configuring it to be a coherent master actually means
> "program the same cacheable AXI settings as you have on the CPU". That
> sounds like Linux should be doing it to me, but even if the firmware takes
> a guess at "normal cacheable WBRWA", it's not clear to me whether that
> register persists across things like adapter reset.
>
> Tom?
The registers that contain the AxDOMAIN and AxCACHE settings do not
persist across an adapter reset.
Tom
>
> There's also the situation where the firmware hasn't initialised the
> register and Linux realises this during probe. What should it do then?
>
> Will
>
next prev parent reply other threads:[~2015-01-16 17:27 UTC|newest]
Thread overview: 154+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-14 15:04 [PATCH v7 00/17] Introduce ACPI for ARM64 based on ACPI 5.1 Hanjun Guo
2015-01-14 15:04 ` [PATCH v7 01/17] arm64: allow late use of early_ioremap Hanjun Guo
2015-01-15 18:44 ` Mark Langsdorf
2015-01-14 15:04 ` [PATCH v7 02/17] ARM64 / ACPI: Get RSDP and ACPI boot-time tables Hanjun Guo
2015-01-15 18:45 ` Mark Langsdorf
2015-01-14 15:04 ` [PATCH v7 03/17] ARM64 / ACPI: Introduce sleep-arm.c Hanjun Guo
2015-01-15 18:45 ` Mark Langsdorf
2015-01-14 15:04 ` [PATCH v7 04/17] ARM64 / ACPI: Introduce early_param for "acpi" and pass acpi=force to enable ACPI Hanjun Guo
2015-01-15 18:46 ` Mark Langsdorf
2015-01-19 11:42 ` Catalin Marinas
2015-01-19 11:55 ` Ard Biesheuvel
2015-01-19 13:51 ` Catalin Marinas
2015-01-19 14:00 ` Ard Biesheuvel
2015-01-19 14:22 ` Catalin Marinas
2015-01-19 15:13 ` Grant Likely
2015-01-19 16:59 ` Jon Masters
2015-01-19 17:52 ` Catalin Marinas
2015-01-19 18:01 ` Mark Rutland
2015-01-20 9:29 ` Hanjun Guo
2015-01-20 10:56 ` Catalin Marinas
2015-01-20 11:10 ` Mark Rutland
2015-01-20 12:17 ` Hanjun Guo
2015-01-20 12:31 ` Leif Lindholm
2015-01-20 19:20 ` Stefano Stabellini
2015-01-21 9:43 ` Parth Dixit
2015-01-21 15:23 ` Catalin Marinas
2015-01-21 15:29 ` Jon Masters
2015-01-21 15:42 ` Catalin Marinas
2015-01-21 15:56 ` Graeme Gregory
2015-01-21 16:05 ` Jon Masters
2015-01-21 16:16 ` Catalin Marinas
2015-01-21 16:51 ` Parth Dixit
2015-01-21 16:10 ` Stefano Stabellini
2015-01-22 12:29 ` Daniel Kiper
2015-01-28 17:58 ` [Linaro-acpi] " Timur Tabi
2015-01-28 18:08 ` Catalin Marinas
2015-01-28 18:08 ` Timur Tabi
2015-01-28 18:14 ` Catalin Marinas
2015-01-28 18:18 ` Timur Tabi
2015-01-29 15:19 ` Catalin Marinas
2015-01-29 18:20 ` Ard Biesheuvel
2015-01-29 18:21 ` Timur Tabi
2015-01-29 18:28 ` Ard Biesheuvel
2015-01-29 18:34 ` Timur Tabi
2015-01-29 18:44 ` Jon Masters
2015-01-29 23:11 ` Catalin Marinas
2015-01-29 23:16 ` Jon Masters
2015-01-29 23:30 ` Catalin Marinas
2015-01-30 11:13 ` Catalin Marinas
2015-01-30 14:48 ` Timur Tabi
2015-01-30 15:12 ` Ard Biesheuvel
2015-01-14 15:04 ` [PATCH v7 05/17] ARM64 / ACPI: If we chose to boot from acpi then disable FDT Hanjun Guo
2015-01-15 18:46 ` Mark Langsdorf
2015-01-19 11:45 ` Catalin Marinas
2015-01-14 15:04 ` [PATCH v7 06/17] ARM64 / ACPI: Make PCI optional for ACPI on ARM64 Hanjun Guo
2015-01-15 18:46 ` Mark Langsdorf
2015-01-16 9:49 ` Catalin Marinas
2015-01-18 6:25 ` Hanjun Guo
2015-01-18 6:31 ` Jon Masters
2015-01-18 6:46 ` Hanjun Guo
2015-01-18 9:29 ` Graeme Gregory
2015-01-18 12:32 ` Jon Masters
2015-01-19 4:26 ` Hanjun Guo
2015-01-19 10:37 ` Catalin Marinas
2015-01-19 10:42 ` Catalin Marinas
2015-01-20 2:39 ` Hanjun Guo
2015-01-20 11:00 ` Catalin Marinas
2015-01-20 11:56 ` Hanjun Guo
2015-01-20 12:26 ` [Linaro-acpi] " Tomasz Nowicki
2015-01-20 15:10 ` Catalin Marinas
2015-01-14 15:04 ` [PATCH v7 07/17] ARM64 / ACPI: Disable ACPI if FADT revision is less than 5.1 Hanjun Guo
2015-01-15 18:47 ` Mark Langsdorf
2015-01-16 14:33 ` Lorenzo Pieralisi
2015-01-18 5:49 ` Hanjun Guo
2015-01-19 11:50 ` Catalin Marinas
2015-01-20 3:05 ` Hanjun Guo
2015-01-14 15:04 ` [PATCH v7 08/17] ARM64 / ACPI: Get PSCI flags in FADT for PSCI init Hanjun Guo
2015-01-15 18:47 ` Mark Langsdorf
2015-01-14 15:04 ` [PATCH v7 09/17] ACPI / table: Print GIC information when MADT is parsed Hanjun Guo
2015-01-15 18:47 ` Mark Langsdorf
2015-01-14 15:04 ` [PATCH v7 10/17] ARM64 / ACPI: Parse MADT for SMP initialization Hanjun Guo
2015-01-15 18:48 ` Mark Langsdorf
2015-01-16 18:18 ` Lorenzo Pieralisi
2015-01-20 13:09 ` Hanjun Guo
2015-01-20 15:16 ` Lorenzo Pieralisi
2015-01-14 15:04 ` [PATCH v7 11/17] ACPI / processor: Make it possible to get CPU hardware ID via GICC Hanjun Guo
2015-01-15 18:48 ` Mark Langsdorf
2015-01-20 11:17 ` Catalin Marinas
2015-01-20 12:26 ` Hanjun Guo
2015-01-20 16:16 ` Lorenzo Pieralisi
2015-01-14 15:05 ` [PATCH v7 12/17] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi Hanjun Guo
2015-01-15 18:48 ` Mark Langsdorf
2015-01-16 10:45 ` Marc Zyngier
2015-01-14 15:05 ` [PATCH v7 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support Hanjun Guo
2015-01-15 18:50 ` Mark Langsdorf
2015-01-16 11:15 ` Marc Zyngier
2015-01-16 13:54 ` Grant Likely
2015-01-16 14:37 ` Marc Zyngier
2015-01-22 12:46 ` Hanjun Guo
2015-01-22 14:46 ` Marc Zyngier
2015-01-23 9:38 ` Hanjun Guo
2015-01-27 16:12 ` Grant Likely
2015-01-29 15:29 ` Catalin Marinas
2015-01-29 16:06 ` Tomasz Nowicki
2015-01-20 10:40 ` Tomasz Nowicki
2015-01-20 13:05 ` Jon Masters
2015-01-14 15:05 ` [PATCH v7 14/17] ARM64 / ACPI: Parse GTDT to initialize arch timer Hanjun Guo
2015-01-15 18:50 ` Mark Langsdorf
2015-01-14 15:05 ` [PATCH v7 15/17] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 Hanjun Guo
2015-01-15 18:50 ` Mark Langsdorf
2015-01-14 15:05 ` [PATCH v7 16/17] ARM64 / ACPI: Enable ARM64 in Kconfig Hanjun Guo
2015-01-15 18:50 ` Mark Langsdorf
2015-01-14 15:05 ` [PATCH v7 17/17] Documentation: ACPI for ARM64 Hanjun Guo
2015-01-15 18:54 ` Mark Langsdorf
2015-01-15 16:26 ` [PATCH v7 00/17] Introduce ACPI for ARM64 based on ACPI 5.1 Grant Likely
2015-01-15 18:23 ` Catalin Marinas
2015-01-15 19:02 ` Mark Brown
2015-01-15 20:04 ` Jason Cooper
2015-01-15 20:31 ` Mark Brown
2015-01-15 20:51 ` Jason Cooper
2015-01-16 11:49 ` Mark Brown
2015-01-16 7:24 ` Hanjun Guo
2015-01-16 10:10 ` Catalin Marinas
2015-01-16 12:05 ` Mark Brown
2015-01-16 12:29 ` Will Deacon
2015-01-16 16:54 ` Mark Brown
2015-01-18 6:36 ` Hanjun Guo
2015-01-15 21:31 ` Al Stone
2015-01-15 21:38 ` Jon Masters
2015-01-16 10:20 ` Catalin Marinas
2015-01-16 15:17 ` [Linaro-acpi] " Al Stone
2015-01-16 15:23 ` Al Stone
2015-01-16 15:44 ` Suravee Suthikulpanit
2015-01-16 7:17 ` Hanjun Guo
2015-01-16 10:04 ` Catalin Marinas
2015-01-16 14:45 ` Tom Lendacky
2015-01-16 14:55 ` Will Deacon
2015-01-16 15:14 ` Arnd Bergmann
2015-01-16 15:25 ` Catalin Marinas
2015-01-16 15:33 ` Will Deacon
2015-01-16 15:40 ` Arnd Bergmann
2015-01-16 15:43 ` [Linaro-acpi] " Arnd Bergmann
2015-01-16 15:49 ` Will Deacon
2015-01-16 15:53 ` [Linaro-acpi] " Arnd Bergmann
2015-01-17 17:53 ` Rob Herring
2015-01-16 17:12 ` Tom Lendacky [this message]
2015-01-16 15:16 ` Tom Lendacky
2015-01-16 16:29 ` Grant Likely
2015-01-16 17:20 ` [Linaro-acpi] " Arnd Bergmann
2015-01-17 11:52 ` Catalin Marinas
2015-01-15 18:58 ` Jon Masters
2015-01-15 21:33 ` Suravee Suthikulanit
2015-01-27 17:46 ` Timur Tabi
2015-01-28 13:53 ` Hanjun Guo
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=54B94674.10206@amd.com \
--to=thomas.lendacky@amd.com \
--cc=Catalin.Marinas@arm.com \
--cc=Charles.Garcia-Tobin@arm.com \
--cc=Lorenzo.Pieralisi@arm.com \
--cc=Marc.Zyngier@arm.com \
--cc=Mark.Rutland@arm.com \
--cc=Sudeep.Holla@arm.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=broonie@kernel.org \
--cc=graeme.gregory@linaro.org \
--cc=grant.likely@linaro.org \
--cc=hanjun.guo@linaro.org \
--cc=jason@lakedaemon.net \
--cc=jcm@redhat.com \
--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=olof@lixom.net \
--cc=phoenix.liyi@huawei.com \
--cc=rdunlap@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=robh@kernel.org \
--cc=rric@kernel.org \
--cc=suravee.suthikulpanit@amd.com \
--cc=timur@codeaurora.org \
--cc=wangyijing@huawei.com \
--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).