(unknown),

(unknown),

[Rohit Vaswani]

Date: Mon, 23 Sep 2013 19:51:25 -0700
Subject: [PATCH 1/3] ARM: debug: Create CONFIG_DEBUG_MSM_UART and re-organize
 the selects for MSM

Create the hidden config DEBUG_MSM_UART and clean-up the default selection
for CONFIG_DEBUG_LL_INCLUDE.

Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
---
 arch/arm/Kconfig.debug | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9762c84..e18a6fc 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -318,6 +318,7 @@ choice
 	config DEBUG_MSM_UART1
 		bool "Kernel low-level debugging messages via MSM UART1"
 		depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
+		select DEBUG_MSM_UART
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the first serial port on MSM devices.
@@ -325,6 +326,7 @@ choice
 	config DEBUG_MSM_UART2
 		bool "Kernel low-level debugging messages via MSM UART2"
 		depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
+		select DEBUG_MSM_UART
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the second serial port on MSM devices.
@@ -332,6 +334,7 @@ choice
 	config DEBUG_MSM_UART3
 		bool "Kernel low-level debugging messages via MSM UART3"
 		depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
+		select DEBUG_MSM_UART
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the third serial port on MSM devices.
@@ -340,6 +343,7 @@ choice
 		bool "Kernel low-level debugging messages via MSM 8660 UART"
 		depends on ARCH_MSM8X60
 		select MSM_HAS_DEBUG_UART_HS
+		select DEBUG_MSM_UART
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the serial port on MSM 8660 devices.
@@ -348,6 +352,7 @@ choice
 		bool "Kernel low-level debugging messages via MSM 8960 UART"
 		depends on ARCH_MSM8960
 		select MSM_HAS_DEBUG_UART_HS
+		select DEBUG_MSM_UART
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the serial port on MSM 8960 devices.
@@ -880,6 +885,10 @@ config DEBUG_STI_UART
 	bool
 	depends on ARCH_STI
 
+config DEBUG_MSM_UART
+	bool
+	depends on ARCH_MSM
+
 config DEBUG_LL_INCLUDE
 	string
 	default "debug/8250.S" if DEBUG_LL_UART_8250 || DEBUG_UART_8250
@@ -895,11 +904,7 @@ config DEBUG_LL_INCLUDE
 				 DEBUG_IMX53_UART ||\
 				 DEBUG_IMX6Q_UART || \
 				 DEBUG_IMX6SL_UART
-	default "debug/msm.S" if DEBUG_MSM_UART1 || \
-				 DEBUG_MSM_UART2 || \
-				 DEBUG_MSM_UART3 || \
-				 DEBUG_MSM8660_UART || \
-				 DEBUG_MSM8960_UART
+	default "debug/msm.S" if DEBUG_MSM_UART
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
 	default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
 	default "debug/sti.S" if DEBUG_STI_UART
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

(no subject)

[Rohit Vaswani]

Date: Mon, 23 Sep 2013 19:51:25 -0700
Subject: [PATCH 1/3] ARM: debug: Create CONFIG_DEBUG_MSM_UART and re-organize
 the selects for MSM

Create the hidden config DEBUG_MSM_UART and clean-up the default selection
for CONFIG_DEBUG_LL_INCLUDE.

Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
---
 arch/arm/Kconfig.debug | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9762c84..e18a6fc 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -318,6 +318,7 @@ choice
 	config DEBUG_MSM_UART1
 		bool "Kernel low-level debugging messages via MSM UART1"
 		depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
+		select DEBUG_MSM_UART
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the first serial port on MSM devices.
@@ -325,6 +326,7 @@ choice
 	config DEBUG_MSM_UART2
 		bool "Kernel low-level debugging messages via MSM UART2"
 		depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
+		select DEBUG_MSM_UART
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the second serial port on MSM devices.
@@ -332,6 +334,7 @@ choice
 	config DEBUG_MSM_UART3
 		bool "Kernel low-level debugging messages via MSM UART3"
 		depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
+		select DEBUG_MSM_UART
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the third serial port on MSM devices.
@@ -340,6 +343,7 @@ choice
 		bool "Kernel low-level debugging messages via MSM 8660 UART"
 		depends on ARCH_MSM8X60
 		select MSM_HAS_DEBUG_UART_HS
+		select DEBUG_MSM_UART
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the serial port on MSM 8660 devices.
@@ -348,6 +352,7 @@ choice
 		bool "Kernel low-level debugging messages via MSM 8960 UART"
 		depends on ARCH_MSM8960
 		select MSM_HAS_DEBUG_UART_HS
+		select DEBUG_MSM_UART
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the serial port on MSM 8960 devices.
@@ -880,6 +885,10 @@ config DEBUG_STI_UART
 	bool
 	depends on ARCH_STI
 
+config DEBUG_MSM_UART
+	bool
+	depends on ARCH_MSM
+
 config DEBUG_LL_INCLUDE
 	string
 	default "debug/8250.S" if DEBUG_LL_UART_8250 || DEBUG_UART_8250
@@ -895,11 +904,7 @@ config DEBUG_LL_INCLUDE
 				 DEBUG_IMX53_UART ||\
 				 DEBUG_IMX6Q_UART || \
 				 DEBUG_IMX6SL_UART
-	default "debug/msm.S" if DEBUG_MSM_UART1 || \
-				 DEBUG_MSM_UART2 || \
-				 DEBUG_MSM_UART3 || \
-				 DEBUG_MSM8660_UART || \
-				 DEBUG_MSM8960_UART
+	default "debug/msm.S" if DEBUG_MSM_UART
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
 	default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
 	default "debug/sti.S" if DEBUG_STI_UART
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

No subject

[Rohit Vaswani]

Date: Mon, 23 Sep 2013 19:51:25 -0700
Subject: [PATCH 1/3] ARM: debug: Create CONFIG_DEBUG_MSM_UART and re-organize
 the selects for MSM

Create the hidden config DEBUG_MSM_UART and clean-up the default selection
for CONFIG_DEBUG_LL_INCLUDE.

Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
---
 arch/arm/Kconfig.debug | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9762c84..e18a6fc 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -318,6 +318,7 @@ choice
 	config DEBUG_MSM_UART1
 		bool "Kernel low-level debugging messages via MSM UART1"
 		depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
+		select DEBUG_MSM_UART
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the first serial port on MSM devices.
@@ -325,6 +326,7 @@ choice
 	config DEBUG_MSM_UART2
 		bool "Kernel low-level debugging messages via MSM UART2"
 		depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
+		select DEBUG_MSM_UART
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the second serial port on MSM devices.
@@ -332,6 +334,7 @@ choice
 	config DEBUG_MSM_UART3
 		bool "Kernel low-level debugging messages via MSM UART3"
 		depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
+		select DEBUG_MSM_UART
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the third serial port on MSM devices.
@@ -340,6 +343,7 @@ choice
 		bool "Kernel low-level debugging messages via MSM 8660 UART"
 		depends on ARCH_MSM8X60
 		select MSM_HAS_DEBUG_UART_HS
+		select DEBUG_MSM_UART
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the serial port on MSM 8660 devices.
@@ -348,6 +352,7 @@ choice
 		bool "Kernel low-level debugging messages via MSM 8960 UART"
 		depends on ARCH_MSM8960
 		select MSM_HAS_DEBUG_UART_HS
+		select DEBUG_MSM_UART
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the serial port on MSM 8960 devices.
@@ -880,6 +885,10 @@ config DEBUG_STI_UART
 	bool
 	depends on ARCH_STI
 
+config DEBUG_MSM_UART
+	bool
+	depends on ARCH_MSM
+
 config DEBUG_LL_INCLUDE
 	string
 	default "debug/8250.S" if DEBUG_LL_UART_8250 || DEBUG_UART_8250
@@ -895,11 +904,7 @@ config DEBUG_LL_INCLUDE
 				 DEBUG_IMX53_UART ||\
 				 DEBUG_IMX6Q_UART || \
 				 DEBUG_IMX6SL_UART
-	default "debug/msm.S" if DEBUG_MSM_UART1 || \
-				 DEBUG_MSM_UART2 || \
-				 DEBUG_MSM_UART3 || \
-				 DEBUG_MSM8660_UART || \
-				 DEBUG_MSM8960_UART
+	default "debug/msm.S" if DEBUG_MSM_UART
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
 	default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
 	default "debug/sti.S" if DEBUG_STI_UART
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Rohit Vaswani]

This patch adds basic board support for APQ8074 Dragonboard
which belongs to the Snapdragon 800 family.
For now, just support a basic machine with device tree.

Signed-off-by: Rohit Vaswani <rvaswani-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
 arch/arm/Kconfig.debug                         |  9 +++++++
 arch/arm/boot/dts/Makefile                     |  3 ++-
 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts |  6 +++++
 arch/arm/boot/dts/qcom-msm8974.dtsi            | 35 ++++++++++++++++++++++++++
 arch/arm/include/debug/msm.S                   |  5 ++++
 arch/arm/mach-msm/Kconfig                      | 13 ++++++++++
 arch/arm/mach-msm/board-dt.c                   |  9 +++++++
 7 files changed, 79 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
 create mode 100644 arch/arm/boot/dts/qcom-msm8974.dtsi

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index e18a6fc..959b2c7 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -357,6 +357,15 @@ choice
 		  Say Y here if you want the debug print routines to direct
 		  their output to the serial port on MSM 8960 devices.
 
+	config DEBUG_MSM8974_UART
+		bool "Kernel low-level debugging messages via MSM 8974 UART"
+		depends on ARCH_MSM8974
+		select MSM_HAS_DEBUG_UART_HS
+		select DEBUG_MSM_UART
+		help
+		  Say Y here if you want the debug print routines to direct
+		  their output to the serial port on MSM 8974 devices.
+
 	config DEBUG_MVEBU_UART
 		bool "Kernel low-level debugging messages via MVEBU UART (old bootloaders)"
 		depends on ARCH_MVEBU
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 000cf76..e71a3ec 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -102,7 +102,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
 	kirkwood-openblocks_a6.dtb
 dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
 dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
-	msm8960-cdp.dtb
+	msm8960-cdp.dtb \
+	qcom-apq8074-dragonboard.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
 	armada-370-mirabox.dtb \
 	armada-370-netgear-rn102.dtb \
diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
new file mode 100644
index 0000000..bb6f3c4
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
@@ -0,0 +1,6 @@
+/include/ "qcom-msm8974.dtsi"
+
+/ {
+	model = "Qualcomm APQ8074 Dragonboard";
+	compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
+};
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
new file mode 100644
index 0000000..f04b643
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -0,0 +1,35 @@
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "Qualcomm MSM8974";
+	compatible = "qcom,msm8974";
+	interrupt-parent = <&intc>;
+
+	soc: soc { };
+};
+
+&soc {
+	#address-cells = <1>;
+	#size-cells = <1>;
+	ranges;
+	compatible = "simple-bus";
+
+	intc: interrupt-controller@f9000000 {
+		compatible = "qcom,msm-qgic2";
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		reg = <0xf9000000 0x1000>,
+		      <0xf9002000 0x1000>;
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <1 2 0xf08>,
+			     <1 3 0xf08>,
+			     <1 4 0xf08>,
+			     <1 1 0xf08>;
+		clock-frequency = <19200000>;
+	};
+};
diff --git a/arch/arm/include/debug/msm.S b/arch/arm/include/debug/msm.S
index 9166e1b..9d653d4 100644
--- a/arch/arm/include/debug/msm.S
+++ b/arch/arm/include/debug/msm.S
@@ -46,6 +46,11 @@
 #define MSM_DEBUG_UART_PHYS	0x16440000
 #endif
 
+#ifdef CONFIG_DEBUG_MSM8974_UART
+#define MSM_DEBUG_UART_BASE	0xFA71E000
+#define MSM_DEBUG_UART_PHYS	0xF991E000
+#endif
+
 	.macro	addruart, rp, rv, tmp
 #ifdef MSM_DEBUG_UART_PHYS
 	ldr	\rp, =MSM_DEBUG_UART_PHYS
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 2586c28..086bcb9 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -64,6 +64,19 @@ config ARCH_MSM_DT
 	select SPARSE_IRQ
 	select USE_OF
 
+config ARCH_MSM8974
+	bool "MSM8974"
+	select ARM_GIC
+	select CPU_V7
+	select HAVE_ARM_ARCH_TIMER
+	select HAVE_SMP
+	select MSM_SCM if SMP
+	select USE_OF
+
+config ARCH_MSM_DT
+	def_bool y
+	depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974)
+
 config MSM_HAS_DEBUG_UART_HS
 	bool
 
diff --git a/arch/arm/mach-msm/board-dt.c b/arch/arm/mach-msm/board-dt.c
index 266a280..5211e80 100644
--- a/arch/arm/mach-msm/board-dt.c
+++ b/arch/arm/mach-msm/board-dt.c
@@ -26,7 +26,16 @@ static const char * const msm_dt_match[] __initconst = {
 	NULL
 };
 
+static const char * const apq8074_dt_match[] __initconst = {
+	"qcom,apq8074-dragonboard",
+	NULL
+};
+
 DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
 	.smp = smp_ops(msm_smp_ops),
 	.dt_compat = msm_dt_match,
 MACHINE_END
+
+DT_MACHINE_START(APQ_DT, "Qualcomm MSM (Flattened Device Tree)")
+	.dt_compat = apq8074_dt_match,
+MACHINE_END
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
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

[PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Rohit Vaswani]

This patch adds basic board support for APQ8074 Dragonboard
which belongs to the Snapdragon 800 family.
For now, just support a basic machine with device tree.

Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
---
 arch/arm/Kconfig.debug                         |  9 +++++++
 arch/arm/boot/dts/Makefile                     |  3 ++-
 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts |  6 +++++
 arch/arm/boot/dts/qcom-msm8974.dtsi            | 35 ++++++++++++++++++++++++++
 arch/arm/include/debug/msm.S                   |  5 ++++
 arch/arm/mach-msm/Kconfig                      | 13 ++++++++++
 arch/arm/mach-msm/board-dt.c                   |  9 +++++++
 7 files changed, 79 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
 create mode 100644 arch/arm/boot/dts/qcom-msm8974.dtsi

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index e18a6fc..959b2c7 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -357,6 +357,15 @@ choice
 		  Say Y here if you want the debug print routines to direct
 		  their output to the serial port on MSM 8960 devices.
 
