Hello, Sorry for dealy. I was on vacation during last week. On Thu, Oct 26, 2017 at 07:16:27AM -0700, Tony Lindgren wrote: > * Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> [171025 21:45]: > > On Wed, Oct 25, 2017 at 10:31:38AM -0700, Tony Lindgren wrote: > > > Great, this branch boots on n900! Early parts of the dmesg attached > > > below. > > > > Sound good. Perhaps, problem is due to the cache management. With my > > patchset, direct mapping for CMA area is cleared in > > dma_contiguous_remap() if CONFIG_HIGHMEM. I guess that proper cache > > operation is required there. > > > > Could you test my newly updated branch again? I re-enable > > dma_contiguous_remap() to clear direct mapping for CMA area and add > > proper(?) cache operation although I'm not the expert on that area. > > > > https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901 > > Yeah that one boots too, dmesg below. I wonder why flushing the range > with dmac_flush_range() and outer_flush_range() no longer seems enough > though? I don't know the reason. AFAIK, it should be enough to flush cpu cache before clearing page table entry, however, it doesn't work for n900. flush_cache_all() has not only d-cache flushing but also i-cache flushing. So, I'd like to test effect of i-cache flushing. Could you test follwing updated branch? https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901 It has three relevant commits on top and enables CMA memory use. "arm/dma: remove i-cache flush" "arm/dma: flush i-cache and d-cache separately" "arm/dma: call flush_cache_all() and don't do outer cache operation" I think that flush_cache_all() here looks fine because size of CMA area is usually large enough to use flush_cache_all() but understanding root cause would be important so I ask this test. If u don't mind, please test each commit with reverting one by one and let me know the result of each test. > Reverting the arch/arm/mm/dma-mapping.c changes in your patch > "arm/dma: re-enable to remap the CMA area and flush cache before > remapping" also boots, but produces the following build warnings: > > arch/arm/mm/dma-mapping.c: In function 'dma_contiguous_remap': > arch/arm/mm/dma-mapping.c:503:20: warning: passing argument 1 of > 'cpu_cache.dma_flush_range' makes pointer from integer without a > cast [-Wint-conversion] > dmac_flush_range(map.virtual, map.virtual + map.length); > ^~~ > arch/arm/mm/dma-mapping.c:503:20: note: expected 'const void *' but > argument is of type 'long unsigned int' > arch/arm/mm/dma-mapping.c:503:33: warning: passing argument 2 of > 'cpu_cache.dma_flush_range' makes pointer from integer without a > cast [-Wint-conversion] > dmac_flush_range(map.virtual, map.virtual + map.length); Thanks for info. I think that incorrect type would not be related to this problem. 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
