On Fri, 24 Jul 2020 at 15:06, Nicolas Saenz Julienne <nsaenzjulie...@suse.de> wrote: > > Hi Amit, > > On Thu, 2020-07-23 at 10:44 +0530, Amit Pundir wrote: > > Hi Nicolas, > > > > Sorry I got stuck on other things yesterday. > > No worries :) > > > On Tue, 21 Jul 2020 at 21:57, Nicolas Saenz Julienne > > [...] > > > > > > > Let's get a bigger hammer, I'm just looking for clues here. Can you > > > apply this and provide the dmesg output. > > > > > > diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c > > > index 6bc74a2d5127..2160676bf488 100644 > > > --- a/kernel/dma/pool.c > > > +++ b/kernel/dma/pool.c > > > @@ -268,6 +268,8 @@ void *dma_alloc_from_pool(struct device *dev, size_t > > > size, > > > schedule_work(&atomic_pool_work); > > > } > > > > > > + dev_info(dev, "%s: size %lx, phys addr %llx, flags 0x%x\n", > > > __func__, size, phys, flags); > > > + > > > return ptr; > > > } > > > > I never made it to dma_alloc_from_pool() call from > > dma_direct_alloc_pages(), dma_should_alloc_from_pool() returns False > > from gfpflags_allow_blocking() block. > > I'm a little sceptical about this. The only way you can get memory from these > pools is through dma_alloc_from_pool(), and given how changes in the pool > initialization affected the phone, it's pretty clear some amount of pool > allocation is happening.
Maybe from here iommu_dma_alloc_remap()? I see two paths to dma_alloc_from_pool(), one from dma_direct_alloc_pages() which I mentioned above and 2nd one is thru iommu_dma_alloc(), but the flow doesn't reach up to dma_alloc_from_pool(), and always returns from iommu_dma_alloc_remap(). Regards, Amit Pundir > > Regards, > Nicolas > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu