[U-Boot] [PATCH v2 00/22] rockchip: Add support for Asus Chromebit

[U-Boot] [PATCH v2 00/22] rockchip: Add support for Asus Chromebit

[Simon Glass]

This series adds support for 'mickey', the Asus Chromebit based on Rockchip
RK3288.

Some refactoring is included to jerry also. The intent is that all
RK3288-based Chromebooks will use the 'veyron' board, with everything
common except the device tree. SPI is used to boot, and we move jerry to
use of-platdata to save space.

At present there are few boards in U-Boot with two displays. Jerry supports
both its internal EDP display and HDMI. The current driver can get confused
if both HDMI and EDP try to use the same video-out device (VOP). Some
adjustments are made to fix this.

Currently there is an option to increase the CPU speed in SPL. This does
not seem necessary with mickey, so instead, this is done in U-Boot proper.

Additionally some bugs have crept in as part of the clock API conversion
and other work, so this series fixes those.

Changes in v2:
- Fix CONFIG_IS_ENABLED condition
- Add new patch with note about the SDRAM voltage
- Add new patch to avoid using u8 in the HDMI driver
- Enable only the active eMMC port

Simon Glass (22):
  rockchip: video: Correct HDMI data source selection
  rockchip: video: Correct VOP clock selection
  rockchip: Allow jerry to use of-platdata
  dm: core: Handle global_data moving in SPL
  stdio: Correct code style nits
  stdio: Correct numbering logic in stdio_probe_device()
  spi: Add of-platdata support to SPI and SPI flash
  rockchip: spi: Add support for of-platdata
  rockchip: spi: Honour the deactivation delay
  spi: Add error checking for invalid bus widths
  spi: Add a debug() on bind failure
  video: Use cache-alignment in video_sync()
  video: Track whether a display is in use
  rockchip: video: Check for device in use
  rockchip: Move jerry to use of-platdata
  rockchip: Rename jerry files to veyron
  rockchip: veyron: Add a note about the SDRAM voltage
  rockchip: Move jerry SDRAM settings into its own .dts file
  rockchip: clk: Support setting ACLK
  rockchip: veyron: Adjust ARM clock after relocation
  rockchip: video: Avoid using u8 in the HDMI driver
  rockchip: Add support for veyron-mickey (Chromebit)

 arch/arm/dts/Makefile                              |   3 +-
 arch/arm/dts/rk3288-veyron-chromebook.dtsi         |   2 +
 .../{rk3288-jerry.dts => rk3288-veyron-jerry.dts}  |  16 +-
 arch/arm/dts/rk3288-veyron-mickey.dts              | 277 +++++++++++++++++++++
 arch/arm/dts/rk3288-veyron.dtsi                    |   8 -
 arch/arm/mach-rockchip/rk3288-board-spl.c          |   3 +
 arch/arm/mach-rockchip/rk3288-board.c              |  44 ++++
 arch/arm/mach-rockchip/rk3288/Kconfig              |  11 +-
 board/google/chromebook_jerry/Kconfig              |  15 --
 board/google/chromebook_jerry/MAINTAINERS          |   6 -
 board/google/chromebook_jerry/jerry.c              |   7 -
 board/google/veyron/Kconfig                        |  31 +++
 board/google/veyron/MAINTAINERS                    |  13 +
 board/google/{chromebook_jerry => veyron}/Makefile |   2 +-
 board/google/veyron/veyron.c                       |  13 +
 common/spl/spl.c                                   |   3 +
 common/stdio.c                                     |   9 +-
 configs/chromebit_mickey_defconfig                 |  84 +++++++
 configs/chromebook_jerry_defconfig                 |  10 +-
 drivers/clk/rockchip/clk_rk3288.c                  |   7 +
 drivers/core/root.c                                |   7 +
 drivers/mtd/spi/spi_flash.c                        |   2 +-
 drivers/spi/rk_spi.c                               |  44 +++-
 drivers/spi/spi-uclass.c                           |  26 +-
 drivers/video/display-uclass.c                     |  18 +-
 drivers/video/rockchip/rk_hdmi.c                   |  33 +--
 drivers/video/rockchip/rk_vop.c                    |  16 +-
 drivers/video/video-uclass.c                       |   3 +-
 include/configs/{chromebook_jerry.h => veyron.h}   |   0
 include/display.h                                  |  10 +
 include/dm/root.h                                  |  10 +
 31 files changed, 648 insertions(+), 85 deletions(-)
 rename arch/arm/dts/{rk3288-jerry.dts => rk3288-veyron-jerry.dts} (92%)
 create mode 100644 arch/arm/dts/rk3288-veyron-mickey.dts
 delete mode 100644 board/google/chromebook_jerry/Kconfig
 delete mode 100644 board/google/chromebook_jerry/MAINTAINERS
 delete mode 100644 board/google/chromebook_jerry/jerry.c
 create mode 100644 board/google/veyron/Kconfig
 create mode 100644 board/google/veyron/MAINTAINERS
 rename board/google/{chromebook_jerry => veyron}/Makefile (81%)
 create mode 100644 board/google/veyron/veyron.c
 create mode 100644 configs/chromebit_mickey_defconfig
 rename include/configs/{chromebook_jerry.h => veyron.h} (100%)

-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 01/22] rockchip: video: Correct HDMI data source selection

[Simon Glass]

This code currently always selects the second source. It only worked
because both sources are set up.

With the change to only init video devices that are present in the stdout
environment variable, this fails. Fix it.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 drivers/video/rockchip/rk_hdmi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/rockchip/rk_hdmi.c b/drivers/video/rockchip/rk_hdmi.c
index 7976c5e..72142dc 100644
--- a/drivers/video/rockchip/rk_hdmi.c
+++ b/drivers/video/rockchip/rk_hdmi.c
@@ -899,7 +899,8 @@ static int rk_hdmi_probe(struct udevice *dev)
 	rk_setreg(&priv->grf->soc_con6, 1 << 15);
 
 	/* hdmi data from vop id */
-	rk_setreg(&priv->grf->soc_con6, (vop_id == 1) ? (1 << 4) : (1 << 4));
+	rk_clrsetreg(&priv->grf->soc_con6, 1 << 4,
+		     (vop_id == 1) ? (1 << 4) : 0);
 
 	ret = hdmi_wait_for_hpd(priv->regs);
 	if (ret < 0) {
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 01/22] rockchip: video: Correct HDMI data source selection

[Simon Glass]

On 13 November 2016 at 14:21, Simon Glass <sjg@chromium.org> wrote:
> This code currently always selects the second source. It only worked
> because both sources are set up.
>
> With the change to only init video devices that are present in the stdout
> environment variable, this fails. Fix it.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2: None
>
>  drivers/video/rockchip/rk_hdmi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied to u-boot-rockchip.

[U-Boot] [PATCH v2 02/22] rockchip: video: Correct VOP clock selection

[Simon Glass]

This code incorrectly uses the oscillator. It should use the clock
selected in the device tree.

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 135aa95 (clk: convert API to match reset/mailbox style)
---

Changes in v2: None

 drivers/video/rockchip/rk_vop.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/video/rockchip/rk_vop.c b/drivers/video/rockchip/rk_vop.c
index c6d88d9..130dace 100644
--- a/drivers/video/rockchip/rk_vop.c
+++ b/drivers/video/rockchip/rk_vop.c
@@ -195,7 +195,6 @@ int rk_display_init(struct udevice *dev, ulong fbbase,
 	struct udevice *disp;
 	int ret, remote, i, offset;
 	struct display_plat *disp_uc_plat;
-	struct udevice *dev_clk;
 	struct clk clk;
 
 	vop_id = fdtdec_get_int(blob, ep_node, "reg", -1);
@@ -238,11 +237,7 @@ int rk_display_init(struct udevice *dev, ulong fbbase,
 		return ret;
 	}
 
-	ret = rockchip_get_clk(&dev_clk);
-	if (!ret) {
-		clk.id = DCLK_VOP0 + remote_vop_id;
-		ret = clk_request(dev_clk, &clk);
-	}
+	ret = clk_get_by_index(dev, 1, &clk);
 	if (!ret)
 		ret = clk_set_rate(&clk, timing.pixelclock.typ);
 	if (ret) {
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 03/22] rockchip: Allow jerry to use of-platdata

[Simon Glass]

This board always boots from SPI, so update the code to support that with
of-platdata. The boot source is not currently available with of-platdata.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 arch/arm/mach-rockchip/rk3288-board-spl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c b/arch/arm/mach-rockchip/rk3288-board-spl.c
index 0f40351..185b5fd 100644
--- a/arch/arm/mach-rockchip/rk3288-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3288-board-spl.c
@@ -64,6 +64,8 @@ u32 spl_boot_device(void)
 	}
 
 fallback:
+#elif defined(CONFIG_TARGET_CHROMEBOOK_JERRY)
+	return BOOT_DEVICE_SPI;
 #endif
 	return BOOT_DEVICE_MMC1;
 }
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 03/22] rockchip: Allow jerry to use of-platdata

[Simon Glass]

On 13 November 2016 at 14:21, Simon Glass <sjg@chromium.org> wrote:
> This board always boots from SPI, so update the code to support that with
> of-platdata. The boot source is not currently available with of-platdata.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2: None
>
>  arch/arm/mach-rockchip/rk3288-board-spl.c | 2 ++
>  1 file changed, 2 insertions(+)

Applied to u-boot-rockchip.

[U-Boot] [PATCH v2 04/22] dm: core: Handle global_data moving in SPL

[Simon Glass]

When CONFIG_SPL_STACK_R is enabled, and spl_init() is called before
board_init_r(), spl_relocate_stack_gd() will move global_data to a new
place in memory. This affects driver model since it uses a list for the
uclasses. Unless this is updated the list will become invalid. When
looking for a non-existent uclass, such as when adding a new one, the loop
in uclass_find() may continue forever, thus causing a hang.

Add a function to correct this rather obscure bug.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2:
- Fix CONFIG_IS_ENABLED condition

 common/spl/spl.c    |  3 +++
 drivers/core/root.c |  7 +++++++
 include/dm/root.h   | 10 ++++++++++
 3 files changed, 20 insertions(+)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index bdb165a..d16cd18 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -511,6 +511,9 @@ ulong spl_relocate_stack_gd(void)
 	ptr = CONFIG_SPL_STACK_R_ADDR - roundup(sizeof(gd_t),16);
 	new_gd = (gd_t *)ptr;
 	memcpy(new_gd, (void *)gd, sizeof(gd_t));
+#if CONFIG_IS_ENABLED(DM)
+	dm_fixup_for_gd_move(new_gd);
+#endif
 #if !defined(CONFIG_ARM)
 	gd = new_gd;
 #endif
diff --git a/drivers/core/root.c b/drivers/core/root.c
index 33dc9c0..9edfc1e 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -41,6 +41,13 @@ struct udevice *dm_root(void)
 	return gd->dm_root;
 }
 
