linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
@ 2015-03-04 21:13 Kumar Gala
  2015-03-04 21:13 ` [PATCH v2 2/3] arm64: qcom: Add support for Qualcomm MSM8916 SoC Kumar Gala
                   ` (3 more replies)
  0 siblings, 4 replies; 28+ messages in thread
From: Kumar Gala @ 2015-03-04 21:13 UTC (permalink / raw)
  To: linux-arm-msm
  Cc: Kumar Gala, linux-arm-kernel, linux-kernel, arm, devicetree, heiko

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
on Qualcomm MSM platforms to determine which device tree should be
utilized and passed to the kernel.

Cc: <devicetree@vger.kernel.org>
Signed-off-by: Kumar Gala <galak@codeaurora.org>
---
 Documentation/devicetree/bindings/arm/msm/ids.txt | 65 +++++++++++++++++++++++
 include/dt-bindings/arm/qcom-ids.h                | 33 ++++++++++++
 2 files changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/ids.txt
 create mode 100644 include/dt-bindings/arm/qcom-ids.h

diff --git a/Documentation/devicetree/bindings/arm/msm/ids.txt b/Documentation/devicetree/bindings/arm/msm/ids.txt
new file mode 100644
index 0000000..9ee8428
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/ids.txt
@@ -0,0 +1,65 @@
+* MSM-ID
+
+The qcom,msm-id entry specifies the MSM chipset and hardware revision.  It can
+optionally be an array of these to indicate multiple hardware that use the same
+device tree.  It is expected that the bootloader will use this information at
+boot-up to decide which device tree to use when given multiple device trees,
+some of which may not be compatible with the actual hardware.  It is the
+bootloader's responsibility to pass the correct device tree to the kernel.
+
+PROPERTIES
+
+- qcom,msm-id:
+	Usage: required
+	Value type: <prop-encoded-array> (<chipset_id, rev_id> [, <c2, r2> ..])
+	Definition:
+		The "chipset_id" consists of three fields as below:
+
+		bits 0-15  = The unique MSM chipset id.
+		bits 16-31 = Reserved.  Should be 0
+
+		chipset_id is an exact match value
+
+		The "rev_id" is a chipset specific 32-bit id that represents
+		the version of the chipset.
+
+		The rev_id is a best match id.  The bootloader will look for
+		the closest possible patch.
+
+* BOARD-ID
+
+The qcom,board-id entry specifies the board type and revision information.  It
+can optionally be an array of these to indicate multiple boards that use the
+same device tree.  It is expected that the bootloader will use this information
+at boot-up to decide which device tree to use when given multiple device trees,
+some of which may not be compatible with the actual hardware.  It is the
+bootloader's responsibility to pass the correct device tree to the kernel.
+
+PROPERTIES
+
+- qcom,board-id:
+	Usage: required
+	Value type: <prop-encoded-array> (<board_id, subtype_id> [, <b2, s2> ..])
+	Definition:
+		The "board_id" consists of three fields as below:
+
+		bits 31-24 = Unusued.
+		bits 23-16 = Platform Version Major
+		bits 15-8  = Platfrom Version Minor
+		bits 7-0   = Platform Type
+
+		Platform Type field is an exact match value.  The Platform
+		Major/Minor field is a best match.  The bootloader will look
+		for the closest possible match.
+
+		The "subtype_id" is unique to a Platform Type/Chipset ID.  For
+		a given Platform Type, there will typically only be a single
+		board and the subtype_id will be 0.  However in some cases board
+		variants may need to be distinquished by different subtype_id
+		values.
+
+		subtype_id is an exact match value.
+
+EXAMPLE:
+	qcom,board-id = <15 2>;
+	qcom,msm-id = <0x1007e 0>;
diff --git a/include/dt-bindings/arm/qcom-ids.h b/include/dt-bindings/arm/qcom-ids.h
new file mode 100644
index 0000000..a18f34e
--- /dev/null
+++ b/include/dt-bindings/arm/qcom-ids.h
@@ -0,0 +1,33 @@
+/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#ifndef __DT_BINDINGS_QCOM_IDS_H
+#define __DT_BINDINGS_QCOM_IDS_H
+
+/* qcom,msm-id */
+#define QCOM_ID_MSM8916		206
+#define QCOM_ID_APQ8016		247
+#define QCOM_ID_MSM8216		248
+#define QCOM_ID_MSM8116		249
+#define QCOM_ID_MSM8616		250
+
+/* qcom,board-id */
+#define QCOM_BRD_ID(a, major, minor) \
+	(((major & 0xff) << 16) | ((minor & 0xff) << 8) | QCOM_BRD_ID_##a)
+
+#define QCOM_BRD_ID_MTP		8
+#define QCOM_BRD_ID_DRAGONBRD	10
+#define QCOM_BRD_ID_SBC		24
+
+#define QCOM_BRD_SUBTYPE_DEFAULT		0
+#define QCOM_BRD_SUBTYPE_MTP8916_SMB1360	1
+
+#endif
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v2 2/3] arm64: qcom: Add support for Qualcomm MSM8916 SoC
  2015-03-04 21:13 [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id Kumar Gala
@ 2015-03-04 21:13 ` Kumar Gala
  2015-03-04 22:33   ` Stephen Boyd
  2015-03-04 21:13 ` [PATCH v2 3/3] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts Kumar Gala
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 28+ messages in thread
From: Kumar Gala @ 2015-03-04 21:13 UTC (permalink / raw)
  To: linux-arm-msm
  Cc: Abhimanyu Kapur, linux-arm-kernel, linux-kernel, arm, devicetree,
	heiko, Kumar Gala

From: Abhimanyu Kapur <abhimany@codeaurora.org>

Add support for Qualcomm MSM8916 SoC in arm64 Kconfig and defconfig.
Enable MSM8916 clock, pin control, and MSM serial driver utilized by
MSM8916 and Qualcomm SoCs in general.

Signed-off-by: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Abhimanyu Kapur <abhimany@codeaurora.org>
---
v2:
* Dropped CONFIG_ARCH_QCOM_MSM8916, just use CONFIG_ARCH_QCOM
* Updated defconfig related to dropping CONFIG_ARCH_QCOM_MSM8916

 arch/arm64/Kconfig           | 9 +++++++++
 arch/arm64/configs/defconfig | 5 +++++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1b8e973..4c8b119 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -177,6 +177,15 @@ config ARCH_MEDIATEK
 	help
 	  Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
 
+config ARCH_QCOM
+	bool "Qualcomm Platforms"
+	select ARCH_REQUIRE_GPIOLIB
+	select COMMON_CLK_QCOM
+	select PINCTRL
+	select SOC_BUS
+	help
+	  This enables support for the ARMv8 based Qualcomm chipsets.
+
 config ARCH_SEATTLE
 	bool "AMD Seattle SoC Family"
 	help
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index be1f12a..913bcb1 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -33,6 +33,7 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_IOSCHED_DEADLINE is not set
 CONFIG_ARCH_FSL_LS2085A=y
 CONFIG_ARCH_MEDIATEK=y
+CONFIG_ARCH_QCOM=y
 CONFIG_ARCH_THUNDER=y
 CONFIG_ARCH_VEXPRESS=y
 CONFIG_ARCH_XGENE=y
@@ -93,11 +94,14 @@ CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_MT6577=y
 CONFIG_SERIAL_AMBA_PL011=y
 CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_SERIAL_MSM=y
+CONFIG_SERIAL_MSM_CONSOLE=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_VIRTIO_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 CONFIG_SPI=y
 CONFIG_SPI_PL022=y
+CONFIG_PINCTRL_MSM8916=y
 CONFIG_GPIO_PL061=y
 CONFIG_GPIO_XGENE=y
 # CONFIG_HWMON is not set
@@ -127,6 +131,7 @@ CONFIG_RTC_DRV_EFI=y
 CONFIG_RTC_DRV_XGENE=y
 CONFIG_VIRTIO_BALLOON=y
 CONFIG_VIRTIO_MMIO=y
+CONFIG_MSM_GCC_8916=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_PHY_XGENE=y
 CONFIG_EXT2_FS=y
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v2 3/3] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts
  2015-03-04 21:13 [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id Kumar Gala
  2015-03-04 21:13 ` [PATCH v2 2/3] arm64: qcom: Add support for Qualcomm MSM8916 SoC Kumar Gala
@ 2015-03-04 21:13 ` Kumar Gala
  2015-03-04 21:19 ` [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id Arnd Bergmann
  2015-03-05 19:42 ` Kevin Hilman
  3 siblings, 0 replies; 28+ messages in thread
From: Kumar Gala @ 2015-03-04 21:13 UTC (permalink / raw)
  To: linux-arm-msm
  Cc: Kumar Gala, linux-arm-kernel, linux-kernel, arm, devicetree, heiko

Add initial device tree support for Qualcomm MSM8916 SoC and MTP8916
evaluation board.  At the current time we only boot up a single processor.

Signed-off-by: Kumar Gala <galak@codeaurora.org>
---
v2:
* Updated to dropping CONFIG_ARCH_QCOM_MSM8916
* Updated to use qcom-ids.h

 arch/arm64/boot/dts/Makefile              |   1 +
 arch/arm64/boot/dts/qcom/Makefile         |   5 +
 arch/arm64/boot/dts/qcom/msm8916-mtp.dts  |  23 ++++
 arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi |  24 ++++
 arch/arm64/boot/dts/qcom/msm8916.dtsi     | 189 ++++++++++++++++++++++++++++++
 5 files changed, 242 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/Makefile
 create mode 100644 arch/arm64/boot/dts/qcom/msm8916-mtp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/msm8916.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index e0350ca..8517f15 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -5,5 +5,6 @@ dts-dirs += cavium
 dts-dirs += exynos
 dts-dirs += freescale
 dts-dirs += mediatek
+dts-dirs += qcom
 
 subdir-y	:= $(dts-dirs)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
new file mode 100644
index 0000000..360ec4c
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_QCOM)	+= msm8916-mtp.dtb
+
+always		:= $(dtb-y)
+subdir-y	:= $(dts-dirs)
+clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dts b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
new file mode 100644
index 0000000..557104e
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
@@ -0,0 +1,23 @@
+/* Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 and
+* only version 2 as published by the Free Software Foundation.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+* GNU General Public License for more details.
+*/
+
+/dts-v1/;
+
+#include <dt-bindings/arm/qcom-ids.h>
+#include "msm8916-mtp.dtsi"
+
+/ {
+	model = "Qualcomm Technologies, Inc. MSM 8916 MTP";
+	compatible = "qcom,msm8916-mtp", "qcom,msm8916", "qcom,mtp";
+	qcom,board-id = <QCOM_BRD_ID(MTP, 1, 0) QCOM_BRD_SUBTYPE_DEFAULT>,
+			<QCOM_BRD_ID(MTP, 1, 0) QCOM_BRD_SUBTYPE_MTP8916_SMB1360>;
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi b/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
new file mode 100644
index 0000000..4d2f073
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
@@ -0,0 +1,24 @@
+/* Copyright (c) 2014-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "msm8916.dtsi"
+
+/ {
+	soc {
+		serial@78b0000 {
+			status = "okay";
+			pinctrl-names = "default", "sleep";
+			pinctrl-0 = <&blsp1_uart2_default>;
+			pinctrl-1 = <&blsp1_uart2_sleep>;
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
new file mode 100644
index 0000000..41f1c0f
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -0,0 +1,189 @@
+/* Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "skeleton.dtsi"
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/qcom,gcc-msm8916.h>
+#include <dt-bindings/reset/qcom,gcc-msm8916.h>
+#include <dt-bindings/arm/qcom-ids.h>
+
+/ {
+	model = "Qualcomm Technologies, Inc. MSM8916";
+	compatible = "qcom,msm8916";
+	qcom,msm-id =	<QCOM_ID_MSM8916 0>,
+			<QCOM_ID_MSM8216 0>,
+			<QCOM_ID_MSM8116 0>,
+			<QCOM_ID_MSM8616 0>;
+
+	interrupt-parent = <&intc>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		CPU0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0>;
+		};
+
+		CPU1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x1>;
+		};
+
+		CPU2: cpu@2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x2>;
+		};
+
+		CPU3: cpu@3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x3>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <GIC_PPI 2 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 3 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 4 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 1 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+		clock-frequency = <19200000>;
+	};
+
+	soc: soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0 0 0xffffffff>;
+		compatible = "simple-bus";
+
+		pinctrl@1000000 {
+			compatible = "qcom,msm8916-pinctrl";
+			reg = <0x1000000 0x300000>;
+			interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+
+			blsp1_uart2_default: blsp1_uart2_default {
+				pinmux {
+					function = "blsp_uart2";
+					pins = "gpio4", "gpio5";
+				};
+				pinconf {
+					pins = "gpio4", "gpio5";
+					drive-strength = <16>;
+					bias-disable;
+				};
+			};
+
+			blsp1_uart2_sleep: blsp1_uart2_sleep {
+				pinmux {
+					function = "blsp_uart2";
+					pins = "gpio4", "gpio5";
+				};
+				pinconf {
+					pins = "gpio4", "gpio5";
+					drive-strength = <2>;
+					bias-pull-down;
+				};
+			};
+		};
+
+		gcc: qcom,gcc@1800000 {
+			compatible = "qcom,gcc-msm8916";
+			#clock-cells = <1>;
+			#reset-cells = <1>;
+			reg = <0x1800000 0x80000>;
+		};
+
+		blsp1_uart2: serial@78b0000 {
+			compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+			reg = <0x78b0000 0x200>;
+			interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&gcc GCC_BLSP1_UART2_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>;
+			clock-names = "core", "iface";
+			status = "disabled";
+		};
+
+		intc: interrupt-controller@b000000 {
+			compatible = "qcom,msm-qgic2";
+			interrupt-controller;
+			#interrupt-cells = <3>;
+			reg = <0x0b000000 0x1000>, <0x0b002000 0x1000>;
+		};
+
+		timer@b020000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+			compatible = "arm,armv7-timer-mem";
+			reg = <0xb020000 0x1000>;
+			clock-frequency = <19200000>;
+
+			frame@b021000 {
+				frame-number = <0>;
+				interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+				reg = <0xb021000 0x1000>,
+				      <0xb022000 0x1000>;
+			};
+
+			frame@b023000 {
+				frame-number = <1>;
+				interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+				reg = <0xb023000 0x1000>;
+				status = "disabled";
+			};
+
+			frame@b024000 {
+				frame-number = <2>;
+				interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+				reg = <0xb024000 0x1000>;
+				status = "disabled";
+			};
+
+			frame@b025000 {
+				frame-number = <3>;
+				interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+				reg = <0xb025000 0x1000>;
+				status = "disabled";
+			};
+
+			frame@b026000 {
+				frame-number = <4>;
+				interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+				reg = <0xb026000 0x1000>;
+				status = "disabled";
+			};
+
+			frame@b027000 {
+				frame-number = <5>;
+				interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+				reg = <0xb027000 0x1000>;
+				status = "disabled";
+			};
+
+			frame@b028000 {
+				frame-number = <6>;
+				interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+				reg = <0xb028000 0x1000>;
+				status = "disabled";
+			};
+		};
+	};
+};
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-04 21:13 [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id Kumar Gala
  2015-03-04 21:13 ` [PATCH v2 2/3] arm64: qcom: Add support for Qualcomm MSM8916 SoC Kumar Gala
  2015-03-04 21:13 ` [PATCH v2 3/3] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts Kumar Gala
@ 2015-03-04 21:19 ` Arnd Bergmann
  2015-03-04 21:22   ` Kumar Gala
  2015-03-05 19:42 ` Kevin Hilman
  3 siblings, 1 reply; 28+ messages in thread
From: Arnd Bergmann @ 2015-03-04 21:19 UTC (permalink / raw)
  To: Kumar Gala
  Cc: linux-arm-msm, linux-arm-kernel, linux-kernel, arm, devicetree, heiko

On Wednesday 04 March 2015 15:13:20 Kumar Gala wrote:
> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
> on Qualcomm MSM platforms to determine which device tree should be
> utilized and passed to the kernel.
> 
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Kumar Gala <galak@codeaurora.org>

This seems to duplicate the root-node compatible strings for no particular
reason, with a less flexible format. I think it would be better to fix
the boot loader.

	Arnd

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-04 21:19 ` [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id Arnd Bergmann
@ 2015-03-04 21:22   ` Kumar Gala
  0 siblings, 0 replies; 28+ messages in thread
From: Kumar Gala @ 2015-03-04 21:22 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arm-msm, linux-arm-kernel, linux-kernel, arm, devicetree, heiko


On Mar 4, 2015, at 3:19 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> On Wednesday 04 March 2015 15:13:20 Kumar Gala wrote:
>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>> on Qualcomm MSM platforms to determine which device tree should be
>> utilized and passed to the kernel.
>> 
>> Cc: <devicetree@vger.kernel.org>
>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
> 
> This seems to duplicate the root-node compatible strings for no particular
> reason, with a less flexible format. I think it would be better to fix
> the boot loader.

While I wish that was an option, this is a solution that has been shipping on MSM platforms and phones for some time.

- k

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 2/3] arm64: qcom: Add support for Qualcomm MSM8916 SoC
  2015-03-04 21:13 ` [PATCH v2 2/3] arm64: qcom: Add support for Qualcomm MSM8916 SoC Kumar Gala
@ 2015-03-04 22:33   ` Stephen Boyd
  2015-03-05 15:06     ` Kumar Gala
  0 siblings, 1 reply; 28+ messages in thread
From: Stephen Boyd @ 2015-03-04 22:33 UTC (permalink / raw)
  To: Kumar Gala, linux-arm-msm
  Cc: Abhimanyu Kapur, linux-arm-kernel, linux-kernel, arm, devicetree, heiko

On 03/04/15 13:13, Kumar Gala wrote:
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 1b8e973..4c8b119 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -177,6 +177,15 @@ config ARCH_MEDIATEK
>  	help
>  	  Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
>  
> +config ARCH_QCOM
> +	bool "Qualcomm Platforms"
> +	select ARCH_REQUIRE_GPIOLIB
> +	select COMMON_CLK_QCOM
> +	select PINCTRL
> +	select SOC_BUS

I imagine all we need is select PINCTRL here. SOC_BUS is not used, also
we shouldn't force COMMON_CLK_QCOM to be Y instead of M so please drop
that select. Also we dropped ARCH_REQUIRE_GPIOLIB in arm32 so it would
match if we just relied on ARCH_WANT_GPIOLIB that arm64 has by default

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 2/3] arm64: qcom: Add support for Qualcomm MSM8916 SoC
  2015-03-04 22:33   ` Stephen Boyd
@ 2015-03-05 15:06     ` Kumar Gala
  2015-03-05 16:03       ` Stephen Boyd
  0 siblings, 1 reply; 28+ messages in thread
From: Kumar Gala @ 2015-03-05 15:06 UTC (permalink / raw)
  To: Stephen Boyd
  Cc: linux-arm-msm, Abhimanyu Kapur, linux-arm-kernel, linux-kernel,
	arm, devicetree, heiko


On Mar 4, 2015, at 4:33 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:

> On 03/04/15 13:13, Kumar Gala wrote:
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 1b8e973..4c8b119 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -177,6 +177,15 @@ config ARCH_MEDIATEK
>> 	help
>> 	  Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
>> 
>> +config ARCH_QCOM
>> +	bool "Qualcomm Platforms"
>> +	select ARCH_REQUIRE_GPIOLIB
>> +	select COMMON_CLK_QCOM
>> +	select PINCTRL
>> +	select SOC_BUS
> 
> I imagine all we need is select PINCTRL here. SOC_BUS is not used, also
> we shouldn't force COMMON_CLK_QCOM to be Y instead of M so please drop
> that select. Also we dropped ARCH_REQUIRE_GPIOLIB in arm32 so it would
> match if we just relied on ARCH_WANT_GPIOLIB that arm64 has by default

Will drop SOC_BUS.  We seem to have other arm64 platforms that set ARCH_REQUIRE_GPIOLIB.  Why should we not select COMMON_CLK_QCOM?  Can we do much useful without COMMON_CLK_QCOM set?

- k

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 2/3] arm64: qcom: Add support for Qualcomm MSM8916 SoC
  2015-03-05 15:06     ` Kumar Gala
@ 2015-03-05 16:03       ` Stephen Boyd
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Boyd @ 2015-03-05 16:03 UTC (permalink / raw)
  To: Kumar Gala
  Cc: linux-arm-msm, Abhimanyu Kapur, linux-arm-kernel, linux-kernel,
	arm, devicetree, heiko

