From: Ohad Ben-Cohen <ohad@wizery.com>
To: "Roedel, Joerg" <Joerg.Roedel@amd.com>
Cc: "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"laurent.pinchart@ideasonboard.com"
<laurent.pinchart@ideasonboard.com>,
"Hiroshi.DOYU@nokia.com" <Hiroshi.DOYU@nokia.com>,
"arnd@arndb.de" <arnd@arndb.de>,
"davidb@codeaurora.org" <davidb@codeaurora.org>,
Omar Ramirez Luna <omar.ramirez@ti.com>
Subject: Re: [RFC 0/6] iommu: generic api migration and grouping
Date: Mon, 6 Jun 2011 19:36:13 +0300 [thread overview]
Message-ID: <BANLkTinwwVO4TmsxuTfSBf6jqYrEVV3b_A@mail.gmail.com> (raw)
In-Reply-To: <20110606153557.GE1953@amd.com>
On Mon, Jun 6, 2011 at 6:35 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> On Mon, Jun 06, 2011 at 11:15:30AM -0400, Ohad Ben-Cohen wrote:
>
>> This is insufficient; users need somehow to tell what page sizes are
>> supported by the underlying hardware (we can't assume host page-sizes,
>> and we want to use bigger pages whenever possible, to relax the TLB
>> pressure).
> /
> What does the IOMMU-API user need this info for? On the x86 IOMMUs these
> details are handled transparently by the IOMMU driver.
That's one way to do that, but then it means duplicating this logic
inside the different IOMMU implementations.
Take the OMAP (and seemingly MSM too) example: we have 4KB, 64KB, 1MB
and 16MB page-table entries. When we map a memory region, we need to
break it up to a minimum number of pages (while validating
sizes/alignments are sane). It's not complicated, but it can be nice
if it'd be implemented only once.
In addition, unless we require 'va' and 'pa' to have the exact same
alignment, we might run into specific page configuration that the
IOMMU implementation cannot restore on ->unmap, since unmap only takes
'va' and 'order'. So we will either have to supply 'pa' too, or have
the implementation remember the mapping in order to unmap it later.
That begins to be a bit messy...
next prev parent reply other threads:[~2011-06-06 16:36 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-02 22:27 [RFC 0/6] iommu: generic api migration and grouping Ohad Ben-Cohen
2011-06-02 22:27 ` [RFC 1/6] omap: iommu: generic iommu api migration Ohad Ben-Cohen
2011-06-07 9:22 ` Laurent Pinchart
2011-06-07 11:19 ` Ohad Ben-Cohen
2011-06-07 11:40 ` Laurent Pinchart
2011-06-07 12:27 ` Ohad Ben-Cohen
2011-06-02 22:27 ` [RFC 2/6] omap: iovmm: " Ohad Ben-Cohen
2011-06-07 9:05 ` Laurent Pinchart
2011-06-07 10:28 ` Ohad Ben-Cohen
2011-06-07 11:26 ` Laurent Pinchart
2011-06-07 13:46 ` Ohad Ben-Cohen
2011-06-08 10:46 ` Laurent Pinchart
2011-06-09 6:42 ` Ohad Ben-Cohen
2011-06-02 22:27 ` [RFC 3/6] media: omap3isp: " Ohad Ben-Cohen
2011-06-02 22:27 ` [RFC 4/6] drivers: iommu: move to a dedicated folder Ohad Ben-Cohen
2011-06-02 22:27 ` [RFC 5/6] omap: iommu/iovmm: move to dedicated iommu folder Ohad Ben-Cohen
2011-06-02 22:27 ` [RFC 6/6] msm: iommu: move to dedicated iommu drivers folder Ohad Ben-Cohen
2011-06-02 23:57 ` [RFC 0/6] iommu: generic api migration and grouping Kyungmin Park
2011-06-05 19:43 ` Ohad Ben-Cohen
2011-06-03 15:53 ` Arnd Bergmann
2011-06-05 19:39 ` Ohad Ben-Cohen
2011-06-06 9:10 ` Arnd Bergmann
2011-06-06 15:17 ` Ohad Ben-Cohen
2011-06-06 10:09 ` Roedel, Joerg
2011-06-06 15:15 ` Ohad Ben-Cohen
2011-06-06 15:35 ` Roedel, Joerg
2011-06-06 16:36 ` Ohad Ben-Cohen [this message]
2011-06-06 19:20 ` Roedel, Joerg
2011-06-06 20:09 ` Ohad Ben-Cohen
2011-06-07 7:52 ` Roedel, Joerg
2011-06-07 9:22 ` Ohad Ben-Cohen
2011-06-07 9:58 ` Roedel, Joerg
2011-06-07 10:30 ` Ohad Ben-Cohen
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=BANLkTinwwVO4TmsxuTfSBf6jqYrEVV3b_A@mail.gmail.com \
--to=ohad@wizery.com \
--cc=Hiroshi.DOYU@nokia.com \
--cc=Joerg.Roedel@amd.com \
--cc=arnd@arndb.de \
--cc=davidb@codeaurora.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=omar.ramirez@ti.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 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).