summaryrefslogtreecommitdiff
path: root/arch/arm/boot/dts/qcom-pm8941.dtsi
diff options
context:
space:
mode:
authorStephen Boyd <sboyd@codeaurora.org>2015-11-21 02:31:16 +0300
committerAndy Gross <andy.gross@linaro.org>2016-02-24 08:48:29 +0300
commitb32e592d3c28f10dc4fd2d55dd14d47deb5f8532 (patch)
treed852017060077e1fd57a955f6c511e9cb1f39f6f /arch/arm/boot/dts/qcom-pm8941.dtsi
parent46fb5280a0c88a7cf66333cd67a0159bd732ce3b (diff)
downloadlinux-b32e592d3c28f10dc4fd2d55dd14d47deb5f8532.tar.xz
devicetree: bindings: Document qcom board compatible format
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 <sboyd@codeaurora.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
Diffstat (limited to 'arch/arm/boot/dts/qcom-pm8941.dtsi')
0 files changed, 0 insertions, 0 deletions