On 03/05, Kumar Gala wrote:
> 
> On Mar 4, 2015, at 4:33 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> 
> > On 03/04/15 13:13, Kumar Gala wrote:
> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> >> index 1b8e973..4c8b119 100644
> >> --- a/arch/arm64/Kconfig
> >> +++ b/arch/arm64/Kconfig
> >> @@ -177,6 +177,15 @@ config ARCH_MEDIATEK
> >> 	help
> >> 	  Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
> >> 
> >> +config ARCH_QCOM
> >> +	bool "Qualcomm Platforms"
> >> +	select ARCH_REQUIRE_GPIOLIB
> >> +	select COMMON_CLK_QCOM
> >> +	select PINCTRL
> >> +	select SOC_BUS
> > 
> > I imagine all we need is select PINCTRL here. SOC_BUS is not used, also
> > we shouldn't force COMMON_CLK_QCOM to be Y instead of M so please drop
> > that select. Also we dropped ARCH_REQUIRE_GPIOLIB in arm32 so it would
> > match if we just relied on ARCH_WANT_GPIOLIB that arm64 has by default
> 
> Will drop SOC_BUS.  We seem to have other arm64 platforms that set ARCH_REQUIRE_GPIOLIB.  Why should we not select COMMON_CLK_QCOM?  Can we do much useful without COMMON_CLK_QCOM set?
> 

