Merge branch 'next'

Bring in the following merges:

commit 8fbbec12f7d2c18f8883f3371cfca74a98b5dd87
Merge: 87f69f467a83 63618e71e89b
Author: Tom Rini <trini@konsulko.com>
Date:   Fri Jan 3 09:48:47 2020 -0500

    Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq into next

    - updates and fixes on ls1028a, lx2, ls1046a, MC-DPSPARSER support

commit 87f69f467a8335b171c71bf217d2625d515acd7c
Merge: c0912f9bbfb2 4466b9970319
Author: Tom Rini <trini@konsulko.com>
Date:   Tue Dec 24 08:18:19 2019 -0500

    Merge https://gitlab.denx.de/u-boot/custodians/u-boot-mpc85xx into next

    - Enable DM driver on ppc/km boards
    - Enable DM_USB for some of NXP powerpc platforms: P5040, T4240, T208x,
      T104x, P4080, P2041, P2020, P1020, P3041
    - Some updates in mpc85xx-ddr driver, km boards

commit c0912f9bbfb26dd03d189953678691b799d35b6e
Merge: 533c9f5714bd a1d6dc3f8407
Author: Tom Rini <trini@konsulko.com>
Date:   Wed Dec 18 07:20:19 2019 -0500

    Merge branch 'next' of https://gitlab.denx.de/u-boot/custodians/u-boot-x86 into next

    - Various x86 common codes updated for TPL/SPL
    - I2C designware driver updated for PCI
    - ICH SPI driver updated to support Apollo Lake
    - Add Intel FSP2 base support
    - Intel Apollo Lake platform specific drivers support
    - Add a new board Google Chromebook Coral

commit 533c9f5714bdba79dc6f2629284d4c1a08a611d1
Merge: 553cb0688782 033e18b47bd0
Author: Tom Rini <trini@konsulko.com>
Date:   Tue Dec 17 07:53:08 2019 -0500

    Merge tag '20191217-for-next' of https://gitlab.denx.de/u-boot/custodians/u-boot-i2c into next

    i2c: for next
    - misc: i2c_eeprom:
      Add partition support and add ability to query size
      of eeprom device and partitions
    - i2c common:
      add support for offset overflow in to address and add
      sandbox tests for it.

commit 553cb06887825314e74a9bdac337467c77d1db88
Merge: f39abbbc531e b4f98b3b16ec
Author: Tom Rini <trini@konsulko.com>
Date:   Thu Dec 12 08:18:59 2019 -0500

    Merge tag 'dm-next-13dec19' of https://gitlab.denx.de/u-boot/custodians/u-boot-dm into next

    buildman improvements including toolchain environment feature
    sandbox unicode support in serial

6 files changed, 366 insertions, 0 deletions