+	config DEBUG_MSM8974_UART
+		bool "Kernel low-level debugging messages via MSM 8974 UART"
+		depends on ARCH_MSM8974
+		select MSM_HAS_DEBUG_UART_HS
+		select DEBUG_MSM_UART
+		help
+		  Say Y here if you want the debug print routines to direct
+		  their output to the serial port on MSM 8974 devices.
+
 	config DEBUG_MVEBU_UART
 		bool "Kernel low-level debugging messages via MVEBU UART (old bootloaders)"
 		depends on ARCH_MVEBU
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 000cf76..e71a3ec 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -102,7 +102,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
 	kirkwood-openblocks_a6.dtb
 dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
 dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
-	msm8960-cdp.dtb
+	msm8960-cdp.dtb \
+	qcom-apq8074-dragonboard.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
 	armada-370-mirabox.dtb \
 	armada-370-netgear-rn102.dtb \
diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
new file mode 100644
index 0000000..bb6f3c4
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
@@ -0,0 +1,6 @@
+/include/ "qcom-msm8974.dtsi"
+
+/ {
+	model = "Qualcomm APQ8074 Dragonboard";
+	compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
+};
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
new file mode 100644
index 0000000..f04b643
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -0,0 +1,35 @@
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "Qualcomm MSM8974";
+	compatible = "qcom,msm8974";
+	interrupt-parent = <&intc>;
+
+	soc: soc { };
+};
+
+&soc {
+	#address-cells = <1>;
+	#size-cells = <1>;
+	ranges;
+	compatible = "simple-bus";
+
+	intc: interrupt-controller@f9000000 {
+		compatible = "qcom,msm-qgic2";
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		reg = <0xf9000000 0x1000>,
+		      <0xf9002000 0x1000>;
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <1 2 0xf08>,
+			     <1 3 0xf08>,
+			     <1 4 0xf08>,
+			     <1 1 0xf08>;
+		clock-frequency = <19200000>;
+	};
+};
diff --git a/arch/arm/include/debug/msm.S b/arch/arm/include/debug/msm.S
index 9166e1b..9d653d4 100644
--- a/arch/arm/include/debug/msm.S
+++ b/arch/arm/include/debug/msm.S
@@ -46,6 +46,11 @@
 #define MSM_DEBUG_UART_PHYS	0x16440000
 #endif
 
+#ifdef CONFIG_DEBUG_MSM8974_UART
+#define MSM_DEBUG_UART_BASE	0xFA71E000
+#define MSM_DEBUG_UART_PHYS	0xF991E000
+#endif
+
 	.macro	addruart, rp, rv, tmp
 #ifdef MSM_DEBUG_UART_PHYS
 	ldr	\rp, =MSM_DEBUG_UART_PHYS
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 2586c28..086bcb9 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -64,6 +64,19 @@ config ARCH_MSM_DT
 	select SPARSE_IRQ
 	select USE_OF
 
+config ARCH_MSM8974
+	bool "MSM8974"
+	select ARM_GIC
+	select CPU_V7
+	select HAVE_ARM_ARCH_TIMER
+	select HAVE_SMP
+	select MSM_SCM if SMP
+	select USE_OF
+
+config ARCH_MSM_DT
+	def_bool y
+	depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974)
+
 config MSM_HAS_DEBUG_UART_HS
 	bool
 
diff --git a/arch/arm/mach-msm/board-dt.c b/arch/arm/mach-msm/board-dt.c
index 266a280..5211e80 100644
--- a/arch/arm/mach-msm/board-dt.c
+++ b/arch/arm/mach-msm/board-dt.c
@@ -26,7 +26,16 @@ static const char * const msm_dt_match[] __initconst = {
 	NULL
 };
 
+static const char * const apq8074_dt_match[] __initconst = {
+	"qcom,apq8074-dragonboard",
+	NULL
+};
+
 DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
 	.smp = smp_ops(msm_smp_ops),
 	.dt_compat = msm_dt_match,
 MACHINE_END
+
+DT_MACHINE_START(APQ_DT, "Qualcomm MSM (Flattened Device Tree)")
+	.dt_compat = apq8074_dt_match,
+MACHINE_END
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Rohit Vaswani]

This patch adds basic board support for APQ8074 Dragonboard
which belongs to the Snapdragon 800 family.
For now, just support a basic machine with device tree.

Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
---
 arch/arm/Kconfig.debug                         |  9 +++++++
 arch/arm/boot/dts/Makefile                     |  3 ++-
 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts |  6 +++++
 arch/arm/boot/dts/qcom-msm8974.dtsi            | 35 ++++++++++++++++++++++++++
 arch/arm/include/debug/msm.S                   |  5 ++++
 arch/arm/mach-msm/Kconfig                      | 13 ++++++++++
 arch/arm/mach-msm/board-dt.c                   |  9 +++++++
 7 files changed, 79 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
 create mode 100644 arch/arm/boot/dts/qcom-msm8974.dtsi

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index e18a6fc..959b2c7 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -357,6 +357,15 @@ choice
 		  Say Y here if you want the debug print routines to direct
 		  their output to the serial port on MSM 8960 devices.
 
+	config DEBUG_MSM8974_UART
+		bool "Kernel low-level debugging messages via MSM 8974 UART"
+		depends on ARCH_MSM8974
+		select MSM_HAS_DEBUG_UART_HS
+		select DEBUG_MSM_UART
+		help
+		  Say Y here if you want the debug print routines to direct
+		  their output to the serial port on MSM 8974 devices.
+
 	config DEBUG_MVEBU_UART
 		bool "Kernel low-level debugging messages via MVEBU UART (old bootloaders)"
 		depends on ARCH_MVEBU
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 000cf76..e71a3ec 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -102,7 +102,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
 	kirkwood-openblocks_a6.dtb
 dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
 dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
-	msm8960-cdp.dtb
+	msm8960-cdp.dtb \
+	qcom-apq8074-dragonboard.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
 	armada-370-mirabox.dtb \
 	armada-370-netgear-rn102.dtb \
diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
new file mode 100644
index 0000000..bb6f3c4
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
@@ -0,0 +1,6 @@
+/include/ "qcom-msm8974.dtsi"
+
+/ {
+	model = "Qualcomm APQ8074 Dragonboard";
+	compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
+};
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
new file mode 100644
index 0000000..f04b643
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -0,0 +1,35 @@
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "Qualcomm MSM8974";
+	compatible = "qcom,msm8974";
+	interrupt-parent = <&intc>;
+
+	soc: soc { };
+};
+
+&soc {
+	#address-cells = <1>;
+	#size-cells = <1>;
+	ranges;
+	compatible = "simple-bus";
+
+	intc: interrupt-controller at f9000000 {
+		compatible = "qcom,msm-qgic2";
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		reg = <0xf9000000 0x1000>,
+		      <0xf9002000 0x1000>;
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <1 2 0xf08>,
+			     <1 3 0xf08>,
+			     <1 4 0xf08>,
+			     <1 1 0xf08>;
+		clock-frequency = <19200000>;
+	};
+};
diff --git a/arch/arm/include/debug/msm.S b/arch/arm/include/debug/msm.S
index 9166e1b..9d653d4 100644
--- a/arch/arm/include/debug/msm.S
+++ b/arch/arm/include/debug/msm.S
@@ -46,6 +46,11 @@
 #define MSM_DEBUG_UART_PHYS	0x16440000
 #endif
 
+#ifdef CONFIG_DEBUG_MSM8974_UART
+#define MSM_DEBUG_UART_BASE	0xFA71E000
+#define MSM_DEBUG_UART_PHYS	0xF991E000
+#endif
+
 	.macro	addruart, rp, rv, tmp
 #ifdef MSM_DEBUG_UART_PHYS
 	ldr	\rp, =MSM_DEBUG_UART_PHYS
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 2586c28..086bcb9 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -64,6 +64,19 @@ config ARCH_MSM_DT
 	select SPARSE_IRQ
 	select USE_OF
 
+config ARCH_MSM8974
+	bool "MSM8974"
+	select ARM_GIC
+	select CPU_V7
+	select HAVE_ARM_ARCH_TIMER
+	select HAVE_SMP
+	select MSM_SCM if SMP
+	select USE_OF
+
+config ARCH_MSM_DT
+	def_bool y
+	depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974)
+
 config MSM_HAS_DEBUG_UART_HS
 	bool
 
diff --git a/arch/arm/mach-msm/board-dt.c b/arch/arm/mach-msm/board-dt.c
index 266a280..5211e80 100644
--- a/arch/arm/mach-msm/board-dt.c
+++ b/arch/arm/mach-msm/board-dt.c
@@ -26,7 +26,16 @@ static const char * const msm_dt_match[] __initconst = {
 	NULL
 };
 
+static const char * const apq8074_dt_match[] __initconst = {
+	"qcom,apq8074-dragonboard",
+	NULL
+};
+
 DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
 	.smp = smp_ops(msm_smp_ops),
 	.dt_compat = msm_dt_match,
 MACHINE_END
+
+DT_MACHINE_START(APQ_DT, "Qualcomm MSM (Flattened Device Tree)")
+	.dt_compat = apq8074_dt_match,
+MACHINE_END
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 3/3] defconfig: msm_defconfig: Enable CONFIG_ARCH_MSM8974

[Rohit Vaswani]

This patch enables MSM8974 build support.

Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
---
 arch/arm/configs/msm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/msm_defconfig b/arch/arm/configs/msm_defconfig
index 690b5f9..0ed32e5 100644
--- a/arch/arm/configs/msm_defconfig
+++ b/arch/arm/configs/msm_defconfig
@@ -20,6 +20,7 @@ CONFIG_PARTITION_ADVANCED=y
 CONFIG_ARCH_MSM=y
 CONFIG_ARCH_MSM8X60=y
 CONFIG_ARCH_MSM8960=y
+CONFIG_ARCH_MSM8974=y
 CONFIG_SMP=y
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 3/3] defconfig: msm_defconfig: Enable CONFIG_ARCH_MSM8974

[Rohit Vaswani]

This patch enables MSM8974 build support.

Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
---
 arch/arm/configs/msm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/msm_defconfig b/arch/arm/configs/msm_defconfig
index 690b5f9..0ed32e5 100644
--- a/arch/arm/configs/msm_defconfig
+++ b/arch/arm/configs/msm_defconfig
@@ -20,6 +20,7 @@ CONFIG_PARTITION_ADVANCED=y
 CONFIG_ARCH_MSM=y
 CONFIG_ARCH_MSM8X60=y
 CONFIG_ARCH_MSM8960=y
+CONFIG_ARCH_MSM8974=y
 CONFIG_SMP=y
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Kumar Gala]

On Sep 23, 2013, at 10:13 PM, Rohit Vaswani wrote:

> This patch adds basic board support for APQ8074 Dragonboard
> which belongs to the Snapdragon 800 family.
> For now, just support a basic machine with device tree.
> 
> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
> ---
> arch/arm/Kconfig.debug                         |  9 +++++++
> arch/arm/boot/dts/Makefile                     |  3 ++-
> arch/arm/boot/dts/qcom-apq8074-dragonboard.dts |  6 +++++
> arch/arm/boot/dts/qcom-msm8974.dtsi            | 35 ++++++++++++++++++++++++++
> arch/arm/include/debug/msm.S                   |  5 ++++
> arch/arm/mach-msm/Kconfig                      | 13 ++++++++++
> arch/arm/mach-msm/board-dt.c                   |  9 +++++++
> 7 files changed, 79 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
> create mode 100644 arch/arm/boot/dts/qcom-msm8974.dtsi
> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index e18a6fc..959b2c7 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -357,6 +357,15 @@ choice
> 		  Say Y here if you want the debug print routines to direct
> 		  their output to the serial port on MSM 8960 devices.
> 
> +	config DEBUG_MSM8974_UART
> +		bool "Kernel low-level debugging messages via MSM 8974 UART"
> +		depends on ARCH_MSM8974
> +		select MSM_HAS_DEBUG_UART_HS
> +		select DEBUG_MSM_UART
> +		help
> +		  Say Y here if you want the debug print routines to direct
> +		  their output to the serial port on MSM 8974 devices.
> +

A little surprised you didn't pull this and the ARCH_MSM8974 into its own patch outside of this patch being board support.

> 	config DEBUG_MVEBU_UART
> 		bool "Kernel low-level debugging messages via MVEBU UART (old bootloaders)"
> 		depends on ARCH_MVEBU
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 000cf76..e71a3ec 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -102,7 +102,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
> 	kirkwood-openblocks_a6.dtb
> dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
> dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
> -	msm8960-cdp.dtb
> +	msm8960-cdp.dtb \
> +	qcom-apq8074-dragonboard.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> 	armada-370-mirabox.dtb \
> 	armada-370-netgear-rn102.dtb \
> diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
> new file mode 100644
> index 0000000..bb6f3c4
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
> @@ -0,0 +1,6 @@
> +/include/ "qcom-msm8974.dtsi"
> +
> +/ {
> +	model = "Qualcomm APQ8074 Dragonboard";
> +	compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
> +};
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> new file mode 100644
> index 0000000..f04b643
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -0,0 +1,35 @@
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	model = "Qualcomm MSM8974";
> +	compatible = "qcom,msm8974";
> +	interrupt-parent = <&intc>;
> +
> +	soc: soc { };

We should have a unit address here:

	  soc: soc@FOOBAR {

also, split out the curly braces so any future patches do have to muck with that.

	};


