diff for duplicates of <6607258.MzzLbm2Afe@wuerfel> diff --git a/a/1.txt b/N1/1.txt index 2f28774..be6dc38 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,27 +2,27 @@ On Tuesday 29 April 2014 19:16:02 Dave Martin wrote: > On Mon, Apr 28, 2014 at 09:55:00PM +0200, Arnd Bergmann wrote: > > On Monday 28 April 2014 20:30:56 Will Deacon wrote: > > -> > > > device@4 { +> > > > device at 4 { > > > > compatible = "some,ethernet"; > > > > iommus = <&/iommu@1>; > > > > }; > > > > -> > > > device@5 { +> > > > device at 5 { > > > > compatible = "some,dmaengine"; > > > > iommus = <&/iommu@2 0x40000000 0x1000000>, > > > > <&/iommu@3 0x101>; > > > > }; > > > > -> > > > The device at address 4 has a one-one relationship with iommu@1, so there -> > > > is no need for any data. device@5 has two master ports. One is connected to -> > > > an IOMMU that has a per-device aperture, device@5 can only issue transfers +> > > > The device at address 4 has a one-one relationship with iommu at 1, so there +> > > > is no need for any data. device at 5 has two master ports. One is connected to +> > > > an IOMMU that has a per-device aperture, device at 5 can only issue transfers > > > > to the 256MB area at 0x40000000, and the IOMMU will have to put entries for > > > > this device into that address. The second master port is connected to -> > > > iommu@3, which uses a master ID that gets passed along with each transfer, +> > > > iommu at 3, which uses a master ID that gets passed along with each transfer, > > > > so that needs to be put into the IOTLBs. > > > > > > I think this is definitely going in the right direction, but it's not clear -> > > to me how the driver for device@5 knows how to configure the two ports. +> > > to me how the driver for device at 5 knows how to configure the two ports. > > > We're still lacking topology information (unless that's implicit in the > > > ordering of the properties) to say how the mastering capabilities of the > > > device are actually routed and configured. diff --git a/a/content_digest b/N1/content_digest index feef19b..37d4e9d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,55 +1,37 @@ "ref\01398584283-22846-1-git-send-email-shaik.ameer@samsung.com\0" "ref\05242619.ZKgCdLW1L4@wuerfel\0" "ref\020140429181601.GE3582@e103592.cambridge.arm.com\0" - "ref\020140429181601.GE3582-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org\0" - "From\0Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>\0" - "Subject\0Re: [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU\0" + "From\0arnd@arndb.de (Arnd Bergmann)\0" + "Subject\0[PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU\0" "Date\0Tue, 29 Apr 2014 22:46:18 +0200\0" - "To\0linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org\0" - "Cc\0t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org <t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>" - Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> - tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> - linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> - s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> - Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> - linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - prathyush.k-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org <prathyush.k-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> - sachin.kamat-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org <sachin.kamat-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> - Dave Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org> - devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> - grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org <grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> - kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org <kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> - a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org> - " pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org <pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>ra\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Tuesday 29 April 2014 19:16:02 Dave Martin wrote:\n" "> On Mon, Apr 28, 2014 at 09:55:00PM +0200, Arnd Bergmann wrote:\n" "> > On Monday 28 April 2014 20:30:56 Will Deacon wrote:\n" "> >\n" - "> > > > \tdevice@4 {\n" + "> > > > \tdevice at 4 {\n" "> > > > \t\tcompatible = \"some,ethernet\";\n" "> > > > \t\tiommus = <&/iommu@1>;\n" "> > > > \t};\n" "> > > > \n" - "> > > > \tdevice@5 {\n" + "> > > > \tdevice at 5 {\n" "> > > > \t\tcompatible = \"some,dmaengine\";\n" "> > > > \t\tiommus = <&/iommu@2 0x40000000 0x1000000>,\n" "> > > > \t\t\t <&/iommu@3 0x101>;\n" "> > > > \t};\n" "> > > > \n" - "> > > > The device at address 4 has a one-one relationship with iommu@1, so there\n" - "> > > > is no need for any data. device@5 has two master ports. One is connected to\n" - "> > > > an IOMMU that has a per-device aperture, device@5 can only issue transfers\n" + "> > > > The device at address 4 has a one-one relationship with iommu at 1, so there\n" + "> > > > is no need for any data. device at 5 has two master ports. One is connected to\n" + "> > > > an IOMMU that has a per-device aperture, device at 5 can only issue transfers\n" "> > > > to the 256MB area at 0x40000000, and the IOMMU will have to put entries for\n" "> > > > this device into that address. The second master port is connected to\n" - "> > > > iommu@3, which uses a master ID that gets passed along with each transfer,\n" + "> > > > iommu at 3, which uses a master ID that gets passed along with each transfer,\n" "> > > > so that needs to be put into the IOTLBs.\n" "> > > \n" "> > > I think this is definitely going in the right direction, but it's not clear\n" - "> > > to me how the driver for device@5 knows how to configure the two ports.\n" + "> > > to me how the driver for device at 5 knows how to configure the two ports.\n" "> > > We're still lacking topology information (unless that's implicit in the\n" "> > > ordering of the properties) to say how the mastering capabilities of the\n" "> > > device are actually routed and configured.\n" @@ -128,4 +110,4 @@ "\n" "\tArnd" -69ed14ed88118ce5bacd7e957ec82a39e69c5366412985c47c9f65b64cfede7f +ce86fb5077a6afac439c3f6eacd08fd20fa0b6579620f146619b89c6ba1cac58
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.