Re: The state of Arm64 on Raspberry Pi (and its Documentation
On Tue, Mar 31, 2020 at 10:04 PM Pete Batard <pete@akeo.ie> wrote:
>
> Hi Arnd,
>
> On 2020.03.31 19:33, Arnd Bergmann wrote:
> > There is no need to use ACPI when using the UEFI boot path, that can
> > just as well work with a normal DT.
>
> But there's also no reason to declare that DT should be the only way to
> boot a platform.
It took us long enough to get all the ARMv7 platforms to agree on
one way to pass platform information, I certainly don't want to see
one platform that runs both 32-bit and 64-bit kernels to use two
different methods depending which kernel you run.
We do have support for ACPI on server platforms, but that doesn't
make it a good idea for embedded SoCs.
> > Do you have a pointer to what the issues with USB and DMA are?
>
> Devices that sit behind the GPU/Videocore can only access 1 GB, and
> require a translation, and (from what we gather) there happens to be a
> silicon bug that forces devices that don't sit behind GPU (USB, Genet)
> to limit DMA to 3 GB. There is also non-cache coherency for XHCI over
> PCIe and some weird ECAM, if I recall correctly.
That sounds exactly like all the issues that we have ways to express
in DT already, but that ACPI specifically assumes work as expected.
For the DMA range settings, there is a 'dma-ranges' property to
express how addresses become visible on the parent bus. The
"dma-coherent" property can be used to list coherency per
dma master, and the pci-host driver supports arbitrary config space
access when using DT.
> Some of these are also mentioned on lkml such as in:
> https://lkml.org/lkml/2019/9/6/352
Ok.
Arnd
Reply to: