linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: stepanm@codeaurora.org (stepanm at codeaurora.org)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] arm: msm: Add System MMU support.
Date: Fri, 30 Jul 2010 09:25:48 -0700 (PDT)	[thread overview]
Message-ID: <3faa32ace3110e9d1e51ef9735287de1.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <201007301001.02509.arnd@arndb.de>

> On Friday 30 July 2010 07:19:06 stepanm at codeaurora.org wrote:
>> Unlike a more traditional system with one IOMMU between the bus and
>> memory, MSM has multiple IOMMUs, with each one hard-wired to a dedicated
>> device. Furthermore, each IOMMU can have more than one translation
>> context. One of the use cases is being able to create mappings within
>> multiple instances of one context, and arbitrarily context-switch the
>> IOMMU on the fly.
>>
>> It sounds like the domain abstraction and attach_device/detach_device
>> can
>> encapsulate this rather nicely and I am in the process of updating my
>> driver to fit this framework.
>>
>> My problem, however, is with iommu_domain_alloc(). This will set up a
>> domain and call the ops function to initialize it, but I want to be able
>> to pass it an ???IOMMU id" that will tell the underlying driver which
>> IOMMU
>> (and which "stream id") is to be associated with that domain instance.
>
> This probably best fits into the device itself, so you can assign the
> iommu data when probing the bus, e.g. (I don't know what bus you use)
>
> struct msm_device {
> 	struct msm_iommu *iommu;
> 	struct device dev;
> };
>
> This will work both for device drivers using the DMA API and for KVM
> with the IOMMU API.


Right, this makes sense, and that is similar to how we were planning to
set the iommus for the devices. But my question is, how does the IOMMU API
know *which* IOMMU to talk to? It seems like this API has been designed
with a singular IOMMU in mind, and it is implied that things like
iommu_domain_alloc, iommu_map, etc all use "the" IOMMU. But I would like
to allocate a domain and specify which IOMMU it is to be used for.

I can think of solving this in several ways.
One way would be to modify iommu_domain_alloc to take an IOMMU parameter,
which gets passed into domain_init. This seems like the cleanest solution.
Another way would be to have something like msm_iommu_domain_bind(domain,
iommu) which would need to be called after iommu_domain_alloc to set the
domain binding.
A third way that I could see is to delay the domain/iommu binding until
iommu_attach_device, where the iommu could be picked up from the device
that is passed in. I am not certain of this approach, since I had not been
planning to pass in full devices, as in the MSM case this makes little
sense (that is, if I am understanding the API correctly). On MSM, each
device already has a dedicated IOMMU hard-wired to it. I had been planning
to use iommu_attach_device to switch between active domains on a specific
IOMMU and the given device would be of little use because that association
is implicit on MSM.

Does that make sense? Am I correctly understanding the API? What do you
think would be a good way to handle the multiple-iommu case?

Thanks
Steve

  reply	other threads:[~2010-07-30 16:25 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-27 22:41 [PATCH 1/2] arm: msm: Add System MMU support Stepan Moskovchenko
2010-07-27 22:43 ` Daniel Walker
2010-07-28  8:39 ` Arnd Bergmann
2010-07-28 17:39   ` stepanm at codeaurora.org
2010-07-28 17:50     ` Arnd Bergmann
2010-07-28 21:21       ` Russell King - ARM Linux
2010-07-29  4:15         ` FUJITA Tomonori
2010-07-29  8:12         ` Arnd Bergmann
2010-07-29 11:47           ` Russell King - ARM Linux
2010-07-30  6:14             ` FUJITA Tomonori
2010-07-29  0:58       ` stepanm at codeaurora.org
2010-07-29  3:35         ` FUJITA Tomonori
2010-07-29  8:26           ` Arnd Bergmann
2010-07-29  8:35             ` FUJITA Tomonori
2010-07-29  8:40             ` Roedel, Joerg
2010-07-29  8:46               ` FUJITA Tomonori
2010-07-29  9:06                 ` Roedel, Joerg
2010-07-29  9:14                   ` FUJITA Tomonori
2010-07-29  9:25                     ` Roedel, Joerg
2010-07-29  9:28                     ` Roedel, Joerg
2010-07-29  9:44                       ` FUJITA Tomonori
2010-07-29 10:01                         ` Roedel, Joerg
2010-07-29 11:25                           ` Arnd Bergmann
2010-07-29 12:12                             ` Roedel, Joerg
2010-07-29 13:01                               ` Arnd Bergmann
2010-07-30  5:19                   ` stepanm at codeaurora.org
2010-07-30  8:01                     ` Arnd Bergmann
2010-07-30 16:25                       ` stepanm at codeaurora.org [this message]
2010-07-30 21:59                         ` Arnd Bergmann
2010-07-30 22:58                           ` stepanm at codeaurora.org
2010-07-31  9:37                             ` Arnd Bergmann
2010-08-02  7:58                     ` Roedel, Joerg
2010-08-02 20:29                       ` Zach Pfeffer
2010-08-03  9:23                         ` Roedel, Joerg
2010-08-03 18:43                           ` Stepan Moskovchenko
2010-08-04  9:52                             ` Roedel, Joerg
2010-07-31  3:15             ` Benjamin Herrenschmidt
2010-08-02  7:48               ` Roedel, Joerg
2010-08-02  8:03                 ` Benjamin Herrenschmidt
2010-08-02  8:10                   ` Roedel, Joerg
2010-08-02  8:30                   ` FUJITA Tomonori
2010-08-02  9:03                     ` Russell King - ARM Linux
2010-08-02  9:20                       ` FUJITA Tomonori
2010-08-02 10:04                         ` Russell King - ARM Linux
2010-08-02 15:26                           ` FUJITA Tomonori
2010-08-02  9:45                     ` Roedel, Joerg
2010-08-02  8:35                   ` Roedel, Joerg
2010-07-31  2:30           ` Benjamin Herrenschmidt

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=3faa32ace3110e9d1e51ef9735287de1.squirrel@www.codeaurora.org \
    --to=stepanm@codeaurora.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).