projects / deliverable / linux.git / blame
| Commit | Line | Data |
|---|---|---|
| b32e592d SB |
1 | QCOM device tree bindings |
| 2 | ------------------------- | |
| 3 | ||
| 4 | Some qcom based bootloaders identify the dtb blob based on a set of | |
| 5 | device properties like SoC and platform and revisions of those components. | |
| 6 | To support this scheme, we encode this information into the board compatible | |
| 7 | string. | |
| 8 | ||
| 9 | Each board must specify a top-level board compatible string with the following | |
| 10 | format: | |
| 11 | ||
| 12 | compatible = "qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<board_version>]" | |
| 13 | ||
| 14 | The 'SoC' and 'board' elements are required. All other elements are optional. | |
| 15 | ||
| 16 | The 'SoC' element must be one of the following strings: | |
| 17 | ||
| 18 | apq8016 | |
| 19 | apq8074 | |
| 20 | apq8084 | |
| 21 | apq8096 | |
| 22 | msm8916 | |
| 23 | msm8974 | |
| 24 | msm8996 | |
| 25 | ||
| 26 | The 'board' element must be one of the following strings: | |
| 27 | ||
| 28 | cdp | |
| 29 | liquid | |
| 30 | dragonboard | |
| 31 | mtp | |
| 32 | sbc | |
| 33 | ||
| 34 | The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor> | |
| 35 | where the minor number may be omitted when it's zero, i.e. v1.0 is the same | |
| 36 | as v1. If all versions of the 'board_version' elements match, then a | |
| 37 | wildcard '*' should be used, e.g. 'v*'. | |
| 38 | ||
| 39 | The 'foundry_id' and 'subtype' elements are one or more digits from 0 to 9. | |
| 40 | ||
| 41 | Examples: | |
| 42 | ||
| 43 | "qcom,msm8916-v1-cdp-pm8916-v2.1" | |
| 44 | ||
| 45 | A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of version | |
| 46 | 2.1. | |
| 47 | ||
| 48 | "qcom,apq8074-v2.0-2-dragonboard/1-v0.1" | |
| 49 | ||
| 50 | A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in | |
| 51 | foundry 2. |