For gpiolib I was trying to say that it would match what we did
for ARCH_QCOM on arm32. The same is true for COMMON_CLK_QCOM.

We don't select these configs because they aren't required to
boot into a ramdisk that contains the clock driver and gpiolib
framework plus whatever disk driver and filesystem we may need to
access the (presumably) much larger disk that contains the rest
of the modules.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-04 21:13 [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id Kumar Gala
                   ` (2 preceding siblings ...)
  2015-03-04 21:19 ` [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id Arnd Bergmann
@ 2015-03-05 19:42 ` Kevin Hilman
  2015-03-05 20:23   ` Kumar Gala
  3 siblings, 1 reply; 28+ messages in thread
From: Kevin Hilman @ 2015-03-05 19:42 UTC (permalink / raw)
  To: Kumar Gala
  Cc: linux-arm-msm, linux-arm-kernel, linux-kernel, arm, devicetree, heiko

Kumar Gala <galak@codeaurora.org> writes:

> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
> on Qualcomm MSM platforms to determine which device tree should be
> utilized and passed to the kernel.
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Kumar Gala <galak@codeaurora.org>

Is this the special magic that allows qcom bootloaders to take a kernel
plus multiple DTBs and figure out which DTB to pass?

Kevin

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-05 19:42 ` Kevin Hilman
@ 2015-03-05 20:23   ` Kumar Gala
  2015-03-06  1:59     ` Olof Johansson
  0 siblings, 1 reply; 28+ messages in thread
From: Kumar Gala @ 2015-03-05 20:23 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: linux-arm-msm, linux-arm-kernel, linux-kernel, arm, devicetree, heiko


On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote:

> Kumar Gala <galak@codeaurora.org> writes:
> 
>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>> on Qualcomm MSM platforms to determine which device tree should be
>> utilized and passed to the kernel.
>> 
>> Cc: <devicetree@vger.kernel.org>
>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
> 
> Is this the special magic that allows qcom bootloaders to take a kernel
> plus multiple DTBs and figure out which DTB to pass?
> 
> Kevin

yes

- k

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-05 20:23   ` Kumar Gala
@ 2015-03-06  1:59     ` Olof Johansson
  2015-03-06  2:28       ` Rob Clark
  2015-03-06 16:08       ` Kumar Gala
  0 siblings, 2 replies; 28+ messages in thread
From: Olof Johansson @ 2015-03-06  1:59 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Kevin Hilman, linux-arm-msm, linux-arm-kernel, linux-kernel, arm,
	devicetree, Heiko Stübner

On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote:
>
>> Kumar Gala <galak@codeaurora.org> writes:
>>
>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>>> on Qualcomm MSM platforms to determine which device tree should be
>>> utilized and passed to the kernel.
>>>
>>> Cc: <devicetree@vger.kernel.org>
>>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
>>
>> Is this the special magic that allows qcom bootloaders to take a kernel
>> plus multiple DTBs and figure out which DTB to pass?
>>
>> Kevin
>
> yes

That's a bummer.

Luckily, the solution for upstream is still quite simple: Provide only
one devicetree, and it'll be used, right?


-Olof

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-06  1:59     ` Olof Johansson
@ 2015-03-06  2:28       ` Rob Clark
       [not found]         ` <CAF6AEGssMoo6c3nf_7fcATwocuETGZ8nbpGQpUO=KcKWC+rvHw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2015-03-06 16:08       ` Kumar Gala
  1 sibling, 1 reply; 28+ messages in thread
From: Rob Clark @ 2015-03-06  2:28 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Kumar Gala, Kevin Hilman, linux-arm-msm, linux-arm-kernel,
	linux-kernel, arm, devicetree, Heiko Stübner

On Thu, Mar 5, 2015 at 8:59 PM, Olof Johansson <olof@lixom.net> wrote:
> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote:
>>
>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote:
>>
>>> Kumar Gala <galak@codeaurora.org> writes:
>>>
>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>>>> on Qualcomm MSM platforms to determine which device tree should be
>>>> utilized and passed to the kernel.
>>>>
>>>> Cc: <devicetree@vger.kernel.org>
>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
>>>
>>> Is this the special magic that allows qcom bootloaders to take a kernel
>>> plus multiple DTBs and figure out which DTB to pass?
>>>
>>> Kevin
>>
>> yes
>
> That's a bummer.
>
> Luckily, the solution for upstream is still quite simple: Provide only
> one devicetree, and it'll be used, right?
>

I never managed to figure out how to get that to work (at least on my
apq8074 dragonboard.. fortunately ifc6540 seems to work w/ appended
dtb).. kind of a pita because it is a bit of a non-standard boot.img
format too..

Otoh getting an upstream (or even different kernel) kernel working can
be hard enough as-is on random different tablet/phone/etc.  Why not
make whoever tries' life a bit easier by allowing some nonsense node
into the qcom dtbs which makes it compatible w/ bootloaders already
out there in the field ;-)

BR,
-R

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
       [not found]         ` <CAF6AEGssMoo6c3nf_7fcATwocuETGZ8nbpGQpUO=KcKWC+rvHw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2015-03-06 15:09           ` Christopher Covington
  0 siblings, 0 replies; 28+ messages in thread
From: Christopher Covington @ 2015-03-06 15:09 UTC (permalink / raw)
  To: Rob Clark, Olof Johansson
  Cc: Kumar Gala, Kevin Hilman, linux-arm-msm,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, arm-DgEjT+Ai2ygdnm+yROfE0A,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner

On 03/05/2015 09:28 PM, Rob Clark wrote:
> On Thu, Mar 5, 2015 at 8:59 PM, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
>> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>>>
>>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>>
>>>> Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> writes:
>>>>
>>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>>>>> on Qualcomm MSM platforms to determine which device tree should be
>>>>> utilized and passed to the kernel.
>>>>>
>>>>> Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>>>>> Signed-off-by: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>>>
>>>> Is this the special magic that allows qcom bootloaders to take a kernel
>>>> plus multiple DTBs and figure out which DTB to pass?
>>>>
>>>> Kevin
>>>
>>> yes
>>
>> That's a bummer.
>>
>> Luckily, the solution for upstream is still quite simple: Provide only
>> one devicetree, and it'll be used, right?
>>
> 
> I never managed to figure out how to get that to work (at least on my
> apq8074 dragonboard.. fortunately ifc6540 seems to work w/ appended
> dtb).. kind of a pita because it is a bit of a non-standard boot.img
> format too..

I think you're talking about the boot flow from plain poweron which I wish I
knew more about, but in case it's any help, here are some fastboot boot steps
what worked for me a while back.

http://elinux.org/Dragonboard/APQ8074

Chris

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-06  1:59     ` Olof Johansson
  2015-03-06  2:28       ` Rob Clark
@ 2015-03-06 16:08       ` Kumar Gala
  2015-03-06 19:15         ` Olof Johansson
  1 sibling, 1 reply; 28+ messages in thread
From: Kumar Gala @ 2015-03-06 16:08 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Kevin Hilman, linux-arm-msm, linux-arm-kernel, linux-kernel, arm,
	devicetree, Heiko Stübner


On Mar 5, 2015, at 7:59 PM, Olof Johansson <olof@lixom.net> wrote:

> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote:
>> 
>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote:
>> 
>>> Kumar Gala <galak@codeaurora.org> writes:
>>> 
>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>>>> on Qualcomm MSM platforms to determine which device tree should be
>>>> utilized and passed to the kernel.
>>>> 
>>>> Cc: <devicetree@vger.kernel.org>
>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
>>> 
>>> Is this the special magic that allows qcom bootloaders to take a kernel
>>> plus multiple DTBs and figure out which DTB to pass?
>>> 
>>> Kevin
>> 
>> yes
> 
> That's a bummer.
> 
> Luckily, the solution for upstream is still quite simple: Provide only
> one devicetree, and it'll be used, right?

We can provide only one, we still need the IDs in the DT.

- k
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-06 16:08       ` Kumar Gala
@ 2015-03-06 19:15         ` Olof Johansson
  2015-03-06 20:37           ` Kumar Gala
  0 siblings, 1 reply; 28+ messages in thread
From: Olof Johansson @ 2015-03-06 19:15 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Kevin Hilman, linux-arm-msm, linux-arm-kernel, linux-kernel, arm,
	devicetree, Heiko Stübner

On Fri, Mar 6, 2015 at 8:08 AM, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Mar 5, 2015, at 7:59 PM, Olof Johansson <olof@lixom.net> wrote:
>
>> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote:
>>>
>>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote:
>>>
>>>> Kumar Gala <galak@codeaurora.org> writes:
>>>>
>>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>>>>> on Qualcomm MSM platforms to determine which device tree should be
>>>>> utilized and passed to the kernel.
>>>>>
>>>>> Cc: <devicetree@vger.kernel.org>
>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
>>>>
>>>> Is this the special magic that allows qcom bootloaders to take a kernel
>>>> plus multiple DTBs and figure out which DTB to pass?
>>>>
>>>> Kevin
>>>
>>> yes
>>
>> That's a bummer.
>>
>> Luckily, the solution for upstream is still quite simple: Provide only
>> one devicetree, and it'll be used, right?
>
> We can provide only one, we still need the IDs in the DT.

How are the DTS provided? Concatenated with the kernel, or in a
wrapped data format? Or in a separate partition from the kernel?


-Olof

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-06 19:15         ` Olof Johansson
@ 2015-03-06 20:37           ` Kumar Gala
  2015-03-09 12:11             ` Arnd Bergmann
  0 siblings, 1 reply; 28+ messages in thread
From: Kumar Gala @ 2015-03-06 20:37 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Kevin Hilman, linux-arm-msm, linux-arm-kernel, linux-kernel, arm,
	devicetree, Heiko Stübner


On Mar 6, 2015, at 1:15 PM, Olof Johansson <olof@lixom.net> wrote:

> On Fri, Mar 6, 2015 at 8:08 AM, Kumar Gala <galak@codeaurora.org> wrote:
>> 
>> On Mar 5, 2015, at 7:59 PM, Olof Johansson <olof@lixom.net> wrote:
>> 
>>> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote:
>>>> 
>>>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote:
>>>> 
>>>>> Kumar Gala <galak@codeaurora.org> writes:
>>>>> 
>>>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>>>>>> on Qualcomm MSM platforms to determine which device tree should be
>>>>>> utilized and passed to the kernel.
>>>>>> 
>>>>>> Cc: <devicetree@vger.kernel.org>
>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
>>>>> 
>>>>> Is this the special magic that allows qcom bootloaders to take a kernel
>>>>> plus multiple DTBs and figure out which DTB to pass?
>>>>> 
>>>>> Kevin
>>>> 
>>>> yes
>>> 
>>> That's a bummer.
>>> 
>>> Luckily, the solution for upstream is still quite simple: Provide only
>>> one devicetree, and it'll be used, right?
>> 
>> We can provide only one, we still need the IDs in the DT.
> 
> How are the DTS provided? Concatenated with the kernel, or in a
> wrapped data format? Or in a separate partition from the kernel?

Its a wrapped data format that is than concatenated with the kernel if I remember correctly.

- k

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-06 20:37           ` Kumar Gala
@ 2015-03-09 12:11             ` Arnd Bergmann
  2015-03-10 17:13               ` Kumar Gala
  0 siblings, 1 reply; 28+ messages in thread
From: Arnd Bergmann @ 2015-03-09 12:11 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Olof Johansson, Kevin Hilman, linux-arm-msm, linux-arm-kernel,
	linux-kernel, arm, devicetree, Heiko Stübner

On Friday 06 March 2015 14:37:52 Kumar Gala wrote:
> On Mar 6, 2015, at 1:15 PM, Olof Johansson <olof@lixom.net> wrote:
> 
> > On Fri, Mar 6, 2015 at 8:08 AM, Kumar Gala <galak@codeaurora.org> wrote:
> >> 
> >> On Mar 5, 2015, at 7:59 PM, Olof Johansson <olof@lixom.net> wrote:
> >> 
> >>> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote:
> >>>> 
> >>>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote:
> >>>> 
> >>>>> Kumar Gala <galak@codeaurora.org> writes:
> >>>>> 
> >>>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
> >>>>>> on Qualcomm MSM platforms to determine which device tree should be
> >>>>>> utilized and passed to the kernel.
> >>>>>> 
> >>>>>> Cc: <devicetree@vger.kernel.org>
> >>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
> >>>>> 
> >>>>> Is this the special magic that allows qcom bootloaders to take a kernel
> >>>>> plus multiple DTBs and figure out which DTB to pass?
> >>>>> 
> >>>>> Kevin
> >>>> 
> >>>> yes
> >>> 
> >>> That's a bummer.
> >>> 
> >>> Luckily, the solution for upstream is still quite simple: Provide only
> >>> one devicetree, and it'll be used, right?
> >> 
> >> We can provide only one, we still need the IDs in the DT.
> > 
> > How are the DTS provided? Concatenated with the kernel, or in a
> > wrapped data format? Or in a separate partition from the kernel?
> 
> Its a wrapped data format that is than concatenated with the kernel if I remember correctly.

Then you should be able to create a tool that can write this concatenated
format and insert these properties from a table that matches the boot
loader, right?

	Arnd

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-09 12:11             ` Arnd Bergmann
@ 2015-03-10 17:13               ` Kumar Gala
       [not found]                 ` <F5017A7F-0EA2-41B3-A9DD-6123CCFD36FA-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
  0 siblings, 1 reply; 28+ messages in thread
From: Kumar Gala @ 2015-03-10 17:13 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Olof Johansson, Kevin Hilman, linux-arm-msm, linux-arm-kernel,
	linux-kernel, arm, devicetree, Heiko Stübner


On Mar 9, 2015, at 7:11 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> On Friday 06 March 2015 14:37:52 Kumar Gala wrote:
>> On Mar 6, 2015, at 1:15 PM, Olof Johansson <olof@lixom.net> wrote:
>> 
>>> On Fri, Mar 6, 2015 at 8:08 AM, Kumar Gala <galak@codeaurora.org> wrote:
>>>> 
>>>> On Mar 5, 2015, at 7:59 PM, Olof Johansson <olof@lixom.net> wrote:
>>>> 
>>>>> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote:
>>>>>> 
>>>>>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote:
>>>>>> 
>>>>>>> Kumar Gala <galak@codeaurora.org> writes:
>>>>>>> 
>>>>>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>>>>>>>> on Qualcomm MSM platforms to determine which device tree should be
>>>>>>>> utilized and passed to the kernel.
>>>>>>>> 
>>>>>>>> Cc: <devicetree@vger.kernel.org>
>>>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
>>>>>>> 
>>>>>>> Is this the special magic that allows qcom bootloaders to take a kernel
>>>>>>> plus multiple DTBs and figure out which DTB to pass?
>>>>>>> 
>>>>>>> Kevin
>>>>>> 
>>>>>> yes
>>>>> 
>>>>> That's a bummer.
>>>>> 
>>>>> Luckily, the solution for upstream is still quite simple: Provide only
>>>>> one devicetree, and it'll be used, right?
>>>> 
>>>> We can provide only one, we still need the IDs in the DT.
>>> 
>>> How are the DTS provided? Concatenated with the kernel, or in a
>>> wrapped data format? Or in a separate partition from the kernel?
>> 
>> Its a wrapped data format that is than concatenated with the kernel if I remember correctly.
> 
> Then you should be able to create a tool that can write this concatenated
> format and insert these properties from a table that matches the boot
> loader, right?
> 
> 	Arnd

Are you suggesting the tool insert the properties in the DT?  I’m not sure I understand what the point of doing that would be.

- k

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
       [not found]                 ` <F5017A7F-0EA2-41B3-A9DD-6123CCFD36FA-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
@ 2015-03-10 17:55                   ` Olof Johansson
  2015-03-10 18:10                     ` Kumar Gala
  0 siblings, 1 reply; 28+ messages in thread
From: Olof Johansson @ 2015-03-10 17:55 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Arnd Bergmann, Kevin Hilman, linux-arm-msm,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, arm-DgEjT+Ai2ygdnm+yROfE0A,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner

On Tue, Mar 10, 2015 at 10:13 AM, Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>
> On Mar 9, 2015, at 7:11 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>
>> On Friday 06 March 2015 14:37:52 Kumar Gala wrote:
>>> On Mar 6, 2015, at 1:15 PM, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
>>>
>>>> On Fri, Mar 6, 2015 at 8:08 AM, Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>>>>>
>>>>> On Mar 5, 2015, at 7:59 PM, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
>>>>>
>>>>>> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak-sgV2jX0FEOJiIJoWrK/4GQ@public.gmane.orgg> wrote:
>>>>>>>
>>>>>>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>>>>>>
>>>>>>>> Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> writes:
>>>>>>>>
>>>>>>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>>>>>>>>> on Qualcomm MSM platforms to determine which device tree should be
>>>>>>>>> utilized and passed to the kernel.
>>>>>>>>>
>>>>>>>>> Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>>>>>>>>> Signed-off-by: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>>>>>>>
>>>>>>>> Is this the special magic that allows qcom bootloaders to take a kernel
>>>>>>>> plus multiple DTBs and figure out which DTB to pass?
>>>>>>>>
>>>>>>>> Kevin
>>>>>>>
>>>>>>> yes
>>>>>>
>>>>>> That's a bummer.
>>>>>>
>>>>>> Luckily, the solution for upstream is still quite simple: Provide only
>>>>>> one devicetree, and it'll be used, right?
>>>>>
>>>>> We can provide only one, we still need the IDs in the DT.
>>>>
>>>> How are the DTS provided? Concatenated with the kernel, or in a
>>>> wrapped data format? Or in a separate partition from the kernel?
>>>
>>> Its a wrapped data format that is than concatenated with the kernel if I remember correctly.
>>
>> Then you should be able to create a tool that can write this concatenated
>> format and insert these properties from a table that matches the boot
>> loader, right?
>>
>>       Arnd
>
> Are you suggesting the tool insert the properties in the DT?  I’m not sure I understand what the point of doing that would be.

To insert platform-local properties that mean nothing outside of the
firmware packaging of the device trees, which is the case here?

I think the idea of having the installer script inserting them is
quite reasonable in this case.


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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-10 17:55                   ` Olof Johansson
@ 2015-03-10 18:10                     ` Kumar Gala
  2015-03-10 19:52                       ` Arnd Bergmann
  0 siblings, 1 reply; 28+ messages in thread
From: Kumar Gala @ 2015-03-10 18:10 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Arnd Bergmann, Kevin Hilman, linux-arm-msm, linux-arm-kernel,
	linux-kernel, arm, devicetree, Heiko Stübner

>>>>>>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>>>>>>>>>> on Qualcomm MSM platforms to determine which device tree should be
>>>>>>>>>> utilized and passed to the kernel.
>>>>>>>>>> 
>>>>>>>>>> Cc: <devicetree@vger.kernel.org>
>>>>>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
>>>>>>>>> 
>>>>>>>>> Is this the special magic that allows qcom bootloaders to take a kernel
>>>>>>>>> plus multiple DTBs and figure out which DTB to pass?
>>>>>>>>> 
>>>>>>>>> Kevin
>>>>>>>> 
>>>>>>>> yes
>>>>>>> 
>>>>>>> That's a bummer.
>>>>>>> 
>>>>>>> Luckily, the solution for upstream is still quite simple: Provide only
>>>>>>> one devicetree, and it'll be used, right?
>>>>>> 
>>>>>> We can provide only one, we still need the IDs in the DT.
>>>>> 
>>>>> How are the DTS provided? Concatenated with the kernel, or in a
>>>>> wrapped data format? Or in a separate partition from the kernel?
>>>> 
>>>> Its a wrapped data format that is than concatenated with the kernel if I remember correctly.
>>> 
>>> Then you should be able to create a tool that can write this concatenated
>>> format and insert these properties from a table that matches the boot
>>> loader, right?
>>> 
>>>      Arnd
>> 
>> Are you suggesting the tool insert the properties in the DT?  I’m not sure I understand what the point of doing that would be.
> 
> To insert platform-local properties that mean nothing outside of the
> firmware packaging of the device trees, which is the case here?
> 
> I think the idea of having the installer script inserting them is
> quite reasonable in this case.
> 
> 
> -Olof

These values are static, so not sure what the point of having the installer script do that?

- k

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-10 18:10                     ` Kumar Gala
@ 2015-03-10 19:52                       ` Arnd Bergmann
  2015-03-10 19:57                         ` Kumar Gala
  2015-03-10 22:01                         ` Rob Clark
  0 siblings, 2 replies; 28+ messages in thread
From: Arnd Bergmann @ 2015-03-10 19:52 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Olof Johansson, Kevin Hilman, linux-arm-msm, linux-arm-kernel,
	linux-kernel, arm, devicetree, Heiko Stübner

On Tuesday 10 March 2015 13:10:08 Kumar Gala wrote:
> >>>>>>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
> >>>>>>>>>> on Qualcomm MSM platforms to determine which device tree should be
> >>>>>>>>>> utilized and passed to the kernel.
> >>>>>>>>>> 
> >>>>>>>>>> Cc: <devicetree@vger.kernel.org>
> >>>>>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
> >>>>>>>>> 
> >>>>>>>>> Is this the special magic that allows qcom bootloaders to take a kernel
> >>>>>>>>> plus multiple DTBs and figure out which DTB to pass?
> >>>>>>>>> 
> >>>>>>>>> Kevin
> >>>>>>>> 
> >>>>>>>> yes
> >>>>>>> 
> >>>>>>> That's a bummer.
> >>>>>>> 
> >>>>>>> Luckily, the solution for upstream is still quite simple: Provide only
> >>>>>>> one devicetree, and it'll be used, right?
> >>>>>> 
> >>>>>> We can provide only one, we still need the IDs in the DT.
> >>>>> 
> >>>>> How are the DTS provided? Concatenated with the kernel, or in a
> >>>>> wrapped data format? Or in a separate partition from the kernel?
> >>>> 
> >>>> Its a wrapped data format that is than concatenated with the kernel if I remember correctly.
> >>> 
> >>> Then you should be able to create a tool that can write this concatenated
> >>> format and insert these properties from a table that matches the boot
> >>> loader, right?
> >>> 
> >>>      Arnd
> >> 
> >> Are you suggesting the tool insert the properties in the DT?  I’m not sure I understand what the point of doing that would be.
> > 
> > To insert platform-local properties that mean nothing outside of the
> > firmware packaging of the device trees, which is the case here?
> > 
> > I think the idea of having the installer script inserting them is
> > quite reasonable in this case.
> > 
> > 
> > -Olof
> 
> These values are static, so not sure what the point of having the installer script do that?
> 

It combines two hacks to work around a nonstandard boot loader.
Once the bootloader is fixed, you can stop using that script.

	Arnd

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-10 19:52                       ` Arnd Bergmann
@ 2015-03-10 19:57                         ` Kumar Gala
  2015-03-11 15:33                           ` Bjorn Andersson
  2015-03-10 22:01                         ` Rob Clark
  1 sibling, 1 reply; 28+ messages in thread
From: Kumar Gala @ 2015-03-10 19:57 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Olof Johansson, Kevin Hilman, linux-arm-msm, linux-arm-kernel,
	linux-kernel, arm, devicetree, Heiko Stübner


On Mar 10, 2015, at 2:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> On Tuesday 10 March 2015 13:10:08 Kumar Gala wrote:
>>>>>>>>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>>>>>>>>>>>> on Qualcomm MSM platforms to determine which device tree should be
>>>>>>>>>>>> utilized and passed to the kernel.
>>>>>>>>>>>> 
>>>>>>>>>>>> Cc: <devicetree@vger.kernel.org>
>>>>>>>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
>>>>>>>>>>> 
>>>>>>>>>>> Is this the special magic that allows qcom bootloaders to take a kernel
>>>>>>>>>>> plus multiple DTBs and figure out which DTB to pass?
>>>>>>>>>>> 
>>>>>>>>>>> Kevin
>>>>>>>>>> 
>>>>>>>>>> yes
>>>>>>>>> 
>>>>>>>>> That's a bummer.
>>>>>>>>> 
>>>>>>>>> Luckily, the solution for upstream is still quite simple: Provide only
>>>>>>>>> one devicetree, and it'll be used, right?
>>>>>>>> 
>>>>>>>> We can provide only one, we still need the IDs in the DT.
>>>>>>> 
>>>>>>> How are the DTS provided? Concatenated with the kernel, or in a
>>>>>>> wrapped data format? Or in a separate partition from the kernel?
>>>>>> 
>>>>>> Its a wrapped data format that is than concatenated with the kernel if I remember correctly.
>>>>> 
>>>>> Then you should be able to create a tool that can write this concatenated
>>>>> format and insert these properties from a table that matches the boot
>>>>> loader, right?
>>>>> 
>>>>>     Arnd
>>>> 
>>>> Are you suggesting the tool insert the properties in the DT?  I’m not sure I understand what the point of doing that would be.
>>> 
>>> To insert platform-local properties that mean nothing outside of the
>>> firmware packaging of the device trees, which is the case here?
>>> 
>>> I think the idea of having the installer script inserting them is
>>> quite reasonable in this case.
>>> 
>>> 
>>> -Olof
>> 
>> These values are static, so not sure what the point of having the installer script do that?
>> 
> 
> It combines two hacks to work around a nonstandard boot loader.
> Once the bootloader is fixed, you can stop using that script.
> 
> 	Arnd

I feel as if I’m missing something here.  If we just have the properties in the .dts files I don’t need to change anything ever, no script, no worries about working with old or new boot loaders, etc.

- k

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-10 19:52                       ` Arnd Bergmann
  2015-03-10 19:57                         ` Kumar Gala
@ 2015-03-10 22:01                         ` Rob Clark
  1 sibling, 0 replies; 28+ messages in thread
From: Rob Clark @ 2015-03-10 22:01 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Kumar Gala, Olof Johansson, Kevin Hilman, linux-arm-msm,
	linux-arm-kernel, linux-kernel, arm, devicetree,
	Heiko Stübner

On Tue, Mar 10, 2015 at 3:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 10 March 2015 13:10:08 Kumar Gala wrote:
>> >>>>>>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>> >>>>>>>>>> on Qualcomm MSM platforms to determine which device tree should be
>> >>>>>>>>>> utilized and passed to the kernel.
>> >>>>>>>>>>
>> >>>>>>>>>> Cc: <devicetree@vger.kernel.org>
>> >>>>>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
>> >>>>>>>>>
>> >>>>>>>>> Is this the special magic that allows qcom bootloaders to take a kernel
>> >>>>>>>>> plus multiple DTBs and figure out which DTB to pass?
>> >>>>>>>>>
>> >>>>>>>>> Kevin
>> >>>>>>>>
>> >>>>>>>> yes
>> >>>>>>>
>> >>>>>>> That's a bummer.
>> >>>>>>>
>> >>>>>>> Luckily, the solution for upstream is still quite simple: Provide only
>> >>>>>>> one devicetree, and it'll be used, right?
>> >>>>>>
>> >>>>>> We can provide only one, we still need the IDs in the DT.
>> >>>>>
>> >>>>> How are the DTS provided? Concatenated with the kernel, or in a
>> >>>>> wrapped data format? Or in a separate partition from the kernel?
>> >>>>
>> >>>> Its a wrapped data format that is than concatenated with the kernel if I remember correctly.
>> >>>
>> >>> Then you should be able to create a tool that can write this concatenated
>> >>> format and insert these properties from a table that matches the boot
>> >>> loader, right?
>> >>>
>> >>>      Arnd
>> >>
>> >> Are you suggesting the tool insert the properties in the DT?  I’m not sure I understand what the point of doing that would be.
>> >
>> > To insert platform-local properties that mean nothing outside of the
>> > firmware packaging of the device trees, which is the case here?
>> >
>> > I think the idea of having the installer script inserting them is
>> > quite reasonable in this case.
>> >
>> >
>> > -Olof
>>
>> These values are static, so not sure what the point of having the installer script do that?
>>
>
> It combines two hacks to work around a nonstandard boot loader.
> Once the bootloader is fixed, you can stop using that script.
>

still sounds like an extra hurdle for distro's..  can't you just add
the extra entry in the dts files w/ a comment about workaround for
bootloader (and then possibly *not* document the property)?

BR,
-R

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-10 19:57                         ` Kumar Gala
@ 2015-03-11 15:33                           ` Bjorn Andersson
  2015-03-11 15:57                             ` Kumar Gala
       [not found]                             ` <CAJAp7OiVwvPjRbrBxw7Dndvk4Apwz_bx=CzSqeqd3JzYhmB7Kw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 2 replies; 28+ messages in thread
From: Bjorn Andersson @ 2015-03-11 15:33 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Arnd Bergmann, Olof Johansson, Kevin Hilman, linux-arm-msm,
	linux-arm-kernel, linux-kernel, arm, devicetree,
	Heiko Stübner

On Tue, Mar 10, 2015 at 12:57 PM, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Mar 10, 2015, at 2:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Tuesday 10 March 2015 13:10:08 Kumar Gala wrote:
>>>>>>>>>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>>>>>>>>>>>>> on Qualcomm MSM platforms to determine which device tree should be
>>>>>>>>>>>>> utilized and passed to the kernel.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cc: <devicetree@vger.kernel.org>
>>>>>>>>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
>>>>>>>>>>>>
>>>>>>>>>>>> Is this the special magic that allows qcom bootloaders to take a kernel
>>>>>>>>>>>> plus multiple DTBs and figure out which DTB to pass?
>>>>>>>>>>>>
>>>>>>>>>>>> Kevin
>>>>>>>>>>>
>>>>>>>>>>> yes
>>>>>>>>>>
>>>>>>>>>> That's a bummer.
>>>>>>>>>>
>>>>>>>>>> Luckily, the solution for upstream is still quite simple: Provide only
>>>>>>>>>> one devicetree, and it'll be used, right?
>>>>>>>>>
>>>>>>>>> We can provide only one, we still need the IDs in the DT.
>>>>>>>>
>>>>>>>> How are the DTS provided? Concatenated with the kernel, or in a
>>>>>>>> wrapped data format? Or in a separate partition from the kernel?
>>>>>>>
>>>>>>> Its a wrapped data format that is than concatenated with the kernel if I remember correctly.
>>>>>>
>>>>>> Then you should be able to create a tool that can write this concatenated
>>>>>> format and insert these properties from a table that matches the boot
>>>>>> loader, right?
>>>>>>
>>>>>>     Arnd
>>>>>
>>>>> Are you suggesting the tool insert the properties in the DT?  I’m not sure I understand what the point of doing that would be.
>>>>
>>>> To insert platform-local properties that mean nothing outside of the
>>>> firmware packaging of the device trees, which is the case here?
>>>>
>>>> I think the idea of having the installer script inserting them is
>>>> quite reasonable in this case.
>>>>
>>>>
>>>> -Olof
>>>
>>> These values are static, so not sure what the point of having the installer script do that?
>>>
>>
>> It combines two hacks to work around a nonstandard boot loader.
>> Once the bootloader is fixed, you can stop using that script.
>>
>>       Arnd
>
> I feel as if I’m missing something here.  If we just have the properties in the .dts files I don’t need to change anything ever, no script, no worries about working with old or new boot loaders, etc.
>

But are these values actually used by the boot loader?

As far as I could see in 8974 the dtbTool provided by Qualcomm
extracts the values from the list of dtbs and use them to create the
table-of-content in the QCDT blob. The boot loader then looks in this
TOC to pick the right dtb to use.

Regards,
Bjorn

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-11 15:33                           ` Bjorn Andersson
@ 2015-03-11 15:57                             ` Kumar Gala
       [not found]                             ` <CAJAp7OiVwvPjRbrBxw7Dndvk4Apwz_bx=CzSqeqd3JzYhmB7Kw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  1 sibling, 0 replies; 28+ messages in thread
From: Kumar Gala @ 2015-03-11 15:57 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Arnd Bergmann, Olof Johansson, Kevin Hilman, linux-arm-msm,
	linux-arm-kernel, linux-kernel, arm, devicetree,
	Heiko Stübner


On Mar 11, 2015, at 10:33 AM, Bjorn Andersson <bjorn@kryo.se> wrote:

> On Tue, Mar 10, 2015 at 12:57 PM, Kumar Gala <galak@codeaurora.org> wrote:
>> 
>> On Mar 10, 2015, at 2:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> 
>>> On Tuesday 10 March 2015 13:10:08 Kumar Gala wrote:
>>>>>>>>>>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>>>>>>>>>>>>>> on Qualcomm MSM platforms to determine which device tree should be
>>>>>>>>>>>>>> utilized and passed to the kernel.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Cc: <devicetree@vger.kernel.org>
>>>>>>>>>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Is this the special magic that allows qcom bootloaders to take a kernel
>>>>>>>>>>>>> plus multiple DTBs and figure out which DTB to pass?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Kevin
>>>>>>>>>>>> 
>>>>>>>>>>>> yes
>>>>>>>>>>> 
>>>>>>>>>>> That's a bummer.
>>>>>>>>>>> 
>>>>>>>>>>> Luckily, the solution for upstream is still quite simple: Provide only
>>>>>>>>>>> one devicetree, and it'll be used, right?
>>>>>>>>>> 
>>>>>>>>>> We can provide only one, we still need the IDs in the DT.
>>>>>>>>> 
>>>>>>>>> How are the DTS provided? Concatenated with the kernel, or in a
>>>>>>>>> wrapped data format? Or in a separate partition from the kernel?
>>>>>>>> 
>>>>>>>> Its a wrapped data format that is than concatenated with the kernel if I remember correctly.
>>>>>>> 
>>>>>>> Then you should be able to create a tool that can write this concatenated
>>>>>>> format and insert these properties from a table that matches the boot
>>>>>>> loader, right?
>>>>>>> 
>>>>>>>    Arnd
>>>>>> 
>>>>>> Are you suggesting the tool insert the properties in the DT?  I’m not sure I understand what the point of doing that would be.
>>>>> 
>>>>> To insert platform-local properties that mean nothing outside of the
>>>>> firmware packaging of the device trees, which is the case here?
>>>>> 
>>>>> I think the idea of having the installer script inserting them is
>>>>> quite reasonable in this case.
>>>>> 
>>>>> 
>>>>> -Olof
>>>> 
>>>> These values are static, so not sure what the point of having the installer script do that?
>>>> 
>>> 
>>> It combines two hacks to work around a nonstandard boot loader.
>>> Once the bootloader is fixed, you can stop using that script.
>>> 
>>>      Arnd
>> 
>> I feel as if I’m missing something here.  If we just have the properties in the .dts files I don’t need to change anything ever, no script, no worries about working with old or new boot loaders, etc.
>> 
> 
> But are these values actually used by the boot loader?
> 
> As far as I could see in 8974 the dtbTool provided by Qualcomm
> extracts the values from the list of dtbs and use them to create the
> table-of-content in the QCDT blob. The boot loader then looks in this
> TOC to pick the right dtb to use.

Are you asking do we utilize the values out of the DT directly?  If so, no.  You are correct that the tool pulls them out.  This is all about where we keep the information that associates a given DTB with its MSM-ID/BOARD-ID values.  While we can move that info into a tool, it just means updating the tool constantly to map an compatible string to those values.  The other means is keeping the values with the DTB as properties as this binding suggests.

- k

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
       [not found]                             ` <CAJAp7OiVwvPjRbrBxw7Dndvk4Apwz_bx=CzSqeqd3JzYhmB7Kw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2015-03-11 20:20                               ` Arnd Bergmann
  2015-03-11 20:35                                 ` Kumar Gala
  0 siblings, 1 reply; 28+ messages in thread
From: Arnd Bergmann @ 2015-03-11 20:20 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Kumar Gala, Olof Johansson, Kevin Hilman, linux-arm-msm,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, arm-DgEjT+Ai2ygdnm+yROfE0A,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner

On Wednesday 11 March 2015 08:33:04 Bjorn Andersson wrote:
> 
> But are these values actually used by the boot loader?
> 
> As far as I could see in 8974 the dtbTool provided by Qualcomm
> extracts the values from the list of dtbs and use them to create the
> table-of-content in the QCDT blob. The boot loader then looks in this
> TOC to pick the right dtb to use.
> 

I guess if I understand this right, we just need to fix that dtbTool
then to look at the top-level compatible property and/or machine
name instead?

	Arnd


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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-11 20:20                               ` Arnd Bergmann
@ 2015-03-11 20:35                                 ` Kumar Gala
  2015-03-11 21:48                                   ` Arnd Bergmann
  0 siblings, 1 reply; 28+ messages in thread
From: Kumar Gala @ 2015-03-11 20:35 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Andersson, Olof Johansson, Kevin Hilman, linux-arm-msm,
	linux-arm-kernel, linux-kernel, arm, devicetree,
	Heiko Stübner


On Mar 11, 2015, at 3:20 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> On Wednesday 11 March 2015 08:33:04 Bjorn Andersson wrote:
>> 
>> But are these values actually used by the boot loader?
>> 
>> As far as I could see in 8974 the dtbTool provided by Qualcomm
>> extracts the values from the list of dtbs and use them to create the
>> table-of-content in the QCDT blob. The boot loader then looks in this
>> TOC to pick the right dtb to use.
>> 
> 
> I guess if I understand this right, we just need to fix that dtbTool
> then to look at the top-level compatible property and/or machine
> name instead?
> 
> 	Arnd

Correct, and it means updating the tool for every board/dts that gets created in the future.

Thus, the feeling was that having the ids kept with the dtb made maintenance far easier.

- k

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
  2015-03-11 20:35                                 ` Kumar Gala
@ 2015-03-11 21:48                                   ` Arnd Bergmann
  0 siblings, 0 replies; 28+ messages in thread
From: Arnd Bergmann @ 2015-03-11 21:48 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Bjorn Andersson, Olof Johansson, Kevin Hilman, linux-arm-msm,
	linux-arm-kernel, linux-kernel, arm, devicetree,
	Heiko Stübner

On Wednesday 11 March 2015 15:35:22 Kumar Gala wrote:
> On Mar 11, 2015, at 3:20 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 
> > On Wednesday 11 March 2015 08:33:04 Bjorn Andersson wrote:
> >> 
> >> But are these values actually used by the boot loader?
> >> 
> >> As far as I could see in 8974 the dtbTool provided by Qualcomm
> >> extracts the values from the list of dtbs and use them to create the
> >> table-of-content in the QCDT blob. The boot loader then looks in this
> >> TOC to pick the right dtb to use.
> >> 
> > 
> > I guess if I understand this right, we just need to fix that dtbTool
> > then to look at the top-level compatible property and/or machine
> > name instead?
> > 
> >       Arnd
> 
> Correct, and it means updating the tool for every board/dts that gets created in the future.
> 
> Thus, the feeling was that having the ids kept with the dtb made maintenance far easier.
> 

Part of my objection was to having nonstandard properties that are
not even used anywhere in the kernel. If you could just encode
them in the root compatible property as a string, that would be
a lot nicer.

	Arnd

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2015-03-11 21:48 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-04 21:13 [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id Kumar Gala
2015-03-04 21:13 ` [PATCH v2 2/3] arm64: qcom: Add support for Qualcomm MSM8916 SoC Kumar Gala
2015-03-04 22:33   ` Stephen Boyd
2015-03-05 15:06     ` Kumar Gala
2015-03-05 16:03       ` Stephen Boyd
2015-03-04 21:13 ` [PATCH v2 3/3] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts Kumar Gala
2015-03-04 21:19 ` [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id Arnd Bergmann
2015-03-04 21:22   ` Kumar Gala
2015-03-05 19:42 ` Kevin Hilman
2015-03-05 20:23   ` Kumar Gala
2015-03-06  1:59     ` Olof Johansson
2015-03-06  2:28       ` Rob Clark
     [not found]         ` <CAF6AEGssMoo6c3nf_7fcATwocuETGZ8nbpGQpUO=KcKWC+rvHw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-06 15:09           ` Christopher Covington
2015-03-06 16:08       ` Kumar Gala
2015-03-06 19:15         ` Olof Johansson
2015-03-06 20:37           ` Kumar Gala
2015-03-09 12:11             ` Arnd Bergmann
2015-03-10 17:13               ` Kumar Gala
     [not found]                 ` <F5017A7F-0EA2-41B3-A9DD-6123CCFD36FA-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-03-10 17:55                   ` Olof Johansson
2015-03-10 18:10                     ` Kumar Gala
2015-03-10 19:52                       ` Arnd Bergmann
2015-03-10 19:57                         ` Kumar Gala
2015-03-11 15:33                           ` Bjorn Andersson
2015-03-11 15:57                             ` Kumar Gala
     [not found]                             ` <CAJAp7OiVwvPjRbrBxw7Dndvk4Apwz_bx=CzSqeqd3JzYhmB7Kw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-11 20:20                               ` Arnd Bergmann
2015-03-11 20:35                                 ` Kumar Gala
2015-03-11 21:48                                   ` Arnd Bergmann
2015-03-10 22:01                         ` Rob Clark

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).