From: joro@8bytes.org (joro at 8bytes.org)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] ARM: IOMMU: Tegra30: Add iommu_ops for SMMU driver
Date: Tue, 24 Jan 2012 15:25:21 +0100 [thread overview]
Message-ID: <20120124142521.GE6269@8bytes.org> (raw)
In-Reply-To: <20120124134601.GT27414@legolas.emea.dhcp.ti.com>
On Tue, Jan 24, 2012 at 03:46:01PM +0200, Felipe Balbi wrote:
> On Tue, Jan 24, 2012 at 02:41:21PM +0100, Hiroshi Doyu wrote:
> > Actually I really like the concept of this "domain" now, which hides
> > the H/W hierarchy from users.
> >
> > But in Tegra SMMU/GART case, there's a single one IOMMU device in the
> > system. Keeping a iommu device list in a domain and iterating iommu
> > device list in each iommu_ops seem to be so nice, but I'm afraid that
> > this may be a bit too much when one already knows that there's only
> > one IOMMU device in the system.
> >
> > If there's no actual problem for 1-1 mapping between IOMMU H/Ws and
> > domains, I think that it may not so bad to keep the original code(1-1)
> > for GART and SMMU. What do you think?
>
> I think it boils down to "extensability". If you can truly/fully
> guarantee that there will *always* be a single IOMMU on all upcoming
> Tegras, then it's really overkill.
>
> But if there's even a remote possibility of the HW being changed and you
> end up with more IOMMUs, things start to feel necessary for the sake of
> making it easy to extend.
Right. But I am fine with the logic as-is when there is only one SMMU in
the system. But please also change the IOMMU driver so that it really
only initializes a single SMMU. When boards pop up with more than one
you we notice that assumption in the code again and are reminded to
change it.
Joerg
next prev parent reply other threads:[~2012-01-24 14:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-05 7:11 [PATCH v3 0/2] ARM: IOMMU: tegra: Add iommu_ops for GART/SMMU driver Hiroshi DOYU
2012-01-05 7:11 ` [PATCH 1/2] ARM: IOMMU: Tegra20: Add iommu_ops for GART driver Hiroshi DOYU
2012-01-23 15:00 ` Joerg Roedel
2012-01-25 7:40 ` Hiroshi Doyu
2012-01-26 11:58 ` joro at 8bytes.org
2012-01-26 14:45 ` Hiroshi Doyu
2012-01-05 7:11 ` [PATCH 2/2] ARM: IOMMU: Tegra30: Add iommu_ops for SMMU driver Hiroshi DOYU
2012-01-23 15:43 ` Joerg Roedel
2012-01-24 9:57 ` Hiroshi Doyu
2012-01-24 11:04 ` Joerg Roedel
2012-01-24 11:36 ` Hiroshi Doyu
2012-01-24 11:57 ` joerg.roedel at amd.com
2012-01-24 12:07 ` Hiroshi Doyu
2012-01-24 13:41 ` Hiroshi Doyu
2012-01-24 13:46 ` Felipe Balbi
2012-01-24 14:25 ` joro at 8bytes.org [this message]
2012-01-25 7:39 ` Hiroshi Doyu
2012-01-26 14:59 ` joro at 8bytes.org
2012-01-05 7:17 ` [PATCH v3 0/2] ARM: IOMMU: tegra: Add iommu_ops for GART/SMMU driver Hiroshi Doyu
2012-01-05 12:53 ` Russell King - ARM Linux
2012-01-05 14:29 ` Hiroshi Doyu
2012-01-05 14:46 ` Russell King - ARM Linux
2012-01-11 14:24 ` Hiroshi Doyu
2012-01-09 0:39 ` KyongHo Cho
2012-01-09 11:45 ` Russell King - ARM Linux
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=20120124142521.GE6269@8bytes.org \
--to=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.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 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).