All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
To: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Cc: "jroedel-l3A5Bk7waGM@public.gmane.org"
	<jroedel-l3A5Bk7waGM@public.gmane.org>,
	"arnd-r2nGTMty4D4@public.gmane.org"
	<arnd-r2nGTMty4D4@public.gmane.org>,
	"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	"thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org"
	<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
	"Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org"
	<Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	"dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org"
	<dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [RFC PATCH 0/7] Introduce automatic DMA configuration for IOMMU masters
Date: Tue, 02 Sep 2014 10:48:02 +0200	[thread overview]
Message-ID: <54058442.2070204@samsung.com> (raw)
In-Reply-To: <20140902083138.GA25379-5wv7dgnIgG8@public.gmane.org>

Hi Will,

On 2014-09-02 10:31, Will Deacon wrote:
> On Tue, Sep 02, 2014 at 07:26:01AM +0100, Marek Szyprowski wrote:
>> On 2014-08-29 17:54, Will Deacon wrote:
>>> This patch series is an RFC to implement IOMMU master configuration into
>>> of_dma_configure. I haven't yet ported any IOMMU drivers to it, so it
>>> remains untested, but I wanted to get some early feedback to ensure that
>>> this doesn't end up going in the wrong direction.
>>>
>>> The idea comes out of my understanding following discussions with Arnd
>>> and David at Kernel Summit / LinuxCon in Chicago. Essentially:
>>>
>>>     - Allow IOMMUs to be probed early and set up per-instance data on their
>>>       of_node
>>>
>>>     - Add a new callback to the iommu_ops structure for adding a device
>>>       with a set of opaque IDs (e.g. Stream IDs or Requester IDs)
>>>
>>>     - Add an of_iommu_configure function, called from of_dma_configure,
>>>       which registers the master IDs with the correspond IOMMU before
>>>       probing the master itself
>>>
>>>     - Where applicable, create an IOMMU domain per device and swizzle the
>>>       DMA ops for that device to use the IOMMU variants.
>>>
>>> I haven't bothered doing anything clever with the DMA masks yet, so I
>>> wouldn't be surprised if we end up chewing through tonnes of memory
>>> allocating IOMMU domains that are far too big at the moment. Again, this
>>> is just an RFC and I'd welcome comments on the general direction of the
>>> series.
>> Thanks for your patches, I wasn't aware the fact that you are working on
>> this. When do you plan to send a second version? I would like to rebase
>> my Exynos IOMMU patches (https://lkml.org/lkml/2014/8/5/183) on top of
>> your work, but I wonder if I should select this version as a base or wait
>> a bit for an update.
> I'll try and get something out today/tomorrow depending on how easily the
> review comments fall out. It would be really great if you get an IOMMU
> working with this (I was going to look at the ARM SMMU once this stops
> moving)

Great, I will wait then for v2.

>   -- I have concerns that allocating one domain per master might be
> too much, but it's hard to tell without an IOMMU driver ported over.

One domain per master is IMHO a sane default configuration. The only default
alternative I see is to have only one domain (related with dma-mapping
subsystem) and bind all devices to it. However I really don't see any
disadvantage of having separate domain per each master and such 
configuration
gives devices better separation.

However we also need to figure out how to let drivers to make their own
configuration, like it is required by Exynos DRM subsystem, which consist
of several devices, each having its own IOMMU controller, but for
convenience those drivers assume that they all have been bound to the same,
single domain.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

WARNING: multiple messages have this Message-ID (diff)
From: m.szyprowski@samsung.com (Marek Szyprowski)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/7] Introduce automatic DMA configuration for IOMMU masters
Date: Tue, 02 Sep 2014 10:48:02 +0200	[thread overview]
Message-ID: <54058442.2070204@samsung.com> (raw)
In-Reply-To: <20140902083138.GA25379@arm.com>

Hi Will,