+void dm_fixup_for_gd_move(struct global_data *new_gd)
+{
+	/* The sentinel node has moved, so update things that point to it */
+	new_gd->uclass_root.next->prev = &new_gd->uclass_root;
+	new_gd->uclass_root.prev->next = &new_gd->uclass_root;
+}
+
 fdt_addr_t dm_get_translation_offset(void)
 {
 	struct udevice *root = dm_root();
diff --git a/include/dm/root.h b/include/dm/root.h
index c7f0c1d..3cf730d 100644
--- a/include/dm/root.h
+++ b/include/dm/root.h
@@ -21,6 +21,16 @@ struct udevice;
  */
 struct udevice *dm_root(void);
 
+struct global_data;
+/**
+ * dm_fixup_for_gd_move() - Handle global_data moving to a new place
+ *
+ * The uclass list is part of global_data. Due to the way lists work, moving
+ * the list will cause it to become invalid. This function fixes that up so
+ * that the uclass list will work correctly.
+ */
+void dm_fixup_for_gd_move(struct global_data *new_gd);
+
 /**
  * dm_scan_platdata() - Scan all platform data and bind drivers
  *
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 05/22] stdio: Correct code style nits

[Simon Glass]

Fix a few code style nits in stdio_get_by_name().

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 common/stdio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/stdio.c b/common/stdio.c
index 8e4a9be..a7d016b 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -173,12 +173,12 @@ static int stdio_probe_device(const char *name, enum uclass_id id,
 }
 #endif
 
-struct stdio_dev* stdio_get_by_name(const char *name)
+struct stdio_dev *stdio_get_by_name(const char *name)
 {
 	struct list_head *pos;
 	struct stdio_dev *sdev;
 
-	if(!name)
+	if (!name)
 		return NULL;
 
 	list_for_each(pos, &(devs.list)) {
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 05/22] stdio: Correct code style nits

[Simon Glass]

On 13 November 2016 at 14:21, Simon Glass <sjg@chromium.org> wrote:
> Fix a few code style nits in stdio_get_by_name().
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2: None
>
>  common/stdio.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied to u-boot-rockchip.

[U-Boot] [PATCH v2 06/22] stdio: Correct numbering logic in stdio_probe_device()

[Simon Glass]

The current code assumes that the devices are ordered corresponding to
their alias value. But (for example) video1 can come before video0 in the
device tree.

Correct this, by always looking for device 0 first. After that we can fall
back to finding the first available device.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 common/stdio.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/common/stdio.c b/common/stdio.c
index a7d016b..4d30017 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -151,9 +151,10 @@ static int stdio_probe_device(const char *name, enum uclass_id id,
 	*sdevp = NULL;
 	seq = trailing_strtoln(name, NULL);
 	if (seq == -1)
+		seq = 0;
+	ret = uclass_get_device_by_seq(id, seq, &dev);
+	if (ret == -ENODEV)
 		ret = uclass_first_device_err(id, &dev);
-	else
-		ret = uclass_get_device_by_seq(id, seq, &dev);
 	if (ret) {
 		debug("No %s device for seq %d (%s)\n", uclass_get_name(id),
 		      seq, name);
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 06/22] stdio: Correct numbering logic in stdio_probe_device()

[Simon Glass]

On 13 November 2016 at 14:22, Simon Glass <sjg@chromium.org> wrote:
> The current code assumes that the devices are ordered corresponding to
> their alias value. But (for example) video1 can come before video0 in the
> device tree.
>
> Correct this, by always looking for device 0 first. After that we can fall
> back to finding the first available device.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2: None
>
>  common/stdio.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Applied to u-boot-rockchip.

[U-Boot] [PATCH v2 07/22] spi: Add of-platdata support to SPI and SPI flash

[Simon Glass]

Some boards may want to use these subsystems with of-platdata in SPL. Add
support for this by avoiding any device tree access in this case.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 drivers/mtd/spi/spi_flash.c |  2 +-
 drivers/spi/spi-uclass.c    | 13 ++++++++++++-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 7f6e9ae..6571f86 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -1228,7 +1228,7 @@ int spi_flash_scan(struct spi_flash *flash)
 		return ret;
 #endif
 
-#if CONFIG_IS_ENABLED(OF_CONTROL)
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
 	ret = spi_flash_decode_fdt(gd->fdt_blob, flash);
 	if (ret) {
 		debug("SF: FDT decode error\n");
diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index d9c49e4..26eada2 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -108,6 +108,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
 	return dm_spi_xfer(slave->dev, bitlen, dout, din, flags);
 }
 
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
 static int spi_child_post_bind(struct udevice *dev)
 {
 	struct dm_spi_slave_platdata *plat = dev_get_parent_platdata(dev);
@@ -117,14 +118,16 @@ static int spi_child_post_bind(struct udevice *dev)
 
 	return spi_slave_ofdata_to_platdata(gd->fdt_blob, dev->of_offset, plat);
 }
+#endif
 
 static int spi_post_probe(struct udevice *bus)
 {
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
 	struct dm_spi_bus *spi = dev_get_uclass_priv(bus);
 
 	spi->max_hz = fdtdec_get_int(gd->fdt_blob, bus->of_offset,
 				     "spi-max-frequency", 0);
-
+#endif
 #if defined(CONFIG_NEEDS_MANUAL_RELOC)
 	struct dm_spi_ops *ops = spi_get_ops(bus);
 
@@ -274,7 +277,11 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int mode,
 	bool created = false;
 	int ret;
 
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+	ret = uclass_first_device_err(UCLASS_SPI, &bus);
+#else
 	ret = uclass_get_device_by_seq(UCLASS_SPI, busnum, &bus);
+#endif
 	if (ret) {
 		printf("Invalid bus %d (err=%d)\n", busnum, ret);
 		return ret;
@@ -436,14 +443,18 @@ UCLASS_DRIVER(spi) = {
 	.id		= UCLASS_SPI,
 	.name		= "spi",
 	.flags		= DM_UC_FLAG_SEQ_ALIAS,
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
 	.post_bind	= dm_scan_fdt_dev,
+#endif
 	.post_probe	= spi_post_probe,
 	.child_pre_probe = spi_child_pre_probe,
 	.per_device_auto_alloc_size = sizeof(struct dm_spi_bus),
 	.per_child_auto_alloc_size = sizeof(struct spi_slave),
 	.per_child_platdata_auto_alloc_size =
 			sizeof(struct dm_spi_slave_platdata),
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
 	.child_post_bind = spi_child_post_bind,
+#endif
 };
 
 UCLASS_DRIVER(spi_generic) = {
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 08/22] rockchip: spi: Add support for of-platdata

[Simon Glass]

Allow this driver to be used with of-platdata on rk3288.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 drivers/spi/rk_spi.c | 36 +++++++++++++++++++++++++++++++++++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/rk_spi.c b/drivers/spi/rk_spi.c
index 105ee4a..8d64249 100644
--- a/drivers/spi/rk_spi.c
+++ b/drivers/spi/rk_spi.c
@@ -12,6 +12,7 @@
 #include <common.h>
 #include <clk.h>
 #include <dm.h>
+#include <dt-structs.h>
 #include <errno.h>
 #include <spi.h>
 #include <linux/errno.h>
@@ -27,6 +28,9 @@ DECLARE_GLOBAL_DATA_PTR;
 #define DEBUG_RK_SPI	0
 
 struct rockchip_spi_platdata {
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+	struct dtd_rockchip_rk3288_spi of_plat;
+#endif
 	s32 frequency;		/* Default clock frequency, -1 for none */
 	fdt_addr_t base;
 	uint deactivate_delay_us;	/* Delay to wait after deactivate */
@@ -127,9 +131,29 @@ static void spi_cs_deactivate(struct udevice *dev, uint cs)
 		priv->last_transaction_us = timer_get_us();
 }
 
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+static int conv_of_platdata(struct udevice *dev)
+{
+	struct rockchip_spi_platdata *plat = dev->platdata;
+	struct dtd_rockchip_rk3288_spi *dtplat = &plat->of_plat;
+	struct rockchip_spi_priv *priv = dev_get_priv(dev);
+	int ret;
+
+	plat->base = dtplat->reg[0];
+	plat->frequency = 20000000;
+	ret = clk_get_by_index_platdata(dev, 0, dtplat->clocks, &priv->clk);
+	if (ret < 0)
+		return ret;
+	dev->req_seq = 0;
+
+	return 0;
+}
+#endif
+
 static int rockchip_spi_ofdata_to_platdata(struct udevice *bus)
 {
-	struct rockchip_spi_platdata *plat = bus->platdata;
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
+	struct rockchip_spi_platdata *plat = dev_get_platdata(bus);
 	struct rockchip_spi_priv *priv = dev_get_priv(bus);
 	const void *blob = gd->fdt_blob;
 	int node = bus->of_offset;
@@ -153,6 +177,7 @@ static int rockchip_spi_ofdata_to_platdata(struct udevice *bus)
 	debug("%s: base=%x, max-frequency=%d, deactivate_delay=%d\n",
 	      __func__, (uint)plat->base, plat->frequency,
 	      plat->deactivate_delay_us);
+#endif
 
 	return 0;
 }
@@ -164,6 +189,11 @@ static int rockchip_spi_probe(struct udevice *bus)
 	int ret;
 
 	debug("%s: probe\n", __func__);
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+	ret = conv_of_platdata(bus);
+	if (ret)
+		return ret;
+#endif
 	priv->regs = (struct rockchip_spi *)plat->base;
 
 	priv->last_transaction_us = timer_get_us();
@@ -369,7 +399,11 @@ static const struct udevice_id rockchip_spi_ids[] = {
 };
 
 U_BOOT_DRIVER(rockchip_spi) = {
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+	.name	= "rockchip_rk3288_spi",
+#else
 	.name	= "rockchip_spi",
+#endif
 	.id	= UCLASS_SPI,
 	.of_match = rockchip_spi_ids,
 	.ops	= &rockchip_spi_ops,
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 09/22] rockchip: spi: Honour the deactivation delay

[Simon Glass]

This is not currently implemented. Add support for this so that the Chrome
OS EC can be used on jerry.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 drivers/spi/rk_spi.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/spi/rk_spi.c b/drivers/spi/rk_spi.c
index 8d64249..15cf0bd 100644
--- a/drivers/spi/rk_spi.c
+++ b/drivers/spi/rk_spi.c
@@ -110,6 +110,14 @@ static void spi_cs_activate(struct udevice *dev, uint cs)
 	struct rockchip_spi_priv *priv = dev_get_priv(bus);
 	struct rockchip_spi *regs = priv->regs;
 
