diff for duplicates of <20140509171019.GA16780@obsidianresearch.com> diff --git a/a/1.txt b/N1/1.txt index e47f92f..1c1a6d1 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -136,13 +136,13 @@ was concerned with, is where the CPU and DMA paths are not the same. > Describing separate masters within a device in this way looks quite nice. > > Understanding what to do with them can still be left up to the driver -> for the parent node (peripheral at 0 in this case). +> for the parent node (peripheral@0 in this case). I was thinking the DMA API could learn to have a handle to the initiator, with no handle it assumes the device node is itself the initiator (eg dma-rages case) -> > peripheral at 1 { +> > peripheral@1 { > > ranges = < ... >; > > regs = <>; > > intiator { @@ -166,14 +166,14 @@ initiator (eg dma-rages case) > not automatically probed, but there are other reasons for that, such as > bus-specific power-on and probing methods. -Again, in this instance, it becomes up to the driver for peripheral at 1 +Again, in this instance, it becomes up to the driver for peripheral@1 to do something sensible with the buried nodes. The generic DT machinery will happily convert the reg of target into a CPU address for you. > > }; -> > peripheral2 at 0 { +> > peripheral2@0 { > > regs = <>; > > > > // Or we can write the simplest case like this. @@ -220,7 +220,7 @@ Right.. > There's no reason why buses can't be cross-connected using slaves > properties. I'd avoided such things so far, because it introduces > new cycle risks, such as -> socket at 0 -> cross -> socket at 1 -> cross -> socket at 0 in the following. +> socket@0 -> cross -> socket@1 -> cross -> socket@0 in the following. That is actually really how hardware works though. The socket-routers are configured to not have cycles on an address-by-address basis, but @@ -228,16 +228,16 @@ the actual high level topology is cyclic. > / { > cpus { -> cpu at 0 { +> cpu@0 { > slaves = <&socket0_interconnect>; > }; -> cpu at 1 { +> cpu@1 { > slaves = <&socket0_interconnect>; > }; -> cpu at 2 { +> cpu@2 { > slaves = <&socket1_interconnect>; > }; -> cpu at 3 { +> cpu@3 { > slaves = <&socket1_interconnect>; > }; > }; @@ -286,3 +286,7 @@ Or go back to the suggestion I gave last time - keep the DT tree basically as-is today and store a graph edge list separately. Jason +-- +To unsubscribe from this list: send the line "unsubscribe devicetree" in +the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org +More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 9a351cc..0a4b64b 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,10 +3,22 @@ "ref\020140502173120.GD3805@e103592.cambridge.arm.com\0" "ref\020140502181750.GD3179@obsidianresearch.com\0" "ref\020140509141633.GD3921@e103592.cambridge.arm.com\0" - "From\0jgunthorpe@obsidianresearch.com (Jason Gunthorpe)\0" - "Subject\0[RFC] Describing arbitrary bus mastering relationships in DT\0" + "ref\020140509141633.GD3921-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org\0" + "From\0Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>\0" + "Subject\0Re: [RFC] Describing arbitrary bus mastering relationships in DT\0" "Date\0Fri, 9 May 2014 11:10:19 -0600\0" - "To\0linux-arm-kernel@lists.infradead.org\0" + "To\0Dave Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org>\0" + "Cc\0Mark Rutland <Mark.Rutland-5wv7dgnIgG8@public.gmane.org>" + devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org + Shaik Ameer Basha <shaik.ameer-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> + Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> + Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> + Grant Grundler <grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> + Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org> + Marc Zyngier <Marc.Zyngier-5wv7dgnIgG8@public.gmane.org> + Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> + linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org + " Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>\0" "\00:1\0" "b\0" "On Fri, May 09, 2014 at 03:16:33PM +0100, Dave Martin wrote:\n" @@ -147,13 +159,13 @@ "> Describing separate masters within a device in this way looks quite nice.\n" "> \n" "> Understanding what to do with them can still be left up to the driver\n" - "> for the parent node (peripheral at 0 in this case).\n" + "> for the parent node (peripheral@0 in this case).\n" "\n" "I was thinking the DMA API could learn to have a handle to the\n" "initiator, with no handle it assumes the device node is itself the\n" "initiator (eg dma-rages case)\n" "\n" - "> > peripheral at 1 {\n" + "> > peripheral@1 {\n" "> > ranges = < ... >;\n" "> > \t\tregs = <>;\n" "> > intiator {\n" @@ -177,14 +189,14 @@ "> not automatically probed, but there are other reasons for that, such as\n" "> bus-specific power-on and probing methods.\n" "\n" - "Again, in this instance, it becomes up to the driver for peripheral at 1\n" + "Again, in this instance, it becomes up to the driver for peripheral@1\n" "to do something sensible with the buried nodes.\n" "\n" "The generic DT machinery will happily convert the reg of target into a\n" "CPU address for you.\n" "\n" "> > };\n" - "> > peripheral2 at 0 {\n" + "> > peripheral2@0 {\n" "> > \t\tregs = <>;\n" "> > \n" "> > \t\t// Or we can write the simplest case like this.\n" @@ -231,7 +243,7 @@ "> There's no reason why buses can't be cross-connected using slaves\n" "> properties. I'd avoided such things so far, because it introduces\n" "> new cycle risks, such as\n" - "> socket at 0 -> cross -> socket at 1 -> cross -> socket at 0 in the following.\n" + "> socket@0 -> cross -> socket@1 -> cross -> socket@0 in the following.\n" "\n" "That is actually really how hardware works though. The socket-routers\n" "are configured to not have cycles on an address-by-address basis, but\n" @@ -239,16 +251,16 @@ "\n" "> / {\n" "> \tcpus {\n" - "> \t\tcpu at 0 {\n" + "> \t\tcpu@0 {\n" "> \t\t\tslaves = <&socket0_interconnect>;\n" "> \t\t};\n" - "> \t\tcpu at 1 {\n" + "> \t\tcpu@1 {\n" "> \t\t\tslaves = <&socket0_interconnect>;\n" "> \t\t};\n" - "> \t\tcpu at 2 {\n" + "> \t\tcpu@2 {\n" "> \t\t\tslaves = <&socket1_interconnect>;\n" "> \t\t};\n" - "> \t\tcpu at 3 {\n" + "> \t\tcpu@3 {\n" "> \t\t\tslaves = <&socket1_interconnect>;\n" "> \t\t};\n" "> \t};\n" @@ -296,6 +308,10 @@ "Or go back to the suggestion I gave last time - keep the DT tree\n" "basically as-is today and store a graph edge list separately.\n" "\n" - Jason + "Jason\n" + "--\n" + "To unsubscribe from this list: send the line \"unsubscribe devicetree\" in\n" + "the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -bbf972be94dfb5817ff15025ed4577b7ca84f0543a0ca61f18018e6087231b2b +2fdd16a0c9186d42161e5bc424ada2c5b6bf285a4141fdd4b759ed33fdf9d7d3
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.