Merge branch '2021-10-31-assorted-platform-updates'

- Revert GIC LPI changes that need to be reworked.
- mvebu SATA booting bugfix
- Samsung Galaxy S9/S9+(SM-G96x0), Samsung Galaxy A and Apple M1
  platform support.

9 files changed, 424 insertions, 0 deletions

diff --git a/doc/board/apple/index.rst b/doc/board/apple/index.rst
new file mode 100644
index 00000000000..84468478182
--- /dev/null
+++ b/doc/board/apple/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Apple
+=====
+
+.. toctree::
+   :maxdepth: 2
+
+   m1
diff --git a/doc/board/apple/m1.rst b/doc/board/apple/m1.rst
new file mode 100644
index 00000000000..9fa21767c92
--- /dev/null
+++ b/doc/board/apple/m1.rst
@@ -0,0 +1,59 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Apple Silicon Macs
+=============================
+
+Allows Apple Silicon Macs to boot U-Boot via the m1n1 bootloader
+developed by the Asahi Linux project.  At this point the machines with
+the following SoCs work:
+
+ - Apple M1 SoC
+
+On these SoCs the following hardware is supported:
+
+ - S5L serial port
+ - Framebuffer
+ - USB 3.1 Type-C ports
+
+Device trees are currently provided for the M1 Mac mini (2020, J274)
+and M1 MacBook Pro 13" (2020, J293).  The M1 MacBook Air (2020) is
+expected to work with the J293 device tree.  The M1 iMac (2021) may
+work with the J274 device tree.
+
+Building U-Boot
+---------------
+
+.. code-block:: bash
+
+    $ export CROSS_COMPILE=aarch64-none-elf-
+    $ make apple_m1_defconfig
+    $ make
+
+This will build ``u-boot-nodtb.bin`` as well as devices trees for some
+of the supported machines.  These device trees can be found in the
+``arch/arm/dts`` subdirectory of your build.
+
+Image creation
+--------------
+
+In order to run U-Boot on an Apple Silicon Mac, U-Boot has to be used
+as a payload for the m1n1 bootloader.  Instructions for building m1n1
+can be found here:
+
+    https://github.com/AsahiLinux/docs/wiki/SW%3Am1n1
+
+.. code-block:: bash
+
+    $ cat m1n1.macho t8103-j274.dtb u-boot-nodtb.bin > u-boot.macho
+
+This uses ``u-boot-nodtb.bin`` as the device tree is passed to U-Boot
+by m1n1 after making some adjustments.
+
+Image installation
+------------------
+
+Instructions on how to install U-Boot on your Mac can be found at:
+
+    https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart
+
+Just replace ``m1n1.macho`` with ``u-boot.macho`` in the instructions.
diff --git a/doc/board/index.rst b/doc/board/index.rst
index aa397ab9421..74ea33e0816 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -10,6 +10,7 @@ Board-specific doc
    advantech/index
    AndesTech/index
    amlogic/index
+   apple/index
    atmel/index
    congatec/index
    coreboot/index
@@ -22,6 +23,7 @@ Board-specific doc
    openpiton/index
    qualcomm/index
    rockchip/index
+   samsung/index
    siemens/index
    sifive/index
    sipeed/index
diff --git a/doc/board/qualcomm/index.rst b/doc/board/qualcomm/index.rst
index f7e0aa92986..10b98214e96 100644
--- a/doc/board/qualcomm/index.rst
+++ b/doc/board/qualcomm/index.rst
@@ -7,3 +7,4 @@ Qualcomm
    :maxdepth: 2
 
    dragonboard410c