+	/* If it's too soon to do another transaction, wait */
+	if (plat->deactivate_delay_us && priv->last_transaction_us) {
+		ulong delay_us;		/* The delay completed so far */
+		delay_us = timer_get_us() - priv->last_transaction_us;
+		if (delay_us < plat->deactivate_delay_us)
+			udelay(plat->deactivate_delay_us - delay_us);
+	}
+
 	debug("activate cs%u\n", cs);
 	writel(1 << cs, &regs->ser);
 	if (plat->activate_delay_us)
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Simon Glass]

At present an invalid bus width prints a message but does not return an
error. This is the opposite of the correct behaviour. Adjust it to avoid
code bloat in the common case, and avoid hard-to-debug failure in the
uncommon case.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 drivers/spi/spi-uclass.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index 26eada2..358e229 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -415,8 +415,8 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
 		mode |= SPI_TX_QUAD;
 		break;
 	default:
-		error("spi-tx-bus-width %d not supported\n", value);
-		break;
+		debug("spi-tx-bus-width %d not supported\n", value);
+		return -EPROTONOSUPPORT;
 	}
 
 	value = fdtdec_get_uint(blob, node, "spi-rx-bus-width", 1);
@@ -430,8 +430,8 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
 		mode |= SPI_RX_QUAD;
 		break;
 	default:
-		error("spi-rx-bus-width %d not supported\n", value);
-		break;
+		debug("spi-rx-bus-width %d not supported\n", value);
+		return -EPROTONOSUPPORT;
 	}
 
 	plat->mode = mode;
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Jagan Teki]

On Mon, Nov 14, 2016 at 2:52 AM, Simon Glass <sjg@chromium.org> wrote:
> At present an invalid bus width prints a message but does not return an
> error. This is the opposite of the correct behaviour. Adjust it to avoid
> code bloat in the common case, and avoid hard-to-debug failure in the
> uncommon case.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2: None
>
>  drivers/spi/spi-uclass.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
> index 26eada2..358e229 100644
> --- a/drivers/spi/spi-uclass.c
> +++ b/drivers/spi/spi-uclass.c
> @@ -415,8 +415,8 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
>                 mode |= SPI_TX_QUAD;
>                 break;
>         default:
> -               error("spi-tx-bus-width %d not supported\n", value);
> -               break;
> +               debug("spi-tx-bus-width %d not supported\n", value);
> +               return -EPROTONOSUPPORT;

Why we need to return? we can simply warn saying that un-supported
width so-that the plat->mode for prior mode assignment shouldn't fail.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

[U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Simon Glass]

Hi Jagan,

On 17 November 2016 at 09:32, Jagan Teki <jagan@openedev.com> wrote:
> On Mon, Nov 14, 2016 at 2:52 AM, Simon Glass <sjg@chromium.org> wrote:
>> At present an invalid bus width prints a message but does not return an
>> error. This is the opposite of the correct behaviour. Adjust it to avoid
>> code bloat in the common case, and avoid hard-to-debug failure in the
>> uncommon case.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>> Changes in v2: None
>>
>>  drivers/spi/spi-uclass.c | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
>> index 26eada2..358e229 100644
>> --- a/drivers/spi/spi-uclass.c
>> +++ b/drivers/spi/spi-uclass.c
>> @@ -415,8 +415,8 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
>>                 mode |= SPI_TX_QUAD;
>>                 break;
>>         default:
>> -               error("spi-tx-bus-width %d not supported\n", value);
>> -               break;
>> +               debug("spi-tx-bus-width %d not supported\n", value);
>> +               return -EPROTONOSUPPORT;
>
> Why we need to return? we can simply warn saying that un-supported
> width so-that the plat->mode for prior mode assignment shouldn't fail.

My understanding (from the error()) call is that this is an error.
What should happen if an unsupported width is requested?

Regards,
Simon

[U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Fabio Estevam]

Hi Simon,

On Sun, Nov 13, 2016 at 7:22 PM, Simon Glass <sjg@chromium.org> wrote:

>  drivers/spi/spi-uclass.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
> index 26eada2..358e229 100644
> --- a/drivers/spi/spi-uclass.c
> +++ b/drivers/spi/spi-uclass.c
> @@ -415,8 +415,8 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
>                 mode |= SPI_TX_QUAD;
>                 break;
>         default:
> -               error("spi-tx-bus-width %d not supported\n", value);
> -               break;
> +               debug("spi-tx-bus-width %d not supported\n", value);
> +               return -EPROTONOSUPPORT;

EPROTONOSUPPORT means: /* Protocol not supported */, which does not
seem to be very appropriate here.

Why not return -EINVAL instead?

[U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Simon Glass]

Hi,

On 19 November 2016 at 07:53, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Simon,
>
> On Sun, Nov 13, 2016 at 7:22 PM, Simon Glass <sjg@chromium.org> wrote:
>
>>  drivers/spi/spi-uclass.c | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
>> index 26eada2..358e229 100644
>> --- a/drivers/spi/spi-uclass.c
>> +++ b/drivers/spi/spi-uclass.c
>> @@ -415,8 +415,8 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
>>                 mode |= SPI_TX_QUAD;
>>                 break;
>>         default:
>> -               error("spi-tx-bus-width %d not supported\n", value);
>> -               break;
>> +               debug("spi-tx-bus-width %d not supported\n", value);
>> +               return -EPROTONOSUPPORT;
>
> EPROTONOSUPPORT means: /* Protocol not supported */, which does not
> seem to be very appropriate here.

This is a protocol as far as I can see - you can either use one pin or
four pins.

>
> Why not return -EINVAL instead?

The value is valid but is not supported. If we just return -EINVAL for
anything we don't like, it makes it harder to root-cause the error. In
particular we use -EINVAL when decoding the device tree. But
EPROTONOSUPPORT is not widely used.

Regards,
Simon

[U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Fabio Estevam]

On Sat, Nov 19, 2016 at 6:04 PM, Simon Glass <sjg@chromium.org> wrote:

>> EPROTONOSUPPORT means: /* Protocol not supported */, which does not
>> seem to be very appropriate here.
>
> This is a protocol as far as I can see - you can either use one pin or
> four pins.

Actually they are SPI modes: one, two or four pins.

>> Why not return -EINVAL instead?
>
> The value is valid but is not supported. If we just return -EINVAL for
> anything we don't like, it makes it harder to root-cause the error. In
> particular we use -EINVAL when decoding the device tree. But
> EPROTONOSUPPORT is not widely used.

I think the current behaviour of not returning an error code on an
invalid mode is correct and it matches what the kernel does in
drivers/spi/spi.c.

If an invalid mode is passed we just ignore it and operate in single
mode instead.

Maybe we can make this clearer by printing a message like this:

--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -408,7 +408,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
                mode |= SPI_TX_QUAD;
                break;
        default:
-               error("spi-tx-bus-width %d not supported\n", value);
+               printf("spi-tx-bus-width %d not supported, operating
in single mode\n", value);
                break;
        }

@@ -423,7 +423,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
                mode |= SPI_RX_QUAD;
                break;
        default:
-               error("spi-rx-bus-width %d not supported\n", value);
+               printf("spi-rx-bus-width %d not supported, operating
in single mode\n", value);
                break;
        }

[U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Simon Glass]

Hi Fabio,

On 19 November 2016 at 13:49, Fabio Estevam <festevam@gmail.com> wrote:
> On Sat, Nov 19, 2016 at 6:04 PM, Simon Glass <sjg@chromium.org> wrote:
>
>>> EPROTONOSUPPORT means: /* Protocol not supported */, which does not
>>> seem to be very appropriate here.
>>
>> This is a protocol as far as I can see - you can either use one pin or
>> four pins.
>
> Actually they are SPI modes: one, two or four pins.
>
>>> Why not return -EINVAL instead?
>>
>> The value is valid but is not supported. If we just return -EINVAL for
>> anything we don't like, it makes it harder to root-cause the error. In
>> particular we use -EINVAL when decoding the device tree. But
>> EPROTONOSUPPORT is not widely used.
>
> I think the current behaviour of not returning an error code on an
> invalid mode is correct and it matches what the kernel does in
> drivers/spi/spi.c.
>
> If an invalid mode is passed we just ignore it and operate in single
> mode instead.
>
> Maybe we can make this clearer by printing a message like this:
>
> --- a/drivers/spi/spi-uclass.c
> +++ b/drivers/spi/spi-uclass.c
> @@ -408,7 +408,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
>                 mode |= SPI_TX_QUAD;
>                 break;
>         default:
> -               error("spi-tx-bus-width %d not supported\n", value);
> +               printf("spi-tx-bus-width %d not supported, operating
> in single mode\n", value);
>                 break;
>         }
>
> @@ -423,7 +423,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
>                 mode |= SPI_RX_QUAD;
>                 break;
>         default:
> -               error("spi-rx-bus-width %d not supported\n", value);
> +               printf("spi-rx-bus-width %d not supported, operating
> in single mode\n", value);
>                 break;
>         }

OK I took another look at the code around it and I see that I misread
it. The 'default' case really is an invalid value isn't it? So -EINVAL
is the right answer. Sorry about that.

Either it is an error, and we should return an error code, or it is
not and we should continue (and ideally not print a message since that
bloats the code).

In this case it looks wrong to me - someone has put an incorrect value
in the device tree, and they should fix it and retry.

Regards,
Simon

[U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Jagan Teki]

