Re: n900 in next-20170901

[Tony Lindgren]

* Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> [171110 00:10]:
> On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote:
> > 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"?

Oh I see, sorry I was not following you earlier. So you mean that
by adding the vmalloc_pool_init() initcall the va mapping for SRAM
changes.

And yes, save_secure_ram_context seems to be doing some sketchy
virt to phys calculation with sram_phy_addr_mask. Here's a small
patch to fix that for your CMA series, maybe you can merge it
with your series to avoid breaking booting for git bisect.

Then I'll follow up on cleaning up save_secure_ram_context later.

Regards,

Tony

8< -------------------------