From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mx.groups.io with SMTP id smtpd.web09.4816.1613549321990513392 for ; Wed, 17 Feb 2021 00:08:42 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=UzDRS8OO; spf=pass (domain: kernel.org, ip: 198.145.29.99, mailfrom: ardb@kernel.org) Received: by mail.kernel.org (Postfix) with ESMTPSA id 3190464E42 for ; Wed, 17 Feb 2021 08:08:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613549321; bh=cPw9orZATEZfIkKCMcPLsdjZiK9MEf848IkiSUrnCEE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=UzDRS8OOrepGw5qyjl6Sdtkwycnh9s8ggRe100nSAoqDD63f+EuuOFBaMo/cO8Toa JNcoMisD37BQD/dbVbYhjbMtBT301lpUR2nSGlc5NKjG0yzHyFDTc/rMxCD50WpQKV fwnmND+9SAjkprfN3Rdf5Opa0ANrZ/MKT417sNHXx43dGXsZgptpYnZsY4l6/lc5mz Bs3G7CVjG5FHbXiYOFpVbDu4bJ+FwYXfI6LxUOuthOv+9a0LlQyLlFY5sX5KY2gqQE TH5Fxj5X0VqAJCcJfr1N+zFaBcq/O89rTEqpYmlp8Z/apwY4CswWtjr1DpVShXLtrJ sFxpc+4lGLexg== Received: by mail-oi1-f170.google.com with SMTP id 18so14134573oiz.7 for ; Wed, 17 Feb 2021 00:08:41 -0800 (PST) X-Gm-Message-State: AOAM533mHXRiuLMBpk7tagcrlL5K15cscdw0cXWiKHH27YxAk/DIrhkp IR4IA3XwsXK6w51EY4uG0c+kkBGezBKKjDtwmtg= X-Google-Smtp-Source: ABdhPJwhC+a0ylKUheL0w2VzJjdTf57fTY/4bWhwqv0rif6Esw8zJ6CMRQxsmygCGpPkEH/tncBTdrMxOuH05jTTV/o= X-Received: by 2002:aca:4bd1:: with SMTP id y200mr5091297oia.33.1613549320405; Wed, 17 Feb 2021 00:08:40 -0800 (PST) MIME-Version: 1.0 References: <20210217061809.307479-1-lintonrjeremy@gmail.com> <8a8bbe3d-d65d-17d3-6c4b-6bffb49cfb2f@arm.com> In-Reply-To: From: "Ard Biesheuvel" Date: Wed, 17 Feb 2021 09:08:28 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates To: Andrei Warkentin Cc: Jeremy Linton , jlinton , "devel@edk2.groups.io" , Peter Batard , Samer El-Haj-Mahmoud , Leif Lindholm , Ard Biesheuvel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 17 Feb 2021 at 08:59, Andrei Warkentin wrot= e: > > I'm not sure I truly follow the conversation you're having (sorry), but I= 'll raise my hand as a _DMA user. I'm not that married to it, but I haven't= added support for the alternate IORT-based DMA range clamping. If long ter= m we want to bail on _DMA and adopt IORT exclusively, I'd love to know that= so I can plan accordingly... > SBSA requires that all memory is DMA addressable by all non-secure masters, but Linux/arm64 can deal with systems that violate this requirement, as long as the DMA limit is 4 GB or higher. The reason is that the memory region from which bounce buffers are allocated is created early during boot, and is allocated in the first 4 GB of memory. For devices such as RPi4, we have relaxed this requirement somewhat when booting Linux/arm64 in ACPI mode, by adding an early IORT scan that finds the smallest DMA limit, and using that limit for the bounce buffer region if it is smaller than 4 GB. (At this point during the boot, the AML interpreter is not up and running yet) On Linux, the _DMA method supersedes the IORT limit, and so the IORT limit is only used for sizing the bounce buffer region, and we get the full 3GB range for XHCI. In this particular case, I'd assume there is no ambiguity if the IORT and the _DMA method both produce the same 1 GB DMA limit.