> +};
> +
> +&soc {
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +	ranges;
> +	compatible = "simple-bus";
> +
> +	intc: interrupt-controller@f9000000 {
> +		compatible = "qcom,msm-qgic2";
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +		reg = <0xf9000000 0x1000>,
> +		      <0xf9002000 0x1000>;
> +	};
> +
> +	timer {
> +		compatible = "arm,armv7-timer";
> +		interrupts = <1 2 0xf08>,
> +			     <1 3 0xf08>,
> +			     <1 4 0xf08>,
> +			     <1 1 0xf08>;
> +		clock-frequency = <19200000>;
> +	};
> +};
> diff --git a/arch/arm/include/debug/msm.S b/arch/arm/include/debug/msm.S
> index 9166e1b..9d653d4 100644
> --- a/arch/arm/include/debug/msm.S
> +++ b/arch/arm/include/debug/msm.S
> @@ -46,6 +46,11 @@
> #define MSM_DEBUG_UART_PHYS	0x16440000
> #endif
> 
> +#ifdef CONFIG_DEBUG_MSM8974_UART
> +#define MSM_DEBUG_UART_BASE	0xFA71E000
> +#define MSM_DEBUG_UART_PHYS	0xF991E000
> +#endif
> +
> 	.macro	addruart, rp, rv, tmp
> #ifdef MSM_DEBUG_UART_PHYS
> 	ldr	\rp, =MSM_DEBUG_UART_PHYS
> diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
> index 2586c28..086bcb9 100644
> --- a/arch/arm/mach-msm/Kconfig
> +++ b/arch/arm/mach-msm/Kconfig
> @@ -64,6 +64,19 @@ config ARCH_MSM_DT
> 	select SPARSE_IRQ
> 	select USE_OF
> 
> +config ARCH_MSM8974
> +	bool "MSM8974"
> +	select ARM_GIC
> +	select CPU_V7
> +	select HAVE_ARM_ARCH_TIMER
> +	select HAVE_SMP
> +	select MSM_SCM if SMP
> +	select USE_OF
> +
> +config ARCH_MSM_DT
> +	def_bool y
> +	depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974)
> +
> config MSM_HAS_DEBUG_UART_HS
> 	bool
> 
> diff --git a/arch/arm/mach-msm/board-dt.c b/arch/arm/mach-msm/board-dt.c
> index 266a280..5211e80 100644
> --- a/arch/arm/mach-msm/board-dt.c
> +++ b/arch/arm/mach-msm/board-dt.c
> @@ -26,7 +26,16 @@ static const char * const msm_dt_match[] __initconst = {
> 	NULL
> };
> 
> +static const char * const apq8074_dt_match[] __initconst = {
> +	"qcom,apq8074-dragonboard",
> +	NULL
> +};
> +
> DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
> 	.smp = smp_ops(msm_smp_ops),
> 	.dt_compat = msm_dt_match,
> MACHINE_END
> +
> +DT_MACHINE_START(APQ_DT, "Qualcomm MSM (Flattened Device Tree)")
> +	.dt_compat = apq8074_dt_match,
> +MACHINE_END
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Kumar Gala]

On Sep 23, 2013, at 10:13 PM, Rohit Vaswani wrote:

> This patch adds basic board support for APQ8074 Dragonboard
> which belongs to the Snapdragon 800 family.
> For now, just support a basic machine with device tree.
> 
> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
> ---
> arch/arm/Kconfig.debug                         |  9 +++++++
> arch/arm/boot/dts/Makefile                     |  3 ++-
> arch/arm/boot/dts/qcom-apq8074-dragonboard.dts |  6 +++++
> arch/arm/boot/dts/qcom-msm8974.dtsi            | 35 ++++++++++++++++++++++++++
> arch/arm/include/debug/msm.S                   |  5 ++++
> arch/arm/mach-msm/Kconfig                      | 13 ++++++++++
> arch/arm/mach-msm/board-dt.c                   |  9 +++++++
> 7 files changed, 79 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
> create mode 100644 arch/arm/boot/dts/qcom-msm8974.dtsi
> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index e18a6fc..959b2c7 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -357,6 +357,15 @@ choice
> 		  Say Y here if you want the debug print routines to direct
> 		  their output to the serial port on MSM 8960 devices.
> 
> +	config DEBUG_MSM8974_UART
> +		bool "Kernel low-level debugging messages via MSM 8974 UART"
> +		depends on ARCH_MSM8974
> +		select MSM_HAS_DEBUG_UART_HS
> +		select DEBUG_MSM_UART
> +		help
> +		  Say Y here if you want the debug print routines to direct
> +		  their output to the serial port on MSM 8974 devices.
> +

A little surprised you didn't pull this and the ARCH_MSM8974 into its own patch outside of this patch being board support.

> 	config DEBUG_MVEBU_UART
> 		bool "Kernel low-level debugging messages via MVEBU UART (old bootloaders)"
> 		depends on ARCH_MVEBU
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 000cf76..e71a3ec 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -102,7 +102,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
> 	kirkwood-openblocks_a6.dtb
> dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
> dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
> -	msm8960-cdp.dtb
> +	msm8960-cdp.dtb \
> +	qcom-apq8074-dragonboard.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> 	armada-370-mirabox.dtb \
> 	armada-370-netgear-rn102.dtb \
> diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
> new file mode 100644
> index 0000000..bb6f3c4
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
> @@ -0,0 +1,6 @@
> +/include/ "qcom-msm8974.dtsi"
> +
> +/ {
> +	model = "Qualcomm APQ8074 Dragonboard";
> +	compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
> +};
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> new file mode 100644
> index 0000000..f04b643
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -0,0 +1,35 @@
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	model = "Qualcomm MSM8974";
> +	compatible = "qcom,msm8974";
> +	interrupt-parent = <&intc>;
> +
> +	soc: soc { };

We should have a unit address here:

	  soc: soc at FOOBAR {

also, split out the curly braces so any future patches do have to muck with that.

	};


> +};
> +
> +&soc {
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +	ranges;
> +	compatible = "simple-bus";
> +
> +	intc: interrupt-controller at f9000000 {
> +		compatible = "qcom,msm-qgic2";
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +		reg = <0xf9000000 0x1000>,
> +		      <0xf9002000 0x1000>;
> +	};
> +
> +	timer {
> +		compatible = "arm,armv7-timer";
> +		interrupts = <1 2 0xf08>,
> +			     <1 3 0xf08>,
> +			     <1 4 0xf08>,
> +			     <1 1 0xf08>;
> +		clock-frequency = <19200000>;
> +	};
> +};
> diff --git a/arch/arm/include/debug/msm.S b/arch/arm/include/debug/msm.S
> index 9166e1b..9d653d4 100644
> --- a/arch/arm/include/debug/msm.S
> +++ b/arch/arm/include/debug/msm.S
> @@ -46,6 +46,11 @@
> #define MSM_DEBUG_UART_PHYS	0x16440000
> #endif
> 
> +#ifdef CONFIG_DEBUG_MSM8974_UART
> +#define MSM_DEBUG_UART_BASE	0xFA71E000
> +#define MSM_DEBUG_UART_PHYS	0xF991E000
> +#endif
> +
> 	.macro	addruart, rp, rv, tmp
> #ifdef MSM_DEBUG_UART_PHYS
> 	ldr	\rp, =MSM_DEBUG_UART_PHYS
> diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
> index 2586c28..086bcb9 100644
> --- a/arch/arm/mach-msm/Kconfig
> +++ b/arch/arm/mach-msm/Kconfig
> @@ -64,6 +64,19 @@ config ARCH_MSM_DT
> 	select SPARSE_IRQ
> 	select USE_OF
> 
> +config ARCH_MSM8974
> +	bool "MSM8974"
> +	select ARM_GIC
> +	select CPU_V7
> +	select HAVE_ARM_ARCH_TIMER
> +	select HAVE_SMP
> +	select MSM_SCM if SMP
> +	select USE_OF
> +
> +config ARCH_MSM_DT
> +	def_bool y
> +	depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974)
> +
> config MSM_HAS_DEBUG_UART_HS
> 	bool
> 
> diff --git a/arch/arm/mach-msm/board-dt.c b/arch/arm/mach-msm/board-dt.c
> index 266a280..5211e80 100644
> --- a/arch/arm/mach-msm/board-dt.c
> +++ b/arch/arm/mach-msm/board-dt.c
> @@ -26,7 +26,16 @@ static const char * const msm_dt_match[] __initconst = {
> 	NULL
> };
> 
> +static const char * const apq8074_dt_match[] __initconst = {
> +	"qcom,apq8074-dragonboard",
> +	NULL
> +};
> +
> DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
> 	.smp = smp_ops(msm_smp_ops),
> 	.dt_compat = msm_dt_match,
> MACHINE_END
> +
> +DT_MACHINE_START(APQ_DT, "Qualcomm MSM (Flattened Device Tree)")
> +	.dt_compat = apq8074_dt_match,
> +MACHINE_END
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Rohit Vaswani]

On 9/25/2013 12:49 PM, Kumar Gala wrote:
> On Sep 23, 2013, at 10:13 PM, Rohit Vaswani wrote:
>
>> This patch adds basic board support for APQ8074 Dragonboard
>> which belongs to the Snapdragon 800 family.
>> For now, just support a basic machine with device tree.
>>
>> Signed-off-by: Rohit Vaswani <rvaswani-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>> arch/arm/Kconfig.debug                         |  9 +++++++
>> arch/arm/boot/dts/Makefile                     |  3 ++-
>> arch/arm/boot/dts/qcom-apq8074-dragonboard.dts |  6 +++++
>> arch/arm/boot/dts/qcom-msm8974.dtsi            | 35 ++++++++++++++++++++++++++
>> arch/arm/include/debug/msm.S                   |  5 ++++
>> arch/arm/mach-msm/Kconfig                      | 13 ++++++++++
>> arch/arm/mach-msm/board-dt.c                   |  9 +++++++
>> 7 files changed, 79 insertions(+), 1 deletion(-)
>> create mode 100644 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>> create mode 100644 arch/arm/boot/dts/qcom-msm8974.dtsi
>>
>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>> index e18a6fc..959b2c7 100644
>> --- a/arch/arm/Kconfig.debug
>> +++ b/arch/arm/Kconfig.debug
>> @@ -357,6 +357,15 @@ choice
>> 		  Say Y here if you want the debug print routines to direct
>> 		  their output to the serial port on MSM 8960 devices.
>>
>> +	config DEBUG_MSM8974_UART
>> +		bool "Kernel low-level debugging messages via MSM 8974 UART"
>> +		depends on ARCH_MSM8974
>> +		select MSM_HAS_DEBUG_UART_HS
>> +		select DEBUG_MSM_UART
>> +		help
>> +		  Say Y here if you want the debug print routines to direct
>> +		  their output to the serial port on MSM 8974 devices.
>> +
> A little surprised you didn't pull this and the ARCH_MSM8974 into its own patch outside of this patch being board support.

Well, its good to have this as part of initial board setup for earlyprintk.

>
>> 	config DEBUG_MVEBU_UART
>> 		bool "Kernel low-level debugging messages via MVEBU UART (old bootloaders)"
>> 		depends on ARCH_MVEBU
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 000cf76..e71a3ec 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -102,7 +102,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
>> 	kirkwood-openblocks_a6.dtb
>> dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
>> dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
>> -	msm8960-cdp.dtb
>> +	msm8960-cdp.dtb \
>> +	qcom-apq8074-dragonboard.dtb
>> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
>> 	armada-370-mirabox.dtb \
>> 	armada-370-netgear-rn102.dtb \
>> diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>> new file mode 100644
>> index 0000000..bb6f3c4
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>> @@ -0,0 +1,6 @@
>> +/include/ "qcom-msm8974.dtsi"
>> +
>> +/ {
>> +	model = "Qualcomm APQ8074 Dragonboard";
>> +	compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
>> +};
>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> new file mode 100644
>> index 0000000..f04b643
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> @@ -0,0 +1,35 @@
>> +/dts-v1/;
>> +
>> +/include/ "skeleton.dtsi"
>> +
>> +/ {
>> +	model = "Qualcomm MSM8974";
>> +	compatible = "qcom,msm8974";
>> +	interrupt-parent = <&intc>;
>> +
>> +	soc: soc { };
> We should have a unit address here:
>
> 	  soc: soc@FOOBAR {
>
> also, split out the curly braces so any future patches do have to muck with that.
>
> 	};
>

Im not sure I understand the reasoning behind the unit address for soc ?
>> +};
>> +
>> +&soc {
>> +	#address-cells = <1>;
>> +	#size-cells = <1>;
>> +	ranges;
>> +	compatible = "simple-bus";
>> +
>> +	intc: interrupt-controller@f9000000 {
>> +		compatible = "qcom,msm-qgic2";
>> +		interrupt-controller;
>> +		#interrupt-cells = <3>;
>> +		reg = <0xf9000000 0x1000>,
>> +		      <0xf9002000 0x1000>;
>> +	};
>> +
>> +	timer {
>> +		compatible = "arm,armv7-timer";
>> +		interrupts = <1 2 0xf08>,
>> +			     <1 3 0xf08>,
>> +			     <1 4 0xf08>,
>> +			     <1 1 0xf08>;
>> +		clock-frequency = <19200000>;
>> +	};
>> +};
>> diff --git a/arch/arm/include/debug/msm.S b/arch/arm/include/debug/msm.S
>> index 9166e1b..9d653d4 100644
>> --- a/arch/arm/include/debug/msm.S
>> +++ b/arch/arm/include/debug/msm.S
>> @@ -46,6 +46,11 @@
>> #define MSM_DEBUG_UART_PHYS	0x16440000
>> #endif
>>
>> +#ifdef CONFIG_DEBUG_MSM8974_UART
>> +#define MSM_DEBUG_UART_BASE	0xFA71E000
>> +#define MSM_DEBUG_UART_PHYS	0xF991E000
>> +#endif
>> +
>> 	.macro	addruart, rp, rv, tmp
>> #ifdef MSM_DEBUG_UART_PHYS
>> 	ldr	\rp, =MSM_DEBUG_UART_PHYS
>> diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
>> index 2586c28..086bcb9 100644
>> --- a/arch/arm/mach-msm/Kconfig
>> +++ b/arch/arm/mach-msm/Kconfig
>> @@ -64,6 +64,19 @@ config ARCH_MSM_DT
>> 	select SPARSE_IRQ
>> 	select USE_OF
>>
>> +config ARCH_MSM8974
>> +	bool "MSM8974"
>> +	select ARM_GIC
>> +	select CPU_V7
>> +	select HAVE_ARM_ARCH_TIMER
>> +	select HAVE_SMP
>> +	select MSM_SCM if SMP
>> +	select USE_OF
>> +
>> +config ARCH_MSM_DT
>> +	def_bool y
>> +	depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974)
>> +
>> config MSM_HAS_DEBUG_UART_HS
>> 	bool
>>
>> diff --git a/arch/arm/mach-msm/board-dt.c b/arch/arm/mach-msm/board-dt.c
>> index 266a280..5211e80 100644
>> --- a/arch/arm/mach-msm/board-dt.c
>> +++ b/arch/arm/mach-msm/board-dt.c
>> @@ -26,7 +26,16 @@ static const char * const msm_dt_match[] __initconst = {
>> 	NULL
>> };
>>
>> +static const char * const apq8074_dt_match[] __initconst = {
>> +	"qcom,apq8074-dragonboard",
>> +	NULL
>> +};
>> +
>> DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
>> 	.smp = smp_ops(msm_smp_ops),
>> 	.dt_compat = msm_dt_match,
>> MACHINE_END
>> +
>> +DT_MACHINE_START(APQ_DT, "Qualcomm MSM (Flattened Device Tree)")
>> +	.dt_compat = apq8074_dt_match,
>> +MACHINE_END
>> -- 
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> hosted by The Linux Foundation
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Thanks,
Rohit Vaswani

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation

