On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote:

* Joonsoo Kim [off-list ref] [171109 03:47]:

quoted

Could you test following two commits on my updated branch?

"arm/dma: vmalloc area allocation"

Won't boot at this commit:

[    6.747283] save_secure_sram() returns 0000ff02
[    6.751983] save_secure_sram()'s param: 0: 0x4
[    6.756561] save_secure_sram()'s param: 1: 0x8e700000
[    6.761749] save_secure_sram()'s param: 2: 0x0
[    6.766326] save_secure_sram()'s param: 3: 0x1
[    6.770904] save_secure_sram()'s param: 4: 0x1

quoted

"arm/dma: defer atomic pool initialization"

Boots at this commit.

quoted

I suspect that changed virtual address of the sram due to early
__dma_alloc_remap() call causes the problem and above two commits test
this theory.

Hmm OK. Does your first patch above now have the initcall issue too?
It boots if I make that also subsys_initcall and then I get:

[    2.078094] vmalloc_pool_init: DMA: get vmalloc area: d0010000

Yes, first patch has the initcall issue and it's intentional in order
to check the theory. I checked following log for this.

- Boot failure
SRAM_ADDR: omap_map_sram: P: 0x40208000 - 0x4020f000
SRAM_ADDR: omap_map_sram: V: 0xd0050000 - 0xd0057000

- Boot success
SRAM_ADDR: omap_map_sram: P: 0x40208000 - 0x4020f000
SRAM_ADDR: omap_map_sram: V: 0xd0008000 - 0xd000f000

When failure, virtual address for sram is higher than normal one due
to vmalloc area allocation in __dma_alloc_remap(). If it is deferred,
virtual address is the same with success case and then the system work.

So, my next theory is that there is n900 specific assumption that sram
should have that address. Could you check if any working tree for n900
which doesn't have my CMA series work or not with adding
"arm/dma: vmalloc area allocation"?

Thanks.