+   sdm845
diff --git a/doc/board/qualcomm/sdm845.rst b/doc/board/qualcomm/sdm845.rst
new file mode 100644
index 00000000000..cd46cbe9cf1
--- /dev/null
+++ b/doc/board/qualcomm/sdm845.rst
@@ -0,0 +1,38 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Dzmitry Sankouski <[email protected]>
+
+Snapdragon 845
+================
+
+About this
+----------
+This document describes the information about Qualcomm Snapdragon 845
+supported boards and it's usage steps.
+
+SDM845 - hi-end qualcomm chip, introduced in late 2017.
+Mostly used in flagship phones and tablets of 2018.
+
+U-Boot can be used as a replacement for Qualcomm's original ABL (UEFI) bootloader.
+It is loaded as an Android boot image through ABL
+
+Installation
+------------
+First, setup ``CROSS_COMPILE`` for aarch64. Then, build U-Boot for your board::
+
+	$ export CROSS_COMPILE=<aarch64 toolchain prefix>
+	$ make <your board name here, see Boards section>_defconfig
+	$ make
+
+This will build ``u-boot.bin`` in the configured output directory.
+
+Boards
+------------
+starqlte
+^^^^^^^^^^^^
+
+The starqltechn is a production board for Samsung S9 (SM-G9600) phone,
+based on the Qualcomm SDM845 SoC.
+
+More information can be found on the `Samsung S9 page`_.
+
+.. _Samsung S9 page: https://en.wikipedia.org/wiki/Samsung_Galaxy_S9
diff --git a/doc/board/samsung/axy17lte.rst b/doc/board/samsung/axy17lte.rst
new file mode 100644
index 00000000000..511cd57a22f
--- /dev/null
+++ b/doc/board/samsung/axy17lte.rst
@@ -0,0 +1,94 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Dzmitry Sankouski <[email protected]>
+
+Samsung 2017 A series phones
+============================
+
+About this
+----------
+This document describes the information about Samsung A(7/5/3) 2017 midrange
+phones and u-boot usage steps.
+
+U-Boot can be used as a chain-loaded bootloader to replace Samsung's original SBOOT bootloader.
+It is loaded as an Android boot image through SBOOT.
+
+Phone specs
+-----------
+A3 (SM-320) (a3y17lte)
+^^^^^^^^^^^^^^^^^^^^^^
+- 4.7 AMOLED display
+- Exynos 7870 SoC
+- 16GB flash
+- 2GB RAM
+
+.. A3 2017 wiki page: https://en.wikipedia.org/wiki/Samsung_Galaxy_A3_(2017)
+
+A5 (SM-520) (a5y17lte)
+^^^^^^^^^^^^^^^^^^^^^^
+- 5.2 AMOLED display
+- Exynos 7880 SoC
+- 32GB flash
+- 3GB RAM
+
+.. A5 2017 wiki page: https://en.wikipedia.org/wiki/Samsung_Galaxy_A5_(2017)
+
+A7 (SM-720) (a5y17lte)
+^^^^^^^^^^^^^^^^^^^^^^
+- 5.7 AMOLED display
+- Exynos 7880 SoC
+- 32GB flash
+- 3GB RAM
+
+.. A7 2017 wiki page: https://en.wikipedia.org/wiki/Samsung_Galaxy_A7_(2017)
+
+Installation
+------------
+
+Building u-boot
+^^^^^^^^^^^^^^^
+
+First, setup ``CROSS_COMPILE`` for aarch64.
+Then, build U-Boot for your phone, for example ``a5y17lte``::
+
+  $ export CROSS_COMPILE=<aarch64 toolchain prefix>
+  $ make a5y17lte_defconfig
+  $ make
+
+This will build ``u-boot.bin`` in the configured output directory.
+
+Payload
+^^^^^^^
+What is a payload?
+""""""""""""""""""
+A payload file is a file to be used instead of linux kernel in android boot image.
+This file will be loaded into memory, and executed by SBOOT,
+and is therefore SBOOT's payload.
+It may be pure u-boot (with loading u-boot's payload from flash in mind),
+or u-boot + u-boot's payload.
+
+It should be kept in mind, that SBOOT binary patches it's payload after loading
+in address range 0x401f8550-0x401f9280. Given SBOOT loads payload to 0x40001000,
+a range of 0x1f7550-0x1f8280 (2061648-2065024) in a payload file
+will be corrupted after loading to RAM.
+
+Creating payload file
+"""""""""""""""""""""
+- Assemble FIT image for your kernel
+- Create a file for u-boot payload ``touch sboot-payload``
+- Write zeroes till 0x200000 address to be sure SBOOT won't corrupt your info
+  ``dd if=/dev/zero of=sboot-payload bs=$((0x200000)) count=1``
+- Write u-boot to the start of the payload ``dd if=<u-boot.bin path> of=sboot-payload``
+- Write FIT image to payload from 0x200000 address
+  ``dd if=<FIT image path> of=sboot-payload seek=1 bs=2M``
+
+Creating android boot image
+"""""""""""""""""""""""""""
+Once payload created, it's time for android image::
+
+  mkbootimg --base 0x40000000 --kernel_offset 0x00000000 --ramdisk_offset 0x01000000 --tags_offset 0x00000100 --pagesize 2048 --second_offset 0x00f00000 --kernel <sboot-payload path> -o uboot.img
+
+Note, that stock Samsung bootloader ignores offsets, set in mkbootimg.
+
+Flashing
+""""""""
+Flash like regular android boot image.
diff --git a/doc/board/samsung/index.rst b/doc/board/samsung/index.rst
new file mode 100644
index 00000000000..c904372dff3
--- /dev/null
+++ b/doc/board/samsung/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Samsung
+========
+
+.. toctree::
+   :maxdepth: 2
+
+   axy17lte
diff --git a/doc/device-tree-bindings/iommu/iommu.txt b/doc/device-tree-bindings/iommu/iommu.txt
new file mode 100644
index 00000000000..26ba9e530f1
--- /dev/null
+++ b/doc/device-tree-bindings/iommu/iommu.txt
@@ -0,0 +1,206 @@
+This document describes the generic device tree binding for IOMMUs and their
+master(s).
+
+
+IOMMU device node:
+==================
+
+An IOMMU can provide the following services:
+
+* Remap address space to allow devices to access physical memory ranges that
+  they otherwise wouldn't be capable of accessing.
+
+  Example: 32-bit DMA to 64-bit physical addresses
+
+* Implement scatter-gather at page level granularity so that the device does
+  not have to.
+
+* Provide system protection against "rogue" DMA by forcing all accesses to go
+  through the IOMMU and faulting when encountering accesses to unmapped
+  address regions.
+
+* Provide address space isolation between multiple contexts.
+
+  Example: Virtualization
+
+Device nodes compatible with this binding represent hardware with some of the
+above capabilities.
+
+IOMMUs can be single-master or multiple-master. Single-master IOMMU devices
+typically have a fixed association to the master device, whereas multiple-
+master IOMMU devices can translate accesses from more than one master.
+
+The device tree node of the IOMMU device's parent bus must contain a valid
+"dma-ranges" property that describes how the physical address space of the
+IOMMU maps to memory. An empty "dma-ranges" property means that there is a
+1:1 mapping from IOMMU to memory.
+
+Required properties:
+--------------------
+- #iommu-cells: The number of cells in an IOMMU specifier needed to encode an
+  address.
+
+The meaning of the IOMMU specifier is defined by the device tree binding of
+the specific IOMMU. Below are a few examples of typical use-cases:
+
+- #iommu-cells = <0>: Single master IOMMU devices are not configurable and
+  therefore no additional information needs to be encoded in the specifier.
+  This may also apply to multiple master IOMMU devices that do not allow the
+  association of masters to be configured. Note that an IOMMU can by design
+  be multi-master yet only expose a single master in a given configuration.
+  In such cases the number of cells will usually be 1 as in the next case.
+- #iommu-cells = <1>: Multiple master IOMMU devices may need to be configured
+  in order to enable translation for a given master. In such cases the single
+  address cell corresponds to the master device's ID. In some cases more than
+  one cell can be required to represent a single master ID.
+- #iommu-cells = <4>: Some IOMMU devices allow the DMA window for masters to
+  be configured. The first cell of the address in this may contain the master
+  device's ID for example, while the second cell could contain the start of
+  the DMA window for the given device. The length of the DMA window is given
+  by the third and fourth cells.
+
+Note that these are merely examples and real-world use-cases may use different
+definitions to represent their individual needs. Always refer to the specific
+IOMMU binding for the exact meaning of the cells that make up the specifier.
+
+
+IOMMU master node:
+==================
+
+Devices that access memory through an IOMMU are called masters. A device can
+have multiple master interfaces (to one or more IOMMU devices).
+
+Required properties:
+--------------------
+- iommus: A list of phandle and IOMMU specifier pairs that describe the IOMMU
+  master interfaces of the device. One entry in the list describes one master
+  interface of the device.
+
+When an "iommus" property is specified in a device tree node, the IOMMU will
+be used for address translation. If a "dma-ranges" property exists in the
+device's parent node it will be ignored. An exception to this rule is if the
+referenced IOMMU is disabled, in which case the "dma-ranges" property of the
+parent shall take effect. Note that merely disabling a device tree node does
+not guarantee that the IOMMU is really disabled since the hardware may not
+have a means to turn off translation. But it is invalid in such cases to
+disable the IOMMU's device tree node in the first place because it would
+prevent any driver from properly setting up the translations.
+
+Optional properties:
+--------------------
+- pasid-num-bits: Some masters support multiple address spaces for DMA, by
+  tagging DMA transactions with an address space identifier. By default,
+  this is 0, which means that the device only has one address space.
+
+- dma-can-stall: When present, the master can wait for a transaction to
+  complete for an indefinite amount of time. Upon translation fault some
+  IOMMUs, instead of aborting the translation immediately, may first
+  notify the driver and keep the transaction in flight. This allows the OS
+  to inspect the fault and, for example, make physical pages resident
+  before updating the mappings and completing the transaction. Such IOMMU
+  accepts a limited number of simultaneous stalled transactions before
+  having to either put back-pressure on the master, or abort new faulting
+  transactions.
+
+  Firmware has to opt-in stalling, because most buses and masters don't
+  support it. In particular it isn't compatible with PCI, where
+  transactions have to complete before a time limit. More generally it
+  won't work in systems and masters that haven't been designed for
+  stalling. For example the OS, in order to handle a stalled transaction,
+  may attempt to retrieve pages from secondary storage in a stalled
+  domain, leading to a deadlock.
+
+
+Notes:
+======
+
+One possible extension to the above is to use an "iommus" property along with
+a "dma-ranges" property in a bus device node (such as PCI host bridges). This
+can be useful to describe how children on the bus relate to the IOMMU if they
+are not explicitly listed in the device tree (e.g. PCI devices). However, the
+requirements of that use-case haven't been fully determined yet. Implementing
+this is therefore not recommended without further discussion and extension of
+this binding.
+
+
+Examples:
+=========
+
+Single-master IOMMU:
+--------------------
+
+	iommu {
+		#iommu-cells = <0>;
+	};
+
+	master {
+		iommus = <&{/iommu}>;
+	};
+
+Multiple-master IOMMU with fixed associations:
+----------------------------------------------
+
+	/* multiple-master IOMMU */
+	iommu {
+		/*
+		 * Masters are statically associated with this IOMMU and share
+		 * the same address translations because the IOMMU does not
+		 * have sufficient information to distinguish between masters.
+		 *
+		 * Consequently address translation is always on or off for
+		 * all masters at any given point in time.
+		 */
+		#iommu-cells = <0>;
+	};
+
+	/* static association with IOMMU */
+	master@1 {
+		reg = <1>;
+		iommus = <&{/iommu}>;
+	};
+
+	/* static association with IOMMU */
+	master@2 {
+		reg = <2>;
+		iommus = <&{/iommu}>;
+	};
+
+Multiple-master IOMMU:
+----------------------
+
+	iommu {
+		/* the specifier represents the ID of the master */
+		#iommu-cells = <1>;
+	};
+
+	master@1 {
+		/* device has master ID 42 in the IOMMU */
+		iommus = <&{/iommu} 42>;
+	};
+
+	master@2 {
+		/* device has master IDs 23 and 24 in the IOMMU */
+		iommus = <&{/iommu} 23>, <&{/iommu} 24>;
+	};
+
+Multiple-master IOMMU with configurable DMA window:
+---------------------------------------------------
+
+	/ {
+		iommu {
+			/*
+			 * One cell for the master ID and one cell for the
+			 * address of the DMA window. The length of the DMA
+			 * window is encoded in two cells.
+			 *
+			 * The DMA window is the range addressable by the
+			 * master (i.e. the I/O virtual address space).
+			 */
+			#iommu-cells = <4>;
+		};
+
+		master {
+			/* master ID 42, 4 GiB DMA window starting at 0 */
+			iommus = <&{/iommu}  42  0  0x1 0x0>;
+		};
+	};
diff --git a/doc/device-tree-bindings/serial/msm-geni-serial.txt b/doc/device-tree-bindings/serial/msm-geni-serial.txt
new file mode 100644
index 00000000000..9eadc2561b4
--- /dev/null
+++ b/doc/device-tree-bindings/serial/msm-geni-serial.txt
@@ -0,0 +1,6 @@
+Qualcomm GENI UART
+
+Required properties:
+- compatible: must be "qcom,msm-geni-uart"
+- reg: start address and size of the registers
+- clock: interface clock (must accept baudrate as a frequency)