diff --git a/doc/board/google/chromebook_coral.rst b/doc/board/google/chromebook_coral.rst
new file mode 100644
index 0000000000..515fd06d76
--- /dev/null
+++ b/doc/board/google/chromebook_coral.rst
@@ -0,0 +1,241 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Simon Glass <sjg@chromium.org>
+
+Chromebook Coral
+================
+
+Coral is a Chromebook (or really about 20 different Chromebooks) which use the
+Intel Apollo Lake platform (APL). The 'reef' Chromebooks use the same APL SoC so
+should also work. Some later ones based on Glacier Lake (GLK) need various
+changes in GPIOs, etc. but are very similar.
+
+It is hoped that this port can enable ports to embedded APL boards which are
+starting to appear.
+
+Note that booting U-Boot on APL is already supported by coreboot and
+Slim Bootloader. This documentation refers to a 'bare metal' port.
+
+
+Boot flow - TPL
+---------------
+
+Apollo Lake boots via an IFWI (Integrated Firmware Image). TPL is placed in
+this, in the IBBL entry.
+
+On boot, an on-chip microcontroller called the CSE (Converged Security Engine)
+sets up some SDRAM at ffff8000 and loads the TPL image to that address. The
+SRAM extends up to the top of 32-bit address space, but the last 2KB is the
+start16 region, so the TPL image must be 30KB at most, and CONFIG_TPL_TEXT_BASE
+must be ffff8000. Actually the start16 region is small and it could probably
+move from f800 to fe00, providing another 1.5KB, but TPL is only about 19KB so
+there is no need to change it at present. The size limit is enforced by
+CONFIG_TPL_SIZE_LIMIT to avoid producing images that won't boot.
+
+TPL (running from start.S) first sets up CAR (Cache-as-RAM) which provides
+larger area of RAM for use while booting. CAR is mapped at CONFIG_SYS_CAR_ADDR
+(fef00000) and is 768KB in size. It then sets up the stack in the botttom 64KB
+of this space (i.e. below fef10000). This means that the stack and early
+malloc() region in TPL can be 64KB at most.
+
+TPL operates without CONFIG_TPL_PCI enabled so PCI config access must use the
+x86-specific functions pci_x86_write_config(), etc. SPL creates a simple-bus
+device so that PCI devices are bound by driver model. Then arch_cpu_init_tpl()
+is called to early init on various devices. This includes placing PCI devices
+at hard-coded addresses in the memory map. PCI auto-config is not used.
+
+Most of the 16KB ROM is mapped into the very top of memory, except for the
+Intel descriptor (first 4KB) and the space for SRAM as above.
+
+TPL does not set up a bloblist since at present it does not have anything to
+pass to SPL.
+
+Once TPL is done it loads SPL from ROM using either the memory-mapped SPI or by
+using the Intel fast SPI driver. SPL is loaded into CAR, at the address given
+by CONFIG_SPL_TEXT_BASE, which is normally fef10000.
+
+Note that booting using the SPI driver results in an TPL image that is about
+26KB in size instead of 19KB. Also boot speed is worse by about 340ms. If you
+really want to use the driver, enable CONFIG_APL_SPI_FLASH_BOOT and set
+BOOT_FROM_FAST_SPI_FLASH to true[2].
+
+
+Boot flow - SPL
+---------------
+
+SPL (running from start_from_tpl.S) continues to use the same stack as TPL.
+It calls arch_cpu_init_spl() to set up a few devices, then init_dram() loads
+the FSP-M binary into CAR and runs to, to set up SDRAM. The address of the
+output 'HOB' list (Hand-off-block) is stored into gd->arch.hob_list for parsing.
+There is a 2GB chunk of SDRAM starting at 0 and the rest is at 4GB.
+
+PCI auto-config is not used in SPL either, but CONFIG_SPL_PCI is defined, so
+proper PCI access is available and normal dm_pci_read_config() calls can be
+used. However PCI auto-config is not used so the same static memory mapping set
+up by TPL is still active.
+
+SPL on x86 always runs with CONFIG_SPL_SEPARATE_BSS=y and BSS is at 120000
+(see u-boot-spl.lds). This works because SPL doesn't access BSS until after
+board_init_r(), as per the rules, and DRAM is available then.
+
+SPL sets up a bloblist and passes the SPL hand-off information to U-Boot proper.
+This includes a pointer to the HOB list as well as DRAM information. See
+struct arch_spl_handoff. The bloblist address is set by CONFIG_BLOBLIST_ADDR,
+normally 100000.
+
+SPL uses SPI flash to update the MRC caches in ROM. This speeds up subsequent
+boots. Be warned that SPL can take 30 seconds without this cache! This is a
+known issue with Intel SoCs with modern DRAM and apparently cannot be improved.
+The MRC caches are used to work around this.
+
+Once SPL is finished it loads U-Boot into SDRAM at CONFIG_SYS_TEXT_BASE, which
+is normally 1110000. Note that CAR is still active.
+
+
+Boot flow - U-Boot pre-relocation
+---------------------------------
+
+U-Boot (running from start_from_spl.S) starts running in RAM and uses the same
+stack as SPL. It does various init activities before relocation. Notably
+arch_cpu_init_dm() sets up the pin muxing for the chip using a very large table
+in the device tree.
+
+PCI auto-config is not used before relocation, but CONFIG_PCI of course is
+defined, so proper PCI access is available. The same static memory mapping set
+up by TPL is still active until relocation.
+
+As per usual, U-Boot allocates memory at the top of available RAM (a bit below
+2GB in this case) and copies things there ready to relocate itself. Notably
+reserve_arch() does not reserve space for the HOB list returned by FSP-M since
+this is already located in RAM.
+
+U-Boot then shuts down CAR and jumps to its relocated version.
+
+
+Boot flow - U-Boot post-relocation
+---------------------------------
+
+U-Boot starts up normally, running near the top of RAM. After driver model is
+running, arch_fsp_init_r() is called which loads and runs the FSP-S binary.
+This updates the HOB list to include graphics information, used by the fsp_video
+driver.
+
+PCI autoconfig is done and a few devices are probed to complete init. Most
+others are started only when they are used.
+
+Note that FSP-S is supposed to run after CAR has been shut down, which happens
+immediately before U-Boot starts up in its relocated position. Therefore we
+cannot run FSP-S before relocation. On the other hand we must run it before
+PCI auto-config is done, since FSP-S may show or hide devices. The first device
+that probes PCI after relocation is the serial port, in initr_serial(), so FSP-S
+must run before that. A corollary is that loading FSP-S must be done without
+using the SPI driver, to avoid probing PCI and causing an autoconfig, so
+memory-mapped reading is always used for FSP-S.
+
+It would be possible to tear down CAR in SPL instead of U-Boot. The SPL handoff
+information could make sure it does not include any pointers into CAR (in fact
+it doesn't). But tearing down CAR in U-Boot allows the initial state used by TPL
+and SPL to be read by U-Boot, which seems useful. It also matches how older
+platforms start up (those that don't use SPL).
+
+
+Performance
+-----------
+
+Bootstage is used through all phases of U-Boot to keep accurate timimgs for
+boot. Use 'bootstage report' in U-Boot to see the report, e.g.:
+
+Timer summary in microseconds (16 records):
+       Mark    Elapsed  Stage
+          0          0  reset
+    155,325    155,325  TPL
+    204,014     48,689  end TPL
+    204,385        371  SPL
+    738,633    534,248  end SPL
+    739,161        528  board_init_f
+    842,764    103,603  board_init_r
+  1,166,233    323,469  main_loop
+  1,166,283         50  id=175
+
+Accumulated time:
+                    62  fast_spi
+                   202  dm_r
+                 7,779  dm_spl
+                15,555  dm_f
+               208,357  fsp-m
+               239,847  fsp-s
+               292,143  mmap_spi
+
+CPU performance is about 3500 DMIPS:
+
+=> dhry
+1000000 iterations in 161 ms: 6211180/s, 3535 DMIPS
+
+
+Partial memory map
+------------------
+
+ffffffff	Top of ROM (and last byte of 32-bit address space)
+ffff8000	TPL loaded here (from IFWI)
+ff000000	Bottom of ROM
+fefc000		 Top of CAR region
+fef96000	Stack for FSP-M
+fef40000 59000	FSP-M
+fef11000	SPL loaded here
+fef10000	CONFIG_BLOBLIST_ADDR
+fef10000	Stack top in TPL, SPL and U-Boot before relocation
+fef00000  1000	CONFIG_BOOTSTAGE_STASH_ADDR
+fef00000	Base of CAR region
+
+   f0000	CONFIG_ROM_TABLE_ADDR
+  120000	BSS (defined in u-boot-spl.lds)
+  200000	FSP-S (which is run after U-Boot is relocated)
+ 1110000	CONFIG_SYS_TEXT_BASE
+
+
+Supported peripherals
+---------------------
+
+- UART
+- SPI flash
+- Video
+- MMC (dev 0) and micro-SD (dev 1)
+- Chrome OS EC
+- Keyboard
+- USB
+
+
+To do
+-----
+
+- Finish peripherals
+   - left-side USB
+   - USB-C
+   - Cr50 (security chip: a basic driver is running but not included here)
+   - I2C (driver exists but not enabled in device tree)
+   - Sound (Intel I2S support exists, but need da7219 driver)
+   - RTC (driver exists but not enabled in device tree)
+   - Various minor features supported by LPC, etc.
+- Booting Chrome OS, e.g. with verified boot
+- Integrate with Chrome OS vboot
+- Improvements to booting from coreboot (i.e. as a coreboot target)
+- Use FSP-T binary instead of our own CAR implementation
+- Use the official FSP package instead of the coreboot one
+- Enable all CPU cores
+- Suspend / resume
+- ACPI
+
+
+Credits
+-------
+
+This is a spare-time project conducted slowly over a long period of time.
+
+Much of the code for this port came from Coreboot, an open-source firmware
+project similar to U-Boot's SPL in terms of features.
+
+Also see [2] for information about the boot flow used by coreboot. It is
+similar, but has an extra postcar stage. U-Boot doesn't need this since it
+supports relocating itself in memory.
+
+
+[2] Intel PDF https://www.coreboot.org/images/2/23/Apollolake_SoC.pdf
diff --git a/doc/board/google/index.rst b/doc/board/google/index.rst
index 7f557feb44..061c797718 100644
--- a/doc/board/google/index.rst
+++ b/doc/board/google/index.rst
@@ -6,5 +6,6 @@ Google
 .. toctree::
    :maxdepth: 2
 
+   chromebook_coral
    chromebook_link
    chromebook_samus
diff --git a/doc/device-tree-bindings/gpio/intel,apl-gpio.txt b/doc/device-tree-bindings/gpio/intel,apl-gpio.txt
new file mode 100644
index 0000000000..e27a40b437
--- /dev/null
+++ b/doc/device-tree-bindings/gpio/intel,apl-gpio.txt
@@ -0,0 +1,55 @@
+Intel Apollo Lake GPIO controller
+
+The Apollo Lake (APL) GPIO controller is used to control GPIO functions of
+the pins.
+
+Required properties:
+- compatible: "intel,apl-gpio"
+- #gpio-cells: Should be 2. The syntax of the gpio specifier used by client
+  nodes should be the following with values derived from the SoC user manual.
+     <[phandle of the gpio controller node]
+      [pin number within the gpio controller]
+      [flags]>
+
+  Values for gpio specifier:
+  - Pin number: is a GPIO pin number between 0 and 244
+  - Flags: GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW
+
+- gpio-controller: Specifies that the node is a gpio controller.
+
+Example:
+
+...
+{
+	p2sb: p2sb@d,0 {
+		reg = <0x02006810 0 0 0 0>;
+		compatible = "intel,apl-p2sb";
+		early-regs = <IOMAP_P2SB_BAR 0x100000>;
+
+		north {
+			compatible = "intel,apl-pinctrl";
+			intel,p2sb-port-id = <PID_GPIO_N>;
+			gpio_n: gpio-n {
+				compatible = "intel,gpio";
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+		};
+	};
+
+	i2c_2: i2c2@16,2 {
+		compatible = "intel,apl-i2c", "snps,designware-i2c-pci";
+		reg = <0x0200b210 0 0 0 0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		clock-frequency = <400000>;
+		tpm@50 {
+			reg = <0x50>;
+			compatible = "google,cr50";
+			u-boot,i2c-offset-len = <0>;
+			ready-gpio = <&gpio_n GPIO_28 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+};
+...
diff --git a/doc/device-tree-bindings/pci/x86-pci.txt b/doc/device-tree-bindings/pci/x86-pci.txt
new file mode 100644
index 0000000000..3aa5bd9a46
--- /dev/null
+++ b/doc/device-tree-bindings/pci/x86-pci.txt
@@ -0,0 +1,24 @@
+x86 PCI DT details:
+===================
+
+Some options are available to affect how PCI operates on x86.
+
+Optional properties:
+- u-boot,skip-auto-config-until-reloc : Don't set up PCI configuration until
+	after U-Boot has relocated. Normally if PCI is used before relocation,
+	this happens before relocation also. Some platforms set up static
+	configuration in TPL/SPL to reduce code size and boot time, since these
+	phases only know about a small subset of PCI devices.
+
+Example:
+
+pci {
+	compatible = "pci-x86";
+	#address-cells = <3>;
+	#size-cells = <2>;
+	u-boot,dm-pre-reloc;
+	ranges = <0x02000000 0x0 0xc0000000 0xc0000000 0 0x10000000
+		0x42000000 0x0 0xb0000000 0xb0000000 0 0x10000000
+		0x01000000 0x0 0x1000 0x1000 0 0xefff>;
+	u-boot,skip-auto-config-until-reloc;
+};
diff --git a/doc/device-tree-bindings/pinctrl/intel,apl-pinctrl.txt b/doc/device-tree-bindings/pinctrl/intel,apl-pinctrl.txt
new file mode 100644
index 0000000000..cd7f8a0ca3
--- /dev/null
+++ b/doc/device-tree-bindings/pinctrl/intel,apl-pinctrl.txt
@@ -0,0 +1,39 @@
+* Intel Apollo Lake pin controller
+
+The Apollo Lake (APL) pin controller is used to select the function of a pin
+and to configure it.
+
+Required properties:
+- compatible: "intel,apl-pinctrl"
+- intel,p2sb-port-id: Port ID number within the parent P2SB
+- reg: PCI address of the controller
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices.
+
+Optional subnodes:
+
+GPIO nodes may be added as children of the pinctrl nodes. See intel,apl-gpio
+for the binding.
+
+
+Example:
+
+...
+{
+	p2sb: p2sb@d,0 {
+		reg = <0x02006810 0 0 0 0>;
+		compatible = "intel,apl-p2sb";
+		early-regs = <IOMAP_P2SB_BAR 0x100000>;
+
+		n {
+			compatible = "intel,apl-pinctrl";
+			intel,p2sb-port-id = <PID_GPIO_N>;
+			gpio_n: gpio-n {
+				compatible = "intel,apl-gpio";
+				#gpio-cells = <2>;
+			};
+		};
+	};
+};
+...
diff --git a/doc/driver-model/of-plat.rst b/doc/driver-model/of-plat.rst
index 557957d2a1..034a68bb4e 100644
--- a/doc/driver-model/of-plat.rst
+++ b/doc/driver-model/of-plat.rst
@@ -279,6 +279,12 @@ For example:
     };
 
 
+Note that struct mmc_platdata is defined in the C file, not in a header. This
+is to avoid needing to include dt-structs.h in a header file. The idea is to
+keep the use of each of-platdata struct to the smallest possible code area.
+There is just one driver C file for each struct, that can convert from the
+of-platdata struct to the standard one used by the driver.
+
 In the case where SPL_OF_PLATDATA is enabled, platdata_auto_alloc_size is
 still used to allocate space for the platform data. This is different from
 the normal behaviour and is triggered by the use of of-platdata (strictly