From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Grant Grundler <grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Cho KyongHo <pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Dave Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] devicetree: Add generic IOMMU device tree bindings
Date: Tue, 20 May 2014 14:02:43 +0200 [thread overview]
Message-ID: <20140520120242.GA20995@ulmo> (raw)
In-Reply-To: <10711669.TTjp9L4tTG@wuerfel>
[-- Attachment #1.1: Type: text/plain, Size: 6471 bytes --]
On Tue, May 20, 2014 at 01:15:48PM +0200, Arnd Bergmann wrote:
> On Tuesday 20 May 2014 13:05:37 Thierry Reding wrote:
> > On Tue, May 20, 2014 at 12:04:54PM +0200, Arnd Bergmann wrote:
> > > On Monday 19 May 2014 22:59:46 Thierry Reding wrote:
> > > > On Mon, May 19, 2014 at 08:34:07PM +0200, Arnd Bergmann wrote:
[...]
> > > > > You should never need #size-cells > #address-cells
> > > >
> > > > That was always my impression as well. But how then do you represent the
> > > > full 4 GiB address space in a 32-bit system? It starts at 0 and ends at
> > > > 4 GiB - 1, which makes it 4 GiB large. That's:
> > > >
> > > > <0 1 0>
> > > >
> > > > With #address-cells = <1> and #size-cells = <1> the best you can do is:
> > > >
> > > > <0 0xffffffff>
> > > >
> > > > but that's not accurate.
> > >
> > > I think we've done both in the past, either extended #size-cells or
> > > taken 0xffffffff as a special token. Note that in your example,
> > > the iommu actually needs #address-cells = <2> anyway.
> >
> > But it needs #address-cells = <2> only to encode an ID in addition to
> > the address. If this was a single-master IOMMU then there'd be no need
> > for the ID.
>
> Right. But for a single-master IOMMU, there is no need to specify
> any additional data, it could have #address-cells=<0> if we take the
> optimization you suggested.
Couldn't a single-master IOMMU be windowed?
> > I'm not sure I understand the need for 0x100 (all IDs) entry above. If
> > bus1's iommus property applies to all devices on the bus, why can't the
> > ID 0xb be listed in the iommus property?
> >
> > bus1 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ranges;
> > iommus = <&{/iommu} 0xb 0 0x1 0x0>; // 4GB ID '0xb'
> > dma-ranges = <0 0xb 0 0x1 0x0>;
> >
> > anothermaster {
> > ...
> > };
> > };
>
> It depends on how the address is interpreted, but we could make this
> a valid case too.
>
> > In which case I guess dma-ranges would be redundant.
>
> No, because the iommus property doesn't translate the address range, it
> just creates a new address space. bus1 and iommu in the example have
> different #address-cells, so you definitely need a non-empty ranges
> property.
Ah, now I get it.
> > > The main advantage I think would be for IOMMUs that use the PCI b/d/f
> > > numbers as IDs. These can have #address-cells=<3>, #size-cells=<2>
> > > and have an empty dma-ranges property in the PCI host bridge node,
> > > and interpret this as using the same encoding as the PCI BARs in
> > > the ranges property.
> >
> > I'm somewhat confused here, since you said earlier:
> >
> > > After giving the ranges stuff some more thought, I have come to the
> > > conclusion that using #iommu-cells should work fine for almost
> > > all cases, including windowed iommus, because the window is not
> > > actually needed in the device, but only in the iommu, wihch is of course
> > > free to interpret the arguments as addresses.
> >
> > But now you seem to be saying that we should still be using the
> > #address-cells and #size-cells properties in the IOMMU node to determine
> > the length of the specifier.
>
> I probably wasn't clear. I think we can make it work either way, but
> my feeling is that using #address-cells/#size-cells gives us a nicer
> syntax for the more complex cases.
Okay, so in summary we'd have something like this for simple cases:
Required properties:
--------------------
- #address-cells: The number of cells in an IOMMU specifier needed to encode
an address.
- #size-cells: The number of cells in an IOMMU specifier needed to represent
the length of an address range.
Typical values for the above include:
- #address-cells = <0>, size-cells = <0>: Single master IOMMU devices are not
configurable and therefore no additional information needs to be encoded in
the specifier. This may also apply to multiple master IOMMU devices that do
not allow the association of masters to be configured.
- #address-cells = <1>, size-cells = <0>: Multiple master IOMMU devices may
need to be configured in order to enable translation for a given master. In
such cases the single address cell corresponds to the master device's ID.
- #address-cells = <2>, size-cells = <2>: Some IOMMU devices allow the DMA
window for masters to be configured. The first cell of the address in this
may contain the master device's ID for example, while the second cell could
contain the start of the DMA window for the given device. The length of the
DMA window is specified by two additional cells.
Examples:
=========
Single-master IOMMU:
--------------------
iommu {
#address-cells = <0>;
#size-cells = <0>;
};
master {
iommus = <&/iommu>;
};
Multiple-master IOMMU with fixed associations:
----------------------------------------------
/* multiple-master IOMMU */
iommu {
/*
* Masters are statically associated with this IOMMU and
* address translation is always enabled.
*/
#iommu-cells = <0>;
};
/* static association with IOMMU */
master@1 {
reg = <1>;
iommus = <&/iommu>;
};
/* static association with IOMMU */
master@2 {
reg = <2>;
iommus = <&/iommu>;
};
Multiple-master IOMMU:
----------------------
iommu {
/* the specifier represents the ID of the master */
#address-cells = <1>;
#size-cells = <0>;
};
master {
/* device has master ID 42 in the IOMMU */
iommus = <&/iommu 42>;
};
Multiple-master device:
-----------------------
/* single-master IOMMU */
iommu@1 {
reg = <1>;
#address-cells = <0>;
#size-cells = <0>;
};
/* multiple-master IOMMU */
iommu@2 {
reg = <2>;
#address-cells = <1>;
#size-cells = <0>;
};
/* device with two master interfaces */
master {
iommus = <&/iommu@1>, /* master of the single-master IOMMU */
<&/iommu@2 42>; /* ID 42 in multiple-master IOMMU */
};
Multiple-master IOMMU with configurable DMA window:
---------------------------------------------------
/ {
#address-cells = <1>;
#size-cells = <1>;
iommu {
/* master ID, address of DMA window */
#address-cells = <2>;
#size-cells = <2>;
};
master {
/* master ID 42, 4 GiB DMA window starting at 0 */
iommus = <&/iommu 42 0 0x1 0x0>;
};
};
Does that sound about right?
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2014-05-20 12:02 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-16 12:23 [PATCH] devicetree: Add generic IOMMU device tree bindings Thierry Reding
[not found] ` <1400242998-437-1-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-17 8:04 ` Cho KyongHo
2014-05-17 20:48 ` Thierry Reding
2014-05-19 10:26 ` Arnd Bergmann
2014-05-19 12:53 ` Thierry Reding
2014-05-19 17:22 ` Dave Martin
[not found] ` <20140519172113.GA13858-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-19 20:32 ` Thierry Reding
2014-05-20 10:08 ` Arnd Bergmann
2014-05-20 13:07 ` Dave Martin
[not found] ` <20140520130659.GA5041-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-20 13:23 ` Arnd Bergmann
2014-05-20 15:26 ` Will Deacon
[not found] ` <20140520152659.GA30404-5wv7dgnIgG8@public.gmane.org>
2014-05-20 16:39 ` Dave Martin
[not found] ` <20140520163912.GC5041-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-20 20:40 ` Arnd Bergmann
2014-05-19 18:34 ` Arnd Bergmann
2014-05-19 20:59 ` Thierry Reding
2014-05-20 10:04 ` Arnd Bergmann
2014-05-20 11:05 ` Thierry Reding
2014-05-20 11:15 ` Arnd Bergmann
2014-05-20 12:02 ` Thierry Reding [this message]
2014-05-20 12:41 ` Arnd Bergmann
2014-05-20 13:17 ` Thierry Reding
2014-05-20 13:34 ` Arnd Bergmann
2014-05-20 14:00 ` Thierry Reding
2014-05-20 20:31 ` Arnd Bergmann
2014-05-21 8:16 ` Thierry Reding
2014-05-21 8:54 ` Arnd Bergmann
2014-05-21 9:02 ` Thierry Reding
2014-05-21 9:32 ` Arnd Bergmann
2014-05-21 15:44 ` Grant Grundler
2014-05-21 16:01 ` Arnd Bergmann
2014-05-20 15:24 ` Dave Martin
[not found] ` <20140520152458.GB5041-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-20 20:26 ` Arnd Bergmann
2014-05-21 8:26 ` Thierry Reding
2014-05-21 8:50 ` Arnd Bergmann
2014-05-21 9:00 ` Thierry Reding
2014-05-21 9:36 ` Arnd Bergmann
2014-05-21 10:50 ` Thierry Reding
2014-05-21 14:01 ` Arnd Bergmann
2014-05-21 17:09 ` Dave Martin
[not found] ` <20140521170954.GC3830-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-21 18:11 ` Arnd Bergmann
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=20140520120242.GA20995@ulmo \
--to=thierry.reding-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=Dave.Martin-5wv7dgnIgG8@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.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).