linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Zach Pfeffer <zpfeffer@codeaurora.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Tim HRM <zt.tmzt@gmail.com>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	ebiederm@xmission.com, linux-arch@vger.kernel.org,
	dwalker@codeaurora.org, mel@csn.ul.ie,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, andi@firstfloor.org,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
Date: Tue, 20 Jul 2010 13:45:17 -0700	[thread overview]
Message-ID: <20100720204515.GA12250@codeaurora.org> (raw)
In-Reply-To: <20100716075856.GC16124@n2100.arm.linux.org.uk>

On Fri, Jul 16, 2010 at 08:58:56AM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 15, 2010 at 08:48:36PM -0400, Tim HRM wrote:
> > Interesting, since I seem to remember the MSM devices mostly conduct
> > IO through regions of normal RAM, largely accomplished through
> > ioremap() calls.
> > 
> > Without more public domain documentation of the MSM chips and AMSS
> > interfaces I wouldn't know how to avoid this, but I can imagine it
> > creates a bit of urgency for Qualcomm developers as they attempt to
> > upstream support for this most interesting SoC.
> 
> As the patch has been out for RFC since early April on the linux-arm-kernel
> mailing list (Subject: [RFC] Prohibit ioremap() on kernel managed RAM),
> and no comments have come back from Qualcomm folk.
> 
> The restriction on creation of multiple V:P mappings with differing
> attributes is also fairly hard to miss in the ARM architecture
> specification when reading the sections about caches.

As you mention in your patch the things that can't conflict are memory
type (strongly- ordered/device/normal), cache policy
(cacheable/non-cacheable, copy- back/write-through), and coherency
realm (non-shareable/inner- shareable/outer-shareable). You can
conflict in allocation preferences (write-allocate/write-no-allocate),
as those are just "hints".

You can also conflict in access permissions which can and do conflict
(which are what multiple mappings are all about...some buffer can get
some access, while others get different access).

The VCM API allows the same memory to be mapped as long as it makes
sense and allows those attributes that can change to be specified. It
could be the alternative, globally applicable approach, your looking
for and request in your patch.

Without the VCM API (or something like it) there will just be a bunch
of duplicated code that's basically doing ioremap. This code will
probably fail to configure its mappings correctly, in which case your
patch is a bad idea because it'll spawn bugs all over the place
instead of at a know location. We could instead change ioremap to
match the attributes of System RAM if that's what its mapping.



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2010-07-20 20:45 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-03  5:38 [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management Zach Pfeffer
2010-07-03 19:06 ` Eric W. Biederman
2010-07-07 22:44   ` Zach Pfeffer
2010-07-07 23:07     ` Russell King - ARM Linux
2010-07-08 23:59       ` Zach Pfeffer
2010-07-12  1:25         ` FUJITA Tomonori
2010-07-13  5:57           ` Zach Pfeffer
2010-07-13  6:03             ` FUJITA Tomonori
2010-07-13 12:14               ` Zach Pfeffer
2010-07-14  1:59                 ` FUJITA Tomonori
2010-07-14 20:11                   ` Zach Pfeffer
2010-07-14 22:05                     ` Russell King - ARM Linux
2010-07-15  1:29                       ` Zach Pfeffer
2010-07-15  1:47                         ` Eric W. Biederman
2010-07-15  5:40                           ` Zach Pfeffer
2010-07-15  5:35                         ` Zach Pfeffer
2010-07-15  8:55                         ` Russell King - ARM Linux
2010-07-16  0:48                           ` Tim HRM
2010-07-16  7:58                             ` Russell King - ARM Linux
2010-07-17  0:01                               ` Larry Bassel
2010-07-19  9:21                                 ` Tim HRM
2010-07-21  0:44                                   ` Zach Pfeffer
2010-07-21  1:44                                     ` Timothy Meade
2010-07-22  4:06                                       ` Zach Pfeffer
2010-07-19 17:55                               ` Michael Bohan
2010-07-19 18:40                                 ` Russell King - ARM Linux
2010-07-20 22:02                                   ` stepanm
2010-07-20 22:29                                     ` Russell King - ARM Linux
2010-07-21  5:49                                       ` Shilimkar, Santosh
2010-07-21  7:28                                         ` Russell King - ARM Linux
2010-07-21  7:45                                           ` Shilimkar, Santosh
2010-07-21 18:04                                           ` stepanm
2010-07-20 20:45                               ` Zach Pfeffer [this message]
2010-07-20 20:54                                 ` Russell King - ARM Linux
2010-07-20 21:56                                   ` Zach Pfeffer
2010-07-19  6:52                           ` Zach Pfeffer
2010-07-19  7:44                             ` Eric W. Biederman
2010-07-22  4:25                               ` Zach Pfeffer
2010-07-22  7:34                                 ` Russell King - ARM Linux
2010-07-22 16:25                                   ` Zach Pfeffer
2010-07-14 23:07                     ` FUJITA Tomonori
2010-07-15  1:41                       ` Zach Pfeffer
2010-07-19  8:22                         ` Russell King - ARM Linux
2010-07-20 10:09                           ` FUJITA Tomonori
2010-07-20 22:20                           ` Zach Pfeffer
2010-07-21  1:44                             ` FUJITA Tomonori
2010-07-22  4:30                               ` Zach Pfeffer
2010-07-22  4:43                                 ` FUJITA Tomonori
2010-07-22 16:44                                   ` Zach Pfeffer
2010-07-22  7:39                                 ` Russell King - ARM Linux
2010-07-22 16:28                                   ` Zach Pfeffer
  -- strict thread matches above, loose matches on Subject: below --
2010-07-06 15:42 Zach Pfeffer
2010-07-21  5:18 stepanm

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=20100720204515.GA12250@codeaurora.org \
    --to=zpfeffer@codeaurora.org \
    --cc=andi@firstfloor.org \
    --cc=dwalker@codeaurora.org \
    --cc=ebiederm@xmission.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mel@csn.ul.ie \
    --cc=zt.tmzt@gmail.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).