06.02.2019 17:56, Dmitry Osipenko пишет: > 06.02.2019 17:53, Thierry Reding пишет: >> On Tue, Feb 05, 2019 at 05:26:25PM +0300, Dmitry Osipenko wrote: >> [...] >>> Oh, another important moment is that physically contiguous dma_buf >>> allocation isn't guaranteed by the DMA API. This may become a problem >>> for T186+ that can transfer up to 64K. We need to enforce the >>> contiguous-allocation requirement by using >>> dma_alloc_attrs(DMA_ATTR_FORCE_CONTIGUOUS) instead of the >>> dma_alloc_coherent(), please see my other comment below. >> >> Actually I don't think that's necessary here. DMA_ATTR_FORCE_CONTIGUOUS >> only seems relevant if you've got an IOMMU attached to the device to >> make sure the physical memory is also contiguous. >> >> See this extract from Documentation/DMA-attributes.txt: >> >> | DMA_ATTR_FORCE_CONTIGUOUS >> | ------------------------- >> | >> | By default DMA-mapping subsystem is allowed to assemble the buffer >> | allocated by dma_alloc_attrs() function from individual pages if it can >> | be mapped as contiguous chunk into device dma address space. By >> | specifying this attribute the allocated buffer is forced to be contiguous >> | also in physical memory. >> >> We don't have an IOMMU attached to I2C or APBDMA, so this can't happen >> and even if we had an IOMMU attached, all we care about is the device's >> DMA address space, which means IOVA space, and that would still be >> guaranteed to be contiguous, according to the above. > > Yes, but doesn't T186+ have IOMMU support for the DMA controller? > Ah, sorry I probably skimmed way too quickly thorough the message. Hmm.. well, seems I was wrong. Sowjanya, after all looks like it should be fine to use the default dma_alloc_coherent() helper. Please put it back in v14.
