From: Matt Sealey <Matt.Sealey@arm.com> To: Rob Herring <robh@kernel.org>, Suzuki Poulose <Suzuki.Poulose@arm.com> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Sudeep Holla <Sudeep.Holla@arm.com>, Mark Rutland <Mark.Rutland@arm.com>, "frowand.list@gmail.com" <frowand.list@gmail.com>, Charles Garcia-Tobin <Charles.Garcia-Tobin@arm.com>, John Horley <John.Horley@arm.com>, "mike.leach@linaro.org" <mike.leach@linaro.org>, "coresight@lists.linaro.org" <coresight@lists.linaro.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org> Subject: RE: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings Date: Thu, 14 Jun 2018 15:04:52 +0000 [thread overview] Message-ID: <HE1PR0802MB241249AB5A90012AA6EB5235EE7D0@HE1PR0802MB2412.eurprd08.prod.outlook.com> (raw) In-Reply-To: <CAL_Jsq+0kExVY33kdDoR6bAxbr2VzRUzW2j0k+2wmv4CSNVnpQ@mail.gmail.com> Hi Rob, To take this in a somewhat different direction... > > No, the above comment is about using "unit" ( if it is a standard > > property for specifying something specific to hardware) instead of > > "coresight,hwid". I would prefer to stick to the DT graph bindings, > > because : > > "unit" is not a standard property and I don't like it either. Fair enough. > If you have "in-ports" and "out-ports" nodes, then that gives you > direction and you can use reg for the "hardware port". > > in-ports { > port@0 { > reg = <0>; > endpoint {...}; > }; > port@1 { > reg = <1>; > endpoint {...}; > }; > }; > out-ports { > port@0 { > reg = <0>; > endpoint {...}; > }; > }; > > I'll need to check, but dtc may need an update to not warn about this. If the requirement that unit-address and the low #address-cells of reg now being forced by a validation tool is screwing us over here, we can't really change the tool; that's a IEEE 1275-1994 requirement we'd be hacking around. Here's a thought - why don't we define the ports in each component in a separate graph? Describing the ATB topology as a bus with a graph structure and then having the components simply reference the port nodes would make it much easier to design. Part of the problem is trying to describe an ATB bus via a component on an APB bus. You lose all the niceties of describing a bus with bus subcomponents. Lets take the ATB bus outside.. by describing the ingress and egress of the component you have no idea where in the graph you are at the point of entry (you could start parsing at a funnel, which means travelling around looking for other units that match other compatibles). If the CoreSight subsystem could have a graph pre-made of the full topology, then the components can point to how they wrap parts of that topology. You can also do away with ridiculous non-programmable funnels and replicator nodes, since the trace graph would encapsulate that information without having to instantiate a stub driver for it. That doesn't solve 'unit' or 'unit-address' or 'reg' or anything but it would keep us in graph bindings and abstract the ATB topology from the components. Other fun stuff; describing bridge components and bus widths within the graph could give abilities to describe bandwidths over each trace path. In any case, what happens when you have to decide what your funnel port priorities are, you'll have to define a new property for that, and it won't be 'reg'. Trying not to add anything to the graph bindings is one thing but trying to shoehorn it in either by doing that or inventing wholly device-specific properties are just as bad. Perhaps we can use the path@unit-address:arguments <-- parameters here to add extra information about the port. 'my-args' would pull it out in Forth, I don't know how FDT code deals with it (but there should be something, since we use it for console definition in /chosen). They're entirely specific to the node in question, but not used in path matching. Why can't we decide on a graph-binding update that allows specifying something simple as a demultiplexer output in a way the driver can understand and map to the hardware? > If DT bindings can be reused for ACPI, that's fine However in my opinion not the preferred way to do it.. > any DT bindings to be accepted simply because they match ACPI > bindings. I'm sure ACPI has capability of a much classier way of describing things, but I have some fear that it's just OF bindings stuffed in a _DSD.. DT and ACPI have the responsibility of shouldering the burden of describing hardware. Any attempts to try and make some commonality to promote brevity of Linux code is totally out of scope.. You can always abstract whatever definition into whatever the Linux drivers need at the time. That's kind of the point. Locking in to 'how it's currently coded' is stifling when realizing the first attempt didn't actually adequately do what it was intended. Ta, Matt IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
WARNING: multiple messages have this Message-ID (diff)
From: Matt.Sealey@arm.com (Matt Sealey) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings Date: Thu, 14 Jun 2018 15:04:52 +0000 [thread overview] Message-ID: <HE1PR0802MB241249AB5A90012AA6EB5235EE7D0@HE1PR0802MB2412.eurprd08.prod.outlook.com> (raw) In-Reply-To: <CAL_Jsq+0kExVY33kdDoR6bAxbr2VzRUzW2j0k+2wmv4CSNVnpQ@mail.gmail.com> Hi Rob, To take this in a somewhat different direction... > > No, the above comment is about using "unit" ( if it is a standard > > property for specifying something specific to hardware) instead of > > "coresight,hwid". I would prefer to stick to the DT graph bindings, > > because : > > "unit" is not a standard property and I don't like it either. Fair enough. > If you have "in-ports" and "out-ports" nodes, then that gives you > direction and you can use reg for the "hardware port". > > in-ports { > port at 0 { > reg = <0>; > endpoint {...}; > }; > port at 1 { > reg = <1>; > endpoint {...}; > }; > }; > out-ports { > port at 0 { > reg = <0>; > endpoint {...}; > }; > }; > > I'll need to check, but dtc may need an update to not warn about this. If the requirement that unit-address and the low #address-cells of reg now being forced by a validation tool is screwing us over here, we can't really change the tool; that's a IEEE 1275-1994 requirement we'd be hacking around. Here's a thought - why don't we define the ports in each component in a separate graph? Describing the ATB topology as a bus with a graph structure and then having the components simply reference the port nodes would make it much easier to design. Part of the problem is trying to describe an ATB bus via a component on an APB bus. You lose all the niceties of describing a bus with bus subcomponents. Lets take the ATB bus outside.. by describing the ingress and egress of the component you have no idea where in the graph you are at the point of entry (you could start parsing at a funnel, which means travelling around looking for other units that match other compatibles). If the CoreSight subsystem could have a graph pre-made of the full topology, then the components can point to how they wrap parts of that topology. You can also do away with ridiculous non-programmable funnels and replicator nodes, since the trace graph would encapsulate that information without having to instantiate a stub driver for it. That doesn't solve 'unit' or 'unit-address' or 'reg' or anything but it would keep us in graph bindings and abstract the ATB topology from the components. Other fun stuff; describing bridge components and bus widths within the graph could give abilities to describe bandwidths over each trace path. In any case, what happens when you have to decide what your funnel port priorities are, you'll have to define a new property for that, and it won't be 'reg'. Trying not to add anything to the graph bindings is one thing but trying to shoehorn it in either by doing that or inventing wholly device-specific properties are just as bad. Perhaps we can use the path at unit-address:arguments <-- parameters here to add extra information about the port. 'my-args' would pull it out in Forth, I don't know how FDT code deals with it (but there should be something, since we use it for console definition in /chosen). They're entirely specific to the node in question, but not used in path matching. Why can't we decide on a graph-binding update that allows specifying something simple as a demultiplexer output in a way the driver can understand and map to the hardware? > If DT bindings can be reused for ACPI, that's fine However in my opinion not the preferred way to do it.. > any DT bindings to be accepted simply because they match ACPI > bindings. I'm sure ACPI has capability of a much classier way of describing things, but I have some fear that it's just OF bindings stuffed in a _DSD.. DT and ACPI have the responsibility of shouldering the burden of describing hardware. Any attempts to try and make some commonality to promote brevity of Linux code is totally out of scope.. You can always abstract whatever definition into whatever the Linux drivers need at the time. That's kind of the point. Locking in to 'how it's currently coded' is stifling when realizing the first attempt didn't actually adequately do what it was intended. Ta, Matt IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
next prev parent reply other threads:[~2018-06-14 15:05 UTC|newest] Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-06-01 13:15 [RFC PATCH 0/8] coresight: Update device tree bindings Suzuki K Poulose 2018-06-01 13:15 ` Suzuki K Poulose 2018-06-01 13:16 ` [RFC PATCH 1/8] dts: binding: coresight: Document graph bindings Suzuki K Poulose 2018-06-01 13:16 ` Suzuki K Poulose 2018-06-01 16:14 ` Mathieu Poirier 2018-06-01 16:14 ` Mathieu Poirier 2018-06-01 13:16 ` [RFC PATCH 2/8] coresight: Fix remote endpoint parsing Suzuki K Poulose 2018-06-01 13:16 ` Suzuki K Poulose 2018-06-01 19:38 ` Mathieu Poirier 2018-06-01 19:38 ` Mathieu Poirier 2018-06-01 19:46 ` Mathieu Poirier 2018-06-01 19:46 ` Mathieu Poirier 2018-06-04 10:34 ` Suzuki K Poulose 2018-06-04 10:34 ` Suzuki K Poulose 2018-06-01 13:16 ` [RFC PATCH 3/8] coresight: Cleanup platform description data Suzuki K Poulose 2018-06-01 13:16 ` Suzuki K Poulose 2018-06-01 13:16 ` [RFC PATCH 4/8] coresight: platform: Cleanup coresight connection handling Suzuki K Poulose 2018-06-01 13:16 ` Suzuki K Poulose 2018-06-01 13:16 ` [RFC PATCH 5/8] coresight: Handle errors in finding input/output ports Suzuki K Poulose 2018-06-01 13:16 ` Suzuki K Poulose 2018-06-01 13:16 ` [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings Suzuki K Poulose 2018-06-01 13:16 ` Suzuki K Poulose 2018-06-01 20:26 ` Mathieu Poirier 2018-06-01 20:26 ` Mathieu Poirier 2018-06-12 20:48 ` Rob Herring 2018-06-12 20:48 ` Rob Herring 2018-06-13 9:45 ` Suzuki K Poulose 2018-06-13 9:45 ` Suzuki K Poulose 2018-06-13 12:49 ` Matt Sealey 2018-06-13 12:49 ` Matt Sealey 2018-06-13 12:49 ` Matt Sealey 2018-06-13 13:35 ` Suzuki K Poulose 2018-06-13 13:35 ` Suzuki K Poulose 2018-06-13 13:35 ` Suzuki K Poulose 2018-06-13 13:57 ` Rob Herring 2018-06-13 13:57 ` Rob Herring 2018-06-13 13:57 ` Rob Herring 2018-06-13 15:47 ` Matt Sealey 2018-06-13 15:47 ` Matt Sealey 2018-06-13 15:47 ` Matt Sealey 2018-06-13 17:07 ` Suzuki K Poulose 2018-06-13 17:07 ` Suzuki K Poulose 2018-06-13 17:07 ` Suzuki K Poulose 2018-06-13 19:40 ` Mathieu Poirier 2018-06-13 19:40 ` Mathieu Poirier 2018-06-13 19:40 ` Mathieu Poirier 2018-06-13 21:07 ` Matt Sealey 2018-06-13 21:07 ` Matt Sealey 2018-06-13 21:07 ` Matt Sealey 2018-06-14 8:53 ` Suzuki K Poulose 2018-06-14 8:53 ` Suzuki K Poulose 2018-06-14 8:53 ` Suzuki K Poulose 2018-06-14 13:59 ` Rob Herring 2018-06-14 13:59 ` Rob Herring 2018-06-14 13:59 ` Rob Herring 2018-06-14 15:04 ` Matt Sealey [this message] 2018-06-14 15:04 ` Matt Sealey 2018-06-14 15:04 ` Matt Sealey 2018-06-15 9:58 ` Suzuki K Poulose 2018-06-15 9:58 ` Suzuki K Poulose 2018-06-15 9:58 ` Suzuki K Poulose 2018-07-03 9:44 ` Suzuki K Poulose 2018-07-03 9:44 ` Suzuki K Poulose 2018-07-03 9:44 ` Suzuki K Poulose 2018-07-03 16:15 ` Mathieu Poirier 2018-06-01 13:16 ` [RFC PATCH 7/8] dts: coresight: Define new bindings for direction of data flow Suzuki K Poulose 2018-06-01 13:16 ` Suzuki K Poulose 2018-06-01 20:39 ` Mathieu Poirier 2018-06-01 20:39 ` Mathieu Poirier 2018-06-04 14:20 ` Suzuki K Poulose 2018-06-04 14:20 ` Suzuki K Poulose 2018-06-01 13:16 ` [RFC PATCH 8/8] dts: juno: Update coresight bindings for hw port Suzuki K Poulose 2018-06-01 13:16 ` Suzuki K Poulose 2018-06-01 20:59 ` Mathieu Poirier 2018-06-01 20:59 ` Mathieu Poirier 2018-06-01 21:04 ` [RFC PATCH 0/8] coresight: Update device tree bindings Mathieu Poirier 2018-06-01 21:04 ` Mathieu Poirier
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=HE1PR0802MB241249AB5A90012AA6EB5235EE7D0@HE1PR0802MB2412.eurprd08.prod.outlook.com \ --to=matt.sealey@arm.com \ --cc=Charles.Garcia-Tobin@arm.com \ --cc=John.Horley@arm.com \ --cc=Mark.Rutland@arm.com \ --cc=Sudeep.Holla@arm.com \ --cc=Suzuki.Poulose@arm.com \ --cc=coresight@lists.linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=frowand.list@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mathieu.poirier@linaro.org \ --cc=mike.leach@linaro.org \ --cc=robh@kernel.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.