From: Pratik Patel <pratikp@codeaurora.org>
To: Will Deacon <will@kernel.org>
Cc: isaacm@codeaurora.org, Robin Murphy <robin.murphy@arm.com>,
Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org, Liam Mark <lmark@codeaurora.org>,
iommu@lists.linux-foundation.org, kernel-team@android.com
Subject: Re: [RFC PATCH] iommu/dma: Allow drivers to reserve an iova range
Date: Thu, 20 Feb 2020 10:57:28 -0800 [thread overview]
Message-ID: <20200220185728.GA32137@pratikp-lnx> (raw)
In-Reply-To: <20200220084552.GB11827@willie-the-truck>
On 02/20 08:45 am, Will Deacon wrote:
> On Wed, Feb 19, 2020 at 12:06:28PM -0800, isaacm@codeaurora.org wrote:
> > On 2020-02-19 03:15, Will Deacon wrote:
> > > On Tue, Feb 18, 2020 at 05:57:18PM -0800, isaacm@codeaurora.org wrote:
> > > > Does this mean that the driver should be managing the IOVA space and
> > > > mappings for this device using the IOMMU API? If so, is the
> > > > rationale for
> > > > this because the device driver can have the information of what IOVA
> > > > ranges
> > > > can and cannot be used? Shouldn't there be a generic way of
> > > > informing an
> > > > IOMMU driver about these reserved ranges? Perhaps through a device
> > > > tree
> > > > property, instead of deferring this type of management to the driver?
> > >
> > > Before we dive into designing that, can you please clarify whether the
> > > reserved IOVA range applies to all DMA masters mastering through a
> > > particular SMMU, or whether it's just about one specific master? I was
> > > assuming the former, but wanted to be sure.
> > >
> > This situation currently applies to one master.
>
> Interesting. Is it problematic if the range is reserved for all masters
> sharing that SMMU?
>
Yes, that would be an overkill. It certainly is useful and in
some cases quite helpful to not waste that range of IOVA space for
other masters on the same SMMU that can use it.
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2020-02-20 18:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-14 22:58 [RFC PATCH] iommu/dma: Allow drivers to reserve an iova range Isaac J. Manjarres
2020-02-17 8:01 ` Christoph Hellwig
2020-02-17 15:50 ` Robin Murphy
2020-02-19 1:57 ` isaacm
2020-02-19 11:15 ` Will Deacon
2020-02-19 20:06 ` isaacm
2020-02-20 8:45 ` Will Deacon
2020-02-20 18:57 ` Pratik Patel [this message]
2020-02-19 9:46 ` Joerg Roedel
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=20200220185728.GA32137@pratikp-lnx \
--to=pratikp@codeaurora.org \
--cc=hch@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=isaacm@codeaurora.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lmark@codeaurora.org \
--cc=robin.murphy@arm.com \
--cc=will@kernel.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).