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 <ohad@xxxxxxxxxx> 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 | 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/media/video/omap3isp/ispvideo.c | 4 +- > 24 files changed, 451 insertions(+), 151 deletions(-) > rename arch/arm/plat-omap/{ => include/plat}/iopgtable.h (84%) > create mode 100644 drivers/iommu/Kconfig > create mode 100644 drivers/iommu/Makefile > rename drivers/{base => iommu}/iommu.c (100%) > rename arch/arm/mach-msm/iommu.c => drivers/iommu/msm-iommu.c (100%) > rename arch/arm/plat-omap/iommu-debug.c => drivers/iommu/omap-iommu-debug.c (99%) > rename arch/arm/plat-omap/iommu.c => drivers/iommu/omap-iommu.c (77%) > rename arch/arm/plat-omap/iovmm.c => drivers/iommu/omap-iovmm.c (85%) > > -- > 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 > -- 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
