Re: [RFC 0/6] iommu: generic api migration and grouping
On Tue, Jun 7, 2011 at 12:58 PM, Roedel, Joerg wrote: > Btw, mind to split out your changes which move the iommu-api into > drivers/iommu? I can merge them meanwhile into my iommu tree and start > working on a proposal for the generic large page-size support. Sure, that will be great. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Tue, Jun 07, 2011 at 05:22:11AM -0400, Ohad Ben-Cohen wrote: > On Tue, Jun 7, 2011 at 10:52 AM, Roedel, Joerg wrote: > > Yup. Btw, is there any IOMMU hardware which supports non-natural > > alignment? In this case we need to expose these requirements somehow. > > Not sure there are. Let's start with natural alignment, and extend it > only if someone with additional requirements shows up. Btw, mind to split out your changes which move the iommu-api into drivers/iommu? I can merge them meanwhile into my iommu tree and start working on a proposal for the generic large page-size support. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Tue, Jun 7, 2011 at 10:52 AM, Roedel, Joerg wrote: > Yup. Btw, is there any IOMMU hardware which supports non-natural > alignment? In this case we need to expose these requirements somehow. Not sure there are. Let's start with natural alignment, and extend it only if someone with additional requirements shows up. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Mon, Jun 06, 2011 at 04:09:33PM -0400, Ohad Ben-Cohen wrote: > On Mon, Jun 6, 2011 at 10:20 PM, Roedel, Joerg wrote: > > Well, it certainly makes sense to have a single implementation for this. > > But I want to hide this complexity to the user of the IOMMU-API. The > > best choice is to put this into the layer between the IOMMU-API and the > > backend implementation. > > I agree. > > The IOMMU API should take physically contiguous regions from the user, > split them up according to page-sizes (/alignment requirements) > supported by the hardware, and then tell the underlying implementation > what to map where. Yup. Btw, is there any IOMMU hardware which supports non-natural alignment? In this case we need to expose these requirements somehow. Regards, Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Mon, Jun 6, 2011 at 10:20 PM, Roedel, Joerg wrote: > Well, it certainly makes sense to have a single implementation for this. > But I want to hide this complexity to the user of the IOMMU-API. The > best choice is to put this into the layer between the IOMMU-API and the > backend implementation. I agree. The IOMMU API should take physically contiguous regions from the user, split them up according to page-sizes (/alignment requirements) supported by the hardware, and then tell the underlying implementation what to map where. > That interface is not put into stone. There were other complains about > the ->unmap part recently, so there is certainly room for improvement > there. Once the supported page sizes are exposed to the framework, the current ->unmap API should probably be enough. 'va' + 'order' sounds like all the information an implementation needs to unmap a page. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Mon, Jun 06, 2011 at 12:36:13PM -0400, Ohad Ben-Cohen wrote: > On Mon, Jun 6, 2011 at 6:35 PM, Roedel, Joerg wrote: > > On Mon, Jun 06, 2011 at 11:15:30AM -0400, Ohad Ben-Cohen wrote: > > > >> This is insufficient; users need somehow to tell what page sizes are > >> supported by the underlying hardware (we can't assume host page-sizes, > >> and we want to use bigger pages whenever possible, to relax the TLB > >> pressure). > > / > > What does the IOMMU-API user need this info for? On the x86 IOMMUs these > > details are handled transparently by the IOMMU driver. > > That's one way to do that, but then it means duplicating this logic > inside the different IOMMU implementations. > > Take the OMAP (and seemingly MSM too) example: we have 4KB, 64KB, 1MB > and 16MB page-table entries. When we map a memory region, we need to > break it up to a minimum number of pages (while validating > sizes/alignments are sane). It's not complicated, but it can be nice > if it'd be implemented only once. Well, it certainly makes sense to have a single implementation for this. But I want to hide this complexity to the user of the IOMMU-API. The best choice is to put this into the layer between the IOMMU-API and the backend implementation. > In addition, unless we require 'va' and 'pa' to have the exact same > alignment, we might run into specific page configuration that the > IOMMU implementation cannot restore on ->unmap, since unmap only takes > 'va' and 'order'. So we will either have to supply 'pa' too, or have > the implementation remember the mapping in order to unmap it later. > That begins to be a bit messy... That interface is not put into stone. There were other complains about the ->unmap part recently, so there is certainly room for improvement there. Regards, Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Mon, Jun 6, 2011 at 6:35 PM, Roedel, Joerg wrote: > On Mon, Jun 06, 2011 at 11:15:30AM -0400, Ohad Ben-Cohen wrote: > >> This is insufficient; users need somehow to tell what page sizes are >> supported by the underlying hardware (we can't assume host page-sizes, >> and we want to use bigger pages whenever possible, to relax the TLB >> pressure). > / > What does the IOMMU-API user need this info for? On the x86 IOMMUs these > details are handled transparently by the IOMMU driver. That's one way to do that, but then it means duplicating this logic inside the different IOMMU implementations. Take the OMAP (and seemingly MSM too) example: we have 4KB, 64KB, 1MB and 16MB page-table entries. When we map a memory region, we need to break it up to a minimum number of pages (while validating sizes/alignments are sane). It's not complicated, but it can be nice if it'd be implemented only once. In addition, unless we require 'va' and 'pa' to have the exact same alignment, we might run into specific page configuration that the IOMMU implementation cannot restore on ->unmap, since unmap only takes 'va' and 'order'. So we will either have to supply 'pa' too, or have the implementation remember the mapping in order to unmap it later. That begins to be a bit messy... -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Mon, Jun 06, 2011 at 11:15:30AM -0400, Ohad Ben-Cohen wrote: > This is insufficient; users need somehow to tell what page sizes are > supported by the underlying hardware (we can't assume host page-sizes, > and we want to use bigger pages whenever possible, to relax the TLB > pressure). / What does the IOMMU-API user need this info for? On the x86 IOMMUs these details are handled transparently by the IOMMU driver. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Mon, Jun 6, 2011 at 12:10 PM, Arnd Bergmann wrote: >> I'd still prefer us to take small steps here, and not gate the omap >> iommu cleanups with Marek's generic dma_map_ops work though. Let's go >> forward and migrate omap's iommu to the generic iommu API, so new code >> will be able to use it (e.g. the long coming virtio-based IPC/AMP >> framework). > > Yes, of course. That's what I meant. Moving over omap to the IOMMU API > is required anyway, so there is no point delaying that. Ok, great ! -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
Hi Joerg, On Mon, Jun 6, 2011 at 1:09 PM, Roedel, Joerg wrote: > The IOMMU-API already supports multiple page-sizes. See the > 'order'-parameter of the map/unmap functions. This is insufficient; users need somehow to tell what page sizes are supported by the underlying hardware (we can't assume host page-sizes, and we want to use bigger pages whenever possible, to relax the TLB pressure). >> Further generalizing of iovmm strongly depends on our broader plans for >> providing a generic virtual memory manager and allocation framework >> (which, as discussed, should be separated from a specific mapper). > > The generic vmm for DMA is called DMA-API :) Any reason for not using > that (those reasons should be fixed)? This is definitely something we will look into (dspbridge will need it too, not only omap3isp). Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
Hi, On Thu, Jun 02, 2011 at 06:27:37PM -0400, Ohad Ben-Cohen wrote: > First stab at iommu consolidation: > > - Migrate OMAP's iommu driver to the generic iommu API. With this in hand, > users can now start using the generic iommu layer instead of calling > omap-specific iommu API. > > New code that requires functionality missing from the generic iommu api, > will add that functionality in the generic framework (e.g. adding framework > awareness to multi page sizes, supported by the underlying hardware, will > avoid the otherwise-inevitable code duplication when mapping a memory > region). The IOMMU-API already supports multiple page-sizes. See the 'order'-parameter of the map/unmap functions. > Further generalizing of iovmm strongly depends on our broader plans for > providing a generic virtual memory manager and allocation framework > (which, as discussed, should be separated from a specific mapper). The generic vmm for DMA is called DMA-API :) Any reason for not using that (those reasons should be fixed)? > iovmm has a mainline user: omap3isp, and therefore must be maintained, > but new potential users will either have to generalize it, or come up > with a different generic framework that will replace it. Moving to the DMA-API should be considered here. If it is too much work iovmm can stay for a while, but the goal should be to get rid of it and only use the DMA-API. > - Create a dedicated iommu drivers folder (and put the base iommu code there) Very good idea. Joerg P.S.: Please also Cc the iommu-list (io...@lists.linux-foundation.org) in the future for IOMMU related patches. -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Sunday 05 June 2011, Ohad Ben-Cohen wrote: > > As far as I can tell, once we have that in > > place, we you can migrate omap3isp from iovmm to dma-mapping and > > remove iovmm. > > Sounds like a plan. > > I'd still prefer us to take small steps here, and not gate the omap > iommu cleanups with Marek's generic dma_map_ops work though. Let's go > forward and migrate omap's iommu to the generic iommu API, so new code > will be able to use it (e.g. the long coming virtio-based IPC/AMP > framework). Yes, of course. That's what I meant. Moving over omap to the IOMMU API is required anyway, so there is no point delaying that. > We'll migrate iovmm/omap3isp just enough so they don't break, but once > the generic dma_map_ops work materializes, we'd be able to complete > the migration, remove iovmm, and decouple omap3isp from omap-specific > iommu APIs for good. Ok, great! Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
Hi Kyungmin, On Fri, Jun 3, 2011 at 2:57 AM, Kyungmin Park wrote: > Please see the RFC patch, ARM: DMA-mapping & IOMMU integration > http://www.spinics.net/lists/linux-mm/msg19856.html Marek's work somehow escaped me, thanks for the pointers ! Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
Hi Arnd, On Fri, Jun 3, 2011 at 6:53 PM, Arnd Bergmann wrote: > I think the future of iovmm is looking not so good. Marek Szyprowski > is working on a generic version of the dma-mapping API (dma_map_ops) > based on the iommu API. Nice! I missed Marek's work somehow. > As far as I can tell, once we have that in > place, we you can migrate omap3isp from iovmm to dma-mapping and > remove iovmm. Sounds like a plan. I'd still prefer us to take small steps here, and not gate the omap iommu cleanups with Marek's generic dma_map_ops work though. Let's go forward and migrate omap's iommu to the generic iommu API, so new code will be able to use it (e.g. the long coming virtio-based IPC/AMP framework). We'll migrate iovmm/omap3isp just enough so they don't break, but once the generic dma_map_ops work materializes, we'd be able to complete the migration, remove iovmm, and decouple omap3isp from omap-specific iommu APIs for good. >> I've only moved the omap and msm implementations for now, to demonstrate >> the idea (and support the ARM diet :), but if this is found desirable, >> we can bring in intel-iommu.c and amd_iommu.c as well. > > Yes, very good idea. Great! (to move intel-iommu.c, we'll have to move the declaration of pci_find_upstream_pcie_bridge() from drivers/pci/pci.h to include/linux/pci.h, but that's probably not too bad). Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Friday 03 June 2011, Ohad Ben-Cohen wrote: > First stab at iommu consolidation: Hi Ohad, Great to see your progress here! > - Migrate OMAP's iommu driver to the generic iommu API. With this in hand, > users can now start using the generic iommu layer instead of calling > omap-specific iommu API. > > New code that requires functionality missing from the generic iommu api, > will add that functionality in the generic framework (e.g. adding framework > awareness to multi page sizes, supported by the underlying hardware, will > avoid the otherwise-inevitable code duplication when mapping a memory > region). > > OMAP-specific api that is still exposed in the omap iommu driver can > now be either moved to the generic iommu framework, or just removed (if not > used). > > This api (and other omap-specific primitives like struct iommu) needs to > be omapified (i.e. renamed to include an 'omap_' prefix). At this early > point of this patch set this is too much churn though, so I'll do that > in the following iteration, after (and if), the general direction is > accepted. Sounds all good. > - Migrate OMAP's iovmm (virtual memory manager) driver to the generic > iommu API. With this in hand, iovmm no longer uses omap-specific api > for mapping/unmapping operations. Nevertheless, iovmm is still coupled > with omap's iommu even with this change: it assumes omap page sizes, > and it uses omap's iommu objects to maintain its internal state. > > Further generalizing of iovmm strongly depends on our broader plans for > providing a generic virtual memory manager and allocation framework > (which, as discussed, should be separated from a specific mapper). > > iovmm has a mainline user: omap3isp, and therefore must be maintained, > but new potential users will either have to generalize it, or come up > with a different generic framework that will replace it. I think the future of iovmm is looking not so good. Marek Szyprowski is working on a generic version of the dma-mapping API (dma_map_ops) based on the iommu API. As far as I can tell, once we have that in place, we you can migrate omap3isp from iovmm to dma-mapping and remove iovmm. Of course if there are things missing from the dma-mapping API that are present in iovmm, we should know about them so that we can extend the dma-mapping API accordingly. > - Migrate OMAP's iommu mainline user, omap3isp, to the generic API as well > (so it doesn't break). As with iovmm, omap3isp still depends on > omap's iommu, mainly because iovmm depends on it, but also for > iommu context saving and restoring. > > It is definitely desirable to completely remove omap3isp's dependency > on the omap-specific iommu layer, and that will be possible as the > required functionality will be added to generic framework. ok. > - Create a dedicated iommu drivers folder (and put the base iommu code there) > > - Move OMAP's and MSM's iommu drivers to that drivers iommu folder > > Putting all iommu drivers together will ease finding similarities > between different platforms, with the intention of solving problems once, > in a generic framework which everyone can use. > > I've only moved the omap and msm implementations for now, to demonstrate > the idea (and support the ARM diet :), but if this is found desirable, > we can bring in intel-iommu.c and amd_iommu.c as well. Yes, very good idea. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
Hi, Good approach. CC'ed the Samsung IOMMU developer. Marek. BTW, Russell wants to use the DMA based IOMMU? Please see the RFC patch, ARM: DMA-mapping & IOMMU integration http://www.spinics.net/lists/linux-mm/msg19856.html Thank you, Kyungmin Park On Fri, Jun 3, 2011 at 7:27 AM, Ohad Ben-Cohen wrote: > First stab at iommu consolidation: > > - Migrate OMAP's iommu driver to the generic iommu API. With this in hand, > users can now start using the generic iommu layer instead of calling > omap-specific iommu API. > > New code that requires functionality missing from the generic iommu api, > will add that functionality in the generic framework (e.g. adding framework > awareness to multi page sizes, supported by the underlying hardware, will > avoid the otherwise-inevitable code duplication when mapping a memory > region). > > OMAP-specific api that is still exposed in the omap iommu driver can > now be either moved to the generic iommu framework, or just removed (if not > used). > > This api (and other omap-specific primitives like struct iommu) needs to > be omapified (i.e. renamed to include an 'omap_' prefix). At this early > point of this patch set this is too much churn though, so I'll do that > in the following iteration, after (and if), the general direction is > accepted. > > - Migrate OMAP's iovmm (virtual memory manager) driver to the generic > iommu API. With this in hand, iovmm no longer uses omap-specific api > for mapping/unmapping operations. Nevertheless, iovmm is still coupled > with omap's iommu even with this change: it assumes omap page sizes, > and it uses omap's iommu objects to maintain its internal state. > > Further generalizing of iovmm strongly depends on our broader plans for > providing a generic virtual memory manager and allocation framework > (which, as discussed, should be separated from a specific mapper). > > iovmm has a mainline user: omap3isp, and therefore must be maintained, > but new potential users will either have to generalize it, or come up > with a different generic framework that will replace it. > > - Migrate OMAP's iommu mainline user, omap3isp, to the generic API as well > (so it doesn't break). As with iovmm, omap3isp still depends on > omap's iommu, mainly because iovmm depends on it, but also for > iommu context saving and restoring. > > It is definitely desirable to completely remove omap3isp's dependency > on the omap-specific iommu layer, and that will be possible as the > required functionality will be added to generic framework. > > - Create a dedicated iommu drivers folder (and put the base iommu code there) > - Move OMAP's and MSM's iommu drivers to that drivers iommu folder > > Putting all iommu drivers together will ease finding similarities > between different platforms, with the intention of solving problems once, > in a generic framework which everyone can use. > > I've only moved the omap and msm implementations for now, to demonstrate > the idea (and support the ARM diet :), but if this is found desirable, > we can bring in intel-iommu.c and amd_iommu.c as well. > > Meta: > > - This patch set is not bisectable; it was splitted (and ordered) this way > to ease its review. Later iterations of this patch set will fix that > (most likely by squashing the first three patches) > - Based on and tested with 3.0-rc1 > - OMAP's iommu code was tested on both OMAP3 and OMAP4 > - omap3isp code was tested with a sensor-less OMAP3 (memory-to-memory only) > (thanks Laurent Pinchart for showing me the magic needed to test omap3isp :) > - MSM code was only compile tested > > Ohad Ben-Cohen (6): > omap: iommu: generic iommu api migration > omap: iovmm: generic iommu api migration > media: omap3isp: generic iommu api migration > drivers: iommu: move to a dedicated folder > omap: iommu/iovmm: move to dedicated iommu folder > msm: iommu: move to dedicated iommu drivers folder > > arch/arm/mach-msm/Kconfig | 15 - > arch/arm/mach-msm/Makefile | 2 +- > arch/arm/plat-omap/Kconfig | 12 - > arch/arm/plat-omap/Makefile | 2 - > arch/arm/plat-omap/include/plat/iommu.h | 3 +- > arch/arm/plat-omap/{ => include/plat}/iopgtable.h | 18 ++ > arch/arm/plat-omap/include/plat/iovmm.h | 27 +- > arch/x86/Kconfig | 5 +- > drivers/Kconfig | 2 + > drivers/Makefile | 1 + > drivers/base/Makefile | 1 - > drivers/iommu/Kconfig | 32 +++ > drivers/iommu/Makefile | 5 + > drivers/{base => iommu}/iommu.c | 0 > .../mach-msm/iommu.c => drivers/iommu/msm-iommu.c | 0 > .../iommu/omap-iommu-debug.c | 2 +- > .../iommu.c => drivers/iommu/omap-iommu.c
[RFC 0/6] iommu: generic api migration and grouping
First stab at iommu consolidation: - Migrate OMAP's iommu driver to the generic iommu API. With this in hand, users can now start using the generic iommu layer instead of calling omap-specific iommu API. New code that requires functionality missing from the generic iommu api, will add that functionality in the generic framework (e.g. adding framework awareness to multi page sizes, supported by the underlying hardware, will avoid the otherwise-inevitable code duplication when mapping a memory region). OMAP-specific api that is still exposed in the omap iommu driver can now be either moved to the generic iommu framework, or just removed (if not used). This api (and other omap-specific primitives like struct iommu) needs to be omapified (i.e. renamed to include an 'omap_' prefix). At this early point of this patch set this is too much churn though, so I'll do that in the following iteration, after (and if), the general direction is accepted. - Migrate OMAP's iovmm (virtual memory manager) driver to the generic iommu API. With this in hand, iovmm no longer uses omap-specific api for mapping/unmapping operations. Nevertheless, iovmm is still coupled with omap's iommu even with this change: it assumes omap page sizes, and it uses omap's iommu objects to maintain its internal state. Further generalizing of iovmm strongly depends on our broader plans for providing a generic virtual memory manager and allocation framework (which, as discussed, should be separated from a specific mapper). iovmm has a mainline user: omap3isp, and therefore must be maintained, but new potential users will either have to generalize it, or come up with a different generic framework that will replace it. - Migrate OMAP's iommu mainline user, omap3isp, to the generic API as well (so it doesn't break). As with iovmm, omap3isp still depends on omap's iommu, mainly because iovmm depends on it, but also for iommu context saving and restoring. It is definitely desirable to completely remove omap3isp's dependency on the omap-specific iommu layer, and that will be possible as the required functionality will be added to generic framework. - Create a dedicated iommu drivers folder (and put the base iommu code there) - Move OMAP's and MSM's iommu drivers to that drivers iommu folder Putting all iommu drivers together will ease finding similarities between different platforms, with the intention of solving problems once, in a generic framework which everyone can use. I've only moved the omap and msm implementations for now, to demonstrate the idea (and support the ARM diet :), but if this is found desirable, we can bring in intel-iommu.c and amd_iommu.c as well. Meta: - This patch set is not bisectable; it was splitted (and ordered) this way to ease its review. Later iterations of this patch set will fix that (most likely by squashing the first three patches) - Based on and tested with 3.0-rc1 - OMAP's iommu code was tested on both OMAP3 and OMAP4 - omap3isp code was tested with a sensor-less OMAP3 (memory-to-memory only) (thanks Laurent Pinchart for showing me the magic needed to test omap3isp :) - MSM code was only compile tested Ohad Ben-Cohen (6): omap: iommu: generic iommu api migration omap: iovmm: generic iommu api migration media: omap3isp: generic iommu api migration drivers: iommu: move to a dedicated folder omap: iommu/iovmm: move to dedicated iommu folder msm: iommu: move to dedicated iommu drivers folder arch/arm/mach-msm/Kconfig | 15 - arch/arm/mach-msm/Makefile |2 +- arch/arm/plat-omap/Kconfig | 12 - arch/arm/plat-omap/Makefile|2 - arch/arm/plat-omap/include/plat/iommu.h|3 +- arch/arm/plat-omap/{ => include/plat}/iopgtable.h | 18 ++ arch/arm/plat-omap/include/plat/iovmm.h| 27 +- arch/x86/Kconfig |5 +- drivers/Kconfig|2 + drivers/Makefile |1 + drivers/base/Makefile |1 - drivers/iommu/Kconfig | 32 +++ drivers/iommu/Makefile |5 + drivers/{base => iommu}/iommu.c|0 .../mach-msm/iommu.c => drivers/iommu/msm-iommu.c |0 .../iommu/omap-iommu-debug.c |2 +- .../iommu.c => drivers/iommu/omap-iommu.c | 290 +--- .../iovmm.c => drivers/iommu/omap-iovmm.c | 113 +--- drivers/media/video/Kconfig|2 +- drivers/media/video/omap3isp/isp.c | 41 +++- drivers/media/video/omap3isp/isp.h |3 + drivers/media/video/omap3isp/ispccdc.c | 16 +- drivers/media/video/omap3isp/ispstat.c |6 +- drivers/medi