On Sun, Nov 20, 2016 at 2:19 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Sat, Nov 19, 2016 at 6:04 PM, Simon Glass <sjg@chromium.org> wrote:
>
>>> EPROTONOSUPPORT means: /* Protocol not supported */, which does not
>>> seem to be very appropriate here.
>>
>> This is a protocol as far as I can see - you can either use one pin or
>> four pins.
>
> Actually they are SPI modes: one, two or four pins.
>
>>> Why not return -EINVAL instead?
>>
>> The value is valid but is not supported. If we just return -EINVAL for
>> anything we don't like, it makes it harder to root-cause the error. In
>> particular we use -EINVAL when decoding the device tree. But
>> EPROTONOSUPPORT is not widely used.
>
> I think the current behaviour of not returning an error code on an
> invalid mode is correct and it matches what the kernel does in
> drivers/spi/spi.c.
>
> If an invalid mode is passed we just ignore it and operate in single
> mode instead.
>
> Maybe we can make this clearer by printing a message like this:
>
> --- a/drivers/spi/spi-uclass.c
> +++ b/drivers/spi/spi-uclass.c
> @@ -408,7 +408,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
>                 mode |= SPI_TX_QUAD;
>                 break;
>         default:
> -               error("spi-tx-bus-width %d not supported\n", value);
> +               printf("spi-tx-bus-width %d not supported, operating
> in single mode\n", value);
>                 break;
>         }
>
> @@ -423,7 +423,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
>                 mode |= SPI_RX_QUAD;
>                 break;
>         default:
> -               error("spi-rx-bus-width %d not supported\n", value);
> +               printf("spi-rx-bus-width %d not supported, operating
> in single mode\n", value);
>                 break;

Yes, this is what I am commenting about.

-EINVAL not needed, we can print "%d is not supporting and operating
in normal/single mode and move on", So-that the dts will fix if
something went wrong.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

[U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Simon Glass]

Hi Jagan,

On 21 November 2016 at 10:57, Jagan Teki <jagan@openedev.com> wrote:
> On Sun, Nov 20, 2016 at 2:19 AM, Fabio Estevam <festevam@gmail.com> wrote:
>> On Sat, Nov 19, 2016 at 6:04 PM, Simon Glass <sjg@chromium.org> wrote:
>>
>>>> EPROTONOSUPPORT means: /* Protocol not supported */, which does not
>>>> seem to be very appropriate here.
>>>
>>> This is a protocol as far as I can see - you can either use one pin or
>>> four pins.
>>
>> Actually they are SPI modes: one, two or four pins.
>>
>>>> Why not return -EINVAL instead?
>>>
>>> The value is valid but is not supported. If we just return -EINVAL for
>>> anything we don't like, it makes it harder to root-cause the error. In
>>> particular we use -EINVAL when decoding the device tree. But
>>> EPROTONOSUPPORT is not widely used.
>>
>> I think the current behaviour of not returning an error code on an
>> invalid mode is correct and it matches what the kernel does in
>> drivers/spi/spi.c.
>>
>> If an invalid mode is passed we just ignore it and operate in single
>> mode instead.
>>
>> Maybe we can make this clearer by printing a message like this:
>>
>> --- a/drivers/spi/spi-uclass.c
>> +++ b/drivers/spi/spi-uclass.c
>> @@ -408,7 +408,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
>>                 mode |= SPI_TX_QUAD;
>>                 break;
>>         default:
>> -               error("spi-tx-bus-width %d not supported\n", value);
>> +               printf("spi-tx-bus-width %d not supported, operating
>> in single mode\n", value);
>>                 break;
>>         }
>>
>> @@ -423,7 +423,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
>>                 mode |= SPI_RX_QUAD;
>>                 break;
>>         default:
>> -               error("spi-rx-bus-width %d not supported\n", value);
>> +               printf("spi-rx-bus-width %d not supported, operating
>> in single mode\n", value);
>>                 break;
>
> Yes, this is what I am commenting about.
>
> -EINVAL not needed, we can print "%d is not supporting and operating
> in normal/single mode and move on", So-that the dts will fix if
> something went wrong.

Well if you add printf() values you will bloat the code for little
benefit. If the device tree is invalid it really should be fixed.

Regards,
Simon

[U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Jagan Teki]

Hi Simon,

On Thu, Nov 24, 2016 at 7:51 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Jagan,
>
> On 21 November 2016 at 10:57, Jagan Teki <jagan@openedev.com> wrote:
>> On Sun, Nov 20, 2016 at 2:19 AM, Fabio Estevam <festevam@gmail.com> wrote:
>>> On Sat, Nov 19, 2016 at 6:04 PM, Simon Glass <sjg@chromium.org> wrote:
>>>
>>>>> EPROTONOSUPPORT means: /* Protocol not supported */, which does not
>>>>> seem to be very appropriate here.
>>>>
>>>> This is a protocol as far as I can see - you can either use one pin or
>>>> four pins.
>>>
>>> Actually they are SPI modes: one, two or four pins.
>>>
>>>>> Why not return -EINVAL instead?
>>>>
>>>> The value is valid but is not supported. If we just return -EINVAL for
>>>> anything we don't like, it makes it harder to root-cause the error. In
>>>> particular we use -EINVAL when decoding the device tree. But
>>>> EPROTONOSUPPORT is not widely used.
>>>
>>> I think the current behaviour of not returning an error code on an
>>> invalid mode is correct and it matches what the kernel does in
>>> drivers/spi/spi.c.
>>>
>>> If an invalid mode is passed we just ignore it and operate in single
>>> mode instead.
>>>
>>> Maybe we can make this clearer by printing a message like this:
>>>
>>> --- a/drivers/spi/spi-uclass.c
>>> +++ b/drivers/spi/spi-uclass.c
>>> @@ -408,7 +408,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
>>>                 mode |= SPI_TX_QUAD;
>>>                 break;
>>>         default:
>>> -               error("spi-tx-bus-width %d not supported\n", value);
>>> +               printf("spi-tx-bus-width %d not supported, operating
>>> in single mode\n", value);
>>>                 break;
>>>         }
>>>
>>> @@ -423,7 +423,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
>>>                 mode |= SPI_RX_QUAD;
>>>                 break;
>>>         default:
>>> -               error("spi-rx-bus-width %d not supported\n", value);
>>> +               printf("spi-rx-bus-width %d not supported, operating
>>> in single mode\n", value);
>>>                 break;
>>
>> Yes, this is what I am commenting about.
>>
>> -EINVAL not needed, we can print "%d is not supporting and operating
>> in normal/single mode and move on", So-that the dts will fix if
>> something went wrong.
>
> Well if you add printf() values you will bloat the code for little
> benefit. If the device tree is invalid it really should be fixed.

Yeah, ie what if dts has a wrong value and do print that and continue
with default width, so-that the user will update this for next run.
Since it's not key a attribute to break or decide functionality better
to go with it.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

[U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Fabio Estevam]

On Fri, Nov 25, 2016 at 2:57 PM, Jagan Teki <jagan@openedev.com> wrote:

> Yeah, ie what if dts has a wrong value and do print that and continue
> with default width, so-that the user will update this for next run.
> Since it's not key a attribute to break or decide functionality better
> to go with it.

Agreed. This also matches with the kernel behaviour.

[U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Simon Glass]

Hi,

On 25 November 2016 at 09:59, Fabio Estevam <festevam@gmail.com> wrote:
> On Fri, Nov 25, 2016 at 2:57 PM, Jagan Teki <jagan@openedev.com> wrote:
>
>> Yeah, ie what if dts has a wrong value and do print that and continue
>> with default width, so-that the user will update this for next run.
>> Since it's not key a attribute to break or decide functionality better
>> to go with it.
>
> Agreed. This also matches with the kernel behaviour.

So it is correct to print an error, and then continue? This error will
almost never occur and thus it wastes code space. SPI is sensitive
because it can be used in SPL. Linux doesn't care about code size as
much.

So how about either:
1. debug() and return an error
2. debug() and skip the error

Regards,
Simon

[U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Fabio Estevam]

On Fri, Nov 25, 2016 at 5:38 PM, Simon Glass <sjg@chromium.org> wrote:

> So it is correct to print an error, and then continue? This error will
> almost never occur and thus it wastes code space. SPI is sensitive
> because it can be used in SPL. Linux doesn't care about code size as
> much.
>
> So how about either:
> 1. debug() and return an error
> 2. debug() and skip the error

I prefer option 2, thanks.

[U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Jagan Teki]

On Sat, Nov 26, 2016 at 1:08 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi,
>
> On 25 November 2016 at 09:59, Fabio Estevam <festevam@gmail.com> wrote:
>> On Fri, Nov 25, 2016 at 2:57 PM, Jagan Teki <jagan@openedev.com> wrote:
>>
>>> Yeah, ie what if dts has a wrong value and do print that and continue
>>> with default width, so-that the user will update this for next run.
>>> Since it's not key a attribute to break or decide functionality better
>>> to go with it.
>>
>> Agreed. This also matches with the kernel behaviour.
>
> So it is correct to print an error, and then continue? This error will
> almost never occur and thus it wastes code space. SPI is sensitive
> because it can be used in SPL. Linux doesn't care about code size as
> much.
>
> So how about either:
> 1. debug() and return an error
> 2. debug() and skip the error

I prefer 2. for SPL and replace debug with printf for U-Boot.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

[U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Simon Glass]

Hi,

On 25 November 2016 at 20:28, Jagan Teki <jagan@openedev.com> wrote:
> On Sat, Nov 26, 2016 at 1:08 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi,
>>
>> On 25 November 2016 at 09:59, Fabio Estevam <festevam@gmail.com> wrote:
>>> On Fri, Nov 25, 2016 at 2:57 PM, Jagan Teki <jagan@openedev.com> wrote:
>>>
>>>> Yeah, ie what if dts has a wrong value and do print that and continue
>>>> with default width, so-that the user will update this for next run.
>>>> Since it's not key a attribute to break or decide functionality better
>>>> to go with it.
>>>
>>> Agreed. This also matches with the kernel behaviour.
>>
>> So it is correct to print an error, and then continue? This error will
>> almost never occur and thus it wastes code space. SPI is sensitive
>> because it can be used in SPL. Linux doesn't care about code size as
>> much.
>>
>> So how about either:
>> 1. debug() and return an error
>> 2. debug() and skip the error
>
> I prefer 2. for SPL and replace debug with printf for U-Boot.

OK I have sent v3.

Regards,
Simon

[U-Boot] [PATCH v2 11/22] spi: Add a debug() on bind failure

[Simon Glass]

This is an uncommon error but we may as well have a debug() message when
it happens.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 drivers/spi/spi-uclass.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index 358e229..b251442 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -297,8 +297,11 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int mode,
 		debug("%s: Binding new device '%s', busnum=%d, cs=%d, driver=%s\n",
 		      __func__, dev_name, busnum, cs, drv_name);
 		ret = device_bind_driver(bus, drv_name, dev_name, &dev);
-		if (ret)
+		if (ret) {
+			debug("%s: Unable to bind driver (ret=%d)\n", __func__,
+			      ret);
 			return ret;
+		}
 		plat = dev_get_parent_platdata(dev);
 		plat->cs = cs;
 		plat->max_hz = speed;
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 12/22] video: Use cache-alignment in video_sync()

[Simon Glass]

Sometimes the frame buffer is not a multiple of the cache line size.
Adjust the cache-flushing code to avoid cache warnings/errors in this
case.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 drivers/video/video-uclass.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 11ca793..3036e3a 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -117,7 +117,8 @@ void video_sync(struct udevice *vid)
 
 	if (priv->flush_dcache) {
 		flush_dcache_range((ulong)priv->fb,
-				   (ulong)priv->fb + priv->fb_size);
+				   ALIGN((ulong)priv->fb + priv->fb_size,
+					 CONFIG_SYS_CACHELINE_SIZE));
 	}
 #elif defined(CONFIG_VIDEO_SANDBOX_SDL)
 	struct video_priv *priv = dev_get_uclass_priv(vid);
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 12/22] video: Use cache-alignment in video_sync()

[Simon Glass]

On 13 November 2016 at 14:22, Simon Glass <sjg@chromium.org> wrote:
> Sometimes the frame buffer is not a multiple of the cache line size.
> Adjust the cache-flushing code to avoid cache warnings/errors in this
> case.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2: None
>
>  drivers/video/video-uclass.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied to u-boot-rockchip.

[U-Boot] [PATCH v2 13/22] video: Track whether a display is in use

[Simon Glass]

