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: 31+ 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 ` [RFC PATCH v4 1/8] iommu: provide early initialisation hook for IOMMU drivers Will Deacon
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 ` [RFC PATCH v4 3/8] iommu: add new iommu_ops callback for adding an OF device 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 ` [RFC PATCH v4 5/8] dma-mapping: detect and configure IOMMU in of_dma_configure Will Deacon
2014-11-14 18:56 ` [RFC PATCH v4 6/8] dma-mapping: set dma segment properties " Will Deacon
2014-11-25 13:05 ` Robin Murphy
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 ` [RFC PATCH v4 8/8] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops Will Deacon
2014-11-17 11:29 ` Robin Murphy
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:27 ` Will Deacon
2014-11-14 20:01 ` Arnd Bergmann
2015-01-19 16:06 ` Will Deacon
2015-01-20 16:56 ` Laurent Pinchart
2015-01-21 14:48 ` Will Deacon
2015-01-21 15:02 ` Laurent Pinchart [this message]
2014-11-19 11:21 ` Marek Szyprowski
2014-11-19 11:41 ` Will Deacon
2014-11-25 7:35 ` Marek Szyprowski
2014-11-26 17:47 ` Will Deacon
2014-11-28 13:03 ` jroedel at suse.de
2014-11-28 13:19 ` Will Deacon
2014-12-15 17:21 ` Laurent Pinchart
2014-12-15 17:34 ` Will Deacon
2014-12-15 17:55 ` Laurent Pinchart
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$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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