From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Will Deacon <will.deacon@arm.com>
Cc: "jroedel@suse.de" <jroedel@suse.de>,
Arnd Bergmann <arnd@arndb.de>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
"Varun.Sethi@freescale.com" <Varun.Sethi@freescale.com>,
"hdoyu@nvidia.com" <hdoyu@nvidia.com>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"m.szyprowski@samsung.com" <m.szyprowski@samsung.com>
Subject: Re: [RFC PATCH v4 0/8] Introduce automatic DMA configuration for IOMMU masters
Date: Wed, 21 Jan 2015 17:02:06 +0200 [thread overview]
Message-ID: <5599950.ffjJapmhpz@avalon> (raw)
In-Reply-To: <20150121144835.GK4549@arm.com>
Hi Will,
On Wednesday 21 January 2015 14:48:35 Will Deacon wrote:
> On Tue, Jan 20, 2015 at 04:56:03PM +0000, Laurent Pinchart wrote:
> > On Monday 19 January 2015 16:06:20 Will Deacon wrote:
> > > On Fri, Nov 14, 2014 at 08:01:56PM +0000, Arnd Bergmann wrote:
> > > > On Friday 14 November 2014 19:27:54 Will Deacon wrote:
> > > > > > At the moment, iommu_ops is a structure that can get used for any
> > > > > > number of iommus of the same type, but by putting per-device
> > > > > > private data into the same structure you have to duplicate it per
> > > > > > instance.
> > > > >
> > > > > I'm not sure I agree -- the pgsize_bitmap, for example, could vary
> > > > > between different implementations of the same IOMMU. I think we
> > > > > already have this in Juno (some SMMUs can only do 64k pages, whilst
> > > > > others can do 4k and 64k).
> > > >
> > > > Ah, I hadn't noticed that, it should be in the 'struct iommu' then of
> > > > course, not in iommu_ops.
> > >
> > > Now that of_iommu_get_ops has its own list of iommu_ops, we can actually
> > > just move pgsize_bitmap into the iommu_domain, which I think makes a lot
> > > more sense anyway.
> >
> > The code looks good to me, but what does it have to do with
> > of_iommu_get_ops() having its own list of iommu_ops ?
>
> So, the initial patches for of_iommu_configure/of_xlate made use of a void
> *priv field in struct iommu_ops (which actually made it to mainline but
> isn't used). This was replaced by the list maintained by of_iommu_get_ops,
> but the discussion highlighted that iommu_ops is not per-IOMMU instance and
> therefore shouldn't contain the pgsize_bitmap, which can (and does) vary
> between different IOMMU instances in a running system.
>
> This patch is an effort to move the pgsize_bitmap field out of iommu_ops
> (leaving that structure to contain only function pointers) and into
> iommu_domain, where I think it makes more sense.
OK, that's what I had understood. Thanks for the clarification. I was just
puzzled by what I thought you meant was a dependency on of_iommu_get_ops().
> > > diff below seems to do the trick. The next step would be postponing the
> > > pgsize_bitmap initialisation until device attach for the ARM SMMU, since
> > > it's at that point that we know the active page table format (and
> > > therefore the supported page sizes).
--
Regards,
Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: laurent.pinchart@ideasonboard.com (Laurent Pinchart)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v4 0/8] Introduce automatic DMA configuration for IOMMU masters
Date: Wed, 21 Jan 2015 17:02:06 +0200 [thread overview]
Message-ID: <5599950.ffjJapmhpz@avalon> (raw)
In-Reply-To: <20150121144835.GK4549@arm.com>
Hi Will,
On Wednesday 21 January 2015 14:48:35 Will Deacon wrote:
> On Tue, Jan 20, 2015 at 04:56:03PM +0000, Laurent Pinchart wrote:
> > On Monday 19 January 2015 16:06:20 Will Deacon wrote:
> > > On Fri, Nov 14, 2014 at 08:01:56PM +0000, Arnd Bergmann wrote:
> > > > On Friday 14 November 2014 19:27:54 Will Deacon wrote:
> > > > > > At the moment, iommu_ops is a structure that can get used for any
> > > > > > number of iommus of the same type, but by putting per-device
> > > > > > private data into the same structure you have to duplicate it per
> > > > > > instance.
> > > > >
> > > > > I'm not sure I agree -- the pgsize_bitmap, for example, could vary
> > > > > between different implementations of the same IOMMU. I think we
> > > > > already have this in Juno (some SMMUs can only do 64k pages, whilst
> > > > > others can do 4k and 64k).
> > > >
> > > > Ah, I hadn't noticed that, it should be in the 'struct iommu' then of
> > > > course, not in iommu_ops.
> > >
> > > Now that of_iommu_get_ops has its own list of iommu_ops, we can actually
> > > just move pgsize_bitmap into the iommu_domain, which I think makes a lot
> > > more sense anyway.
> >
> > The code looks good to me, but what does it have to do with
> > of_iommu_get_ops() having its own list of iommu_ops ?
>
> So, the initial patches for of_iommu_configure/of_xlate made use of a void
> *priv field in struct iommu_ops (which actually made it to mainline but
> isn't used). This was replaced by the list maintained by of_iommu_get_ops,
> but the discussion highlighted that iommu_ops is not per-IOMMU instance and
> therefore shouldn't contain the pgsize_bitmap, which can (and does) vary
> between different IOMMU instances in a running system.
>
> This patch is an effort to move the pgsize_bitmap field out of iommu_ops
> (leaving that structure to contain only function pointers) and into
> iommu_domain, where I think it makes more sense.
OK, that's what I had understood. Thanks for the clarification. I was just
puzzled by what I thought you meant was a dependency on of_iommu_get_ops().
> > > diff below seems to do the trick. The next step would be postponing the
> > > pgsize_bitmap initialisation until device attach for the ARM SMMU, since
> > > it's at that point that we know the active page table format (and
> > > therefore the supported page sizes).
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2015-01-21 15:02 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-14 18:56 [RFC PATCH v4 0/8] Introduce automatic DMA configuration for IOMMU masters Will Deacon
2014-11-14 18:56 ` Will Deacon
[not found] ` <1415991397-9618-1-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-11-14 18:56 ` [RFC PATCH v4 1/8] iommu: provide early initialisation hook for IOMMU drivers Will Deacon
2014-11-14 18:56 ` Will Deacon
[not found] ` <1415991397-9618-2-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-11-18 12:28 ` Marek Szyprowski
2014-11-18 12:28 ` Marek Szyprowski
2014-11-14 18:56 ` [RFC PATCH v4 2/8] dma-mapping: replace set_arch_dma_coherent_ops with arch_setup_dma_ops Will Deacon
2014-11-14 18:56 ` Will Deacon
2014-11-14 18:56 ` [RFC PATCH v4 3/8] iommu: add new iommu_ops callback for adding an OF device Will Deacon
2014-11-14 18:56 ` Will Deacon
2014-11-14 18:56 ` [RFC PATCH v4 4/8] iommu: provide helper function to configure an IOMMU for an of master Will Deacon
2014-11-14 18:56 ` Will Deacon
2014-11-14 18:56 ` [RFC PATCH v4 5/8] dma-mapping: detect and configure IOMMU in of_dma_configure Will Deacon
2014-11-14 18:56 ` Will Deacon
2014-11-14 18:56 ` [RFC PATCH v4 6/8] dma-mapping: set dma segment properties " Will Deacon
2014-11-14 18:56 ` Will Deacon
2014-11-25 13:05 ` Robin Murphy
2014-11-25 13:05 ` Robin Murphy
[not found] ` <54747EA0.1020001-5wv7dgnIgG8@public.gmane.org>
2014-11-26 11:37 ` Will Deacon
2014-11-26 11:37 ` Will Deacon
2014-11-14 18:56 ` [RFC PATCH v4 7/8] arm: call iommu_init before of_platform_populate Will Deacon
2014-11-14 18:56 ` Will Deacon
2014-11-14 18:56 ` [RFC PATCH v4 8/8] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops Will Deacon
2014-11-14 18:56 ` Will Deacon
2014-11-17 11:29 ` Robin Murphy
2014-11-17 11:29 ` Robin Murphy
[not found] ` <5469DC13.6040700-5wv7dgnIgG8@public.gmane.org>
2014-11-17 11:41 ` Will Deacon
2014-11-17 11:41 ` Will Deacon
2014-11-14 19:11 ` [RFC PATCH v4 0/8] Introduce automatic DMA configuration for IOMMU masters Arnd Bergmann
2014-11-14 19:11 ` Arnd Bergmann
2014-11-14 19:27 ` Will Deacon
2014-11-14 19:27 ` Will Deacon
[not found] ` <20141114192754.GB9291-5wv7dgnIgG8@public.gmane.org>
2014-11-14 20:01 ` Arnd Bergmann
2014-11-14 20:01 ` Arnd Bergmann
2015-01-19 16:06 ` Will Deacon
2015-01-19 16:06 ` Will Deacon
[not found] ` <20150119160620.GB2373-5wv7dgnIgG8@public.gmane.org>
2015-01-20 16:56 ` Laurent Pinchart
2015-01-20 16:56 ` Laurent Pinchart
2015-01-21 14:48 ` Will Deacon
2015-01-21 14:48 ` Will Deacon
2015-01-21 15:02 ` Laurent Pinchart [this message]
2015-01-21 15:02 ` Laurent Pinchart
2014-11-19 11:21 ` Marek Szyprowski
2014-11-19 11:21 ` Marek Szyprowski
[not found] ` <546C7D36.7030400-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-11-19 11:41 ` Will Deacon
2014-11-19 11:41 ` Will Deacon
[not found] ` <20141119114150.GD15985-5wv7dgnIgG8@public.gmane.org>
2014-11-25 7:35 ` Marek Szyprowski
2014-11-25 7:35 ` Marek Szyprowski
[not found] ` <54743139.2020804-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-11-26 17:47 ` Will Deacon
2014-11-26 17:47 ` Will Deacon
[not found] ` <20141126174707.GO14866-5wv7dgnIgG8@public.gmane.org>
2014-11-28 13:03 ` jroedel-l3A5Bk7waGM
2014-11-28 13:03 ` jroedel at suse.de
[not found] ` <20141128130336.GF3156-l3A5Bk7waGM@public.gmane.org>
2014-11-28 13:19 ` Will Deacon
2014-11-28 13:19 ` Will Deacon
2014-12-15 17:21 ` Laurent Pinchart
2014-12-15 17:21 ` Laurent Pinchart
2014-12-15 17:34 ` Will Deacon
2014-12-15 17:34 ` Will Deacon
[not found] ` <20141215173416.GS20738-5wv7dgnIgG8@public.gmane.org>
2014-12-15 17:55 ` Laurent Pinchart
2014-12-15 17:55 ` Laurent Pinchart
2014-11-25 13:15 ` Robin Murphy
2014-11-25 13:15 ` Robin Murphy
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=5599950.ffjJapmhpz@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=Varun.Sethi@freescale.com \
--cc=arnd@arndb.de \
--cc=dwmw2@infradead.org \
--cc=hdoyu@nvidia.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jroedel@suse.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=m.szyprowski@samsung.com \
--cc=thierry.reding@gmail.com \
--cc=will.deacon@arm.com \
/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.