--
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

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Rohit Vaswani]

On 9/25/2013 12:49 PM, Kumar Gala wrote:
> On Sep 23, 2013, at 10:13 PM, Rohit Vaswani wrote:
>
>> This patch adds basic board support for APQ8074 Dragonboard
>> which belongs to the Snapdragon 800 family.
>> For now, just support a basic machine with device tree.
>>
>> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
>> ---
>> arch/arm/Kconfig.debug                         |  9 +++++++
>> arch/arm/boot/dts/Makefile                     |  3 ++-
>> arch/arm/boot/dts/qcom-apq8074-dragonboard.dts |  6 +++++
>> arch/arm/boot/dts/qcom-msm8974.dtsi            | 35 ++++++++++++++++++++++++++
>> arch/arm/include/debug/msm.S                   |  5 ++++
>> arch/arm/mach-msm/Kconfig                      | 13 ++++++++++
>> arch/arm/mach-msm/board-dt.c                   |  9 +++++++
>> 7 files changed, 79 insertions(+), 1 deletion(-)
>> create mode 100644 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>> create mode 100644 arch/arm/boot/dts/qcom-msm8974.dtsi
>>
>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>> index e18a6fc..959b2c7 100644
>> --- a/arch/arm/Kconfig.debug
>> +++ b/arch/arm/Kconfig.debug
>> @@ -357,6 +357,15 @@ choice
>> 		  Say Y here if you want the debug print routines to direct
>> 		  their output to the serial port on MSM 8960 devices.
>>
>> +	config DEBUG_MSM8974_UART
>> +		bool "Kernel low-level debugging messages via MSM 8974 UART"
>> +		depends on ARCH_MSM8974
>> +		select MSM_HAS_DEBUG_UART_HS
>> +		select DEBUG_MSM_UART
>> +		help
>> +		  Say Y here if you want the debug print routines to direct
>> +		  their output to the serial port on MSM 8974 devices.
>> +
> A little surprised you didn't pull this and the ARCH_MSM8974 into its own patch outside of this patch being board support.

Well, its good to have this as part of initial board setup for earlyprintk.

>
>> 	config DEBUG_MVEBU_UART
>> 		bool "Kernel low-level debugging messages via MVEBU UART (old bootloaders)"
>> 		depends on ARCH_MVEBU
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 000cf76..e71a3ec 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -102,7 +102,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
>> 	kirkwood-openblocks_a6.dtb
>> dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
>> dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
>> -	msm8960-cdp.dtb
>> +	msm8960-cdp.dtb \
>> +	qcom-apq8074-dragonboard.dtb
>> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
>> 	armada-370-mirabox.dtb \
>> 	armada-370-netgear-rn102.dtb \
>> diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>> new file mode 100644
>> index 0000000..bb6f3c4
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>> @@ -0,0 +1,6 @@
>> +/include/ "qcom-msm8974.dtsi"
>> +
>> +/ {
>> +	model = "Qualcomm APQ8074 Dragonboard";
>> +	compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
>> +};
>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> new file mode 100644
>> index 0000000..f04b643
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> @@ -0,0 +1,35 @@
>> +/dts-v1/;
>> +
>> +/include/ "skeleton.dtsi"
>> +
>> +/ {
>> +	model = "Qualcomm MSM8974";
>> +	compatible = "qcom,msm8974";
>> +	interrupt-parent = <&intc>;
>> +
>> +	soc: soc { };
> We should have a unit address here:
>
> 	  soc: soc@FOOBAR {
>
> also, split out the curly braces so any future patches do have to muck with that.
>
> 	};
>

Im not sure I understand the reasoning behind the unit address for soc ?
>> +};
>> +
>> +&soc {
>> +	#address-cells = <1>;
>> +	#size-cells = <1>;
>> +	ranges;
>> +	compatible = "simple-bus";
>> +
>> +	intc: interrupt-controller@f9000000 {
>> +		compatible = "qcom,msm-qgic2";
>> +		interrupt-controller;
>> +		#interrupt-cells = <3>;
>> +		reg = <0xf9000000 0x1000>,
>> +		      <0xf9002000 0x1000>;
>> +	};
>> +
>> +	timer {
>> +		compatible = "arm,armv7-timer";
>> +		interrupts = <1 2 0xf08>,
>> +			     <1 3 0xf08>,
>> +			     <1 4 0xf08>,
>> +			     <1 1 0xf08>;
>> +		clock-frequency = <19200000>;
>> +	};
>> +};
>> diff --git a/arch/arm/include/debug/msm.S b/arch/arm/include/debug/msm.S
>> index 9166e1b..9d653d4 100644
>> --- a/arch/arm/include/debug/msm.S
>> +++ b/arch/arm/include/debug/msm.S
>> @@ -46,6 +46,11 @@
>> #define MSM_DEBUG_UART_PHYS	0x16440000
>> #endif
>>
>> +#ifdef CONFIG_DEBUG_MSM8974_UART
>> +#define MSM_DEBUG_UART_BASE	0xFA71E000
>> +#define MSM_DEBUG_UART_PHYS	0xF991E000
>> +#endif
>> +
>> 	.macro	addruart, rp, rv, tmp
>> #ifdef MSM_DEBUG_UART_PHYS
>> 	ldr	\rp, =MSM_DEBUG_UART_PHYS
>> diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
>> index 2586c28..086bcb9 100644
>> --- a/arch/arm/mach-msm/Kconfig
>> +++ b/arch/arm/mach-msm/Kconfig
>> @@ -64,6 +64,19 @@ config ARCH_MSM_DT
>> 	select SPARSE_IRQ
>> 	select USE_OF
>>
>> +config ARCH_MSM8974
>> +	bool "MSM8974"
>> +	select ARM_GIC
>> +	select CPU_V7
>> +	select HAVE_ARM_ARCH_TIMER
>> +	select HAVE_SMP
>> +	select MSM_SCM if SMP
>> +	select USE_OF
>> +
>> +config ARCH_MSM_DT
>> +	def_bool y
>> +	depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974)
>> +
>> config MSM_HAS_DEBUG_UART_HS
>> 	bool
>>
>> diff --git a/arch/arm/mach-msm/board-dt.c b/arch/arm/mach-msm/board-dt.c
>> index 266a280..5211e80 100644
>> --- a/arch/arm/mach-msm/board-dt.c
>> +++ b/arch/arm/mach-msm/board-dt.c
>> @@ -26,7 +26,16 @@ static const char * const msm_dt_match[] __initconst = {
>> 	NULL
>> };
>>
>> +static const char * const apq8074_dt_match[] __initconst = {
>> +	"qcom,apq8074-dragonboard",
>> +	NULL
>> +};
>> +
>> DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
>> 	.smp = smp_ops(msm_smp_ops),
>> 	.dt_compat = msm_dt_match,
>> MACHINE_END
>> +
>> +DT_MACHINE_START(APQ_DT, "Qualcomm MSM (Flattened Device Tree)")
>> +	.dt_compat = apq8074_dt_match,
>> +MACHINE_END
>> -- 
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> hosted by The Linux Foundation
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Thanks,
Rohit Vaswani

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation

[PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Rohit Vaswani]

On 9/25/2013 12:49 PM, Kumar Gala wrote:
> On Sep 23, 2013, at 10:13 PM, Rohit Vaswani wrote:
>
>> This patch adds basic board support for APQ8074 Dragonboard
>> which belongs to the Snapdragon 800 family.
>> For now, just support a basic machine with device tree.
>>
>> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
>> ---
>> arch/arm/Kconfig.debug                         |  9 +++++++
>> arch/arm/boot/dts/Makefile                     |  3 ++-
>> arch/arm/boot/dts/qcom-apq8074-dragonboard.dts |  6 +++++
>> arch/arm/boot/dts/qcom-msm8974.dtsi            | 35 ++++++++++++++++++++++++++
>> arch/arm/include/debug/msm.S                   |  5 ++++
>> arch/arm/mach-msm/Kconfig                      | 13 ++++++++++
>> arch/arm/mach-msm/board-dt.c                   |  9 +++++++
>> 7 files changed, 79 insertions(+), 1 deletion(-)
>> create mode 100644 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>> create mode 100644 arch/arm/boot/dts/qcom-msm8974.dtsi
>>
>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>> index e18a6fc..959b2c7 100644
>> --- a/arch/arm/Kconfig.debug
>> +++ b/arch/arm/Kconfig.debug
>> @@ -357,6 +357,15 @@ choice
>> 		  Say Y here if you want the debug print routines to direct
>> 		  their output to the serial port on MSM 8960 devices.
>>
>> +	config DEBUG_MSM8974_UART
>> +		bool "Kernel low-level debugging messages via MSM 8974 UART"
>> +		depends on ARCH_MSM8974
>> +		select MSM_HAS_DEBUG_UART_HS
>> +		select DEBUG_MSM_UART
>> +		help
>> +		  Say Y here if you want the debug print routines to direct
>> +		  their output to the serial port on MSM 8974 devices.
>> +
> A little surprised you didn't pull this and the ARCH_MSM8974 into its own patch outside of this patch being board support.

Well, its good to have this as part of initial board setup for earlyprintk.

>
>> 	config DEBUG_MVEBU_UART
>> 		bool "Kernel low-level debugging messages via MVEBU UART (old bootloaders)"
>> 		depends on ARCH_MVEBU
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 000cf76..e71a3ec 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -102,7 +102,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
>> 	kirkwood-openblocks_a6.dtb
>> dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
>> dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
>> -	msm8960-cdp.dtb
>> +	msm8960-cdp.dtb \
>> +	qcom-apq8074-dragonboard.dtb
>> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
>> 	armada-370-mirabox.dtb \
>> 	armada-370-netgear-rn102.dtb \
>> diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>> new file mode 100644
>> index 0000000..bb6f3c4
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>> @@ -0,0 +1,6 @@
>> +/include/ "qcom-msm8974.dtsi"
>> +
>> +/ {
>> +	model = "Qualcomm APQ8074 Dragonboard";
>> +	compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
>> +};
>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> new file mode 100644
>> index 0000000..f04b643
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> @@ -0,0 +1,35 @@
>> +/dts-v1/;
>> +
>> +/include/ "skeleton.dtsi"
>> +
>> +/ {
>> +	model = "Qualcomm MSM8974";
>> +	compatible = "qcom,msm8974";
>> +	interrupt-parent = <&intc>;
>> +
>> +	soc: soc { };
> We should have a unit address here:
>
> 	  soc: soc at FOOBAR {
>
> also, split out the curly braces so any future patches do have to muck with that.
>
> 	};
>

Im not sure I understand the reasoning behind the unit address for soc ?
>> +};
>> +
>> +&soc {
>> +	#address-cells = <1>;
>> +	#size-cells = <1>;
>> +	ranges;
>> +	compatible = "simple-bus";
>> +
>> +	intc: interrupt-controller at f9000000 {
>> +		compatible = "qcom,msm-qgic2";
>> +		interrupt-controller;
>> +		#interrupt-cells = <3>;
>> +		reg = <0xf9000000 0x1000>,
>> +		      <0xf9002000 0x1000>;
>> +	};
>> +
>> +	timer {
>> +		compatible = "arm,armv7-timer";
>> +		interrupts = <1 2 0xf08>,
>> +			     <1 3 0xf08>,
>> +			     <1 4 0xf08>,
>> +			     <1 1 0xf08>;
>> +		clock-frequency = <19200000>;
>> +	};
>> +};
>> diff --git a/arch/arm/include/debug/msm.S b/arch/arm/include/debug/msm.S
>> index 9166e1b..9d653d4 100644
>> --- a/arch/arm/include/debug/msm.S
>> +++ b/arch/arm/include/debug/msm.S
>> @@ -46,6 +46,11 @@
>> #define MSM_DEBUG_UART_PHYS	0x16440000
>> #endif
>>
>> +#ifdef CONFIG_DEBUG_MSM8974_UART
>> +#define MSM_DEBUG_UART_BASE	0xFA71E000
>> +#define MSM_DEBUG_UART_PHYS	0xF991E000
>> +#endif
>> +
>> 	.macro	addruart, rp, rv, tmp
>> #ifdef MSM_DEBUG_UART_PHYS
>> 	ldr	\rp, =MSM_DEBUG_UART_PHYS
>> diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
>> index 2586c28..086bcb9 100644
>> --- a/arch/arm/mach-msm/Kconfig
>> +++ b/arch/arm/mach-msm/Kconfig
>> @@ -64,6 +64,19 @@ config ARCH_MSM_DT
>> 	select SPARSE_IRQ
>> 	select USE_OF
>>
>> +config ARCH_MSM8974
>> +	bool "MSM8974"
>> +	select ARM_GIC
>> +	select CPU_V7
>> +	select HAVE_ARM_ARCH_TIMER
>> +	select HAVE_SMP
>> +	select MSM_SCM if SMP
>> +	select USE_OF
>> +
>> +config ARCH_MSM_DT
>> +	def_bool y
>> +	depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974)
>> +
>> config MSM_HAS_DEBUG_UART_HS
>> 	bool
>>
>> diff --git a/arch/arm/mach-msm/board-dt.c b/arch/arm/mach-msm/board-dt.c
>> index 266a280..5211e80 100644
>> --- a/arch/arm/mach-msm/board-dt.c
>> +++ b/arch/arm/mach-msm/board-dt.c
>> @@ -26,7 +26,16 @@ static const char * const msm_dt_match[] __initconst = {
>> 	NULL
>> };
>>
>> +static const char * const apq8074_dt_match[] __initconst = {
>> +	"qcom,apq8074-dragonboard",
>> +	NULL
>> +};
>> +
>> DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
>> 	.smp = smp_ops(msm_smp_ops),
>> 	.dt_compat = msm_dt_match,
>> MACHINE_END
>> +
>> +DT_MACHINE_START(APQ_DT, "Qualcomm MSM (Flattened Device Tree)")
>> +	.dt_compat = apq8074_dt_match,
>> +MACHINE_END
>> -- 
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> hosted by The Linux Foundation
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Thanks,
Rohit Vaswani

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Kumar Gala]

