Re: [RFC 0/6] iommu: generic api migration and grouping
From: Kyungmin Park
Date: Thu Jun 02 2011 - 19:57:14 EST
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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/