On Thu, Mar 05 2015 at 02:38:45 AM, Robin Murphy <[email protected]> wrote: > Hi Mitch, > > On 05/03/15 00:18, Mitchel Humpherys wrote: >> We're currently mapping a page in arm_smmu_flush_pgtable without ever >> unmapping it. Fix this by calling dma_unmap_page on the returned dma >> address. Since the only reason we're calling dma_map_page is to make >> sure it actually gets flushed out to RAM, we can just call >> dma_unmap_page immediately following the map. >> >> Without this, eventually swiotlb runs out of memory and starts printing >> things like: >> >> [ 35.545076] arm-smmu d00000.arm,smmu: swiotlb buffer is full (sz: >> 128 bytes) >> > > So, you have non-coherent SMMUs too ;) The real problem is that the SMMU's > DMA mask is wrong (as it happens I've just given Will a patch to fix that) > - this is really just doing a whole bunch of unnecessary work (two memory > copies and two cache flushes, one of which isn't even flushing the right > area) to hide the problem. With an appropriate DMA mask set, > swiotlb_map_page becomes a no-op and we fall through to the cache flush > without ever allocating anything.
Yeah I noticed that as well... But isn't this still incorrect usage of the API (DMA-API-HOWTO.txt seems to indicate that calls to map should always be balanced with calls to unmap)? What we really want to do here is just call __dma_map_area directly, but the comment on that guy expressly forbids it... Not sure what's worse, abusing the DMA API or disobeying that comment? -Mitch -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