On Sep 25, 2013, at 5:35 PM, Rohit Vaswani wrote:

> On 9/25/2013 12:49 PM, Kumar Gala wrote:
>> On Sep 23, 2013, at 10:13 PM, Rohit Vaswani wrote:
>> 
>>> This patch adds basic board support for APQ8074 Dragonboard
>>> which belongs to the Snapdragon 800 family.
>>> For now, just support a basic machine with device tree.
>>> 
>>> Signed-off-by: Rohit Vaswani <rvaswani-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>> ---
>>> arch/arm/Kconfig.debug                         |  9 +++++++
>>> arch/arm/boot/dts/Makefile                     |  3 ++-
>>> arch/arm/boot/dts/qcom-apq8074-dragonboard.dts |  6 +++++
>>> arch/arm/boot/dts/qcom-msm8974.dtsi            | 35 ++++++++++++++++++++++++++
>>> arch/arm/include/debug/msm.S                   |  5 ++++
>>> arch/arm/mach-msm/Kconfig                      | 13 ++++++++++
>>> arch/arm/mach-msm/board-dt.c                   |  9 +++++++
>>> 7 files changed, 79 insertions(+), 1 deletion(-)
>>> create mode 100644 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>>> create mode 100644 arch/arm/boot/dts/qcom-msm8974.dtsi
>>> 
>>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>>> index e18a6fc..959b2c7 100644
>>> --- a/arch/arm/Kconfig.debug
>>> +++ b/arch/arm/Kconfig.debug
>>> @@ -357,6 +357,15 @@ choice
>>> 		  Say Y here if you want the debug print routines to direct
>>> 		  their output to the serial port on MSM 8960 devices.
>>> 
>>> +	config DEBUG_MSM8974_UART
>>> +		bool "Kernel low-level debugging messages via MSM 8974 UART"
>>> +		depends on ARCH_MSM8974
>>> +		select MSM_HAS_DEBUG_UART_HS
>>> +		select DEBUG_MSM_UART
>>> +		help
>>> +		  Say Y here if you want the debug print routines to direct
>>> +		  their output to the serial port on MSM 8974 devices.
>>> +
>> A little surprised you didn't pull this and the ARCH_MSM8974 into its own patch outside of this patch being board support.
> 
> Well, its good to have this as part of initial board setup for earlyprintk.

I agree, just figured it would have been a standalone patch and a precursor to this patch.

>>> 	config DEBUG_MVEBU_UART
>>> 		bool "Kernel low-level debugging messages via MVEBU UART (old bootloaders)"
>>> 		depends on ARCH_MVEBU
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index 000cf76..e71a3ec 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -102,7 +102,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
>>> 	kirkwood-openblocks_a6.dtb
>>> dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
>>> dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
>>> -	msm8960-cdp.dtb
>>> +	msm8960-cdp.dtb \
>>> +	qcom-apq8074-dragonboard.dtb
>>> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
>>> 	armada-370-mirabox.dtb \
>>> 	armada-370-netgear-rn102.dtb \
>>> diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>>> new file mode 100644
>>> index 0000000..bb6f3c4
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>>> @@ -0,0 +1,6 @@
>>> +/include/ "qcom-msm8974.dtsi"
>>> +
>>> +/ {
>>> +	model = "Qualcomm APQ8074 Dragonboard";
>>> +	compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
>>> +};
>>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
>>> new file mode 100644
>>> index 0000000..f04b643
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
>>> @@ -0,0 +1,35 @@
>>> +/dts-v1/;
>>> +
>>> +/include/ "skeleton.dtsi"
>>> +
>>> +/ {
>>> +	model = "Qualcomm MSM8974";
>>> +	compatible = "qcom,msm8974";
>>> +	interrupt-parent = <&intc>;
>>> +
>>> +	soc: soc { };
>> We should have a unit address here:
>> 
>> 	  soc: soc@FOOBAR {
>> 
>> also, split out the curly braces so any future patches do have to muck with that.
>> 
>> 	};
>> 
> 
> Im not sure I understand the reasoning behind the unit address for soc ?

Its fairly standard practice and there is a fair amount of discussion about the lack of a unit address for memory nodes.



>>> +};
>>> +
>>> +&soc {
>>> +	#address-cells = <1>;
>>> +	#size-cells = <1>;
>>> +	ranges;
>>> +	compatible = "simple-bus";
>>> +
>>> +	intc: interrupt-controller@f9000000 {
>>> +		compatible = "qcom,msm-qgic2";
>>> +		interrupt-controller;
>>> +		#interrupt-cells = <3>;
>>> +		reg = <0xf9000000 0x1000>,
>>> +		      <0xf9002000 0x1000>;
>>> +	};
>>> +
>>> +	timer {
>>> +		compatible = "arm,armv7-timer";
>>> +		interrupts = <1 2 0xf08>,
>>> +			     <1 3 0xf08>,
>>> +			     <1 4 0xf08>,
>>> +			     <1 1 0xf08>;
>>> +		clock-frequency = <19200000>;
>>> +	};
>>> +};

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

--
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

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Kumar Gala]

On Sep 25, 2013, at 5:35 PM, Rohit Vaswani wrote:

> On 9/25/2013 12:49 PM, Kumar Gala wrote:
>> On Sep 23, 2013, at 10:13 PM, Rohit Vaswani wrote:
>> 
>>> This patch adds basic board support for APQ8074 Dragonboard
>>> which belongs to the Snapdragon 800 family.
>>> For now, just support a basic machine with device tree.
>>> 
>>> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
>>> ---
>>> arch/arm/Kconfig.debug                         |  9 +++++++
>>> arch/arm/boot/dts/Makefile                     |  3 ++-
>>> arch/arm/boot/dts/qcom-apq8074-dragonboard.dts |  6 +++++
>>> arch/arm/boot/dts/qcom-msm8974.dtsi            | 35 ++++++++++++++++++++++++++
>>> arch/arm/include/debug/msm.S                   |  5 ++++
>>> arch/arm/mach-msm/Kconfig                      | 13 ++++++++++
>>> arch/arm/mach-msm/board-dt.c                   |  9 +++++++
>>> 7 files changed, 79 insertions(+), 1 deletion(-)
>>> create mode 100644 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>>> create mode 100644 arch/arm/boot/dts/qcom-msm8974.dtsi
>>> 
>>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>>> index e18a6fc..959b2c7 100644
>>> --- a/arch/arm/Kconfig.debug
>>> +++ b/arch/arm/Kconfig.debug
>>> @@ -357,6 +357,15 @@ choice
>>> 		  Say Y here if you want the debug print routines to direct
>>> 		  their output to the serial port on MSM 8960 devices.
>>> 
>>> +	config DEBUG_MSM8974_UART
>>> +		bool "Kernel low-level debugging messages via MSM 8974 UART"
>>> +		depends on ARCH_MSM8974
>>> +		select MSM_HAS_DEBUG_UART_HS
>>> +		select DEBUG_MSM_UART
>>> +		help
>>> +		  Say Y here if you want the debug print routines to direct
>>> +		  their output to the serial port on MSM 8974 devices.
>>> +
>> A little surprised you didn't pull this and the ARCH_MSM8974 into its own patch outside of this patch being board support.
> 
> Well, its good to have this as part of initial board setup for earlyprintk.

I agree, just figured it would have been a standalone patch and a precursor to this patch.

>>> 	config DEBUG_MVEBU_UART
>>> 		bool "Kernel low-level debugging messages via MVEBU UART (old bootloaders)"
>>> 		depends on ARCH_MVEBU
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index 000cf76..e71a3ec 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -102,7 +102,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
>>> 	kirkwood-openblocks_a6.dtb
>>> dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
>>> dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
>>> -	msm8960-cdp.dtb
>>> +	msm8960-cdp.dtb \
>>> +	qcom-apq8074-dragonboard.dtb
>>> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
>>> 	armada-370-mirabox.dtb \
>>> 	armada-370-netgear-rn102.dtb \
>>> diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>>> new file mode 100644
>>> index 0000000..bb6f3c4
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>>> @@ -0,0 +1,6 @@
>>> +/include/ "qcom-msm8974.dtsi"
>>> +
>>> +/ {
>>> +	model = "Qualcomm APQ8074 Dragonboard";
>>> +	compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
>>> +};
>>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
>>> new file mode 100644
>>> index 0000000..f04b643
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
>>> @@ -0,0 +1,35 @@
>>> +/dts-v1/;
>>> +
>>> +/include/ "skeleton.dtsi"
>>> +
>>> +/ {
>>> +	model = "Qualcomm MSM8974";
>>> +	compatible = "qcom,msm8974";
>>> +	interrupt-parent = <&intc>;
>>> +
>>> +	soc: soc { };
>> We should have a unit address here:
>> 
>> 	  soc: soc@FOOBAR {
>> 
>> also, split out the curly braces so any future patches do have to muck with that.
>> 
>> 	};
>> 
> 
> Im not sure I understand the reasoning behind the unit address for soc ?

Its fairly standard practice and there is a fair amount of discussion about the lack of a unit address for memory nodes.



>>> +};
>>> +
>>> +&soc {
>>> +	#address-cells = <1>;
>>> +	#size-cells = <1>;
>>> +	ranges;
>>> +	compatible = "simple-bus";
>>> +
>>> +	intc: interrupt-controller@f9000000 {
>>> +		compatible = "qcom,msm-qgic2";
>>> +		interrupt-controller;
>>> +		#interrupt-cells = <3>;
>>> +		reg = <0xf9000000 0x1000>,
>>> +		      <0xf9002000 0x1000>;
>>> +	};
>>> +
>>> +	timer {
>>> +		compatible = "arm,armv7-timer";
>>> +		interrupts = <1 2 0xf08>,
>>> +			     <1 3 0xf08>,
>>> +			     <1 4 0xf08>,
>>> +			     <1 1 0xf08>;
>>> +		clock-frequency = <19200000>;
>>> +	};
>>> +};

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Kumar Gala]

On Sep 25, 2013, at 5:35 PM, Rohit Vaswani wrote:

> On 9/25/2013 12:49 PM, Kumar Gala wrote:
>> On Sep 23, 2013, at 10:13 PM, Rohit Vaswani wrote:
>> 
>>> This patch adds basic board support for APQ8074 Dragonboard
>>> which belongs to the Snapdragon 800 family.
>>> For now, just support a basic machine with device tree.
>>> 
>>> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
>>> ---
>>> arch/arm/Kconfig.debug                         |  9 +++++++
>>> arch/arm/boot/dts/Makefile                     |  3 ++-
>>> arch/arm/boot/dts/qcom-apq8074-dragonboard.dts |  6 +++++
>>> arch/arm/boot/dts/qcom-msm8974.dtsi            | 35 ++++++++++++++++++++++++++
>>> arch/arm/include/debug/msm.S                   |  5 ++++
>>> arch/arm/mach-msm/Kconfig                      | 13 ++++++++++
>>> arch/arm/mach-msm/board-dt.c                   |  9 +++++++
>>> 7 files changed, 79 insertions(+), 1 deletion(-)
>>> create mode 100644 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>>> create mode 100644 arch/arm/boot/dts/qcom-msm8974.dtsi
>>> 
>>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>>> index e18a6fc..959b2c7 100644
>>> --- a/arch/arm/Kconfig.debug
>>> +++ b/arch/arm/Kconfig.debug
>>> @@ -357,6 +357,15 @@ choice
>>> 		  Say Y here if you want the debug print routines to direct
>>> 		  their output to the serial port on MSM 8960 devices.
>>> 
>>> +	config DEBUG_MSM8974_UART
>>> +		bool "Kernel low-level debugging messages via MSM 8974 UART"
>>> +		depends on ARCH_MSM8974
>>> +		select MSM_HAS_DEBUG_UART_HS
>>> +		select DEBUG_MSM_UART
>>> +		help
>>> +		  Say Y here if you want the debug print routines to direct
>>> +		  their output to the serial port on MSM 8974 devices.
>>> +
>> A little surprised you didn't pull this and the ARCH_MSM8974 into its own patch outside of this patch being board support.
> 
> Well, its good to have this as part of initial board setup for earlyprintk.

I agree, just figured it would have been a standalone patch and a precursor to this patch.

>>> 	config DEBUG_MVEBU_UART
>>> 		bool "Kernel low-level debugging messages via MVEBU UART (old bootloaders)"
>>> 		depends on ARCH_MVEBU
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index 000cf76..e71a3ec 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -102,7 +102,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
>>> 	kirkwood-openblocks_a6.dtb
>>> dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
>>> dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
>>> -	msm8960-cdp.dtb
>>> +	msm8960-cdp.dtb \
>>> +	qcom-apq8074-dragonboard.dtb
>>> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
>>> 	armada-370-mirabox.dtb \
>>> 	armada-370-netgear-rn102.dtb \
>>> diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>>> new file mode 100644
>>> index 0000000..bb6f3c4
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>>> @@ -0,0 +1,6 @@
>>> +/include/ "qcom-msm8974.dtsi"
>>> +
>>> +/ {
>>> +	model = "Qualcomm APQ8074 Dragonboard";
>>> +	compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
>>> +};
>>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
>>> new file mode 100644
>>> index 0000000..f04b643
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
>>> @@ -0,0 +1,35 @@
>>> +/dts-v1/;
>>> +
>>> +/include/ "skeleton.dtsi"
>>> +
>>> +/ {
>>> +	model = "Qualcomm MSM8974";
>>> +	compatible = "qcom,msm8974";
>>> +	interrupt-parent = <&intc>;
>>> +
>>> +	soc: soc { };
>> We should have a unit address here:
>> 
>> 	  soc: soc at FOOBAR {
>> 
>> also, split out the curly braces so any future patches do have to muck with that.
>> 
>> 	};
>> 
> 
> Im not sure I understand the reasoning behind the unit address for soc ?

Its fairly standard practice and there is a fair amount of discussion about the lack of a unit address for memory nodes.



>>> +};
>>> +
>>> +&soc {
>>> +	#address-cells = <1>;
>>> +	#size-cells = <1>;
>>> +	ranges;
>>> +	compatible = "simple-bus";
>>> +
>>> +	intc: interrupt-controller at f9000000 {
>>> +		compatible = "qcom,msm-qgic2";
>>> +		interrupt-controller;
>>> +		#interrupt-cells = <3>;
>>> +		reg = <0xf9000000 0x1000>,
>>> +		      <0xf9002000 0x1000>;
>>> +	};
>>> +
>>> +	timer {
>>> +		compatible = "arm,armv7-timer";
>>> +		interrupts = <1 2 0xf08>,
>>> +			     <1 3 0xf08>,
>>> +			     <1 4 0xf08>,
>>> +			     <1 1 0xf08>;
>>> +		clock-frequency = <19200000>;
>>> +	};
>>> +};

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Rohit Vaswani]

