[PATCH 13/18] arm64: ioremap: use nGnRnE mappings on platforms that require it

[Arnd Bergmann]

On Tue, Feb 9, 2021 at 12:20 AM Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> > From: Arnd Bergmann <arnd at kernel.org>
> It is only PCI mmio space that needs to be nGnRE.  The PCI host
> controller register space itself needs nGnRnE just like all other
> integrated peripherals (or at least it works that way).
>
> For U-Boot I'm using the following memory map:
>
> static struct mm_region apple_mem_map[] = {
>         {
>                 /* I/O */
>                 .virt = 0x200000000,
>                 .phys = 0x200000000,
>                 .size = 8UL * SZ_1G,
>                 .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>                          PTE_BLOCK_NON_SHARE |
>                          PTE_BLOCK_PXN | PTE_BLOCK_UXN
>         }, {...
>                 /* List terminator */
>                 0,
>         }
> };

Right, that list agrees mostly what I found, except I didn't see a
continuous 8GB range at 0x200000000 in the ADT ranges properties
but instead a 4GB range for most of the on-chip components plus a
2GB range for stuff that is related to the first PCIe host, starting at
0x380000000 and nothing inbetween. I suppose this makes no
practical difference.

For the PCIe ranges, I see that only one of them is non-prefetchable,
while the other two ranges are marked as prefetchable. These usually
get turned into ioremap_wc() or ioremap_wt() mappings in Linux,
which are more relaxed than MT_DEVICE_NGNRE. Having
stricter attributes in u-boot shouldn't hurt, it might just be slightly
slower than it has to be.

> struct mm_region *mem_map = apple_mem_map;
>
> This seems to work so far.  It only has the regions for one PCIe
> controller.  I suppose the other two are there to support the TB4
> ports?
>
> So there is one 512M region for "32-bit" mmio starting at 0x6a0000000
> and one 1G region for "64-bit" mmio starting at 0x6c0000000.

What is connected to this controller?

        Arnd