linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Suman Anna <s-anna@ti.com>,
	linux-omap@vger.kernel.org, iommu@lists.linux-foundation.org,
	Florian Vaussard <florian.vaussard@epfl.ch>,
	sakari.ailus@iki.fi, Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions
Date: Tue, 8 Apr 2014 15:43:22 +0200	[thread overview]
Message-ID: <20140408134322.GT13491@8bytes.org> (raw)
In-Reply-To: <1907788.6W1haHecHa@avalon>

Hi Laurent,

On Tue, Apr 08, 2014 at 02:50:38PM +0200, Laurent Pinchart wrote:
> I agree with you, the two levels are already present, but there's still rough 
> edges that we need to soften. 
> 
> The ARM DMA API implementation requires someone to create the VA space mapping 
> by calling arm_iommu_create_mapping() and attach devices to mappings by 
> calling arm_iommu_attach_device().

Who is "someone" in this case?

> This must only be performed for devices that use the DMA API, devices
> that manage their IOMMU directly will call to the IOMMU API directly.
> 
> One obvious possibility is to call those functions in the IOMMU bus masters 
> device drivers. This is pretty easy, but makes the drivers IOMMU-aware (which 
> I'd like to avoid) and doesn't allow multiple bus masters to share a VA space 
> mapping. Another possibility is to place the calls in the IOMMU drivers. This 
> has the advantage of removing any IOMMU knowledge from bus masters device 
> drivers and allowing multiple bus masters per IOMMU, but makes IOMMU 
> management by the DMA API unconditional.

Why does that make IOMMU management by the DMA API unconditional? On x86
it works this way: The IOMMU drivers create DMA-API mappings for the
devices by default. So any driver can use the DMA-API just
out-of-the-box without being aware of an IOMMU. If the driver wants to
deal with the IOMMU directly, it creates its own iommu-domain and
attaches the device to it. The device uses the drivers domain then and
not the DMA-API domain setup by the IOMMU driver. On iommu-detach the
device is assigned back to its DMA-API domain.

> > The way this works on x86 is that a device driver can use the DMA-API per
> > default. If it wants to use the IOMMU-API it has to allocate a domain and
> > add the device it handles to this domain (it can't use DMA-API anymore
> > then).
> 
> Are drivers supposed to reimplement the DMA API internally in that case?

Usually not, but possible. Device drivers use the IOMMU-API when they
want to control the io-addresses themselves. This is the case for VFIO
for example, where a given range from a process address space is mapped
into a device address space. In those cases the device driver usally
does not need to implement its own address allocator.


Regards,

	Joerg



  reply	other threads:[~2014-04-08 13:43 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-08  0:46 [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions Laurent Pinchart
2014-03-08  0:46 ` [PATCH 1/5] iommu/omap: Use the cache cleaning API Laurent Pinchart
     [not found]   ` <1394239574-2389-2-git-send-email-laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
2014-03-14  2:47     ` Suman Anna
2014-03-14 16:15       ` Santosh Shilimkar
2014-03-14 16:38         ` Laurent Pinchart
2014-03-14 17:51           ` Santosh Shilimkar
     [not found]             ` <5323418B.90805-l0cyMroinI0@public.gmane.org>
2014-03-15  1:49               ` Suman Anna
2014-03-15 17:54                 ` Santosh Shilimkar
     [not found]                   ` <532493DF.5010409-l0cyMroinI0@public.gmane.org>
2014-03-17 19:16                     ` Suman Anna
2014-03-17 22:56                 ` Laurent Pinchart
2014-03-14 16:57         ` Arnd Bergmann
2014-03-14 17:59           ` Santosh Shilimkar
     [not found]           ` <201403141757.48824.arnd-r2nGTMty4D4@public.gmane.org>
2014-03-17 23:12             ` Laurent Pinchart
2014-03-18  1:20               ` Suman Anna
     [not found] ` <1394239574-2389-1-git-send-email-laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
2014-03-08  0:46   ` [PATCH 2/5] iommu/omap: Fix 'no page for' debug message in flush_iotlb_page() Laurent Pinchart
     [not found]     ` <1394239574-2389-3-git-send-email-laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
2014-03-13 22:16       ` Suman Anna
2014-03-14  9:50         ` Laurent Pinchart
2014-03-08  0:46   ` [PATCH 3/5] iommu/omap: Flush the TLB only after updating translation table entries Laurent Pinchart
     [not found]     ` <1394239574-2389-4-git-send-email-laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
2014-03-13 22:27       ` Suman Anna
     [not found]         ` <532230DA.30302-l0cyMroinI0@public.gmane.org>
2014-03-14  9:58           ` Laurent Pinchart
2014-03-15  0:18             ` Suman Anna
2014-03-14  2:33   ` [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions Suman Anna
2014-03-14 11:00     ` Laurent Pinchart
2014-03-16 21:54       ` Sakari Ailus
     [not found]         ` <20140316215455.GA2108-S+BSfZ9RZZmRSg0ZkenSGLdO1Tsj/99ntUK59QYPAWc@public.gmane.org>
2014-03-17 19:58           ` Suman Anna
2014-03-17 22:44             ` Laurent Pinchart
2014-04-04 12:23               ` Marek Szyprowski
     [not found]                 ` <533EA45D.70002-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-04-08 13:09                   ` Laurent Pinchart
2014-04-04 10:18       ` Joerg Roedel
     [not found]         ` <20140404101811.GR13491-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-04-08 12:50           ` Laurent Pinchart
2014-04-08 13:43             ` Joerg Roedel [this message]
2014-04-08 15:02               ` Laurent Pinchart
2014-04-09 15:08                 ` Joerg Roedel
2014-04-10 23:30                   ` Laurent Pinchart
2014-03-08  0:46 ` [PATCH 4/5] iommu/omap: Remove comment about supporting single page mappings only Laurent Pinchart
2014-03-08  0:46 ` [PATCH 5/5] iommu/omap: Fix map protection value handling Laurent Pinchart
     [not found]   ` <1394239574-2389-6-git-send-email-laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
2014-03-14  0:07     ` Suman Anna
2014-03-14  9:46       ` Laurent Pinchart
2014-03-15  0:16         ` Suman Anna
2014-03-08 11:04 ` [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions Sakari Ailus
2014-03-12 15:26 ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140408134322.GT13491@8bytes.org \
    --to=joro@8bytes.org \
    --cc=florian.vaussard@epfl.ch \
    --cc=iommu@lists.linux-foundation.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=s-anna@ti.com \
    --cc=sakari.ailus@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).