On Tue, Mar 31, 2020 at 10:04 PM Pete Batard <p...@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