On 9/26/2013 9:37 AM, Kumar Gala wrote:
> <snip>

> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
> @@ -0,0 +1,6 @@
> +/include/ "qcom-msm8974.dtsi"
> +
> +/ {
> +	model = "Qualcomm APQ8074 Dragonboard";
> +	compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
> +};
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> new file mode 100644
> index 0000000..f04b643
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -0,0 +1,35 @@
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	model = "Qualcomm MSM8974";
> +	compatible = "qcom,msm8974";
> +	interrupt-parent = <&intc>;
> +
> +	soc: soc { };
>>> We should have a unit address here:
>>>
>>> 	  soc: soc@FOOBAR {
>>>
>>> also, split out the curly braces so any future patches do have to muck with that.
>>>
>>> 	};
>>>
>> Im not sure I understand the reasoning behind the unit address for soc ?
> Its fairly standard practice and there is a fair amount of discussion about the lack of a unit address for memory nodes.
>
That still doesn't really answer anything :) - and I couldn't find any 
discussions about this either.
I don't see anybody in upstream adding an address to soc except sun.
What is that address supposed to be for - what does it mean ?
The soc is way of encapsulating meaningful blocks  for the particular SoC.

>
>>>> +};
>>>> +
>>>> +&soc {
>>>> +	#address-cells = <1>;
>>>> +	#size-cells = <1>;
>>>> +	ranges;
>>>> +	compatible = "simple-bus";
>>>> +
>>>> +	intc: interrupt-controller@f9000000 {
>>>> +		compatible = "qcom,msm-qgic2";
>>>> +		interrupt-controller;
>>>> +		#interrupt-cells = <3>;
>>>> +		reg = <0xf9000000 0x1000>,
>>>> +		      <0xf9002000 0x1000>;
>>>> +	};
>>>> +
>>>> +	timer {
>>>> +		compatible = "arm,armv7-timer";
>>>> +		interrupts = <1 2 0xf08>,
>>>> +			     <1 3 0xf08>,
>>>> +			     <1 4 0xf08>,
>>>> +			     <1 1 0xf08>;
>>>> +		clock-frequency = <19200000>;
>>>> +	};
>>>> +};
> - k
>


Thanks,
Rohit Vaswani

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation

[PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Rohit Vaswani]

On 9/26/2013 9:37 AM, Kumar Gala wrote:
> <snip>

> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
> @@ -0,0 +1,6 @@
> +/include/ "qcom-msm8974.dtsi"
> +
> +/ {
> +	model = "Qualcomm APQ8074 Dragonboard";
> +	compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
> +};
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> new file mode 100644
> index 0000000..f04b643
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -0,0 +1,35 @@
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	model = "Qualcomm MSM8974";
> +	compatible = "qcom,msm8974";
> +	interrupt-parent = <&intc>;
> +
> +	soc: soc { };
>>> We should have a unit address here:
>>>
>>> 	  soc: soc at FOOBAR {
>>>
>>> also, split out the curly braces so any future patches do have to muck with that.
>>>
>>> 	};
>>>
>> Im not sure I understand the reasoning behind the unit address for soc ?
> Its fairly standard practice and there is a fair amount of discussion about the lack of a unit address for memory nodes.
>
That still doesn't really answer anything :) - and I couldn't find any 
discussions about this either.
I don't see anybody in upstream adding an address to soc except sun.
What is that address supposed to be for - what does it mean ?
The soc is way of encapsulating meaningful blocks  for the particular SoC.

>
>>>> +};
>>>> +
>>>> +&soc {
>>>> +	#address-cells = <1>;
>>>> +	#size-cells = <1>;
>>>> +	ranges;
>>>> +	compatible = "simple-bus";
>>>> +
>>>> +	intc: interrupt-controller at f9000000 {
>>>> +		compatible = "qcom,msm-qgic2";
>>>> +		interrupt-controller;
>>>> +		#interrupt-cells = <3>;
>>>> +		reg = <0xf9000000 0x1000>,
>>>> +		      <0xf9002000 0x1000>;
>>>> +	};
>>>> +
>>>> +	timer {
>>>> +		compatible = "arm,armv7-timer";
>>>> +		interrupts = <1 2 0xf08>,
>>>> +			     <1 3 0xf08>,
>>>> +			     <1 4 0xf08>,
>>>> +			     <1 1 0xf08>;
>>>> +		clock-frequency = <19200000>;
>>>> +	};
>>>> +};
> - k
>


Thanks,
Rohit Vaswani

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Rohit Vaswani]

On 9/26/2013 11:05 AM, Rohit Vaswani wrote:
> On 9/26/2013 9:37 AM, Kumar Gala wrote:
>> <snip>
>
>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>> @@ -0,0 +1,6 @@
>> +/include/ "qcom-msm8974.dtsi"
>> +
>> +/ {
>> +    model = "Qualcomm APQ8074 Dragonboard";
>> +    compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
>> +};
>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
>> b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> new file mode 100644
>> index 0000000..f04b643
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> @@ -0,0 +1,35 @@
>> +/dts-v1/;
>> +
>> +/include/ "skeleton.dtsi"
>> +
>> +/ {
>> +    model = "Qualcomm MSM8974";
>> +    compatible = "qcom,msm8974";
>> +    interrupt-parent = <&intc>;
>> +
>> +    soc: soc { };
>>>> We should have a unit address here:
>>>>
>>>>       soc: soc@FOOBAR {
>>>>
>>>> also, split out the curly braces so any future patches do have to 
>>>> muck with that.
>>>>
>>>>     };
>>>>
>>> Im not sure I understand the reasoning behind the unit address for 
>>> soc ?
>> Its fairly standard practice and there is a fair amount of discussion 
>> about the lack of a unit address for memory nodes.
>>
> That still doesn't really answer anything :) - and I couldn't find any 
> discussions about this either.
> I don't see anybody in upstream adding an address to soc except sun.
> What is that address supposed to be for - what does it mean ?
> The soc is way of encapsulating meaningful blocks  for the particular 
> SoC.

I see the mail from Stephen Warren for adding a check stating that

"ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
node that has a reg property must include a unit address in its name
with value matching the first entry in its reg property. Conversely, if
a node does not have a reg property, the node name must not include a
unit address."

The soc node we have does not have a reg property ?


>
>>
>>>>> +};
>>>>> +
>>>>> +&soc {
>>>>> +    #address-cells = <1>;
>>>>> +    #size-cells = <1>;
>>>>> +    ranges;
>>>>> +    compatible = "simple-bus";
>>>>> +
>>>>> +    intc: interrupt-controller@f9000000 {
>>>>> +        compatible = "qcom,msm-qgic2";
>>>>> +        interrupt-controller;
>>>>> +        #interrupt-cells = <3>;
>>>>> +        reg = <0xf9000000 0x1000>,
>>>>> +              <0xf9002000 0x1000>;
>>>>> +    };
>>>>> +
>>>>> +    timer {
>>>>> +        compatible = "arm,armv7-timer";
>>>>> +        interrupts = <1 2 0xf08>,
>>>>> +                 <1 3 0xf08>,
>>>>> +                 <1 4 0xf08>,
>>>>> +                 <1 1 0xf08>;
>>>>> +        clock-frequency = <19200000>;
>>>>> +    };
>>>>> +};
>> - k
>>
>
>
> Thanks,
> Rohit Vaswani
>


Thanks,
Rohit Vaswani

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation

--
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

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Rohit Vaswani]

On 9/26/2013 11:05 AM, Rohit Vaswani wrote:
> On 9/26/2013 9:37 AM, Kumar Gala wrote:
>> <snip>
>
>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>> @@ -0,0 +1,6 @@
>> +/include/ "qcom-msm8974.dtsi"
>> +
>> +/ {
>> +    model = "Qualcomm APQ8074 Dragonboard";
>> +    compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
>> +};
>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
>> b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> new file mode 100644
>> index 0000000..f04b643
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> @@ -0,0 +1,35 @@
>> +/dts-v1/;
>> +
>> +/include/ "skeleton.dtsi"
>> +
>> +/ {
>> +    model = "Qualcomm MSM8974";
>> +    compatible = "qcom,msm8974";
>> +    interrupt-parent = <&intc>;
>> +
>> +    soc: soc { };
>>>> We should have a unit address here:
>>>>
>>>>       soc: soc@FOOBAR {
>>>>
>>>> also, split out the curly braces so any future patches do have to 
>>>> muck with that.
>>>>
>>>>     };
>>>>
>>> Im not sure I understand the reasoning behind the unit address for 
>>> soc ?
>> Its fairly standard practice and there is a fair amount of discussion 
>> about the lack of a unit address for memory nodes.
>>
> That still doesn't really answer anything :) - and I couldn't find any 
> discussions about this either.
> I don't see anybody in upstream adding an address to soc except sun.
> What is that address supposed to be for - what does it mean ?
> The soc is way of encapsulating meaningful blocks  for the particular 
> SoC.

I see the mail from Stephen Warren for adding a check stating that

"ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
node that has a reg property must include a unit address in its name
with value matching the first entry in its reg property. Conversely, if
a node does not have a reg property, the node name must not include a
unit address."

The soc node we have does not have a reg property ?


>
>>
>>>>> +};
>>>>> +
>>>>> +&soc {
>>>>> +    #address-cells = <1>;
>>>>> +    #size-cells = <1>;
>>>>> +    ranges;
>>>>> +    compatible = "simple-bus";
>>>>> +
>>>>> +    intc: interrupt-controller@f9000000 {
>>>>> +        compatible = "qcom,msm-qgic2";
>>>>> +        interrupt-controller;
>>>>> +        #interrupt-cells = <3>;
>>>>> +        reg = <0xf9000000 0x1000>,
>>>>> +              <0xf9002000 0x1000>;
>>>>> +    };
>>>>> +
>>>>> +    timer {
>>>>> +        compatible = "arm,armv7-timer";
>>>>> +        interrupts = <1 2 0xf08>,
>>>>> +                 <1 3 0xf08>,
>>>>> +                 <1 4 0xf08>,
>>>>> +                 <1 1 0xf08>;
>>>>> +        clock-frequency = <19200000>;
>>>>> +    };
>>>>> +};
>> - k
>>
>
>
> Thanks,
> Rohit Vaswani
>


Thanks,
Rohit Vaswani

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation

[PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Rohit Vaswani]

On 9/26/2013 11:05 AM, Rohit Vaswani wrote:
> On 9/26/2013 9:37 AM, Kumar Gala wrote:
>> <snip>
>
>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>> @@ -0,0 +1,6 @@
>> +/include/ "qcom-msm8974.dtsi"
>> +
>> +/ {
>> +    model = "Qualcomm APQ8074 Dragonboard";
>> +    compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
>> +};
>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
>> b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> new file mode 100644
>> index 0000000..f04b643
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> @@ -0,0 +1,35 @@
>> +/dts-v1/;
>> +
>> +/include/ "skeleton.dtsi"
>> +
>> +/ {
>> +    model = "Qualcomm MSM8974";
>> +    compatible = "qcom,msm8974";
>> +    interrupt-parent = <&intc>;
>> +
>> +    soc: soc { };
>>>> We should have a unit address here:
>>>>
>>>>       soc: soc at FOOBAR {
>>>>
>>>> also, split out the curly braces so any future patches do have to 
>>>> muck with that.
>>>>
>>>>     };
>>>>
>>> Im not sure I understand the reasoning behind the unit address for 
>>> soc ?
>> Its fairly standard practice and there is a fair amount of discussion 
>> about the lack of a unit address for memory nodes.
>>
> That still doesn't really answer anything :) - and I couldn't find any 
> discussions about this either.
> I don't see anybody in upstream adding an address to soc except sun.
> What is that address supposed to be for - what does it mean ?
> The soc is way of encapsulating meaningful blocks  for the particular 
> SoC.

I see the mail from Stephen Warren for adding a check stating that

"ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
node that has a reg property must include a unit address in its name
with value matching the first entry in its reg property. Conversely, if
a node does not have a reg property, the node name must not include a
unit address."

The soc node we have does not have a reg property ?


>
>>
>>>>> +};
>>>>> +
>>>>> +&soc {
>>>>> +    #address-cells = <1>;
>>>>> +    #size-cells = <1>;
>>>>> +    ranges;
>>>>> +    compatible = "simple-bus";
>>>>> +
>>>>> +    intc: interrupt-controller at f9000000 {
>>>>> +        compatible = "qcom,msm-qgic2";
>>>>> +        interrupt-controller;
>>>>> +        #interrupt-cells = <3>;
>>>>> +        reg = <0xf9000000 0x1000>,
>>>>> +              <0xf9002000 0x1000>;
>>>>> +    };
>>>>> +
>>>>> +    timer {
>>>>> +        compatible = "arm,armv7-timer";
>>>>> +        interrupts = <1 2 0xf08>,
>>>>> +                 <1 3 0xf08>,
>>>>> +                 <1 4 0xf08>,
>>>>> +                 <1 1 0xf08>;
>>>>> +        clock-frequency = <19200000>;
>>>>> +    };
>>>>> +};
>> - k
>>
>
>
> Thanks,
> Rohit Vaswani
>


Thanks,
Rohit Vaswani

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Kumar Gala]

On Sep 26, 2013, at 2:17 PM, Rohit Vaswani wrote:

