On Fri, Jul 21, 2017 at 7:09 AM, Sakari Ailus <sakari.ai...@iki.fi> wrote: > Hi Arnd, > > On Wed, Jul 19, 2017 at 09:24:41AM +0200, Arnd Bergmann wrote: >> On Wed, Jul 19, 2017 at 5:12 AM, Yong Zhi <yong....@intel.com> wrote: >> > From: Tomasz Figa <tf...@chromium.org> >> > >> > This patch adds support for the IPU3 DMA mapping API. >> > >> > Signed-off-by: Tomasz Figa <tf...@chromium.org> >> > Signed-off-by: Yong Zhi <yong....@intel.com> >> >> This needs some explanation on why you decided to go down the >> route of adding your own dma_map_ops. It's not obvious at all, >> and and I'm still concerned that this complicates things more than >> it helps. > > There are a few considerations here --- they could be documented in the > patch commit message > > - The device has its own MMU. The default x86 DMA ops assume there isn't. > > - As this is an image signal processor device, the buffers are typically > large (often in the range of tens of MB) and they do not need to be > physically contiguous. The current implementation of e.g. > drivers/iommu/intel-iommu.c allocate memory using alloc_pages() which is > unfeasible for such single allocations. Neither CMA is needed. > > Also other IOMMU implementations have their own DMA ops currently. > > I agree it'd be nice to unify these in the long run but I don't think this > stands apart from the rest currently --- except that the MMU is only used > by a single PCI device, the same which it is contained in.
On top of what Sakari said, it just perfectly matches what V4L2 videobuf2 framework expects. It does all the buffer mapping and synchronization using DMA mapping and given the x86 DMA ops being useless for this device, it makes everything that videobuf2 does using them useless too. Best regards, Tomasz
