summaryrefslogtreecommitdiff
path: root/Documentation/arm
diff options
context:
space:
mode:
authorArnd Bergmann <arnd@arndb.de>2022-07-14 17:02:04 +0200
committerArnd Bergmann <arnd@arndb.de>2022-07-14 17:02:12 +0200
commite0a592505566c82d60a2010d0976b8ae0a831fcc (patch)
tree655f77884683bc73c1e1f9d3a339e0add6a4f48b /Documentation/arm
parent8c1e9736c5bdb280ab45eba58254f048b750481e (diff)
parentabf61f7e66c15e00f40ca7e10367f4149639bc57 (diff)
downloadlwn-e0a592505566c82d60a2010d0976b8ae0a831fcc.tar.gz
lwn-e0a592505566c82d60a2010d0976b8ae0a831fcc.zip
Merge tag 'qcom-arm64-for-5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
Qualcomm ARM64 DTS updates for v5.20 This introduces initial support for Lenovo ThinkPad X13s, Qualcomm 8cx Gen 3 Compute Reference Device, SA8295P Automotive Development Platform, Xiaomi Mi 5s Plus, five new SC7180 Chrome OS boards, Inforce IFC6560, LG G7 ThinQ and LG V35 ThinQ. With IPQ8074 gaining GDSC support, this was expressed in the gcc node and defined for the USB nodes. The SDHCI reset line was defined to get the storage devices into a known state. For MSM8996 interconnect providers, the second DSI interface, resets for SDHCI are introduced. Support for the Xiaomi Mi 5s Plus is introduced and the Dragonboard 820c gains definitions for its LEDs. The MSM8998 platform changes consists of a various cleanup patches, the FxTec Pro1 is split out from using the MTP dts and Sony Xperia devices on the "Yoshino" platform gains ToF sensor. On SC7180 five new Trogdor based boards are added and the description of keyboard and detachables is improved. On the SC7280-based Herobrine board DisplayPort is enabled, SPI flash clock rate is changed, WiFi is enabled and the modem firmware path is updated. The Villager boards gains touchscreen, and keyboard backlight. This introduces initial support for the SC8280XP (aka 8cx Gen 3) and related automotive platforms are introduced, with support for the Qualcomm reference board, the Lenovo Thinkpad X13s and the SA8295P Automotive Development Platform. In addition to a wide range of smaller fixes on the SDM630 and SDM660 platforms, support for the secondary high speed USB controller is introduced and the Sony Xperia "Nile" platform gains support for the RGB status LED. Support for the Inforce IFC6560 board is introduced. On SDM845 the bandwidth monitor for the CPU subsystem is introduced, to scale LLCC clock rate based on profiling. CPU and cluster idle states are switched to OSI hierarchical states. DB845c and SHIFT 6mq gains LED support and new support for the LG G7 ThinQ and LG V35 ThinQ boards are added. DLL/DDR configuration for SDHCI nodes are defined for SM6125. On SM8250 the GPU per-process page tables is enabled and for RB5 the Light Pulse Generator-based LEDs are added. The display clock controller is introduced for SM8350. On SM8450 this introduces the camera clock controller and the UART typically used for Bluetooth. The interconnect path for the crypto engine is added to the SCM node, to ensure this is adequately clocked. The assigned-clock-rate for the display processor is dropped from several platforms, now that the driver derrives the min and max from the clock. In addition to this a wide range of fixes for stylistic issues and issues discovered through Devicetree binding validation across many platforms and boards are introduced. * tag 'qcom-arm64-for-5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (193 commits) arm64: dts: qcom: sc8280xp: fix DP PHY node unit addresses arm64: dts: qcom: sc8280xp: fix usb_0 HS PHY ref clock arm64: dts: qcom: sc7280: fix PCIe clock reference docs: arm: index.rst: add google/chromebook-boot-flow arm64: dts: qcom: msm8996: clean up PCIe PHY node arm64: dts: qcom: msm8996: use non-empty ranges for PCIe PHYs arm64: dts: qcom: sm8450: drop UFS PHY clock-cells arm64: dts: qcom: sm8250: drop UFS PHY clock-cells arm64: dts: qcom: sc8280xp: drop UFS PHY clock-cells arm64: dts: qcom: sm8450: drop USB PHY clock index arm64: dts: qcom: sm8350: drop USB PHY clock index arm64: dts: qcom: msm8998: drop USB PHY clock index arm64: dts: qcom: ipq8074: drop USB PHY clock index arm64: dts: qcom: ipq6018: drop USB PHY clock index arm64: dts: qcom: sm8250: add missing PCIe PHY clock-cells arm64: dts: qcom: sc7280: drop PCIe PHY clock index Revert "arm64: dts: qcom: Fix 'reg-names' for sdhci nodes" arm64: dts: qcom: sc7180-idp: add vdds supply to the DSI PHY arm64: dts: qcom: sc7280: use constants for gpucc clocks and power-domains arm64: dts: qcom: msm8996: add missing DSI clock assignments ... Link: https://lore.kernel.org/r/20220713203939.1431054-1-bjorn.andersson@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Diffstat (limited to 'Documentation/arm')
-rw-r--r--Documentation/arm/google/chromebook-boot-flow.rst69
-rw-r--r--Documentation/arm/index.rst2
2 files changed, 71 insertions, 0 deletions
diff --git a/Documentation/arm/google/chromebook-boot-flow.rst b/Documentation/arm/google/chromebook-boot-flow.rst
new file mode 100644
index 000000000000..36da77684bba
--- /dev/null
+++ b/Documentation/arm/google/chromebook-boot-flow.rst
@@ -0,0 +1,69 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================
+Chromebook Boot Flow
+======================================
+
+Most recent Chromebooks that use device tree are using the opensource
+depthcharge_ bootloader. Depthcharge_ expects the OS to be packaged as a `FIT
+Image`_ which contains an OS image as well as a collection of device trees. It
+is up to depthcharge_ to pick the right device tree from the `FIT Image`_ and
+provide it to the OS.
+
+The scheme that depthcharge_ uses to pick the device tree takes into account
+three variables:
+
+- Board name, specified at depthcharge_ compile time. This is $(BOARD) below.
+- Board revision number, determined at runtime (perhaps by reading GPIO
+ strappings, perhaps via some other method). This is $(REV) below.
+- SKU number, read from GPIO strappings at boot time. This is $(SKU) below.
+
+For recent Chromebooks, depthcharge_ creates a match list that looks like this:
+
+- google,$(BOARD)-rev$(REV)-sku$(SKU)
+- google,$(BOARD)-rev$(REV)
+- google,$(BOARD)-sku$(SKU)
+- google,$(BOARD)
+
+Note that some older Chromebooks use a slightly different list that may
+not include SKU matching or may prioritize SKU/rev differently.
+
+Note that for some boards there may be extra board-specific logic to inject
+extra compatibles into the list, but this is uncommon.
+
+Depthcharge_ will look through all device trees in the `FIT Image`_ trying to
+find one that matches the most specific compatible. It will then look
+through all device trees in the `FIT Image`_ trying to find the one that
+matches the *second most* specific compatible, etc.
+
+When searching for a device tree, depthcharge_ doesn't care where the
+compatible string falls within a device tree's root compatible string array.
+As an example, if we're on board "lazor", rev 4, SKU 0 and we have two device
+trees:
+
+- "google,lazor-rev5-sku0", "google,lazor-rev4-sku0", "qcom,sc7180"
+- "google,lazor", "qcom,sc7180"
+
+Then depthcharge_ will pick the first device tree even though
+"google,lazor-rev4-sku0" was the second compatible listed in that device tree.
+This is because it is a more specific compatible than "google,lazor".
+
+It should be noted that depthcharge_ does not have any smarts to try to
+match board or SKU revisions that are "close by". That is to say that
+if depthcharge_ knows it's on "rev4" of a board but there is no "rev4"
+device tree then depthcharge_ *won't* look for a "rev3" device tree.
+
+In general when any significant changes are made to a board the board
+revision number is increased even if none of those changes need to
+be reflected in the device tree. Thus it's fairly common to see device
+trees with multiple revisions.
+
+It should be noted that, taking into account the above system that
+depthcharge_ has, the most flexibility is achieved if the device tree
+supporting the newest revision(s) of a board omits the "-rev{REV}"
+compatible strings. When this is done then if you get a new board
+revision and try to run old software on it then we'll at pick the
+newest device tree we know about.
+
+.. _depthcharge: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/depthcharge/
+.. _`FIT Image`: https://doc.coreboot.org/lib/payloads/fit.html
diff --git a/Documentation/arm/index.rst b/Documentation/arm/index.rst
index 2bda5461a80b..495ada7915e1 100644
--- a/Documentation/arm/index.rst
+++ b/Documentation/arm/index.rst
@@ -31,6 +31,8 @@ SoC-specific documents
.. toctree::
:maxdepth: 1
+ google/chromebook-boot-flow
+
ixp4xx
marvell