On Thu, Jul 6, 2017 at 9:23 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote: >> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote: >>> On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >>>> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote: > >>> >>> I'd say that this is something that has been consistently tried to be >>> avoided by V4L2 and that's why it's so tightly integrated with DMA >>> mapping. IMHO re-implementing the code that's already there in >>> videobuf2 again in the driver, only because, for no good reason >>> mentioned as for now, having a loadable module providing DMA ops was >>> disliked. >> >> Sorry, I intended to mean: >> >> IMHO re-implementing the code that's already there in videobuf2 again >> in the driver, only because, for no good reason mentioned as for now, >> having a loadable module providing DMA ops was disliked, would make no >> sense. > > Why would we need to duplicate that code? I would expect that the videobuf2 > core can simply call the regular dma_mapping interfaces, and you handle the > IOPTE generation at the point when the buffer is handed off from the core > code to the device driver. Am I missing something? Well, for example, the iommu-dma helpers already implement all the IOVA management, SG iterations, IOMMU API calls, sanity checks and so on. There is a significant amount of common code. On the other hand, if it's strictly about base/dma-mapping, we might not need it indeed. The driver could call iommu-dma helpers directly, without the need to provide its own DMA ops. One caveat, though, we are not able to obtain coherent (i.e. uncached) memory with this approach, which might have some performance effects and complicates the code, that would now need to flush caches even for some small internal buffers. Best regards, Tomasz