Mark a display as in use when display_enable() is called. This can avoid
a display being used by multiple video-output devices.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 drivers/video/display-uclass.c | 18 +++++++++++++++++-
 include/display.h              | 10 ++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/video/display-uclass.c b/drivers/video/display-uclass.c
index e4763de..e752eb0 100644
--- a/drivers/video/display-uclass.c
+++ b/drivers/video/display-uclass.c
@@ -23,10 +23,19 @@ int display_enable(struct udevice *dev, int panel_bpp,
 			const struct display_timing *timing)
 {
 	struct dm_display_ops *ops = display_get_ops(dev);
+	struct display_plat *disp_uc_plat;
+	int ret;
 
 	if (!ops || !ops->enable)
 		return -ENOSYS;
-	return ops->enable(dev, panel_bpp, timing);
+	ret = ops->enable(dev, panel_bpp, timing);
+	if (ret)
+		return ret;
+
+	disp_uc_plat = dev_get_uclass_platdata(dev);
+	disp_uc_plat->in_use = true;
+
+	return 0;
 }
 
 int display_read_timing(struct udevice *dev, struct display_timing *timing)
@@ -48,6 +57,13 @@ int display_read_timing(struct udevice *dev, struct display_timing *timing)
 	return edid_get_timing(buf, ret, timing, &panel_bits_per_colour);
 }
 
+bool display_in_use(struct udevice *dev)
+{
+	struct display_plat *disp_uc_plat = dev_get_uclass_platdata(dev);
+
+	return disp_uc_plat->in_use;
+}
+
 UCLASS_DRIVER(display) = {
 	.id		= UCLASS_DISPLAY,
 	.name		= "display",
diff --git a/include/display.h b/include/display.h
index b1c4766..d0a08d4 100644
--- a/include/display.h
+++ b/include/display.h
@@ -16,10 +16,12 @@ struct display_timing;
  * @source_id:	ID for the source of the display data, typically a video
  * controller
  * @src_dev:	Source device providing the video
+ * @in_use:	Display is being used
  */
 struct display_plat {
 	int source_id;
 	struct udevice *src_dev;
+	bool in_use;
 };
 
 /**
@@ -41,6 +43,14 @@ int display_read_timing(struct udevice *dev, struct display_timing *timing);
 int display_enable(struct udevice *dev, int panel_bpp,
 		   const struct display_timing *timing);
 
+/**
+ * display_in_use() - Check if a display is in use by any device
+ *
+ * @return true if the device is in use (display_enable() has been called
+ * successfully), else false
+ */
+bool display_in_use(struct udevice *dev);
+
 struct dm_display_ops {
 	/**
 	 * read_timing() - Read information directly
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 13/22] video: Track whether a display is in use

[Simon Glass]

On 13 November 2016 at 14:22, Simon Glass <sjg@chromium.org> wrote:
> Mark a display as in use when display_enable() is called. This can avoid
> a display being used by multiple video-output devices.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2: None
>
>  drivers/video/display-uclass.c | 18 +++++++++++++++++-
>  include/display.h              | 10 ++++++++++
>  2 files changed, 27 insertions(+), 1 deletion(-)

Applied to u-boot-rockchip.

[U-Boot] [PATCH v2 14/22] rockchip: video: Check for device in use

[Simon Glass]

Check whether a display device is in use before using it. Add a comment as
to why two displays cannot currently be used at the same time.

This allows us to remove the device-tree change that disables vopb on
jerry.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 arch/arm/dts/rk3288-jerry.dts              | 5 -----
 arch/arm/dts/rk3288-veyron-chromebook.dtsi | 2 ++
 drivers/video/rockchip/rk_vop.c            | 9 +++++++++
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/arm/dts/rk3288-jerry.dts b/arch/arm/dts/rk3288-jerry.dts
index 2aa3b9f..da37ea8 100644
--- a/arch/arm/dts/rk3288-jerry.dts
+++ b/arch/arm/dts/rk3288-jerry.dts
@@ -108,11 +108,6 @@
 	pinctrl-0 = <&vcc50_hdmi_en>;
 };
 
-&vopb {
-	/* Disable this so that we use vopl */
-	status = "disabled";
-};
-
 &edp {
 	pinctrl-names = "default";
 	pinctrl-0 = <&edp_hpd>;
diff --git a/arch/arm/dts/rk3288-veyron-chromebook.dtsi b/arch/arm/dts/rk3288-veyron-chromebook.dtsi
index bbbc2f4..f88a868 100644
--- a/arch/arm/dts/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/dts/rk3288-veyron-chromebook.dtsi
@@ -13,6 +13,8 @@
 / {
 	aliases {
 		i2c20 = &i2c_tunnel;
+		video0 = &vopl;
+		video1 = &vopb;
 	};
 
 	gpio_keys: gpio-keys {
diff --git a/drivers/video/rockchip/rk_vop.c b/drivers/video/rockchip/rk_vop.c
index 130dace..eab5486 100644
--- a/drivers/video/rockchip/rk_vop.c
+++ b/drivers/video/rockchip/rk_vop.c
@@ -221,6 +221,11 @@ int rk_display_init(struct udevice *dev, ulong fbbase,
 
 	disp_uc_plat = dev_get_uclass_platdata(disp);
 	debug("Found device '%s', disp_uc_priv=%p\n", disp->name, disp_uc_plat);
+	if (display_in_use(disp)) {
+		debug("   - device in use\n");
+		return -EBUSY;
+	}
+
 	disp_uc_plat->source_id = remote_vop_id;
 	disp_uc_plat->src_dev = dev;
 
@@ -311,6 +316,10 @@ static int rk_vop_probe(struct udevice *dev)
 	/*
 	 * Try all the ports until we find one that works. In practice this
 	 * tries EDP first if available, then HDMI.
+	 *
+	 * Note that rockchip_vop_set_clk() always uses NPLL as the source
+	 * clock so it is currently not possible to use more than one display
+	 * device simultaneously.
 	 */
 	port = fdt_subnode_offset(blob, dev->of_offset, "port");
 	if (port < 0)
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 15/22] rockchip: Move jerry to use of-platdata

[Simon Glass]

Adjust jerry to use of-platdata like other rk3288 boards. This reduces the
SPL size enough that it boots again.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 configs/chromebook_jerry_defconfig | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/configs/chromebook_jerry_defconfig b/configs/chromebook_jerry_defconfig
index 876adc4..6f4ae18 100644
--- a/configs/chromebook_jerry_defconfig
+++ b/configs/chromebook_jerry_defconfig
@@ -1,12 +1,9 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ROCKCHIP=y
 CONFIG_SYS_MALLOC_F_LEN=0x2000
-CONFIG_SPL_I2C_SUPPORT=y
 # CONFIG_SPL_MMC_SUPPORT is not set
-CONFIG_SPL_POWER_SUPPORT=y
 CONFIG_ROCKCHIP_RK3288=y
 CONFIG_TARGET_CHROMEBOOK_JERRY=y
-CONFIG_ROCKCHIP_FAST_SPL=y
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_SPL_STACK_R_ADDR=0x80000
@@ -36,7 +33,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_SPL_OF_CONTROL=y
-CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_REGMAP=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SYSCON=y
@@ -71,6 +68,7 @@ CONFIG_DEBUG_UART_BASE=0xff690000
 CONFIG_DEBUG_UART_CLOCK=24000000
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYS_NS16550=y
+CONFIG_ROCKCHIP_SERIAL=y
 CONFIG_ROCKCHIP_SPI=y
 CONFIG_SYSRESET=y
 CONFIG_DM_VIDEO=y
@@ -80,3 +78,5 @@ CONFIG_CONSOLE_SCROLL_LINES=10
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ERRNO_STR=y
+CONFIG_SPL_OF_PLATDATA=y
+# CONFIG_SPL_OF_LIBFDT is not set
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 16/22] rockchip: Rename jerry files to veyron

[Simon Glass]

At present we have a single rk3288-based Chromebook: chromebook_jerry. But
all such Chromebooks can use the same binary with only device-tree
differences. The family name is 'veyron', so rename the files accordingly.

Also update the device-tree filename since this currently differs from
Linux.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 arch/arm/dts/Makefile                                      | 2 +-
 arch/arm/dts/{rk3288-jerry.dts => rk3288-veyron-jerry.dts} | 0
 arch/arm/mach-rockchip/rk3288/Kconfig                      | 2 +-
 board/google/{chromebook_jerry => veyron}/Kconfig          | 4 ++--
 board/google/{chromebook_jerry => veyron}/MAINTAINERS      | 4 ++--
 board/google/{chromebook_jerry => veyron}/Makefile         | 2 +-
 board/google/{chromebook_jerry/jerry.c => veyron/veyron.c} | 0
 configs/chromebook_jerry_defconfig                         | 2 +-
 include/configs/{chromebook_jerry.h => veyron.h}           | 0
 9 files changed, 8 insertions(+), 8 deletions(-)
 rename arch/arm/dts/{rk3288-jerry.dts => rk3288-veyron-jerry.dts} (100%)
 rename board/google/{chromebook_jerry => veyron}/Kconfig (74%)
 rename board/google/{chromebook_jerry => veyron}/MAINTAINERS (60%)
 rename board/google/{chromebook_jerry => veyron}/Makefile (81%)
 rename board/google/{chromebook_jerry/jerry.c => veyron/veyron.c} (100%)
 rename include/configs/{chromebook_jerry.h => veyron.h} (100%)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 836a8c4..af8b0de 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -29,7 +29,7 @@ dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
 dtb-$(CONFIG_EXYNOS7420) += exynos7420-espresso7420.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3288-firefly.dtb \
-	rk3288-jerry.dtb \
+	rk3288-veyron-jerry.dtb \
 	rk3288-rock2-square.dtb \
 	rk3288-evb.dtb \
 	rk3288-fennec.dtb \
diff --git a/arch/arm/dts/rk3288-jerry.dts b/arch/arm/dts/rk3288-veyron-jerry.dts
similarity index 100%
rename from arch/arm/dts/rk3288-jerry.dts
rename to arch/arm/dts/rk3288-veyron-jerry.dts
diff --git a/arch/arm/mach-rockchip/rk3288/Kconfig b/arch/arm/mach-rockchip/rk3288/Kconfig
index c53d2e2..30c557b 100644
--- a/arch/arm/mach-rockchip/rk3288/Kconfig
+++ b/arch/arm/mach-rockchip/rk3288/Kconfig
@@ -88,7 +88,7 @@ source "board/chipspark/popmetal_rk3288/Kconfig"
 
 source "board/firefly/firefly-rk3288/Kconfig"
 
-source "board/google/chromebook_jerry/Kconfig"
+source "board/google/veyron/Kconfig"
 
 source "board/radxa/rock2/Kconfig"
 
diff --git a/board/google/chromebook_jerry/Kconfig b/board/google/veyron/Kconfig
similarity index 74%
rename from board/google/chromebook_jerry/Kconfig
rename to board/google/veyron/Kconfig
index 3640513..b1f51ce 100644
--- a/board/google/chromebook_jerry/Kconfig
+++ b/board/google/veyron/Kconfig
@@ -1,13 +1,13 @@
 if TARGET_CHROMEBOOK_JERRY
 
 config SYS_BOARD
-	default "chromebook_jerry"
+	default "veyron"
 
 config SYS_VENDOR
 	default "google"
 
 config SYS_CONFIG_NAME
-	default "chromebook_jerry"
+	default "veyron"
 
 config BOARD_SPECIFIC_OPTIONS # dummy
 	def_bool y
diff --git a/board/google/chromebook_jerry/MAINTAINERS b/board/google/veyron/MAINTAINERS
similarity index 60%
rename from board/google/chromebook_jerry/MAINTAINERS
rename to board/google/veyron/MAINTAINERS
index b01b6cd..d641eed 100644
--- a/board/google/chromebook_jerry/MAINTAINERS
+++ b/board/google/veyron/MAINTAINERS
@@ -1,6 +1,6 @@
 CHROMEBOOK JERRY BOARD
 M:	Simon Glass <sjg@chromium.org>
 S:	Maintained
-F:	board/google/chromebook_jerry/
-F:	include/configs/chromebook_jerry.h
+F:	board/google/veyron/
+F:	include/configs/veyron.h
 F:	configs/chromebook_jerry_defconfig
diff --git a/board/google/chromebook_jerry/Makefile b/board/google/veyron/Makefile
similarity index 81%
rename from board/google/chromebook_jerry/Makefile
rename to board/google/veyron/Makefile
index d29a063..9868357 100644
--- a/board/google/chromebook_jerry/Makefile
+++ b/board/google/veyron/Makefile
@@ -4,4 +4,4 @@
 # SPDX-License-Identifier:     GPL-2.0+
 #
 
-obj-y	+= jerry.o
+obj-y	+= veyron.o
diff --git a/board/google/chromebook_jerry/jerry.c b/board/google/veyron/veyron.c
similarity index 100%
rename from board/google/chromebook_jerry/jerry.c
rename to board/google/veyron/veyron.c
diff --git a/configs/chromebook_jerry_defconfig b/configs/chromebook_jerry_defconfig
index 6f4ae18..46df1a6 100644
--- a/configs/chromebook_jerry_defconfig
+++ b/configs/chromebook_jerry_defconfig
@@ -7,7 +7,7 @@ CONFIG_TARGET_CHROMEBOOK_JERRY=y
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_SPL_STACK_R_ADDR=0x80000
-CONFIG_DEFAULT_DEVICE_TREE="rk3288-jerry"
+CONFIG_DEFAULT_DEVICE_TREE="rk3288-veyron-jerry"
 CONFIG_SILENT_CONSOLE=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_STACK_R=y
diff --git a/include/configs/chromebook_jerry.h b/include/configs/veyron.h
similarity index 100%
rename from include/configs/chromebook_jerry.h
rename to include/configs/veyron.h
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 16/22] rockchip: Rename jerry files to veyron

[Simon Glass]

On 13 November 2016 at 14:22, Simon Glass <sjg@chromium.org> wrote:
> At present we have a single rk3288-based Chromebook: chromebook_jerry. But
> all such Chromebooks can use the same binary with only device-tree
> differences. The family name is 'veyron', so rename the files accordingly.
>
> Also update the device-tree filename since this currently differs from
> Linux.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2: None
>
>  arch/arm/dts/Makefile                                      | 2 +-
>  arch/arm/dts/{rk3288-jerry.dts => rk3288-veyron-jerry.dts} | 0
>  arch/arm/mach-rockchip/rk3288/Kconfig                      | 2 +-
>  board/google/{chromebook_jerry => veyron}/Kconfig          | 4 ++--
>  board/google/{chromebook_jerry => veyron}/MAINTAINERS      | 4 ++--
>  board/google/{chromebook_jerry => veyron}/Makefile         | 2 +-
>  board/google/{chromebook_jerry/jerry.c => veyron/veyron.c} | 0
>  configs/chromebook_jerry_defconfig                         | 2 +-
>  include/configs/{chromebook_jerry.h => veyron.h}           | 0
>  9 files changed, 8 insertions(+), 8 deletions(-)
>  rename arch/arm/dts/{rk3288-jerry.dts => rk3288-veyron-jerry.dts} (100%)
>  rename board/google/{chromebook_jerry => veyron}/Kconfig (74%)
>  rename board/google/{chromebook_jerry => veyron}/MAINTAINERS (60%)
>  rename board/google/{chromebook_jerry => veyron}/Makefile (81%)
>  rename board/google/{chromebook_jerry/jerry.c => veyron/veyron.c} (100%)
>  rename include/configs/{chromebook_jerry.h => veyron.h} (100%)

Applied to u-boot-rockchip.

[U-Boot] [PATCH v2 17/22] rockchip: veyron: Add a note about the SDRAM voltage

[Simon Glass]

Add a comment to indicate that we are not supporting the PWM regulator
yet.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2:
- Add new patch with note about the SDRAM voltage

 board/google/veyron/veyron.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/board/google/veyron/veyron.c b/board/google/veyron/veyron.c
index 5119e95..20297e1 100644
--- a/board/google/veyron/veyron.c
+++ b/board/google/veyron/veyron.c
@@ -5,3 +5,9 @@
  */
 
 #include <common.h>
+
+/*
+ * We should increase the DDR voltage to 1.2V using the PWM regulator.
+ * There is a U-Boot driver for this but it may need to add support for the
+ * 'voltage-table' property.
+ */
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 17/22] rockchip: veyron: Add a note about the SDRAM voltage

[Simon Glass]

On 13 November 2016 at 14:22, Simon Glass <sjg@chromium.org> wrote:
> Add a comment to indicate that we are not supporting the PWM regulator
> yet.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2:
> - Add new patch with note about the SDRAM voltage
>
>  board/google/veyron/veyron.c | 6 ++++++
>  1 file changed, 6 insertions(+)

Applied to u-boot-rockchip.

[U-Boot] [PATCH v2 18/22] rockchip: Move jerry SDRAM settings into its own .dts file

[Simon Glass]

The SDRAM settings are not common across all veyron models. Move the
current settings into Jerry's file.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 arch/arm/dts/rk3288-veyron-jerry.dts | 11 +++++++++++
 arch/arm/dts/rk3288-veyron.dtsi      |  8 --------
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/arm/dts/rk3288-veyron-jerry.dts b/arch/arm/dts/rk3288-veyron-jerry.dts
index da37ea8..8aab607 100644
--- a/arch/arm/dts/rk3288-veyron-jerry.dts
+++ b/arch/arm/dts/rk3288-veyron-jerry.dts
@@ -55,6 +55,17 @@
 	};
 };
 
