From: Suzuki K Poulose <Suzuki.Poulose@arm.com> To: Matt Sealey <Matt.Sealey@arm.com>, Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Rob Herring <robh@kernel.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 09:53:46 +0100 [thread overview] Message-ID: <5e013d65-9931-6b8d-ce7c-4333309d4ada@arm.com> (raw) In-Reply-To: <HE1PR0802MB24121F0EEF8D7D643BC391A1EE7E0@HE1PR0802MB2412.eurprd08.prod.outlook.com> On 13/06/18 22:07, Matt Sealey wrote: > > >> -----Original Message----- >> From: Mathieu Poirier <mathieu.poirier@linaro.org> >> >>> So, if the suggestion is to use an existing property "unit", I am fine >>> with it, if people agree to it. >> >> If we're going to have something sharply different than ACPI I prefer >> Rob's idea. 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 : 1) The connections are bi-directional => Well, not necessarily bi-directional in terms of the data flow. But the connection information is critical. i.e, we need information about both the end-points of a connection, which the DT graph bindings solves. All we are missing is a way for specifying the "hardware port" number and the direction of flow. I don't see why do we need to create something new just for these two properties for something that exists today and works reasonably well for the usecase. > > What are you trying to say about being sharply different than ACPI? The proposed Coresight ACPI draft bindings are based on the ACPI Graph bindings (just like the DT graph bindings and is compatible with it, in terms of the APIs. i.e, fwnode_graph_* operations work for both ACPI and DT alike). So, what Mathieu, in turn means is, if we depart from the DT Graph bindings, which I personally don't see any benefit in. Suzuki
WARNING: multiple messages have this Message-ID (diff)
From: Suzuki.Poulose@arm.com (Suzuki K Poulose) 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 09:53:46 +0100 [thread overview] Message-ID: <5e013d65-9931-6b8d-ce7c-4333309d4ada@arm.com> (raw) In-Reply-To: <HE1PR0802MB24121F0EEF8D7D643BC391A1EE7E0@HE1PR0802MB2412.eurprd08.prod.outlook.com> On 13/06/18 22:07, Matt Sealey wrote: > > >> -----Original Message----- >> From: Mathieu Poirier <mathieu.poirier@linaro.org> >> >>> So, if the suggestion is to use an existing property "unit", I am fine >>> with it, if people agree to it. >> >> If we're going to have something sharply different than ACPI I prefer >> Rob's idea. 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 : 1) The connections are bi-directional => Well, not necessarily bi-directional in terms of the data flow. But the connection information is critical. i.e, we need information about both the end-points of a connection, which the DT graph bindings solves. All we are missing is a way for specifying the "hardware port" number and the direction of flow. I don't see why do we need to create something new just for these two properties for something that exists today and works reasonably well for the usecase. > > What are you trying to say about being sharply different than ACPI? The proposed Coresight ACPI draft bindings are based on the ACPI Graph bindings (just like the DT graph bindings and is compatible with it, in terms of the APIs. i.e, fwnode_graph_* operations work for both ACPI and DT alike). So, what Mathieu, in turn means is, if we depart from the DT Graph bindings, which I personally don't see any benefit in. Suzuki
next prev parent reply other threads:[~2018-06-14 8:53 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 [this message] 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 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=5e013d65-9931-6b8d-ce7c-4333309d4ada@arm.com \ --to=suzuki.poulose@arm.com \ --cc=Charles.Garcia-Tobin@arm.com \ --cc=John.Horley@arm.com \ --cc=Mark.Rutland@arm.com \ --cc=Matt.Sealey@arm.com \ --cc=Sudeep.Holla@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.