> On 9/26/2013 11:05 AM, Rohit Vaswani wrote:
>> On 9/26/2013 9:37 AM, Kumar Gala wrote:
>>> <snip>
>> 
>>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>>> @@ -0,0 +1,6 @@
>>> +/include/ "qcom-msm8974.dtsi"
>>> +
>>> +/ {
>>> +    model = "Qualcomm APQ8074 Dragonboard";
>>> +    compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
>>> +};
>>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
>>> new file mode 100644
>>> index 0000000..f04b643
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
>>> @@ -0,0 +1,35 @@
>>> +/dts-v1/;
>>> +
>>> +/include/ "skeleton.dtsi"
>>> +
>>> +/ {
>>> +    model = "Qualcomm MSM8974";
>>> +    compatible = "qcom,msm8974";
>>> +    interrupt-parent = <&intc>;
>>> +
>>> +    soc: soc { };
>>>>> We should have a unit address here:
>>>>> 
>>>>>      soc: soc@FOOBAR {
>>>>> 
>>>>> also, split out the curly braces so any future patches do have to muck with that.
>>>>> 
>>>>>    };
>>>>> 
>>>> Im not sure I understand the reasoning behind the unit address for soc ?
>>> Its fairly standard practice and there is a fair amount of discussion about the lack of a unit address for memory nodes.
>>> 
>> That still doesn't really answer anything :) - and I couldn't find any discussions about this either.
>> I don't see anybody in upstream adding an address to soc except sun.
>> What is that address supposed to be for - what does it mean ?
>> The soc is way of encapsulating meaningful blocks  for the particular SoC.
> 
> I see the mail from Stephen Warren for adding a check stating that
> 
> "ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
> node that has a reg property must include a unit address in its name
> with value matching the first entry in its reg property. Conversely, if
> a node does not have a reg property, the node name must not include a
> unit address."
> 
> The soc node we have does not have a reg property ?

Not 100% sure what people will decide on this.  There are a number of examples on the PPC side (arch/powerpc/boot/dts) that are soc@ADDR, but they don't typically have "reg" properties at the soc level.

Let's go ahead w/o the unit address (as you have it) for now.

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

--
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

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Kumar Gala]

On Sep 26, 2013, at 2:17 PM, Rohit Vaswani wrote:

> On 9/26/2013 11:05 AM, Rohit Vaswani wrote:
>> On 9/26/2013 9:37 AM, Kumar Gala wrote:
>>> <snip>
>> 
>>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>>> @@ -0,0 +1,6 @@
>>> +/include/ "qcom-msm8974.dtsi"
>>> +
>>> +/ {
>>> +    model = "Qualcomm APQ8074 Dragonboard";
>>> +    compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
>>> +};
>>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
>>> new file mode 100644
>>> index 0000000..f04b643
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
>>> @@ -0,0 +1,35 @@
>>> +/dts-v1/;
>>> +
>>> +/include/ "skeleton.dtsi"
>>> +
>>> +/ {
>>> +    model = "Qualcomm MSM8974";
>>> +    compatible = "qcom,msm8974";
>>> +    interrupt-parent = <&intc>;
>>> +
>>> +    soc: soc { };
>>>>> We should have a unit address here:
>>>>> 
>>>>>      soc: soc@FOOBAR {
>>>>> 
>>>>> also, split out the curly braces so any future patches do have to muck with that.
>>>>> 
>>>>>    };
>>>>> 
>>>> Im not sure I understand the reasoning behind the unit address for soc ?
>>> Its fairly standard practice and there is a fair amount of discussion about the lack of a unit address for memory nodes.
>>> 
>> That still doesn't really answer anything :) - and I couldn't find any discussions about this either.
>> I don't see anybody in upstream adding an address to soc except sun.
>> What is that address supposed to be for - what does it mean ?
>> The soc is way of encapsulating meaningful blocks  for the particular SoC.
> 
> I see the mail from Stephen Warren for adding a check stating that
> 
> "ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
> node that has a reg property must include a unit address in its name
> with value matching the first entry in its reg property. Conversely, if
> a node does not have a reg property, the node name must not include a
> unit address."
> 
> The soc node we have does not have a reg property ?

Not 100% sure what people will decide on this.  There are a number of examples on the PPC side (arch/powerpc/boot/dts) that are soc@ADDR, but they don't typically have "reg" properties at the soc level.

Let's go ahead w/o the unit address (as you have it) for now.

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Kumar Gala]

On Sep 26, 2013, at 2:17 PM, Rohit Vaswani wrote:

> On 9/26/2013 11:05 AM, Rohit Vaswani wrote:
>> On 9/26/2013 9:37 AM, Kumar Gala wrote:
>>> <snip>
>> 
>>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
>>> @@ -0,0 +1,6 @@
>>> +/include/ "qcom-msm8974.dtsi"
>>> +
>>> +/ {
>>> +    model = "Qualcomm APQ8074 Dragonboard";
>>> +    compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
>>> +};
>>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
>>> new file mode 100644
>>> index 0000000..f04b643
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
>>> @@ -0,0 +1,35 @@
>>> +/dts-v1/;
>>> +
>>> +/include/ "skeleton.dtsi"
>>> +
>>> +/ {
>>> +    model = "Qualcomm MSM8974";
>>> +    compatible = "qcom,msm8974";
>>> +    interrupt-parent = <&intc>;
>>> +
>>> +    soc: soc { };
>>>>> We should have a unit address here:
>>>>> 
>>>>>      soc: soc at FOOBAR {
>>>>> 
>>>>> also, split out the curly braces so any future patches do have to muck with that.
>>>>> 
>>>>>    };
>>>>> 
>>>> Im not sure I understand the reasoning behind the unit address for soc ?
>>> Its fairly standard practice and there is a fair amount of discussion about the lack of a unit address for memory nodes.
>>> 
>> That still doesn't really answer anything :) - and I couldn't find any discussions about this either.
>> I don't see anybody in upstream adding an address to soc except sun.
>> What is that address supposed to be for - what does it mean ?
>> The soc is way of encapsulating meaningful blocks  for the particular SoC.
> 
> I see the mail from Stephen Warren for adding a check stating that
> 
> "ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
> node that has a reg property must include a unit address in its name
> with value matching the first entry in its reg property. Conversely, if
> a node does not have a reg property, the node name must not include a
> unit address."
> 
> The soc node we have does not have a reg property ?

Not 100% sure what people will decide on this.  There are a number of examples on the PPC side (arch/powerpc/boot/dts) that are soc at ADDR, but they don't typically have "reg" properties at the soc level.

Let's go ahead w/o the unit address (as you have it) for now.

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[David Brown]

On Thu, Sep 26, 2013 at 02:33:53PM -0500, Kumar Gala wrote:

>> "ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
>> node that has a reg property must include a unit address in its name
>> with value matching the first entry in its reg property. Conversely, if
>> a node does not have a reg property, the node name must not include a
>> unit address."
>>
>> The soc node we have does not have a reg property ?
>
>Not 100% sure what people will decide on this.  There are a number of
>examples on the PPC side (arch/powerpc/boot/dts) that are soc@ADDR,
>but they don't typically have "reg" properties at the soc level.
>
>Let's go ahead w/o the unit address (as you have it) for now.

What is the address even supposed to mean?  Are we expecting multiple
'soc' nodes?

David
--
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

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[David Brown]

On Thu, Sep 26, 2013 at 02:33:53PM -0500, Kumar Gala wrote:

>> "ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
>> node that has a reg property must include a unit address in its name
>> with value matching the first entry in its reg property. Conversely, if
>> a node does not have a reg property, the node name must not include a
>> unit address."
>>
>> The soc node we have does not have a reg property ?
>
>Not 100% sure what people will decide on this.  There are a number of
>examples on the PPC side (arch/powerpc/boot/dts) that are soc@ADDR,
>but they don't typically have "reg" properties at the soc level.
>
>Let's go ahead w/o the unit address (as you have it) for now.

What is the address even supposed to mean?  Are we expecting multiple
'soc' nodes?

David

[PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[David Brown]

On Thu, Sep 26, 2013 at 02:33:53PM -0500, Kumar Gala wrote:

>> "ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
>> node that has a reg property must include a unit address in its name
>> with value matching the first entry in its reg property. Conversely, if
>> a node does not have a reg property, the node name must not include a
>> unit address."
>>
>> The soc node we have does not have a reg property ?
>
>Not 100% sure what people will decide on this.  There are a number of
>examples on the PPC side (arch/powerpc/boot/dts) that are soc at ADDR,
>but they don't typically have "reg" properties at the soc level.
>
>Let's go ahead w/o the unit address (as you have it) for now.

What is the address even supposed to mean?  Are we expecting multiple
'soc' nodes?

David

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Kumar Gala]

On Sep 26, 2013, at 3:58 PM, David Brown wrote:

> On Thu, Sep 26, 2013 at 02:33:53PM -0500, Kumar Gala wrote:
> 
>>> "ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
>>> node that has a reg property must include a unit address in its name
>>> with value matching the first entry in its reg property. Conversely, if
>>> a node does not have a reg property, the node name must not include a
>>> unit address."
>>> 
>>> The soc node we have does not have a reg property ?
>> 
>> Not 100% sure what people will decide on this.  There are a number of
>> examples on the PPC side (arch/powerpc/boot/dts) that are soc@ADDR,
>> but they don't typically have "reg" properties at the soc level.
>> 
>> Let's go ahead w/o the unit address (as you have it) for now.
> 
> What is the address even supposed to mean?  Are we expecting multiple
> 'soc' nodes?


What do we consider to exist under soc in general?  I'd expect the address to be the base of the MMIO register register for on SoC devices (but that's based on my PPC history).

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

--
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

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Kumar Gala]

On Sep 26, 2013, at 3:58 PM, David Brown wrote:

> On Thu, Sep 26, 2013 at 02:33:53PM -0500, Kumar Gala wrote:
> 
>>> "ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
>>> node that has a reg property must include a unit address in its name
>>> with value matching the first entry in its reg property. Conversely, if
>>> a node does not have a reg property, the node name must not include a
>>> unit address."
>>> 
>>> The soc node we have does not have a reg property ?
>> 
>> Not 100% sure what people will decide on this.  There are a number of
>> examples on the PPC side (arch/powerpc/boot/dts) that are soc@ADDR,
>> but they don't typically have "reg" properties at the soc level.
>> 
>> Let's go ahead w/o the unit address (as you have it) for now.
> 
> What is the address even supposed to mean?  Are we expecting multiple
> 'soc' nodes?


What do we consider to exist under soc in general?  I'd expect the address to be the base of the MMIO register register for on SoC devices (but that's based on my PPC history).

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Kumar Gala]

On Sep 26, 2013, at 3:58 PM, David Brown wrote:

> On Thu, Sep 26, 2013 at 02:33:53PM -0500, Kumar Gala wrote:
> 
>>> "ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
>>> node that has a reg property must include a unit address in its name
>>> with value matching the first entry in its reg property. Conversely, if
>>> a node does not have a reg property, the node name must not include a
>>> unit address."
>>> 
>>> The soc node we have does not have a reg property ?
>> 
>> Not 100% sure what people will decide on this.  There are a number of
>> examples on the PPC side (arch/powerpc/boot/dts) that are soc at ADDR,
>> but they don't typically have "reg" properties at the soc level.
>> 
>> Let's go ahead w/o the unit address (as you have it) for now.
> 
> What is the address even supposed to mean?  Are we expecting multiple
> 'soc' nodes?


What do we consider to exist under soc in general?  I'd expect the address to be the base of the MMIO register register for on SoC devices (but that's based on my PPC history).

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Rob Herring]

On 09/26/2013 02:33 PM, Kumar Gala wrote:
> 
> On Sep 26, 2013, at 2:17 PM, Rohit Vaswani wrote:
> 
>> On 9/26/2013 11:05 AM, Rohit Vaswani wrote:
>>> On 9/26/2013 9:37 AM, Kumar Gala wrote:
>>>> <snip>
>>> 
>>>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts @@ -0,0
>>>> +1,6 @@ +/include/ "qcom-msm8974.dtsi" + +/ { +    model =
>>>> "Qualcomm APQ8074 Dragonboard"; +    compatible =
>>>> "qcom,apq8074-dragonboard", "qcom,apq8074"; +}; diff --git
>>>> a/arch/arm/boot/dts/qcom-msm8974.dtsi
>>>> b/arch/arm/boot/dts/qcom-msm8974.dtsi new file mode 100644 
>>>> index 0000000..f04b643 --- /dev/null +++
>>>> b/arch/arm/boot/dts/qcom-msm8974.dtsi @@ -0,0 +1,35 @@ 
>>>> +/dts-v1/; + +/include/ "skeleton.dtsi" + +/ { +    model =
>>>> "Qualcomm MSM8974"; +    compatible = "qcom,msm8974"; +
>>>> interrupt-parent = <&intc>; + +    soc: soc { };
>>>>>> We should have a unit address here:
>>>>>> 
>>>>>> soc: soc@FOOBAR {
>>>>>> 
>>>>>> also, split out the curly braces so any future patches do
>>>>>> have to muck with that.
>>>>>> 
>>>>>> };
>>>>>> 
>>>>> Im not sure I understand the reasoning behind the unit
>>>>> address for soc ?
>>>> Its fairly standard practice and there is a fair amount of
>>>> discussion about the lack of a unit address for memory nodes.
>>>> 
>>> That still doesn't really answer anything :) - and I couldn't
>>> find any discussions about this either. I don't see anybody in
>>> upstream adding an address to soc except sun. What is that
>>> address supposed to be for - what does it mean ? The soc is way
>>> of encapsulating meaningful blocks  for the particular SoC.
>> 
>> I see the mail from Stephen Warren for adding a check stating that
>> 
>> "ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that
>> any node that has a reg property must include a unit address in its
>> name with value matching the first entry in its reg property.
>> Conversely, if a node does not have a reg property, the node name
>> must not include a unit address."
>> 
>> The soc node we have does not have a reg property ?
> 
> Not 100% sure what people will decide on this.  There are a number of
> examples on the PPC side (arch/powerpc/boot/dts) that are soc@ADDR,
> but they don't typically have "reg" properties at the soc level.

No, but you may have a ranges property which is related.

I've just hit this on highbank in needing to add a second bank of
peripherals for midway. So my vote would be to have unit address.

Rob
--
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

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Rob Herring]