+&dmc {
+	rockchip,pctl-timing = <0x29a 0xc8 0x1f4 0x42 0x4e 0x4 0xea 0xa
+		0x5 0x0 0xa 0x7 0x19 0x24 0xa 0x7
+		0x5 0xa 0x5 0x200 0x5 0x10 0x40 0x0
+		0x1 0x7 0x7 0x4 0xc 0x43 0x100 0x0
+		0x5 0x0>;
+	rockchip,phy-timing = <0x48f9aab4 0xea0910 0x1002c200
+		0xa60 0x40 0x10 0x0>;
+	rockchip,sdram-params = <0x30B25564 0x627 3 666000000 3 9 1>;
+};
+
 &gpio_keys {
 	power {
 		gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
diff --git a/arch/arm/dts/rk3288-veyron.dtsi b/arch/arm/dts/rk3288-veyron.dtsi
index 2ffe39c..a314058 100644
--- a/arch/arm/dts/rk3288-veyron.dtsi
+++ b/arch/arm/dts/rk3288-veyron.dtsi
@@ -245,14 +245,6 @@
 		533000 1150000
 		666000 1200000
 	>;
-	rockchip,pctl-timing = <0x29a 0xc8 0x1f4 0x42 0x4e 0x4 0xea 0xa
-		0x5 0x0 0xa 0x7 0x19 0x24 0xa 0x7
-		0x5 0xa 0x5 0x200 0x5 0x10 0x40 0x0
-		0x1 0x7 0x7 0x4 0xc 0x43 0x100 0x0
-		0x5 0x0>;
-	rockchip,phy-timing = <0x48f9aab4 0xea0910 0x1002c200
-		0xa60 0x40 0x10 0x0>;
-	rockchip,sdram-params = <0x30B25564 0x627 3 666000000 3 9 1>;
 };
 
 &efuse {
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 19/22] rockchip: clk: Support setting ACLK

[Simon Glass]

Add basic support for setting the ARM clock, since this allows us to run
at maximum speed in U-Boot. Currently only a single speed is supported
(1.8GHz).

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 drivers/clk/rockchip/clk_rk3288.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk3288.c b/drivers/clk/rockchip/clk_rk3288.c
index ed97e87..d15504c 100644
--- a/drivers/clk/rockchip/clk_rk3288.c
+++ b/drivers/clk/rockchip/clk_rk3288.c
@@ -691,6 +691,13 @@ static ulong rk3288_clk_set_rate(struct clk *clk, ulong rate)
 
 	gclk_rate = rkclk_pll_get_rate(priv->cru, CLK_GENERAL);
 	switch (clk->id) {
+	case PLL_APLL:
+		/* We only support a fixed rate here */
+		if (rate != 1800000000)
+			return -EINVAL;
+		rk3288_clk_configure_cpu(priv->cru, priv->grf);
+		new_rate = rate;
+		break;
 	case CLK_DDR:
 		new_rate = rkclk_configure_ddr(priv->cru, priv->grf, rate);
 		break;
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 19/22] rockchip: clk: Support setting ACLK

[Simon Glass]

On 13 November 2016 at 14:22, Simon Glass <sjg@chromium.org> wrote:
> Add basic support for setting the ARM clock, since this allows us to run
> at maximum speed in U-Boot. Currently only a single speed is supported
> (1.8GHz).
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2: None
>
>  drivers/clk/rockchip/clk_rk3288.c | 7 +++++++
>  1 file changed, 7 insertions(+)

Applied to u-boot-rockchip.

[U-Boot] [PATCH v2 20/22] rockchip: veyron: Adjust ARM clock after relocation

[Simon Glass]

Update board_init() to increase the ARM clock to the maximum speed on
veyron boards. This makes quite a large difference in performance. With
this change, speed goes from about 750 DMIPS to 2720 DMIPs.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2: None

 arch/arm/mach-rockchip/rk3288-board.c | 44 +++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/mach-rockchip/rk3288-board.c b/arch/arm/mach-rockchip/rk3288-board.c
index baf9522..bca6075 100644
--- a/arch/arm/mach-rockchip/rk3288-board.c
+++ b/arch/arm/mach-rockchip/rk3288-board.c
@@ -16,6 +16,8 @@
 #include <asm/arch/boot_mode.h>
 #include <asm/gpio.h>
 #include <dm/pinctrl.h>
+#include <dt-bindings/clock/rk3288-cru.h>
+#include <power/regulator.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -56,6 +58,39 @@ int board_late_init(void)
 	return rk_board_late_init();
 }
 
