arm64: mm: move dma_contiguous_reserve() to be after paging_init()

[Song Bao Hua (Barry Song)]

> -----Original Message-----
> From: Mike Kravetz [mailto:mike.kravetz at oracle.com]
> Sent: Thursday, September 17, 2020 12:27 PM
> To: Nick Desaulniers <ndesaulniers at google.com>; Song Bao Hua (Barry Song)
> <song.bao.hua at hisilicon.com>
> Cc: akpm at linux-foundation.org; guro at fb.com;
> linux-arm-kernel at lists.infradead.org; linux-mm at kvack.org; Linuxarm
> <linuxarm at huawei.com>; sfr at canb.auug.org.au; will at kernel.org;
> ardb at kernel.org; clang-built-linux at googlegroups.com
> Subject: Re: arm64: mm: move dma_contiguous_reserve() to be after
> paging_init()
> 
> On 9/16/20 5:19 PM, Nick Desaulniers wrote:
> > It looks like that change referenced may also break arm32 boots with
> > today's next?
> >
> > The following allows me to boot, but I have no idea if it's incorrect or not.
> 
> Thanks Nick,
> 
> The referenced commit was pulled from Andrew's tree and subsequent
> versions of next.
> 
> I'm looking into other architectures as this is dependent on where in arch
> specific boot process first cma call is made.  Hopefully, there is a some way to
> do this without potentially touching a bunch of arch code.

The default cma is probably not the only who has been broken. I think the patch to enable the 
dynamic number of cma areas has also broken fdt-based CMA. For example, 
early_init_fdt_scan_reserved_mem() is called before paging_init() in arm64.

Considering many arch are calling early_init_fdt_scan_reserved_mem(), it seems using
memblock_alloc() for cma_area will require lots of test on different platforms.
1. arc
2.arm
3.arm64
4.csky
5.h8300
6.mips
7.nsd32
8.nios32
9.openrise
10.powerpc
11.riscv
12.sh
13.xtensa

> --
> Mike Kravetz

Thanks
Barry