diff for duplicates of <20140428193056.GD22135@arm.com> diff --git a/a/1.txt b/N1/1.txt index 032642e..d0e635c 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -12,45 +12,45 @@ On Mon, Apr 28, 2014 at 01:05:30PM +0100, Arnd Bergmann wrote: > > let me clarify by example: > -> iommu@1 { +> iommu at 1 { > compatible = "some,simple-iommu"; > reg = <1>; > #iommu-cells = <0>; /* supports only one master */ > }; > -> iommu@2 { +> iommu at 2 { > compatible = "some,other-iommu"; > reg = <3>; > #iommu-cells = <1>; /* contains master ID */ > }; > -> iommu@3 { +> iommu at 3 { > compatible = "some,windowed-iommu"; > reg = <2>; > #iommu-cells = <2>; /* contains dma-window */ > }; > -> 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 a9d825b..f560205 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,27 +2,10 @@ "ref\06544270.ddFBoY6LMm@wuerfel\0" "ref\020140428111802.GI19455@ulmo\0" "ref\04780885.JaktFvJeC7@wuerfel\0" - "From\0Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>\0" - "Subject\0Re: [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU\0" + "From\0will.deacon@arm.com (Will Deacon)\0" + "Subject\0[PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU\0" "Date\0Mon, 28 Apr 2014 20:30:56 +0100\0" - "To\0Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>\0" - "Cc\0t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org <t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>" - tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> - joshi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org <joshi-Sze3O3UU22JBDgjK7y7TUQ@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-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> - " linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "Hi Arnd,\n" @@ -39,45 +22,45 @@ "> \n" "> let me clarify by example:\n" "> \n" - "> \tiommu@1 {\n" + "> \tiommu at 1 {\n" "> \t\tcompatible = \"some,simple-iommu\";\n" "> \t\treg = <1>;\n" "> \t\t#iommu-cells = <0>; /* supports only one master */\n" "> \t};\n" "> \n" - "> \tiommu@2 {\n" + "> \tiommu at 2 {\n" "> \t\tcompatible = \"some,other-iommu\";\n" "> \t\treg = <3>;\n" "> \t\t#iommu-cells = <1>; /* contains master ID */\n" "> \t};\n" "> \n" - "> \tiommu@3 {\n" + "> \tiommu at 3 {\n" "> \t\tcompatible = \"some,windowed-iommu\";\n" "> \t\treg = <2>;\n" "> \t\t#iommu-cells = <2>; /* contains dma-window */\n" "> \t};\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" @@ -101,4 +84,4 @@ "\n" Will -2ff8d56714a0e5bd8e83ecdca17566d756d85179e1ee6b4dbcc06584a104a410 +888e4d751d8f26622486d767bbfb6b449b0df280a6993e325821949ddc2b42ca
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.