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>

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