On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote: > * Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> [171109 03:47]: > > 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 > > > "arm/dma: defer atomic pool initialization" > > Boots at this commit. > > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