+#ifndef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
+static int veyron_init(void)
+{
+	struct udevice *dev;
+	struct clk clk;
+	int ret;
+
+	ret = regulator_get_by_platname("vdd_arm", &dev);
+	if (ret)
+		return ret;
+
+	/* Slowly raise to max CPU voltage to prevent overshoot */
+	ret = regulator_set_value(dev, 1200000);
+	if (ret)
+		return ret;
+	udelay(175); /* Must wait for voltage to stabilize, 2mV/us */
+	ret = regulator_set_value(dev, 1400000);
+	if (ret)
+		return ret;
+	udelay(100); /* Must wait for voltage to stabilize, 2mV/us */
+
+	ret = rockchip_get_clk(&clk.dev);
+	if (ret)
+		return ret;
+	clk.id = PLL_APLL;
+	ret = clk_set_rate(&clk, 1800000000);
+	if (IS_ERR_VALUE(ret))
+		return ret;
+
+	return 0;
+}
+#endif
+
 int board_init(void)
 {
 #ifdef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
@@ -87,6 +122,15 @@ err:
 
 	return -1;
 #else
+	int ret;
+
+	/* We do some SoC one time setting here */
+	if (!fdt_node_check_compatible(gd->fdt_blob, 0, "google,veyron")) {
+		ret = veyron_init();
+		if (ret)
+			return ret;
+	}
+
 	return 0;
 #endif
 }
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 21/22] rockchip: video: Avoid using u8 in the HDMI driver

[Simon Glass]

It makes not sense using u8 to hold a value on a 32-bit or 64-bit machine.
It can only bloat the code by forcing the compiler to mask the value.
Change it to uint.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2:
- Add new patch to avoid using u8 in the HDMI driver

 drivers/video/rockchip/rk_hdmi.c | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/video/rockchip/rk_hdmi.c b/drivers/video/rockchip/rk_hdmi.c
