From: "Ard Biesheuvel" <ard.biesheuvel@arm.com>
To: Andrei Warkentin <awarkentin@vmware.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>,
Jeremy Linton <jeremy.linton@arm.com>, Pete Batard <pete@akeo.ie>,
Leif Lindholm <leif@nuviainc.com>
Subject: Re: [PATCH edk2-platforms 1/1] Platform/RaspberryPi/AcpiTables: add a IORT ACPI table to limit XHCI DMA
Date: Sun, 11 Oct 2020 19:56:06 +0200 [thread overview]
Message-ID: <2f7578b6-42b0-d46c-ee4d-1ac77df963f6@arm.com> (raw)
In-Reply-To: <BN6PR05MB3411DC16A5BF5FB524D3ABC4B9060@BN6PR05MB3411.namprd05.prod.outlook.com>
On 10/11/20 7:25 PM, Andrei Warkentin wrote:
> Hi Ard,
>
> This makes sense to me. Glad there's a way forward to support such
> systems with ACPI in Linux.
>
> Could the other "legacy" devices behind the GPU be handled similarly? I
> mean the ones with the 1GB DMA limit. Not this change, of course.
>
Yes. Anything we describe in the namespace can be added here as a named
component, with the associated address limit.
> Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
>
Thanks,
> ------------------------------------------------------------------------
> *From:* Ard Biesheuvel <ard.biesheuvel@arm.com>
> *Sent:* Sunday, October 11, 2020 3:20 AM
> *To:* devel@edk2.groups.io <devel@edk2.groups.io>
> *Cc:* Ard Biesheuvel <ard.biesheuvel@arm.com>; Samer El-Haj-Mahmoud
> <Samer.El-Haj-Mahmoud@arm.com>; Jeremy Linton <jeremy.linton@arm.com>;
> Pete Batard <pete@akeo.ie>; Andrei Warkentin <awarkentin@vmware.com>;
> Leif Lindholm <leif@nuviainc.com>
> *Subject:* [PATCH edk2-platforms 1/1] Platform/RaspberryPi/AcpiTables:
> add a IORT ACPI table to limit XHCI DMA
> Add an IORT table that will limit XHCI DMA to 2 GB, by setting the
> DMA width to 31 bits. This is needed for Linux/arm64, which can
> only reliably deal with devices that are unable to perform DMA to
> the entire 32-bit address range if it can discover their existence
> early during boot, and this is before the ACPI interpreter is up
> and running (which rules out calling the _DMA method of the XHC0
> object)
>
> Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
> Cc: Jeremy Linton <jeremy.linton@arm.com>
> Cc: Pete Batard <pete@akeo.ie>
> Cc: Andrei Warkentin <awarkentin@vmware.com>
> Cc: Leif Lindholm <leif@nuviainc.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
> ---
> Related discussions here:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flinux-arm-kernel%2F20201001161740.29064-1-nsaenzjulienne%40suse.de%2F&data=04%7C01%7Cawarkentin%40vmware.com%7C0ceb573430144cf5a9c308d86dbe9d15%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637380012741008284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Z1MavubU27xkVXFXSSLtobrwpKSmerA9y9uRZNDd2Nw%3D&reserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flinux-acpi%2F20201010093153.30177-1-ardb%40kernel.org%2F&data=04%7C01%7Cawarkentin%40vmware.com%7C0ceb573430144cf5a9c308d86dbe9d15%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637380012741008284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JrfduAeqAJqiFzP8CrwnTigwy21SIJYviMW6IkdA8KI%3D&reserved=0
>
> On Linux, a _DMA method supersedes the IORT, and so the 3 GB limit will
> be used at runtime. IOW, streaming DMA will be permitted to the entire
> 3 GB region, but if shared buffers or bounce buffers are needed, they
> will be allocated from the first 2 GB of DRAM.
>
> We may need to offer some guidance on this in the IORT spec, i.e., which
> value takes precedence if the IORT and the _DMA method disagree.
>
> Platform/RaspberryPi/AcpiTables/AcpiTables.inf | 1 +
> Platform/RaspberryPi/AcpiTables/Iort.aslc | 58 ++++++++++++++++++++
> 2 files changed, 59 insertions(+)
>
> diff --git a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
> b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
> index c40c32e16ff7..d2cce074e56c 100644
> --- a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
> +++ b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
> @@ -29,6 +29,7 @@ [Sources]
> Fadt.aslc
> Dbg2.aslc
> Gtdt.aslc
> + Iort.aslc
> Dsdt.asl
> Csrt.aslc
> Spcr.aslc
> diff --git a/Platform/RaspberryPi/AcpiTables/Iort.aslc
> b/Platform/RaspberryPi/AcpiTables/Iort.aslc
> new file mode 100644
> index 000000000000..1351e8f7b262
> --- /dev/null
> +++ b/Platform/RaspberryPi/AcpiTables/Iort.aslc
> @@ -0,0 +1,58 @@
> +/** @file
> +
> + Copyright (c) 2020, Arm, Ltd. All rights reserved.<BR>
> +
> + SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include <IndustryStandard/IoRemappingTable.h>
> +
> +#include "AcpiTables.h"
> +
> +#pragma pack(1)
> +
> +typedef struct {
> + EFI_ACPI_6_0_IO_REMAPPING_NAMED_COMP_NODE Node;
> + CONST CHAR8 Name[16];
> +} RPI4_NC_NODE;
> +
> +typedef struct {
> + EFI_ACPI_6_0_IO_REMAPPING_TABLE Iort;
> + RPI4_NC_NODE NamedCompNode;
> +} RPI4_IO_REMAPPING_STRUCTURE;
> +
> +STATIC RPI4_IO_REMAPPING_STRUCTURE Iort = {
> + {
> + ACPI_HEADER (EFI_ACPI_6_0_IO_REMAPPING_TABLE_SIGNATURE,
> + RPI4_IO_REMAPPING_STRUCTURE,
> + EFI_ACPI_IO_REMAPPING_TABLE_REVISION),
> + 1, // NumNodes
> + sizeof (EFI_ACPI_6_0_IO_REMAPPING_TABLE), // NodeOffset
> + 0 // Reserved
> + }, {
> + // XHCI named component node
> + {
> + {
> + EFI_ACPI_IORT_TYPE_NAMED_COMP,
> + sizeof (RPI4_NC_NODE),
> + 0x0,
> + 0x0,
> + 0x0,
> + 0x0,
> + },
> + 0x0,
> + 0x0,
> + 0x0,
> + 0x0,
> + 0x0,
> + 31,
> + }, {
> + "\\_SB_.SCB0.XHC0"
> + }
> + }
> +};
> +
> +#pragma pack()
> +
> +VOID* CONST ReferenceAcpiTable = &Iort;
> --
> 2.17.1
>
next prev parent reply other threads:[~2020-10-11 17:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-11 8:20 [PATCH edk2-platforms 1/1] Platform/RaspberryPi/AcpiTables: add a IORT ACPI table to limit XHCI DMA Ard Biesheuvel
2020-10-11 17:25 ` Andrei Warkentin
2020-10-11 17:56 ` Ard Biesheuvel [this message]
2020-10-12 17:31 ` Ard Biesheuvel
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-list 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=2f7578b6-42b0-d46c-ee4d-1ac77df963f6@arm.com \
--to=devel@edk2.groups.io \
/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