Merge branch 'tracking-qcomlt-dt' into integration-linux-qcomlt

* tracking-qcomlt-dt: (48 commits)
  arm64: dts: qcom: Add MSM8916 restart device node
  arm64: dts: qcom: Add sdhci support for APQ8016 SBC board
  arm64: dts: qcom: Add USB related device nodes on APQ8016 SBC board
  arm64: dts: qcom: Switch to upstream SPMI PMIC bindings
  arm64: dts: msm8916: Add thermal zones, tsens and eeprom nodes
  arm: dts: msm8974: Add thermal zones, tsens and eeprom nodes
  arm64: dts: qcom: msm8916: Reorder rpm/regulators
  arm64: dts: qcom: msm8916: Fix whitespace
  arm64: dts: qcom: Add APQ8016 SBC support
  arm64: dts: qcom : msm8916: add sdhci support
  arm64: dts: qcom: msm8916: Add RPM controlled regulators
  arm64: dts: qcom: msm8916: Add spmi controlled regulators
  arm64: dts: qcom: msm8916 Add smem nodes.
  arm64: dts: qcom: msm8916 Add hwspinlock nodes.
  arm64: dts: qcom: msm8916: Add reserved memory nodes.
  dts:msm8916: Fix spi4_sleep duplicate error
  DT: arm64: msm8916-mtp: enable spi3
  DT: arm64: msm8916: add all SPI DT nodes
  arm64: dts: Add Qualcomm MSM8916 & MTP8916 ids
  devicetree: bindings: Document qcom,msm-id and qcom,board-id
  ...

1 files changed, 65 insertions, 0 deletions

diff --git a/Documentation/devicetree/bindings/arm/msm/ids.txt b/Documentation/devicetree/bindings/arm/msm/ids.txt
new file mode 100644
index 000000000000..9ee8428f4670
--- /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>;