index 72142dc..032b1de 100644
--- a/drivers/video/rockchip/rk_hdmi.c
+++ b/drivers/video/rockchip/rk_hdmi.c
@@ -132,8 +132,8 @@ static const u32 csc_coeff_default[3][4] = {
 
 static void hdmi_set_clock_regenerator(struct rk3288_hdmi *regs, u32 n, u32 cts)
 {
-	u8 cts3;
-	u8 n3;
+	uint cts3;
+	uint n3;
 
 	/* first set ncts_atomic_write (if present) */
 	n3 = HDMI_AUD_N3_NCTS_ATOMIC_WRITE;
@@ -199,7 +199,7 @@ static void hdmi_audio_set_samplerate(struct rk3288_hdmi *regs, u32 pixel_clk)
 static void hdmi_video_sample(struct rk3288_hdmi *regs)
 {
 	u32 color_format = 0x01;
-	u8 val;
+	uint val;
 
 	val = HDMI_TX_INVID0_INTERNAL_DE_GENERATOR_DISABLE |
 	      ((color_format << HDMI_TX_INVID0_VIDEO_MAPPING_OFFSET) &
@@ -256,7 +256,7 @@ static void hdmi_video_packetize(struct rk3288_hdmi *regs)
 	u32 output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS;
 	u32 remap_size = HDMI_VP_REMAP_YCC422_16BIT;
 	u32 color_depth = 0;
-	u8 val, vp_conf;
+	uint val, vp_conf;
 
 	/* set the packetizer registers */
 	val = ((color_depth << HDMI_VP_PR_CD_COLOR_DEPTH_OFFSET) &
@@ -297,7 +297,7 @@ static void hdmi_video_packetize(struct rk3288_hdmi *regs)
 			output_select);
 }
 
-static inline void hdmi_phy_test_clear(struct rk3288_hdmi *regs, u8 bit)
+static inline void hdmi_phy_test_clear(struct rk3288_hdmi *regs, uint bit)
 {
 	clrsetbits_le32(&regs->phy_tst0, HDMI_PHY_TST0_TSTCLR_MASK,
 			bit << HDMI_PHY_TST0_TSTCLR_OFFSET);
@@ -382,7 +382,7 @@ static void hdmi_phy_sel_interface_control(struct rk3288_hdmi *regs,
 static int hdmi_phy_configure(struct rk3288_hdmi *regs, u32 mpixelclock)
 {
 	ulong start;
-	u8 i, val;
+	uint i, val;
 
 	writel(HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_BYPASS,
 	       &regs->mc_flowctrl);
@@ -481,8 +481,8 @@ static int hdmi_phy_init(struct rk3288_hdmi *regs, uint mpixelclock)
 static void hdmi_av_composer(struct rk3288_hdmi *regs,
 			     const struct display_timing *edid)
 {
-	u8 mdataenablepolarity = 1;
-	u8 inv_val;
+	bool mdataenablepolarity = true;
+	uint inv_val;
 	uint hbl;
 	uint vbl;
 
@@ -553,7 +553,7 @@ static void hdmi_av_composer(struct rk3288_hdmi *regs,
 /* hdmi initialization step b.4 */
 static void hdmi_enable_video_path(struct rk3288_hdmi *regs)
 {
-	u8 clkdis;
+	uint clkdis;
 
 	/* control period minimum duration */
 	writel(12, &regs->fc_ctrldur);
@@ -580,7 +580,7 @@ static void hdmi_enable_video_path(struct rk3288_hdmi *regs)
 /* workaround to clear the overflow condition */
 static void hdmi_clear_overflow(struct rk3288_hdmi *regs)
 {
-	u8 val, count;
+	uint val, count;
 
 	/* tmds software reset */
 	writel((u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ, &regs->mc_swrstz);
@@ -614,7 +614,7 @@ static void hdmi_audio_fifo_reset(struct rk3288_hdmi *regs)
 
 static void hdmi_init_interrupt(struct rk3288_hdmi *regs)
 {
-	u8 ih_mute;
+	uint ih_mute;
 
 	/*
 	 * boot up defaults are:
@@ -650,11 +650,11 @@ static void hdmi_init_interrupt(struct rk3288_hdmi *regs)
 	writel(HDMI_IH_PHY_STAT0_HPD, &regs->ih_phy_stat0);
 }
 
-static u8 hdmi_get_plug_in_status(struct rk3288_hdmi *regs)
+static int hdmi_get_plug_in_status(struct rk3288_hdmi *regs)
 {
-	u8 val = readl(&regs->phy_stat0) & HDMI_PHY_HPD;
+	uint val = readl(&regs->phy_stat0) & HDMI_PHY_HPD;
 
-	return !!(val);
+	return !!val;
 }
 
 static int hdmi_wait_for_hpd(struct rk3288_hdmi *regs)
@@ -753,7 +753,7 @@ static int hdmi_read_edid(struct rk3288_hdmi *regs, int block, u8 *buff)
 	return edid_read_err;
 }
 
-static u8 pre_buf[] = {
+static const u8 pre_buf[] = {
 	0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
 	0x04, 0x69, 0xfa, 0x23, 0xc8, 0x28, 0x01, 0x00,
 	0x10, 0x17, 0x01, 0x03, 0x80, 0x33, 0x1d, 0x78,
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 22/22] rockchip: Add support for veyron-mickey (Chromebit)

[Simon Glass]

This adds support for the Asus Chromebit, and RK3288-based device designed
to plug directly into an HDMI monitor. The device tree file comes from
Linux v4.8.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2:
- Enable only the active eMMC port

 arch/arm/dts/Makefile                     |   1 +
 arch/arm/dts/rk3288-veyron-mickey.dts     | 277 ++++++++++++++++++++++++++++++
 arch/arm/mach-rockchip/rk3288-board-spl.c |   3 +-
 arch/arm/mach-rockchip/rk3288/Kconfig     |   9 +
 board/google/veyron/Kconfig               |  16 ++
 board/google/veyron/MAINTAINERS           |   7 +
 configs/chromebit_mickey_defconfig        |  84 +++++++++
 7 files changed, 396 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/rk3288-veyron-mickey.dts
 create mode 100644 configs/chromebit_mickey_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index af8b0de..5723c1b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -30,6 +30,7 @@ dtb-$(CONFIG_EXYNOS7420) += exynos7420-espresso7420.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3288-firefly.dtb \
 	rk3288-veyron-jerry.dtb \
+	rk3288-veyron-mickey.dtb \
 	rk3288-rock2-square.dtb \
 	rk3288-evb.dtb \
 	rk3288-fennec.dtb \
diff --git a/arch/arm/dts/rk3288-veyron-mickey.dts b/arch/arm/dts/rk3288-veyron-mickey.dts
new file mode 100644
index 0000000..e0dc362
--- /dev/null
+++ b/arch/arm/dts/rk3288-veyron-mickey.dts
@@ -0,0 +1,277 @@
+/*
+ * Google Veyron Mickey Rev 0 board device tree source
+ *
+ * Copyright 2015 Google, Inc
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ *  Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "rk3288-veyron-chromebook.dtsi"
+
+/ {
+	model = "Google Mickey";
+	compatible = "google,veyron-mickey-rev8", "google,veyron-mickey-rev7",
+		     "google,veyron-mickey-rev6", "google,veyron-mickey-rev5",
+		     "google,veyron-mickey-rev4", "google,veyron-mickey-rev3",
+		     "google,veyron-mickey-rev2", "google,veyron-mickey-rev1",
+		     "google,veyron-mickey-rev0", "google,veyron-mickey",
+		     "google,veyron", "rockchip,rk3288";
+
+	vcc_5v: vcc-5v {
+		vin-supply = <&vcc33_sys>;
+	};
+
+	vcc33_io: vcc33_io {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc33_io";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc33_sys>;
+	};
+};
+
+&cpu_thermal {
+	/delete-node/ trips;
+	/delete-node/ cooling-maps;
+
+	trips {
+		cpu_alert_almost_warm: cpu_alert_almost_warm {
+			temperature = <63000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = "passive";
+		};
+		cpu_alert_warm: cpu_alert_warm {
+			temperature = <65000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = "passive";
+		};
+		cpu_alert_almost_hot: cpu_alert_almost_hot {
+			temperature = <80000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = "passive";
+		};
+		cpu_alert_hot: cpu_alert_hot {
+			temperature = <82000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = "passive";
+		};
+		cpu_alert_hotter: cpu_alert_hotter {
+			temperature = <84000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = "passive";
+		};
+		cpu_alert_very_hot: cpu_alert_very_hot {
+			temperature = <85000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = "passive";
+		};
+		cpu_crit: cpu_crit {
+			temperature = <90000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = "critical";
+		};
+	};
+
+	cooling-maps {
+		/*
+		 * After 1st level, throttle the CPU down to as low as 1.4 GHz
+		 * and don't let the GPU go faster than 400 MHz.  Note that we
+		 * won't throttle the GPU lower than 400 MHz due to CPU
+		 * heat--we'll let the GPU do the rest itself.
+		 */
+		cpu_warm_limit_cpu {
+			trip = <&cpu_alert_warm>;
+			cooling-device =
+				<&cpu0 THERMAL_NO_LIMIT 4>;
+		};
+
+		/*
+		 * Add some discrete steps to help throttling system deal
+		 * with the fact that there are two passive cooling devices:
+		 * the CPU and the GPU.
+		 *
+		 * - 1.2 GHz - 1.0 GHz (almost hot)
+		 * - 800 MHz           (hot)
+		 * - 800 MHz - 696 MHz (hotter)
+		 * - 696 MHz - min     (very hot)
+		 *
+		 * Note:
+		 * - 800 MHz appears to be a "sweet spot" for me.  I can run
+		 *   some pretty serious workload here and be happy.
+		 * - After 696 MHz we stop lowering voltage, so throttling
+		 *   past there is less effective.
+		 */
+		cpu_almost_hot_limit_cpu {
+			trip = <&cpu_alert_almost_hot>;
+			cooling-device =
+				<&cpu0 5 6>;
+		};
+		cpu_hot_limit_cpu {
+			trip = <&cpu_alert_hot>;
+			cooling-device =
+				<&cpu0 7 7>;
+		};
+		cpu_hotter_limit_cpu {
+			trip = <&cpu_alert_hotter>;
+			cooling-device =
+				<&cpu0 7 8>;
+		};
+		cpu_very_hot_limit_cpu {
+			trip = <&cpu_alert_very_hot>;
+			cooling-device =
+				<&cpu0 8 THERMAL_NO_LIMIT>;
+		};
+	};
+};
+
+&dmc {
+	rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
+		0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
+		0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
+		0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
+		0x8 0x1f4>;
+	rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
+		0x0 0xc3 0x6 0x2>;
+	rockchip,sdram-params = <0x20d266a4 0x5b6 2 533000000 6 9 1>;
+};
+
+&emmc {
+	/delete-property/mmc-hs200-1_8v;
+};
+
+&i2c2 {
+	status = "disabled";
+};
+
+&i2c4 {
+	status = "disabled";
+};
+
+&i2s {
+	status = "okay";
+	clock-names = "i2s_hclk", "i2s_clk", "i2s_clk_out";
+	clocks = <&cru HCLK_I2S0>, <&cru SCLK_I2S0>, <&cru SCLK_I2S0_OUT>;
+};
+
+&rk808 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pmic_int_l &dvs_1 &dvs_2>;
+	dvs-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>,
+		    <&gpio7 15 GPIO_ACTIVE_HIGH>;
+
+	/delete-property/ vcc6-supply;
+	/delete-property/ vcc12-supply;
+
+	vcc11-supply = <&vcc33_sys>;
+
+	regulators {
+		/* vcc33_io is sourced directly from vcc33_sys */
+		/delete-node/ LDO_REG1;
+		/delete-node/ LDO_REG7;
+
+		/* This is not a pwren anymore, but the real power supply */
+		vdd10_lcd: LDO_REG7 {
+			regulator-always-on;
+			regulator-boot-on;
+			regulator-min-microvolt = <1000000>;
+			regulator-max-microvolt = <1000000>;
+			regulator-name = "vdd10_lcd";
+			regulator-suspend-mem-disabled;
+		};
+
+		vcc18_lcd: LDO_REG8 {
+			regulator-always-on;
+			regulator-boot-on;
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-name = "vcc18_lcd";
+			regulator-suspend-mem-disabled;
+		};
+	};
+};
+
+&pinctrl {
+	hdmi {
+		power_hdmi_on: power-hdmi-on {
+			rockchip,pins = <7 11 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pmic {
+		dvs_1: dvs-1 {
+			rockchip,pins = <7 12 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		dvs_2: dvs-2 {
+			rockchip,pins = <7 15 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+};
+
+&sdmmc {
+	status = "disabled";
+};
+
+&sdio0 {
+	status = "disabled";
+};
+
+&sdmmc {
+	status = "disabled";
+};
+
+&spi0 {
+	status = "disabled";
+};
+
+&usb_host0_ehci {
+	status = "disabled";
+};
+
+&usb_host1 {
+	status = "disabled";
+};
+
+&vcc50_hdmi {
+	enable-active-high;
+	gpio = <&gpio7 11 GPIO_ACTIVE_HIGH>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&power_hdmi_on>;
+};
diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c b/arch/arm/mach-rockchip/rk3288-board-spl.c
index 185b5fd..03ac0b4 100644
--- a/arch/arm/mach-rockchip/rk3288-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3288-board-spl.c
@@ -64,7 +64,8 @@ u32 spl_boot_device(void)
 	}
 
 fallback:
-#elif defined(CONFIG_TARGET_CHROMEBOOK_JERRY)
+#elif defined(CONFIG_TARGET_CHROMEBOOK_JERRY) || \
+		defined(CONFIG_TARGET_CHROMEBIT_MICKEY)
 	return BOOT_DEVICE_SPI;
 #endif
 	return BOOT_DEVICE_MMC1;
diff --git a/arch/arm/mach-rockchip/rk3288/Kconfig b/arch/arm/mach-rockchip/rk3288/Kconfig
index 30c557b..204c1c7 100644
--- a/arch/arm/mach-rockchip/rk3288/Kconfig
+++ b/arch/arm/mach-rockchip/rk3288/Kconfig
@@ -49,6 +49,15 @@ config TARGET_CHROMEBOOK_JERRY
 	  WiFi. It includes a Chrome OS EC (Cortex-M3) to provide access to
 	  the keyboard and battery functions.
 
+config TARGET_CHROMEBIT_MICKEY
+	bool "Google/Rockchip Veyron-Mickey Chromebit"
+	help
+	  Mickey is a small RK3288-based device with one USB 3.0 port, HDMI
+	  and WiFi. It has a separate power port and is designed to connect
+	  to the HDMI input of a monitor or TV. It has no internal battery.
+	  Typically a USB hub or wireless keyboard/touchpad is used to get
+	  keyboard and mouse access.
+
 config TARGET_ROCK2
 	bool "Radxa Rock 2"
 	help
diff --git a/board/google/veyron/Kconfig b/board/google/veyron/Kconfig
index b1f51ce..a99190f 100644
--- a/board/google/veyron/Kconfig
+++ b/board/google/veyron/Kconfig
@@ -13,3 +13,19 @@ config BOARD_SPECIFIC_OPTIONS # dummy
 	def_bool y
 
 endif
+
+if TARGET_CHROMEBIT_MICKEY
+
+config SYS_BOARD
+	default "veyron"
+
+config SYS_VENDOR
+	default "google"
+
+config SYS_CONFIG_NAME
+	default "veyron"
+
+config BOARD_SPECIFIC_OPTIONS # dummy
+	def_bool y
+
+endif
diff --git a/board/google/veyron/MAINTAINERS b/board/google/veyron/MAINTAINERS
index d641eed..e44e1a9 100644
--- a/board/google/veyron/MAINTAINERS
+++ b/board/google/veyron/MAINTAINERS
@@ -4,3 +4,10 @@ S:	Maintained
 F:	board/google/veyron/
 F:	include/configs/veyron.h
 F:	configs/chromebook_jerry_defconfig
+
+CHROMEBIT MICKEY BOARD
+M:	Simon Glass <sjg@chromium.org>
+S:	Maintained
+F:	board/google/veyron/
+F:	include/configs/veyron.h
+F:	configs/chromebit_mickey_defconfig
diff --git a/configs/chromebit_mickey_defconfig b/configs/chromebit_mickey_defconfig
new file mode 100644
index 0000000..b118907
--- /dev/null
+++ b/configs/chromebit_mickey_defconfig
@@ -0,0 +1,84 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+# CONFIG_SPL_MMC_SUPPORT is not set
+CONFIG_ROCKCHIP_RK3288=y
+CONFIG_TARGET_CHROMEBIT_MICKEY=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DM_KEYBOARD=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3288-veyron-mickey"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
+# CONFIG_SPL_SIMPLE_BUS is not set
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_I2C_CROS_EC_TUNNEL=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_I2C_MUX=y
+CONFIG_CROS_EC_KEYB=y
+CONFIG_CMD_CROS_EC=y
+CONFIG_CROS_EC=y
+CONFIG_CROS_EC_SPI=y
+CONFIG_PWRSEQ=y
+CONFIG_ROCKCHIP_DWMMC=y
+CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
+# CONFIG_SPL_PINCTRL_FULL is not set
+CONFIG_ROCKCHIP_RK3288_PINCTRL=y
+CONFIG_DM_PMIC=y
+# CONFIG_SPL_PMIC_CHILDREN is not set
+CONFIG_PMIC_RK808=y
+CONFIG_DM_REGULATOR=y
+CONFIG_SPL_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_REGULATOR_RK808=y
+CONFIG_DM_PWM=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_RAM=y
+CONFIG_SPL_RAM=y
+CONFIG_DEBUG_UART=y
+CONFIG_DEBUG_UART_BASE=0xff690000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
+CONFIG_ROCKCHIP_SERIAL=y
+CONFIG_ROCKCHIP_SPI=y
+CONFIG_SYSRESET=y
+CONFIG_DM_VIDEO=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_CMD_DHRYSTONE=y
+CONFIG_ERRNO_STR=y
+CONFIG_SPL_OF_PLATDATA=y
+# CONFIG_SPL_OF_LIBFDT is not set
-- 
2.8.0.rc3.226.g39d4020

[U-Boot] [PATCH v2 22/22] rockchip: Add support for veyron-mickey (Chromebit)

[Simon Glass]

On 13 November 2016 at 14:22, Simon Glass <sjg@chromium.org> wrote:
> This adds support for the Asus Chromebit, and RK3288-based device designed
> to plug directly into an HDMI monitor. The device tree file comes from
> Linux v4.8.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2:
> - Enable only the active eMMC port
>
>  arch/arm/dts/Makefile                     |   1 +
>  arch/arm/dts/rk3288-veyron-mickey.dts     | 277 ++++++++++++++++++++++++++++++
>  arch/arm/mach-rockchip/rk3288-board-spl.c |   3 +-
>  arch/arm/mach-rockchip/rk3288/Kconfig     |   9 +
>  board/google/veyron/Kconfig               |  16 ++
>  board/google/veyron/MAINTAINERS           |   7 +
>  configs/chromebit_mickey_defconfig        |  84 +++++++++
>  7 files changed, 396 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/rk3288-veyron-mickey.dts
>  create mode 100644 configs/chromebit_mickey_defconfig

Applied to u-boot-rockchip.