On 09/26/2013 02:33 PM, Kumar Gala wrote:
> 
> On Sep 26, 2013, at 2:17 PM, Rohit Vaswani wrote:
> 
>> On 9/26/2013 11:05 AM, Rohit Vaswani wrote:
>>> On 9/26/2013 9:37 AM, Kumar Gala wrote:
>>>> <snip>
>>> 
>>>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts @@ -0,0
>>>> +1,6 @@ +/include/ "qcom-msm8974.dtsi" + +/ { +    model =
>>>> "Qualcomm APQ8074 Dragonboard"; +    compatible =
>>>> "qcom,apq8074-dragonboard", "qcom,apq8074"; +}; diff --git
>>>> a/arch/arm/boot/dts/qcom-msm8974.dtsi
>>>> b/arch/arm/boot/dts/qcom-msm8974.dtsi new file mode 100644 
>>>> index 0000000..f04b643 --- /dev/null +++
>>>> b/arch/arm/boot/dts/qcom-msm8974.dtsi @@ -0,0 +1,35 @@ 
>>>> +/dts-v1/; + +/include/ "skeleton.dtsi" + +/ { +    model =
>>>> "Qualcomm MSM8974"; +    compatible = "qcom,msm8974"; +
>>>> interrupt-parent = <&intc>; + +    soc: soc { };
>>>>>> We should have a unit address here:
>>>>>> 
>>>>>> soc: soc@FOOBAR {
>>>>>> 
>>>>>> also, split out the curly braces so any future patches do
>>>>>> have to muck with that.
>>>>>> 
>>>>>> };
>>>>>> 
>>>>> Im not sure I understand the reasoning behind the unit
>>>>> address for soc ?
>>>> Its fairly standard practice and there is a fair amount of
>>>> discussion about the lack of a unit address for memory nodes.
>>>> 
>>> That still doesn't really answer anything :) - and I couldn't
>>> find any discussions about this either. I don't see anybody in
>>> upstream adding an address to soc except sun. What is that
>>> address supposed to be for - what does it mean ? The soc is way
>>> of encapsulating meaningful blocks  for the particular SoC.
>> 
>> I see the mail from Stephen Warren for adding a check stating that
>> 
>> "ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that
>> any node that has a reg property must include a unit address in its
>> name with value matching the first entry in its reg property.
>> Conversely, if a node does not have a reg property, the node name
>> must not include a unit address."
>> 
>> The soc node we have does not have a reg property ?
> 
> Not 100% sure what people will decide on this.  There are a number of
> examples on the PPC side (arch/powerpc/boot/dts) that are soc@ADDR,
> but they don't typically have "reg" properties at the soc level.

No, but you may have a ranges property which is related.

I've just hit this on highbank in needing to add a second bank of
peripherals for midway. So my vote would be to have unit address.

Rob

[PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Rob Herring]

On 09/26/2013 02:33 PM, Kumar Gala wrote:
> 
> On Sep 26, 2013, at 2:17 PM, Rohit Vaswani wrote:
> 
>> On 9/26/2013 11:05 AM, Rohit Vaswani wrote:
>>> On 9/26/2013 9:37 AM, Kumar Gala wrote:
>>>> <snip>
>>> 
>>>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts @@ -0,0
>>>> +1,6 @@ +/include/ "qcom-msm8974.dtsi" + +/ { +    model =
>>>> "Qualcomm APQ8074 Dragonboard"; +    compatible =
>>>> "qcom,apq8074-dragonboard", "qcom,apq8074"; +}; diff --git
>>>> a/arch/arm/boot/dts/qcom-msm8974.dtsi
>>>> b/arch/arm/boot/dts/qcom-msm8974.dtsi new file mode 100644 
>>>> index 0000000..f04b643 --- /dev/null +++
>>>> b/arch/arm/boot/dts/qcom-msm8974.dtsi @@ -0,0 +1,35 @@ 
>>>> +/dts-v1/; + +/include/ "skeleton.dtsi" + +/ { +    model =
>>>> "Qualcomm MSM8974"; +    compatible = "qcom,msm8974"; +
>>>> interrupt-parent = <&intc>; + +    soc: soc { };
>>>>>> We should have a unit address here:
>>>>>> 
>>>>>> soc: soc at FOOBAR {
>>>>>> 
>>>>>> also, split out the curly braces so any future patches do
>>>>>> have to muck with that.
>>>>>> 
>>>>>> };
>>>>>> 
>>>>> Im not sure I understand the reasoning behind the unit
>>>>> address for soc ?
>>>> Its fairly standard practice and there is a fair amount of
>>>> discussion about the lack of a unit address for memory nodes.
>>>> 
>>> That still doesn't really answer anything :) - and I couldn't
>>> find any discussions about this either. I don't see anybody in
>>> upstream adding an address to soc except sun. What is that
>>> address supposed to be for - what does it mean ? The soc is way
>>> of encapsulating meaningful blocks  for the particular SoC.
>> 
>> I see the mail from Stephen Warren for adding a check stating that
>> 
>> "ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that
>> any node that has a reg property must include a unit address in its
>> name with value matching the first entry in its reg property.
>> Conversely, if a node does not have a reg property, the node name
>> must not include a unit address."
>> 
>> The soc node we have does not have a reg property ?
> 
> Not 100% sure what people will decide on this.  There are a number of
> examples on the PPC side (arch/powerpc/boot/dts) that are soc at ADDR,
> but they don't typically have "reg" properties at the soc level.

No, but you may have a ranges property which is related.

I've just hit this on highbank in needing to add a second bank of
peripherals for midway. So my vote would be to have unit address.

Rob

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Kumar Gala]

On Sep 26, 2013, at 4:10 PM, Rob Herring wrote:

> On 09/26/2013 02:33 PM, Kumar Gala wrote:
>> 
>> On Sep 26, 2013, at 2:17 PM, Rohit Vaswani wrote:
>> 
>>> On 9/26/2013 11:05 AM, Rohit Vaswani wrote:
>>>> On 9/26/2013 9:37 AM, Kumar Gala wrote:
>>>>> <snip>
>>>> 
>>>>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts @@ -0,0
>>>>> +1,6 @@ +/include/ "qcom-msm8974.dtsi" + +/ { +    model =
>>>>> "Qualcomm APQ8074 Dragonboard"; +    compatible =
>>>>> "qcom,apq8074-dragonboard", "qcom,apq8074"; +}; diff --git
>>>>> a/arch/arm/boot/dts/qcom-msm8974.dtsi
>>>>> b/arch/arm/boot/dts/qcom-msm8974.dtsi new file mode 100644 
>>>>> index 0000000..f04b643 --- /dev/null +++
>>>>> b/arch/arm/boot/dts/qcom-msm8974.dtsi @@ -0,0 +1,35 @@ 
>>>>> +/dts-v1/; + +/include/ "skeleton.dtsi" + +/ { +    model =
>>>>> "Qualcomm MSM8974"; +    compatible = "qcom,msm8974"; +
>>>>> interrupt-parent = <&intc>; + +    soc: soc { };
>>>>>>> We should have a unit address here:
>>>>>>> 
>>>>>>> soc: soc@FOOBAR {
>>>>>>> 
>>>>>>> also, split out the curly braces so any future patches do
>>>>>>> have to muck with that.
>>>>>>> 
>>>>>>> };
>>>>>>> 
>>>>>> Im not sure I understand the reasoning behind the unit
>>>>>> address for soc ?
>>>>> Its fairly standard practice and there is a fair amount of
>>>>> discussion about the lack of a unit address for memory nodes.
>>>>> 
>>>> That still doesn't really answer anything :) - and I couldn't
>>>> find any discussions about this either. I don't see anybody in
>>>> upstream adding an address to soc except sun. What is that
>>>> address supposed to be for - what does it mean ? The soc is way
>>>> of encapsulating meaningful blocks  for the particular SoC.
>>> 
>>> I see the mail from Stephen Warren for adding a check stating that
>>> 
>>> "ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that
>>> any node that has a reg property must include a unit address in its
>>> name with value matching the first entry in its reg property.
>>> Conversely, if a node does not have a reg property, the node name
>>> must not include a unit address."
>>> 
>>> The soc node we have does not have a reg property ?
>> 
>> Not 100% sure what people will decide on this.  There are a number of
>> examples on the PPC side (arch/powerpc/boot/dts) that are soc@ADDR,
>> but they don't typically have "reg" properties at the soc level.
> 
> No, but you may have a ranges property which is related.
> 
> I've just hit this on highbank in needing to add a second bank of
> peripherals for midway. So my vote would be to have unit address.
> 
> Rob

So are we saying the rule for needing a unit-address being either 'reg' or 'ranges' ?

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

--
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

Re: [PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Kumar Gala]

On Sep 26, 2013, at 4:10 PM, Rob Herring wrote:

> On 09/26/2013 02:33 PM, Kumar Gala wrote:
>> 
>> On Sep 26, 2013, at 2:17 PM, Rohit Vaswani wrote:
>> 
>>> On 9/26/2013 11:05 AM, Rohit Vaswani wrote:
>>>> On 9/26/2013 9:37 AM, Kumar Gala wrote:
>>>>> <snip>
>>>> 
>>>>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts @@ -0,0
>>>>> +1,6 @@ +/include/ "qcom-msm8974.dtsi" + +/ { +    model =
>>>>> "Qualcomm APQ8074 Dragonboard"; +    compatible =
>>>>> "qcom,apq8074-dragonboard", "qcom,apq8074"; +}; diff --git
>>>>> a/arch/arm/boot/dts/qcom-msm8974.dtsi
>>>>> b/arch/arm/boot/dts/qcom-msm8974.dtsi new file mode 100644 
>>>>> index 0000000..f04b643 --- /dev/null +++
>>>>> b/arch/arm/boot/dts/qcom-msm8974.dtsi @@ -0,0 +1,35 @@ 
>>>>> +/dts-v1/; + +/include/ "skeleton.dtsi" + +/ { +    model =
>>>>> "Qualcomm MSM8974"; +    compatible = "qcom,msm8974"; +
>>>>> interrupt-parent = <&intc>; + +    soc: soc { };
>>>>>>> We should have a unit address here:
>>>>>>> 
>>>>>>> soc: soc@FOOBAR {
>>>>>>> 
>>>>>>> also, split out the curly braces so any future patches do
>>>>>>> have to muck with that.
>>>>>>> 
>>>>>>> };
>>>>>>> 
>>>>>> Im not sure I understand the reasoning behind the unit
>>>>>> address for soc ?
>>>>> Its fairly standard practice and there is a fair amount of
>>>>> discussion about the lack of a unit address for memory nodes.
>>>>> 
>>>> That still doesn't really answer anything :) - and I couldn't
>>>> find any discussions about this either. I don't see anybody in
>>>> upstream adding an address to soc except sun. What is that
>>>> address supposed to be for - what does it mean ? The soc is way
>>>> of encapsulating meaningful blocks  for the particular SoC.
>>> 
>>> I see the mail from Stephen Warren for adding a check stating that
>>> 
>>> "ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that
>>> any node that has a reg property must include a unit address in its
>>> name with value matching the first entry in its reg property.
>>> Conversely, if a node does not have a reg property, the node name
>>> must not include a unit address."
>>> 
>>> The soc node we have does not have a reg property ?
>> 
>> Not 100% sure what people will decide on this.  There are a number of
>> examples on the PPC side (arch/powerpc/boot/dts) that are soc@ADDR,
>> but they don't typically have "reg" properties at the soc level.
> 
> No, but you may have a ranges property which is related.
> 
> I've just hit this on highbank in needing to add a second bank of
> peripherals for midway. So my vote would be to have unit address.
> 
> Rob

So are we saying the rule for needing a unit-address being either 'reg' or 'ranges' ?

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard

[Kumar Gala]

On Sep 26, 2013, at 4:10 PM, Rob Herring wrote:

> On 09/26/2013 02:33 PM, Kumar Gala wrote:
>> 
>> On Sep 26, 2013, at 2:17 PM, Rohit Vaswani wrote:
>> 
>>> On 9/26/2013 11:05 AM, Rohit Vaswani wrote:
>>>> On 9/26/2013 9:37 AM, Kumar Gala wrote:
>>>>> <snip>
>>>> 
>>>>> +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts @@ -0,0
>>>>> +1,6 @@ +/include/ "qcom-msm8974.dtsi" + +/ { +    model =
>>>>> "Qualcomm APQ8074 Dragonboard"; +    compatible =
>>>>> "qcom,apq8074-dragonboard", "qcom,apq8074"; +}; diff --git
>>>>> a/arch/arm/boot/dts/qcom-msm8974.dtsi
>>>>> b/arch/arm/boot/dts/qcom-msm8974.dtsi new file mode 100644 
>>>>> index 0000000..f04b643 --- /dev/null +++
>>>>> b/arch/arm/boot/dts/qcom-msm8974.dtsi @@ -0,0 +1,35 @@ 
>>>>> +/dts-v1/; + +/include/ "skeleton.dtsi" + +/ { +    model =
>>>>> "Qualcomm MSM8974"; +    compatible = "qcom,msm8974"; +
>>>>> interrupt-parent = <&intc>; + +    soc: soc { };
>>>>>>> We should have a unit address here:
>>>>>>> 
>>>>>>> soc: soc at FOOBAR {
>>>>>>> 
>>>>>>> also, split out the curly braces so any future patches do
>>>>>>> have to muck with that.
>>>>>>> 
>>>>>>> };
>>>>>>> 
>>>>>> Im not sure I understand the reasoning behind the unit
>>>>>> address for soc ?
>>>>> Its fairly standard practice and there is a fair amount of
>>>>> discussion about the lack of a unit address for memory nodes.
>>>>> 
>>>> That still doesn't really answer anything :) - and I couldn't
>>>> find any discussions about this either. I don't see anybody in
>>>> upstream adding an address to soc except sun. What is that
>>>> address supposed to be for - what does it mean ? The soc is way
>>>> of encapsulating meaningful blocks  for the particular SoC.
>>> 
>>> I see the mail from Stephen Warren for adding a check stating that
>>> 
>>> "ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that
>>> any node that has a reg property must include a unit address in its
>>> name with value matching the first entry in its reg property.
>>> Conversely, if a node does not have a reg property, the node name
>>> must not include a unit address."
>>> 
>>> The soc node we have does not have a reg property ?
>> 
>> Not 100% sure what people will decide on this.  There are a number of
>> examples on the PPC side (arch/powerpc/boot/dts) that are soc at ADDR,
>> but they don't typically have "reg" properties at the soc level.
> 
> No, but you may have a ranges property which is related.
> 
> I've just hit this on highbank in needing to add a second bank of
> peripherals for midway. So my vote would be to have unit address.
> 
> Rob

So are we saying the rule for needing a unit-address being either 'reg' or 'ranges' ?

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation