[RFC 0/6] iommu: generic api migration and grouping

* [RFC 0/6] iommu: generic api migration and grouping
@ 2011-06-02 22:27 ` Ohad Ben-Cohen
  0 siblings, 0 replies; 83+ messages in thread
From: Ohad Ben-Cohen @ 2011-06-02 22:27 UTC (permalink / raw)
  To: linux-media, linux-omap, linux-kernel, linux-arm-kernel
  Cc: laurent.pinchart, Hiroshi.DOYU, arnd, davidb, Joerg.Roedel,
	Ohad Ben-Cohen

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%)

^ permalink raw reply	[flat|nested] 83+ messages in thread