On 2014-09-02 10:31, Will Deacon wrote:
> On Tue, Sep 02, 2014 at 07:26:01AM +0100, Marek Szyprowski wrote:
>> On 2014-08-29 17:54, Will Deacon wrote:
>>> This patch series is an RFC to implement IOMMU master configuration into
>>> of_dma_configure. I haven't yet ported any IOMMU drivers to it, so it
>>> remains untested, but I wanted to get some early feedback to ensure that
>>> this doesn't end up going in the wrong direction.
>>>
>>> The idea comes out of my understanding following discussions with Arnd
>>> and David at Kernel Summit / LinuxCon in Chicago. Essentially:
>>>
>>>     - Allow IOMMUs to be probed early and set up per-instance data on their
>>>       of_node
>>>
>>>     - Add a new callback to the iommu_ops structure for adding a device
>>>       with a set of opaque IDs (e.g. Stream IDs or Requester IDs)
>>>
>>>     - Add an of_iommu_configure function, called from of_dma_configure,
>>>       which registers the master IDs with the correspond IOMMU before
>>>       probing the master itself
>>>
>>>     - Where applicable, create an IOMMU domain per device and swizzle the
>>>       DMA ops for that device to use the IOMMU variants.
>>>
>>> I haven't bothered doing anything clever with the DMA masks yet, so I
>>> wouldn't be surprised if we end up chewing through tonnes of memory
>>> allocating IOMMU domains that are far too big at the moment. Again, this
>>> is just an RFC and I'd welcome comments on the general direction of the
>>> series.
>> Thanks for your patches, I wasn't aware the fact that you are working on
>> this. When do you plan to send a second version? I would like to rebase
>> my Exynos IOMMU patches (https://lkml.org/lkml/2014/8/5/183) on top of
>> your work, but I wonder if I should select this version as a base or wait
>> a bit for an update.
> I'll try and get something out today/tomorrow depending on how easily the
> review comments fall out. It would be really great if you get an IOMMU
> working with this (I was going to look at the ARM SMMU once this stops
> moving)

Great, I will wait then for v2.

>   -- I have concerns that allocating one domain per master might be
> too much, but it's hard to tell without an IOMMU driver ported over.

One domain per master is IMHO a sane default configuration. The only default
alternative I see is to have only one domain (related with dma-mapping
subsystem) and bind all devices to it. However I really don't see any
disadvantage of having separate domain per each master and such 
configuration
gives devices better separation.

However we also need to figure out how to let drivers to make their own
configuration, like it is required by Exynos DRM subsystem, which consist
of several devices, each having its own IOMMU controller, but for
convenience those drivers assume that they all have been bound to the same,
single domain.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

  parent reply	other threads:[~2014-09-02  8:48 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-29 15:54 [RFC PATCH 0/7] Introduce automatic DMA configuration for IOMMU masters Will Deacon
2014-08-29 15:54 ` Will Deacon
     [not found] ` <1409327670-3495-1-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-08-29 15:54   ` [RFC PATCH 1/7] iommu: provide early initialisation hook for IOMMU drivers Will Deacon
2014-08-29 15:54     ` Will Deacon
     [not found]     ` <1409327670-3495-2-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-09-01  7:52       ` Thierry Reding
2014-09-01  7:52         ` Thierry Reding
2014-09-01 14:31         ` Arnd Bergmann
2014-09-01 14:31           ` Arnd Bergmann
2014-09-01 16:36           ` Will Deacon
2014-09-01 16:36             ` Will Deacon
2014-09-02  6:56         ` Laurent Pinchart
2014-09-02  6:56           ` Laurent Pinchart
2014-09-02 14:47       ` Varun Sethi
2014-09-02 14:47         ` Varun Sethi
2014-09-02 15:04         ` Arnd Bergmann
2014-09-02 15:04           ` Arnd Bergmann
2014-08-29 15:54   ` [RFC PATCH 2/7] dma-mapping: replace set_arch_dma_coherent_ops with arch_setup_dma_ops Will Deacon
2014-08-29 15:54     ` Will Deacon
     [not found]     ` <1409327670-3495-3-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-09-01 14:27       ` Arnd Bergmann
2014-09-01 14:27         ` Arnd Bergmann
2014-09-01 16:20         ` Will Deacon
2014-09-01 16:20           ` Will Deacon
2014-08-29 15:54   ` [RFC PATCH 3/7] iommu: add new iommu_ops callback for adding a device with a set of IDs Will Deacon
2014-08-29 15:54     ` Will Deacon
     [not found]     ` <1409327670-3495-4-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-09-01  8:13       ` Thierry Reding
2014-09-01  8:13         ` Thierry Reding
2014-09-01 14:39         ` Arnd Bergmann
2014-09-01 14:39           ` Arnd Bergmann
2014-09-01 16:34           ` Will Deacon
2014-09-01 16:34             ` Will Deacon
     [not found]             ` <20140901163400.GK24594-5wv7dgnIgG8@public.gmane.org>
2014-09-01 17:18               ` Arnd Bergmann
2014-09-01 17:18                 ` Arnd Bergmann
2014-08-29 15:54   ` [RFC PATCH 4/7] iommu: provide helper function to configure an IOMMU for an of master Will Deacon
2014-08-29 15:54     ` Will Deacon
     [not found]     ` <1409327670-3495-5-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-09-01  8:29       ` Thierry Reding
2014-09-01  8:29         ` Thierry Reding
2014-09-01 14:46         ` Arnd Bergmann
2014-09-01 14:46           ` Arnd Bergmann
2014-09-01 16:40           ` Will Deacon
2014-09-01 16:40             ` Will Deacon
     [not found]             ` <20140901164000.GM24594-5wv7dgnIgG8@public.gmane.org>
2014-09-01 20:18               ` Arnd Bergmann
2014-09-01 20:18                 ` Arnd Bergmann
2014-09-02 10:03                 ` Will Deacon
2014-09-02 10:03                   ` Will Deacon
     [not found]                   ` <20140902100342.GG25379-5wv7dgnIgG8@public.gmane.org>
2014-09-02 12:15                     ` Arnd Bergmann
2014-09-02 12:15                       ` Arnd Bergmann
2014-09-02 13:05                       ` Will Deacon
2014-09-02 13:05                         ` Will Deacon
     [not found]                         ` <20140902130508.GK25379-5wv7dgnIgG8@public.gmane.org>
2014-09-02 14:01                           ` Arnd Bergmann
2014-09-02 14:01                             ` Arnd Bergmann
2014-09-02 20:59                             ` jroedel-l3A5Bk7waGM
2014-09-02 20:59                               ` jroedel at suse.de
     [not found]                               ` <20140902205941.GA26123-l3A5Bk7waGM@public.gmane.org>
2014-09-03  9:45                                 ` Will Deacon
2014-09-03  9:45                                   ` Will Deacon
2014-09-02 15:03                       ` Varun Sethi
2014-09-02 15:03                         ` Varun Sethi
     [not found]                         ` <b8484a1ea45846bbaa8512d4597b9e65-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-09-02 15:08                           ` Arnd Bergmann
2014-09-02 15:08                             ` Arnd Bergmann
2014-09-02 10:23           ` Laurent Pinchart
2014-09-02 10:23             ` Laurent Pinchart
2014-09-02 10:51       ` Laurent Pinchart
2014-09-02 10:51         ` Laurent Pinchart
2014-09-02 11:03         ` Will Deacon
2014-09-02 11:03           ` Will Deacon
     [not found]           ` <20140902110340.GI25379-5wv7dgnIgG8@public.gmane.org>
2014-09-02 19:08             ` Laurent Pinchart
2014-09-02 19:08               ` Laurent Pinchart
2014-09-02 14:55       ` Varun Sethi
2014-09-02 14:55         ` Varun Sethi
2014-08-29 15:54   ` [RFC PATCH 5/7] dma-mapping: detect and configure IOMMU in of_dma_configure Will Deacon
2014-08-29 15:54     ` Will Deacon
     [not found]     ` <1409327670-3495-6-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-09-01 14:53       ` Arnd Bergmann
2014-09-01 14:53         ` Arnd Bergmann
2014-08-29 15:54   ` [RFC PATCH 6/7] arm: call iommu_init before of_platform_populate Will Deacon
2014-08-29 15:54     ` Will Deacon
2014-08-29 15:54   ` [RFC PATCH 7/7] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops Will Deacon
2014-08-29 15:54     ` Will Deacon
2014-09-02  6:26   ` [RFC PATCH 0/7] Introduce automatic DMA configuration for IOMMU masters Marek Szyprowski
2014-09-02  6:26     ` Marek Szyprowski
     [not found]     ` <540562F9.2030508-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-09-02  8:31       ` Will Deacon
2014-09-02  8:31         ` Will Deacon
     [not found]         ` <20140902083138.GA25379-5wv7dgnIgG8@public.gmane.org>
2014-09-02  8:48           ` Marek Szyprowski [this message]
2014-09-02  8:48             ` Marek Szyprowski
     [not found]             ` <54058442.2070204-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-09-02  8:56               ` Arnd Bergmann
2014-09-02  8:56                 ` Arnd Bergmann
2014-09-02 10:42                 ` Marek Szyprowski
2014-09-02 10:42                   ` Marek Szyprowski
     [not found]                   ` <54059F05.2090901-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-09-02 10:57                     ` Will Deacon
2014-09-02 10:57                       ` Will Deacon
     [not found]                       ` <20140902105730.GH25379-5wv7dgnIgG8@public.gmane.org>
2014-09-02 12:24                         ` Marek Szyprowski
2014-09-02 12:24                           ` Marek Szyprowski
     [not found]                           ` <5405B6F2.1060105-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-09-02 12:43                             ` Arnd Bergmann
2014-09-02 12:43                               ` Arnd Bergmann
2014-09-02 21:50                               ` Laurent Pinchart
2014-09-02 21:50                                 ` Laurent Pinchart
2014-09-02 12:22                     ` Arnd Bergmann
2014-09-02 12:22                       ` Arnd Bergmann
2014-09-02 12:30                       ` Marek Szyprowski
2014-09-02 12:30                         ` Marek Szyprowski
2014-09-02 12:46                         ` Arnd Bergmann
2014-09-02 12:46                           ` Arnd Bergmann
2014-09-02 13:11                           ` Marek Szyprowski
2014-09-02 13:11                             ` Marek Szyprowski

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=54058442.2070204@samsung.com \
    --to=m.szyprowski-sze3o3uu22jbdgjk7y7tuq@public.gmane.org \
    --cc=Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=jroedel-l3A5Bk7waGM@public.gmane.org \
    --cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.