Remove the need for qcom,{msm-id,board-id,pmic-id}

Some qcom based bootloaders identify the dtb blob based on a set of device properties like SoC, platform, PMIC, and revisions of those components. In downstream kernels, these values are added to the different component dtsi files (i.e. pmic dtsi file, SoC dtsi file, board dtsi file, etc.) via qcom specific DT properties. The dtb files are parsed by a program called dtbTool that picks out these properties and creates a table of contents binary blob with the property information and some offsets into the concatenation of all the dtbs (termed a QCDT image).

The suggestion is to do this via the board compatible string instead, because these qcom specific properties are never used by the kernel. Add a document describing the format of the compatible string that encodes all this information that's currently encoded in the qcom,{msm-id,board-id,pmic-id} properties in downstream devicetrees. Future bootloaders may be updated to look at the compatible field instead of looking for the table of contents image. For non-updateable bootloaders, a new dtbTool program will parse the compatible string and generate a QCDT image from it.

Signed-off-by Stephen Boyd <[email protected]>

---
 Documentation/devicetree/bindings/arm/qcom.txt | 51 ++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/qcom.txt

Documentation/devicetree/bindings/arm/qcom.txt new file +51 -0

new file mode 100644
index 000000000000..3e24518c6678
@@ -0,0 +1,51 @@
+QCOM device tree bindings
+-------------------------
+
+Some qcom based bootloaders identify the dtb blob based on a set of
+device properties like SoC and platform and revisions of those components.
+To support this scheme, we encode this information into the board compatible
+string.
+
+Each board must specify a top-level board compatible string with the following
+format:
+
+	compatible = "qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<board_version>]"
+
+The 'SoC' and 'board' elements are required. All other elements are optional.
+
+The 'SoC' element must be one of the following strings:
+
+	apq8016
+	apq8074
+	apq8084
+	apq8096
+	msm8916
+	msm8974
+	msm8996
+
+The 'board' element must be one of the following strings:
+
+	cdp
+	liquid
+	dragonboard
+	mtp
+	sbc
+
+The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor>
+where the minor number may be omitted when it's zero, i.e.  v1.0 is the same
+as v1. If all versions of the 'board_version' elements match, then a
+wildcard '*' should be used, e.g. 'v*'.
+
+The 'foundry_id' and 'subtype' elements are one or more digits from 0 to 9.
+
+Examples:
+
+	"qcom,msm8916-v1-cdp-pm8916-v2.1"
+
+A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of version
+2.1.
+
+	"qcom,apq8074-v2.0-2-dragonboard/1-v0.1"
+
+A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in
+foundry 2.

Signature · 7 lines

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 at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 21 lines · Stephen Boyd

Some qcom based bootloaders identify the dtb blob based on a set of device properties like SoC, platform, PMIC, and revisions of those components. In downstream kernels, these values are added to the different component dtsi files (i.e. pmic dtsi file, SoC dtsi file, board dtsi file, etc.) via qcom specific DT properties. The dtb files are parsed by a program called dtbTool that picks out these properties and creates a table of contents binary blob with the property information and some offsets into the concatenation of all the dtbs (termed a QCDT image).

The suggestion is to do this via the board compatible string instead, because these qcom specific properties are never used by the kernel. Add a document describing the format of the compatible string that encodes all this information that's currently encoded in the qcom,{msm-id,board-id,pmic-id} properties in downstream devicetrees. Future bootloaders may be updated to look at the compatible field instead of looking for the table of contents image. For non-updateable bootloaders, a new dtbTool program will parse the compatible string and generate a QCDT image from it.

Quoted 1 line

Signed-off-by Stephen Boyd <[email protected]>

Much more reasonable now. I do find the '/' in it a bit strange though.

Acked-by Rob Herring <[email protected]>

Quoted 2 lines · Rob Herring

Much more reasonable now. I do find the '/' in it a bit strange though.

I can remove the backslash if you like. Is a dash more preferred?

Quoted 2 lines

Acked-by Rob Herring <[email protected]>

and if so can I keep the ack? I'll resend with that change and add the ack.

Add an alias for pm8916 on msm8916 based SoCs so that the newly updated dtbTool can find the pmic compatible string and add the pmic-id element to the QCDT header.

Signed-off-by Stephen Boyd <[email protected]>

---
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 1 +
 arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi | 1 +
 arch/arm64/boot/dts/qcom/pm8916.dtsi      | 6 +++---
 3 files changed, 5 insertions(+), 3 deletions(-)

arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi +1 -0

index 6b8abbe68746..46bfcb9b2e84 100644
@@ -20,6 +20,7 @@
 	aliases {
 		serial0 = &blsp1_uart2;
 		serial1 = &blsp1_uart1;
+		usid0 = &pm8916_0;
 	};
 
 	chosen {

arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi +1 -0

index a1aa0b201e92..ceeb8a6feed6 100644
@@ -17,6 +17,7 @@
 / {
 	aliases {
 		serial0 = &blsp1_uart2;
+		usid0 = &pm8916_0;
 	};
 
 	chosen {

arch/arm64/boot/dts/qcom/pm8916.dtsi +2 -2

index b222ece7e3d2..37432451ee4c 100644
@@ -4,8 +4,8 @@
 
 &spmi_bus {
 
-	usid0: pm8916 at 0 {
-		compatible = "qcom,spmi-pmic";
+	pm8916_0: pm8916 at 0 {
+		compatible = "qcom,pm8916", "qcom,spmi-pmic";
 		reg = <0x0 SPMI_USID>;
 		#address-cells = <1>;
 		#size-cells = <0>;