On Tue, Apr 19, 2011 at 09:35:56PM +0900, Kyungmin Park wrote: > On Tue, Apr 19, 2011 at 9:01 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Tuesday 19 April 2011, Kyungmin Park wrote: > >> On Mon, Apr 18, 2011 at 11:13 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > >> > On Monday 18 April 2011, Kyungmin Park wrote: > >> >> On Mon, Apr 18, 2011 at 8:58 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > >> >> > > >> >> > One missing piece is still a way for a platform to provide both > >> >> > the iommu and the dma-mapping API in a unified driver. Right now, > >> >> > you have to export both interface for a generic solution. > >> >> > >> >> Actually MSM and we (Michal, Marek) tried to merge the generic IOMMU > >> >> implementation into mm, but MM did't accept it. > >> > > >> > I'm confused. What do you mean with MM? > >> linux/mm, Memory Management. > > > > I'm still confused. What were you suggesting to merge in there? > > Do you have a link to a mailing list discussion? > > First, Zach Pfeffer <zpfeffer@xxxxxxxxxxxxxx> sent the patch > https://patchwork.kernel.org/patch/108736/ > > Second, Michal tried it. > http://lkml.org/lkml/2010/9/6/41 > > http://lwn.net/Articles/403643/ > https://patchwork.kernel.org/patch/157451/ This shows why ARM is in such a problem. People love to create new frameworks and infrastructure where they find existing stuff lacking, rather than looking at what other architectures do and adapt. As I'm sure has already mentioned, the kernel already has support for IOMMUs in the DMA path with several non-ARM architectures, and this support is managed through the existing DMA API. When you want a device behind an IOMMU to perform DMA, the driver uses the DMA API in the standard way as if there was no IOMMU there. As part of the DMA API, particularly the SG list part, the DMA API is allowed to coalesce the SG entries together if it can arrange the IOMMU mappings to achieve a continguous mapping for the device. Remember, dma_map_sg() is allowed to return _fewer_ entries in the scatterlist than was passed to it for this very purpose. In order to transition ARM over to this, we need to modify the scatterlist structure by enabling CONFIG_NEED_SG_DMA_LENGTH. We then need to arrange for the DMA API to have the hooks _both_ into the DMA cache coherency code (to ensure that the data hits memory) and the IOMMU code (this part is missing from ARM.) The current abstractions in the generic header files don't allow for this. I don't believe there's any need for any major new framework - and I don't think I'm alone in thinking that, especially as this point has been raised more than once when this framework has been submitted. I see no reason why ARM should be any different from other architectures which have IOMMUs, and I don't see why ARM should have to invent a whole new framework to handle IOMMUs. And I see no explanation why the existing hooks are unsuitable - at least as the _initial_ starting point. So, can you please explain why your IOMMU code can not be hidden behind the DMA API. (Please omit any complaints about the mechanics of hooking it in there, such things are solvable.) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
