On Thu, Jul 6, 2017 at 3:31 PM, Tomasz Figa <tf...@chromium.org> wrote: > On Thu, Jul 6, 2017 at 9:23 PM, Arnd Bergmann <a...@arndb.de> wrote: >> On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa <tf...@chromium.org> wrote: >>> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa <tf...@chromium.org> wrote: >>> >>> 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.
Yes, that's what I meant: if using the IOMMU interface helps, I don't see anything wrong with that, but using the iommu based dma_map_ops seems like it may introduce more problems than it solves. Arnd