devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>,
	Liviu Dudau <liviu.dudau@arm.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Sudeep Holla <sudeep.holla@arm.com>
Subject: [PATCH] arm64: dts: juno: fix graph node unit addresses for coresight components
Date: Wed, 16 May 2018 11:34:22 +0100	[thread overview]
Message-ID: <1526466862-19173-1-git-send-email-sudeep.holla@arm.com> (raw)

Currently the coresight components graph node unit addresses are
continuous for both input and output ports while the "reg" properties
are restarted for input and output ports separately. This results is
the following DTC warnings:

 (graph_port): /etf@20010000/ports/port@1: graph node unit address error, expected "0"
 (graph_port): /etf@20140000/ports/port@1: graph node unit address error, expected "0"
 (graph_port): /funnel@20040000/ports/port@1: graph node unit address error, expected "0"
 (graph_port): /funnel@20040000/ports/port@2: graph node unit address error, expected "1"
 (graph_port): /funnel@20040000/ports/port@3: graph node unit address error, expected "2"
 (graph_port): /funnel@20130000/ports/port@1: graph node unit address error, expected "0"
 (graph_port): /funnel@20150000/ports/port@1: graph node unit address error, expected "0"
 (graph_port): /funnel@20150000/ports/port@2: graph node unit address error, expected "1"
 (graph_port): /funnel@220c0000/ports/port@1: graph node unit address error, expected "0"
 (graph_port): /funnel@220c0000/ports/port@2: graph node unit address error, expected "1"
 (graph_port): /funnel@230c0000/ports/port@1: graph node unit address error, expected "0"
 (graph_port): /funnel@230c0000/ports/port@2: graph node unit address error, expected "1"
 (graph_port): /funnel@230c0000/ports/port@3: graph node unit address error, expected "2"
 (graph_port): /funnel@230c0000/ports/port@4: graph node unit address error, expected "3"
 (graph_port): /replicator@20120000/ports/port@2: graph node unit address error, expected "0"

This patch makes even the reg property to follow the continuous
numbering as in the graph node unit address.

Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 arch/arm64/boot/dts/arm/juno-base.dtsi    | 20 ++++++++++----------
 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi |  8 ++++----
 arch/arm64/boot/dts/arm/juno.dts          |  2 +-
 3 files changed, 15 insertions(+), 15 deletions(-)

Hi Suzuki/Mathieu,

I did a quick scan @ drivers/hwtracing/coresight/of_coresight.c to check
if reg field is being used or not and whether this change causes any
regression. I don't think so, but I may be wrong, let me know.

diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 708a15887af4..dbeca292a57c 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -131,7 +131,7 @@
 
 			/* output port */
 			port@1 {
-				reg = <0>;
+				reg = <1>;
 				etf0_out_port: endpoint {
 				};
 			};
@@ -175,7 +175,7 @@
 
 			/* input ports */
 			port@1 {
-				reg = <0>;
+				reg = <1>;
 				main_funnel_in_port0: endpoint {
 					slave-mode;
 					remote-endpoint = <&cluster0_funnel_out_port>;
@@ -183,7 +183,7 @@
 			};
 
 			port@2 {
-				reg = <1>;
+				reg = <2>;
 				main_funnel_in_port1: endpoint {
 					slave-mode;
 					remote-endpoint = <&cluster1_funnel_out_port>;
@@ -265,7 +265,7 @@
 			};
 
 			port@1 {
-				reg = <0>;
+				reg = <1>;
 				cluster0_funnel_in_port0: endpoint {
 					slave-mode;
 					remote-endpoint = <&cluster0_etm0_out_port>;
@@ -273,7 +273,7 @@
 			};
 
 			port@2 {
-				reg = <1>;
+				reg = <2>;
 				cluster0_funnel_in_port1: endpoint {
 					slave-mode;
 					remote-endpoint = <&cluster0_etm1_out_port>;
@@ -347,7 +347,7 @@
 			};
 
 			port@1 {
-				reg = <0>;
+				reg = <1>;
 				cluster1_funnel_in_port0: endpoint {
 					slave-mode;
 					remote-endpoint = <&cluster1_etm0_out_port>;
@@ -355,21 +355,21 @@
 			};
 
 			port@2 {
-				reg = <1>;
+				reg = <2>;
 				cluster1_funnel_in_port1: endpoint {
 					slave-mode;
 					remote-endpoint = <&cluster1_etm1_out_port>;
 				};
 			};
 			port@3 {
-				reg = <2>;
+				reg = <3>;
 				cluster1_funnel_in_port2: endpoint {
 					slave-mode;
 					remote-endpoint = <&cluster1_etm2_out_port>;
 				};
 			};
 			port@4 {
-				reg = <3>;
+				reg = <4>;
 				cluster1_funnel_in_port3: endpoint {
 					slave-mode;
 					remote-endpoint = <&cluster1_etm3_out_port>;
@@ -476,7 +476,7 @@
 
 			/* replicator input port */
 			port@2 {
-				reg = <0>;
+				reg = <2>;
 				replicator_in_port0: endpoint {
 					slave-mode;
 				};
diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
index 21287f2d75d3..a99f311c8dcb 100644
--- a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
@@ -21,7 +21,7 @@
 
 			/* input port */
 			port@1 {
-				reg = <0>;
+				reg = <1>;
 				csys1_funnel_in_port0: endpoint {
 					slave-mode;
 				};
@@ -52,7 +52,7 @@
 
 			/* output port */
 			port@1 {
-				reg = <0>;
+				reg = <1>;
 				etf1_out_port: endpoint {
 					remote-endpoint = <&csys2_funnel_in_port1>;
 				};
@@ -81,7 +81,7 @@
 
 			/* input ports */
 			port@1 {
-				reg = <0>;
+				reg = <1>;
 				csys2_funnel_in_port0: endpoint {
 					slave-mode;
 					remote-endpoint = <&etf0_out_port>;
@@ -89,7 +89,7 @@
 			};
 
 			port@2 {
-				reg = <1>;
+				reg = <2>;
 				csys2_funnel_in_port1: endpoint {
 					slave-mode;
 					remote-endpoint = <&etf1_out_port>;
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index aa3b341a7547..34e940e7465b 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -260,7 +260,7 @@
 &main_funnel {
 	ports {
 		port@3 {
-			reg = <2>;
+			reg = <3>;
 			main_funnel_in_port2: endpoint {
 				slave-mode;
 				remote-endpoint = <&stm_out_port>;
-- 
2.7.4

             reply	other threads:[~2018-05-16 10:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-16 10:34 Sudeep Holla [this message]
2018-05-16 11:23 ` [PATCH] arm64: dts: juno: fix graph node unit addresses for coresight components Suzuki K Poulose
2018-05-16 11:49   ` Sudeep Holla
2018-05-16 17:29     ` Mathieu Poirier
2018-05-16 17:40       ` Sudeep Holla
2018-05-16 21:30         ` 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=1526466862-19173-1-git-send-email-sudeep.holla@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=liviu.dudau@arm.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=suzuki.poulose@arm.com \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).