[U-Boot] [PATCH 0/10] Enable LCD display on snow

[U-Boot] [PATCH 0/10] Enable LCD display on snow

[Simon Glass]

This series adds a driver for TPS65090 and plumbs it in to get the LCD
working correctly on snow.

The display driver is already present, but needs information about the
display to be provided in the device tree.

The backlight also needs to be enabled - it is controlled by a FET on
the TPS65090. Note that the TPS65090 is controlled by the device tree
so will only be present if the board's device tree file specifies it.
At present this is only the case for snow, but other exynos5 boards will
use it (e.g. pit).

Note: the TPS65090 driver was sent to the list around the middle of last
year but was never applied.


Aaron Durbin (3):
  exynos5: Enable tps65090 on smdk5250
  power: Explicitly select pmic device's bus
  exynos5: support tps65090 pmic

Simon Glass (6):
  power: Rename CONFIG_PMIC_... to CONFIG_POWER_...
  exynos: Enable PSHOLD in SPL
  exynos: dts: Disable cros_ec interrupts due to broken GPIOs
  exynos: dts: Enable LCD for snow
  exynos: Enable the LCD backlight for snow
  initcall: Improve debugging support

Tom Wai-Hong Tam (1):
  power: Add support for TPS65090 PMU chip.

 arch/arm/cpu/armv7/exynos/lowlevel_init.c   |   2 +
 arch/arm/dts/exynos5250-snow.dts            |  56 +++++-
 board/samsung/common/board.c                |   7 +
 board/samsung/smdk5250/exynos5-dt.c         |  90 +++++++++
 doc/device-tree-bindings/power/tps65090.txt |  21 ++
 drivers/power/pmic/Makefile                 |   1 +
 drivers/power/pmic/pmic_tps65090.c          | 296 ++++++++++++++++++++++++++++
 drivers/power/power_fsl.c                   |   6 +-
 drivers/power/power_i2c.c                   |   4 +
 include/configs/arndale.h                   |   4 +-
 include/configs/exynos5-dt.h                |   1 +
 include/configs/exynos5250-dt.h             |   2 +-
 include/configs/mx25pdk.h                   |   2 +-
 include/configs/mx35pdk.h                   |   2 +-
 include/configs/mx53evk.h                   |   2 +-
 include/configs/mx53loco.h                  |   2 +-
 include/configs/woodburn_common.h           |   2 +-
 include/fdtdec.h                            |   1 +
 include/initcall.h                          |   2 +-
 include/power/tps65090_pmic.h               |  83 ++++++++
 lib/fdtdec.c                                |   1 +
 lib/initcall.c                              |  17 +-
 22 files changed, 585 insertions(+), 19 deletions(-)
 create mode 100644 doc/device-tree-bindings/power/tps65090.txt
 create mode 100644 drivers/power/pmic/pmic_tps65090.c
 create mode 100644 include/power/tps65090_pmic.h

-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 01/10] power: Rename CONFIG_PMIC_... to CONFIG_POWER_...

[Simon Glass]

Commit be3b51aa did this mostly, but several have been added since. Do the
job again.

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

 drivers/power/power_fsl.c         | 6 +++---
 include/configs/arndale.h         | 4 ++--
 include/configs/exynos5250-dt.h   | 2 +-
 include/configs/mx25pdk.h         | 2 +-
 include/configs/mx35pdk.h         | 2 +-
 include/configs/mx53evk.h         | 2 +-
 include/configs/mx53loco.h        | 2 +-
 include/configs/woodburn_common.h | 2 +-
 8 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/power/power_fsl.c b/drivers/power/power_fsl.c
index ac0b541..a64161b 100644
--- a/drivers/power/power_fsl.c
+++ b/drivers/power/power_fsl.c
@@ -11,9 +11,9 @@
 #include <fsl_pmic.h>
 #include <errno.h>
 
-#if defined(CONFIG_PMIC_FSL_MC13892)
+#if defined(CONFIG_POWER_FSL_MC13892)
 #define FSL_PMIC_I2C_LENGTH	3
-#elif defined(CONFIG_PMIC_FSL_MC34704)
+#elif defined(CONFIG_POWER_FSL_MC34704)
 #define FSL_PMIC_I2C_LENGTH	1
 #endif
 
@@ -51,7 +51,7 @@ int pmic_init(unsigned char bus)
 	p->hw.i2c.addr = CONFIG_SYS_FSL_PMIC_I2C_ADDR;
 	p->hw.i2c.tx_num = FSL_PMIC_I2C_LENGTH;
 #else
-#error "You must select CONFIG_POWER_SPI or CONFIG_PMIC_I2C"
+#error "You must select CONFIG_POWER_SPI or CONFIG_POWER_I2C"
 #endif
 
 	return 0;
diff --git a/include/configs/arndale.h b/include/configs/arndale.h
index 515facf..30ecd45 100644
--- a/include/configs/arndale.h
+++ b/include/configs/arndale.h
@@ -224,8 +224,8 @@
 
 /* PMIC */
 #define CONFIG_PMIC
-#define CONFIG_PMIC_I2C
-#define CONFIG_PMIC_MAX77686
+#define CONFIG_POWER_I2C
+#define CONFIG_POWER_MAX77686
 
 #define CONFIG_DEFAULT_DEVICE_TREE	exynos5250-arndale
 
diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index b7ff472..9d1d56a 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -45,7 +45,7 @@
 #define CONFIG_SYS_INIT_SP_ADDR	CONFIG_IRAM_STACK
 
 /* PMIC */
-#define CONFIG_PMIC_MAX77686
+#define CONFIG_POWER_MAX77686
 
 /* Sound */
 #define CONFIG_CMD_SOUND
diff --git a/include/configs/mx25pdk.h b/include/configs/mx25pdk.h
index af6aafa..571d45a 100644
--- a/include/configs/mx25pdk.h
+++ b/include/configs/mx25pdk.h
@@ -106,7 +106,7 @@
 #define CONFIG_POWER
 #define CONFIG_POWER_I2C
 #define CONFIG_POWER_FSL
-#define CONFIG_PMIC_FSL_MC34704
+#define CONFIG_POWER_FSL_MC34704
 #define CONFIG_SYS_FSL_PMIC_I2C_ADDR	0x54
 
 #define CONFIG_DOS_PARTITION
diff --git a/include/configs/mx35pdk.h b/include/configs/mx35pdk.h
index 0a46f4c..ab48144 100644
--- a/include/configs/mx35pdk.h
+++ b/include/configs/mx35pdk.h
@@ -52,7 +52,7 @@
 #define CONFIG_POWER
 #define CONFIG_POWER_I2C
 #define CONFIG_POWER_FSL
-#define CONFIG_PMIC_FSL_MC13892
+#define CONFIG_POWER_FSL_MC13892
 #define CONFIG_SYS_FSL_PMIC_I2C_ADDR	0x08
 #define CONFIG_RTC_MC13XXX
 
diff --git a/include/configs/mx53evk.h b/include/configs/mx53evk.h
index 3f0d80a..042cdd0 100644
--- a/include/configs/mx53evk.h
+++ b/include/configs/mx53evk.h
@@ -45,7 +45,7 @@
 #define CONFIG_POWER_I2C
 #define CONFIG_POWER_FSL
 #define CONFIG_SYS_FSL_PMIC_I2C_ADDR    8
-#define CONFIG_PMIC_FSL_MC13892
+#define CONFIG_POWER_FSL_MC13892
 #define CONFIG_RTC_MC13XXX
 
 /* MMC Configs */
diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index 1415584..365d072 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -80,7 +80,7 @@
 #define CONFIG_POWER_I2C
 #define CONFIG_DIALOG_POWER
 #define CONFIG_POWER_FSL
-#define CONFIG_PMIC_FSL_MC13892
+#define CONFIG_POWER_FSL_MC13892
 #define CONFIG_SYS_DIALOG_PMIC_I2C_ADDR	0x48
 #define CONFIG_SYS_FSL_PMIC_I2C_ADDR	0x8
 
diff --git a/include/configs/woodburn_common.h b/include/configs/woodburn_common.h
index 695bc23..259205e 100644
--- a/include/configs/woodburn_common.h
+++ b/include/configs/woodburn_common.h
@@ -55,7 +55,7 @@
 #define CONFIG_POWER
 #define CONFIG_POWER_I2C
 #define CONFIG_POWER_FSL
-#define CONFIG_PMIC_FSL_MC13892
+#define CONFIG_POWER_FSL_MC13892
 #define CONFIG_SYS_FSL_PMIC_I2C_ADDR	0x8
 #define CONFIG_RTC_MC13XXX
 
-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.

[Simon Glass]

From: Tom Wai-Hong Tam <waihong@chromium.org>

This adds driver support for the TPS65090 PMU. Support includes
hooking into the pmic infrastructure  so that the pmic commands
can be used on the console. The TPS65090 supports the following
functionality:

- fet enable/disable/querying
- getting and setting of charge state

Even though it is connected to the pmic infrastructure it does
not hook into the pmic charging charging infrastructure.

Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org>
Signed-off-by: Rong Chang <rongchang@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
---

 doc/device-tree-bindings/power/tps65090.txt |  21 ++
 drivers/power/pmic/Makefile                 |   1 +
 drivers/power/pmic/pmic_tps65090.c          | 296 ++++++++++++++++++++++++++++
 include/fdtdec.h                            |   1 +
 include/power/tps65090_pmic.h               |  83 ++++++++
 lib/fdtdec.c                                |   1 +
 6 files changed, 403 insertions(+)
 create mode 100644 doc/device-tree-bindings/power/tps65090.txt
 create mode 100644 drivers/power/pmic/pmic_tps65090.c
 create mode 100644 include/power/tps65090_pmic.h

diff --git a/doc/device-tree-bindings/power/tps65090.txt b/doc/device-tree-bindings/power/tps65090.txt
new file mode 100644
index 0000000..6a8a884
--- /dev/null
+++ b/doc/device-tree-bindings/power/tps65090.txt
@@ -0,0 +1,21 @@
+TPSchrome binding
+=================
+
+The device tree node which describes the operation of the Texas Instrument
+TPS65090 power regulator chip is as follows:
+
+Required properties :
+- compatible : "ti,tps65090"
+- reg : slave address on the i2c bus
+
+The tps65090 node should appear as a subnode of the i2c bus that connects it.
+
+Example
+=======
+
+	i2c at 12ca0000 {
+		power-regulator at 48 {
+			compatible = "ti,tps65090"
+			reg = <0x48>;
+		};
+	};
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 0b45ffa..7ed55e6 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -9,5 +9,6 @@ obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
 obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
 obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
 obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
+obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
 obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
 obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
diff --git a/drivers/power/pmic/pmic_tps65090.c b/drivers/power/pmic/pmic_tps65090.c
new file mode 100644
index 0000000..ef9f911
--- /dev/null
+++ b/drivers/power/pmic/pmic_tps65090.c
@@ -0,0 +1,296 @@
+/*
+ * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ */
+
+#include <common.h>
+#include <errno.h>
+#include <fdtdec.h>
+#include <i2c.h>
+#include <power/pmic.h>
+#include <power/tps65090_pmic.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define TPS65090_NAME "TPS65090_PMIC"
+
+/* TPS65090 register addresses */
+enum {
+	REG_CG_CTRL0 = 4,
+	REG_CG_STATUS1 = 0xa,
+	REG_FET1_CTRL = 0x0f,
+	REG_FET2_CTRL,
+	REG_FET3_CTRL,
+	REG_FET4_CTRL,
+	REG_FET5_CTRL,
+	REG_FET6_CTRL,
+	REG_FET7_CTRL,
+	TPS65090_NUM_REGS,
+};
+
+enum {
+	CG_CTRL0_ENC_MASK	= 0x01,
+
+	MAX_FET_NUM	= 7,
+	MAX_CTRL_READ_TRIES = 5,
+
+	/* TPS65090 FET_CTRL register values */
+	FET_CTRL_TOFET		= 1 << 7,  /* Timeout, startup, overload */
+	FET_CTRL_PGFET		= 1 << 4,  /* Power good for FET status */
+	FET_CTRL_WAIT		= 3 << 2,  /* Overcurrent timeout max */
+	FET_CTRL_ADENFET	= 1 << 1,  /* Enable output auto discharge */
+	FET_CTRL_ENFET		= 1 << 0,  /* Enable FET */
+};
+
+/**
+ * Checks for a valid FET number
+ *
+ * @param fet_id	FET number to check
+ * @return 0 if ok, -1 if FET value is out of range
+ */
+static int tps65090_check_fet(unsigned int fet_id)
+{
+	if (fet_id == 0 || fet_id > MAX_FET_NUM) {
+		debug("parameter fet_id is out of range, %u not in 1 ~ %u\n",
+		      fet_id, MAX_FET_NUM);
+		return -1;
+	}
+
+	return 0;
+}
+
+/**
+ * Set the power state for a FET
+ *
+ * @param pmic		pmic structure for the tps65090
+ * @param fet_id	Fet number to set (1..MAX_FET_NUM)
+ * @param set		1 to power on FET, 0 to power off
+ * @return FET_ERR_COMMS if we got a comms error, FET_ERR_NOT_READY if the
+ * FET failed to change state. If all is ok, returns 0.
+ */
+static int tps65090_fet_set(struct pmic *pmic, int fet_id, int set)
+{
+	int retry;
+	u32 reg, value;
+
+	value = FET_CTRL_ADENFET | FET_CTRL_WAIT;
+	if (set)
+		value |= FET_CTRL_ENFET;
+
+	if (pmic_reg_write(pmic, REG_FET1_CTRL + fet_id - 1, value))
+		return FET_ERR_COMMS;
+	/* Try reading until we get a result */
+	for (retry = 0; retry < MAX_CTRL_READ_TRIES; retry++) {
+		if (pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1, &reg))
+			return FET_ERR_COMMS;
+
+		/* Check that the fet went into the expected state */
+		if (!!(reg & FET_CTRL_PGFET) == set)
+			return 0;
+
+		/* If we got a timeout, there is no point in waiting longer */
+		if (reg & FET_CTRL_TOFET)
+			break;
+
+		mdelay(1);
+	}
+
+	debug("FET %d: Power good should have set to %d but reg=%#02x\n",
+	      fet_id, set, reg);
+	return FET_ERR_NOT_READY;
+}
+
+int tps65090_fet_enable(unsigned int fet_id)
+{
+	int loops;
+	ulong start;
+	struct pmic *pmic;
+	int ret = 0;
+
+	if (tps65090_check_fet(fet_id))
+		return -1;
+
+	pmic = pmic_get(TPS65090_NAME);
+	if (pmic == NULL)
+		return -1;
+
+	start = get_timer(0);
+	for (loops = 0;; loops++) {
+		ret = tps65090_fet_set(pmic, fet_id, 1);
+		if (!ret)
+			break;
+
+		if (get_timer(start) > 100)
+			break;
+
+		/* Turn it off and try again until we time out */
+		tps65090_fet_set(pmic, fet_id, 0);
+	}
+
+	if (ret) {
+		debug("%s: FET%d failed to power on: time=%lums, loops=%d\n",
+		      __func__, fet_id, get_timer(start), loops);
+	} else if (loops) {
+		debug("%s: FET%d powered on after %lums, loops=%d\n",
+		      __func__, fet_id, get_timer(start), loops);
+	}
+	/*
+	 * Unfortunately, there are some conditions where the power
+	 * good bit will be 0, but the fet still comes up. One such
+	 * case occurs with the lcd backlight. We'll just return 0 here
+	 * and assume that the fet will eventually come up.
+	 */
+	if (ret == FET_ERR_NOT_READY)
+		ret = 0;
+
+	return ret;
+}
+
+int tps65090_fet_disable(unsigned int fet_id)
+{
+	int ret;
+	struct pmic *pmic;
+
+	if (tps65090_check_fet(fet_id))
+		return -1;
+
+	pmic = pmic_get(TPS65090_NAME);
+	if (pmic == NULL)
+		return -1;
+	ret = tps65090_fet_set(pmic, fet_id, 0);
+
+	return ret;
+}
+
+int tps65090_fet_is_enabled(unsigned int fet_id)
+{
+	u32 reg;
+	int ret;
+	struct pmic *pmic;
+
+	if (tps65090_check_fet(fet_id))
+		return -1;
+	pmic = pmic_get(TPS65090_NAME);
+	if (pmic == NULL)
+		return -1;
+	ret = pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1, &reg);
+	if (ret) {
+		debug("fail to read FET%u_CTRL register over I2C", fet_id);
+		return -2;
+	}
+
+	return reg & FET_CTRL_ENFET;
+}
+
+int tps65090_get_charging(void)
+{
+	u32 val;
+	int ret;
+	struct pmic *pmic;
+
+	pmic = pmic_get(TPS65090_NAME);
+	if (pmic == NULL)
+		return -1;
+	ret = pmic_reg_read(pmic, REG_CG_CTRL0, &val);
+	if (ret)
+		return ret;
+	return val & CG_CTRL0_ENC_MASK ? 1 : 0;
+}
+
+int tps65090_set_charge_enable(int enable)
+{
+	u32 val;
+	int ret;
+	struct pmic *pmic;
+
+	pmic = pmic_get(TPS65090_NAME);
+	if (pmic == NULL)
+		return -1;
+
+	ret = pmic_reg_read(pmic, REG_CG_CTRL0, &val);
+	if (!ret) {
+		if (enable)
+			val |= CG_CTRL0_ENC_MASK;
+		else
+			val &= ~CG_CTRL0_ENC_MASK;
+		ret = pmic_reg_write(pmic, REG_CG_CTRL0, val);
+	}
+	if (ret) {
+		debug("%s: Failed to read/write register\n", __func__);
+		return ret;
+	}
+	return 0;
+}
+
+int tps65090_get_status(void)
+{
+	u32 val;
+	int ret;
+	struct pmic *pmic;
+
+	pmic = pmic_get(TPS65090_NAME);
+
+	if (pmic == NULL)
+		return -1;
+	ret = pmic_reg_read(pmic, REG_CG_STATUS1, &val);
+	if (ret)
+		return ret;
+	return val;
+}
+
+int tps65090_init(void)
+{
+	int bus;
+	int addr;
+	struct pmic *p;
+
+#ifdef CONFIG_OF_CONTROL
+	const void *blob = gd->fdt_blob;
+	int node, parent;
+
+	node = fdtdec_next_compatible(blob, 0, COMPAT_TI_TPS65090);
+	if (node < 0) {
+		debug("PMIC: No node for PMIC Chip in device tree\n");
+		debug("node = %d\n", node);
+		return -ENODEV;
+	}
+
+	parent = fdt_parent_offset(blob, node);
+	if (parent < 0) {
+		debug("%s: Cannot find node parent\n", __func__);
+		return -1;
+	}
+
+	bus = i2c_get_bus_num_fdt(parent);
+	if (p->bus < 0) {
+		debug("%s: Cannot find I2C bus\n", __func__);
+		return -1;
+	}
+	addr = fdtdec_get_int(blob, node, "reg", TPS65090_I2C_ADDR);
+#else
+	bus = CONFIG_POWER_TPS65090_BUS;
+	addr = TPS65090_I2C_ADDR;
+#endif
+	p = pmic_alloc();
+
+	if (!p) {
+		printf("%s: POWER allocation error!\n", __func__);
+		return -ENOMEM;
+	}
+
+	p->name = TPS65090_NAME;
+	p->bus = bus;
+	p->interface = PMIC_I2C;
+	p->number_of_regs = TPS65090_NUM_REGS;
+	p->hw.i2c.addr = addr;
+	p->hw.i2c.tx_num = 1;
+
+	puts("TPS65090 PMIC init\n");
+
+	return 0;
+}
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 6e859ce..8f17ed3 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -90,6 +90,7 @@ enum fdt_compat_id {
 	COMPAT_SAMSUNG_EXYNOS5_I2C,	/* Exynos5 High Speed I2C Controller */
 	COMPAT_SANDBOX_HOST_EMULATION,	/* Sandbox emulation of a function */
 	COMPAT_SANDBOX_LCD_SDL,		/* Sandbox LCD emulation with SDL */
+	COMPAT_TI_TPS65090,		/* Texas Instrument TPS65090 */
 
 	COMPAT_COUNT,
 };
diff --git a/include/power/tps65090_pmic.h b/include/power/tps65090_pmic.h
new file mode 100644
index 0000000..fde30eb
--- /dev/null
+++ b/include/power/tps65090_pmic.h
@@ -0,0 +1,83 @@
+/*
+ * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ */
+
+#ifndef __TPS65090_PMIC_H_
+#define __TPS65090_PMIC_H_
+
+/* I2C device address for TPS65090 PMU */
+#define TPS65090_I2C_ADDR	0x48
+
+enum {
+	/* Status register fields */
+	TPS65090_ST1_OTC	= 1 << 0,
+	TPS65090_ST1_OCC	= 1 << 1,
+	TPS65090_ST1_STATE_SHIFT = 4,
+	TPS65090_ST1_STATE_MASK	= 0xf << TPS65090_ST1_STATE_SHIFT,
+};
+
+/* FET errors */
+enum {
+	FET_ERR_COMMS		= -1,	/* FET comms error */
+	FET_ERR_NOT_READY	= -2,	/* FET is not yet ready - retry */
+};
+
+/**
+ * Enable FET
+ *
+ * @param	fet_id	FET ID, value between 1 and 7
+ * @return	0 on success, non-0 on failure
+ */
+int tps65090_fet_enable(unsigned int fet_id);
+
+/**
+ * Disable FET
+ *
+ * @param	fet_id	FET ID, value between 1 and 7
+ * @return	0 on success, non-0 on failure
+ */
+int tps65090_fet_disable(unsigned int fet_id);
+
+/**
+ * Is FET enabled?
+ *
+ * @param	fet_id	FET ID, value between 1 and 7
+ * @return	1 enabled, 0 disabled, negative value on failure
+ */
+int tps65090_fet_is_enabled(unsigned int fet_id);
+
+/**
+ * Enable / disable the battery charger
+ *
+ * @param enable	0 to disable charging, non-zero to enable
+ */
+int tps65090_set_charge_enable(int enable);
+
+/**
+ * Check whether we have enabled battery charging
+ *
+ * @return 1 if enabled, 0 if disabled
+ */
+int tps65090_get_charging(void);
+
+/**
+ * Return the value of the status register
+ *
+ * @return status register value, or -1 on error
+ */
+int tps65090_get_status(void);
+
+/**
+ * Initialize the TPS65090 PMU.
+ *
+ * @return	0 on success, non-0 on failure
+ */
+int tps65090_init(void);
+
+#endif /* __TPS65090_PMIC_H_ */
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index f65ab4f..beee1d0 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -63,6 +63,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
 	COMPAT(SAMSUNG_EXYNOS5_I2C, "samsung,exynos5-hsi2c"),
 	COMPAT(SANDBOX_HOST_EMULATION, "sandbox,host-emulation"),
 	COMPAT(SANDBOX_LCD_SDL, "sandbox,lcd-sdl"),
+	COMPAT(TI_TPS65090, "ti,tps65090"),
 };
 
 const char *fdtdec_get_compatible(enum fdt_compat_id id)
-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 03/10] exynos5: Enable tps65090 on smdk5250

[Simon Glass]

From: Aaron Durbin <adurbin@chromium.org>

The TPS65090 pmic chip can be on exynos5250 boards. Therefore,
select the appropriate config option for TPS65090 devices.

This commit should really use exynos5-dt.c, when it is available.

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

 include/configs/exynos5-dt.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h
index 414db42..fbf09f5 100644
--- a/include/configs/exynos5-dt.h
+++ b/include/configs/exynos5-dt.h
@@ -259,6 +259,7 @@
 /* PMIC */
 #define CONFIG_POWER
 #define CONFIG_POWER_I2C
+#define CONFIG_POWER_TPS65090
 
 /* Ethernet Controllor Driver */
 #ifdef CONFIG_CMD_NET
-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus

[Simon Glass]

From: Aaron Durbin <adurbin@chromium.org>

The current pmic i2c code assumes the current i2c bus is
the same as the pmic device's bus. There is nothing ensuring
that to be true. Therefore, select the proper bus before performing
a transaction.

Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
---

 drivers/power/power_i2c.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
index ac76870..594cd11 100644
--- a/drivers/power/power_i2c.c
+++ b/drivers/power/power_i2c.c
@@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
 	if (check_reg(p, reg))
 		return -1;
 
+	I2C_SET_BUS(p->bus);
+
 	switch (pmic_i2c_tx_num) {
 	case 3:
 		if (p->sensor_byte_order == PMIC_SENSOR_BYTE_ORDER_BIG) {
@@ -66,6 +68,8 @@ int pmic_reg_read(struct pmic *p, u32 reg, u32 *val)
 	if (check_reg(p, reg))
 		return -1;
 
+	I2C_SET_BUS(p->bus);
+
 	if (i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num))
 		return -1;
 
-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 05/10] exynos5: support tps65090 pmic

[Simon Glass]

From: Aaron Durbin <adurbin@chromium.org>

The TSP65090 is a PMIC on some exynos5 boards. The init function is
called for the TPS65090 pmic. If that device is not a part of the device
tree (returns -ENODEV) then continue. Otherwise return a failure.

Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
---

 board/samsung/common/board.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 3866495..654bdb6 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -23,6 +23,7 @@
 #include <power/pmic.h>
 #include <asm/arch/sromc.h>
 #include <power/max77686_pmic.h>
+#include <power/tps65090_pmic.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -261,6 +262,12 @@ int power_init_board(void)
 	ret = max77686_init();
 #endif
 
+	/* The TPS65090 may not be in the device tree. If so, it is not
+	 * an error. */
+	ret = tps65090_init();
+	if (ret == 0 || ret == -ENODEV)
+		return 0;
+
 	return ret;
 }
 #endif
-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 06/10] exynos: Enable PSHOLD in SPL

[Simon Glass]

There is quite a tight deadline in enabling PSHOLD, less than a second.
In some cases (e.g. with USB download), U-Boot takes longer than that
to load, so the board powers off before U-Boot starts.

Add a call in SPL to enable PSHOLD.

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

 arch/arm/cpu/armv7/exynos/lowlevel_init.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/cpu/armv7/exynos/lowlevel_init.c b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
index 11fe5b8..48b5511 100644
--- a/arch/arm/cpu/armv7/exynos/lowlevel_init.c
+++ b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
@@ -48,6 +48,8 @@ int do_lowlevel_init(void)
 
 	arch_cpu_init();
 
+	set_ps_hold_ctrl();
+
 	reset_status = get_reset_status();
 
 	switch (reset_status) {
-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 07/10] exynos: dts: Disable cros_ec interrupts due to broken GPIOs

[Simon Glass]

At present the GPIO numbering patch has not been applied, so exynos GPIO
numbering is inconsistent (there are large gaps). Disable interrupts to
avoid a crash on boot.

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

 arch/arm/dts/exynos5250-snow.dts | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/exynos5250-snow.dts b/arch/arm/dts/exynos5250-snow.dts
index 9b48a0c..42a687b 100644
--- a/arch/arm/dts/exynos5250-snow.dts
+++ b/arch/arm/dts/exynos5250-snow.dts
@@ -44,7 +44,11 @@
 			reg = <0x1e>;
 			compatible = "google,cros-ec";
 			i2c-max-frequency = <100000>;
-			ec-interrupt = <&gpio 782 1>;
+			/*
+			 * GPIO numbering is broken on exynos at present
+			 *
+			 * ec-interrupt = <&gpio 782 1>;
+			 */
 		};
 
 		power-regulator at 48 {
@@ -60,7 +64,11 @@
 			reg = <0>;
 			compatible = "google,cros-ec";
 			spi-max-frequency = <5000000>;
-			ec-interrupt = <&gpio 782 1>;
+			/*
+			 * GPIO numbering is broken on exynos at present
+			 *
+			 * ec-interrupt = <&gpio 782 1>;
+			 */
 			optimise-flash-write;
 			status = "disabled";
 		};
-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 08/10] exynos: dts: Enable LCD for snow

[Simon Glass]

Enable LCD for snow. This is a 1366 x 768 panel.

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

 arch/arm/dts/exynos5250-snow.dts | 44 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/dts/exynos5250-snow.dts b/arch/arm/dts/exynos5250-snow.dts
index 42a687b..725a1bf 100644
--- a/arch/arm/dts/exynos5250-snow.dts
+++ b/arch/arm/dts/exynos5250-snow.dts
@@ -192,4 +192,48 @@
 			/* UP      LEFT    */
 			0x070b0067 0x070c0069>;
 	};
+
+	fimd at 14400000 {
+		samsung,vl-freq = <60>;
+		samsung,vl-col = <1366>;
+		samsung,vl-row = <768>;
+		samsung,vl-width = <1366>;
+		samsung,vl-height = <768>;
+
+		samsung,vl-clkp;
+		samsung,vl-dp;
+		samsung,vl-hsp;
+		samsung,vl-vsp;
+
+		samsung,vl-bpix = <4>;
+
+		samsung,vl-hspw = <32>;
+		samsung,vl-hbpd = <80>;
+		samsung,vl-hfpd = <48>;
+		samsung,vl-vspw = <5>;
+		samsung,vl-vbpd = <14>;
+		samsung,vl-vfpd = <3>;
+		samsung,vl-cmd-allow-len = <0xf>;
+
+		samsung,winid = <0>;
+		samsung,interface-mode = <1>;
+		samsung,dp-enabled = <1>;
+		samsung,dual-lcd-enabled = <0>;
+	};
+
+	dp at 145b0000 {
+		samsung,lt-status = <0>;
+
+		samsung,master-mode = <0>;
+		samsung,bist-mode = <0>;
+		samsung,bist-pattern = <0>;
+		samsung,h-sync-polarity = <0>;
+		samsung,v-sync-polarity = <0>;
+		samsung,interlaced = <0>;
+		samsung,color-space = <0>;
+		samsung,dynamic-range = <0>;
+		samsung,ycbcr-coeff = <0>;
+		samsung,color-depth = <1>;
+	};
+
 };
-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight for snow

[Simon Glass]

The backlight uses FETs on the TPS65090. Enable this so that the display
is visible.

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

 board/samsung/smdk5250/exynos5-dt.c | 90 +++++++++++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)

diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c
index c83b034..a0ae641 100644
--- a/board/samsung/smdk5250/exynos5-dt.c
+++ b/board/samsung/smdk5250/exynos5-dt.c
@@ -20,6 +20,7 @@
 #include <asm/arch/sromc.h>
 #include <power/pmic.h>
 #include <power/max77686_pmic.h>
+#include <power/tps65090_pmic.h>
 #include <tmu.h>
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -60,6 +61,52 @@ int checkboard(void)
 #endif
 
 #ifdef CONFIG_LCD
+static int board_dp_bridge_setup(void)
+{
+	struct exynos5_gpio_part1 *gpio1 =
+		(struct exynos5_gpio_part1 *)samsung_get_base_gpio_part1();
+	const int MAX_TRIES = 10;
+	int num_tries;
+
+	debug("%s\n", __func__);
+
+	/* Setup the GPIOs */
+
+	/* PD is ACTIVE_LOW, and initially de-asserted */
+	s5p_gpio_set_pull(&gpio1->y2, 5, GPIO_PULL_NONE);
+	s5p_gpio_direction_output(&gpio1->y2, 5, 1);
+
+	/* Reset is ACTIVE_LOW */
+	s5p_gpio_set_pull(&gpio1->x1, 5, GPIO_PULL_NONE);
+	s5p_gpio_direction_output(&gpio1->x1, 5, 0);
+
+	udelay(10);
+	s5p_gpio_set_value(&gpio1->x1, 5, 1);
+
+	s5p_gpio_direction_input(&gpio1->x0, 7);
+
+	/*
+	 * We need to wait for 90ms after bringing up the bridge since there
+	 * is a phantom "high" on the HPD chip during its bootup.  The phantom
+	 * high comes within 7ms of de-asserting PD and persists for at least
+	 * 15ms.  The real high comes roughly 50ms after PD is de-asserted. The
+	 * phantom high makes it hard for us to know when the NXP chip is up.
+	 */
+	mdelay(90);
+
+	for (num_tries = 0; num_tries < MAX_TRIES; num_tries++) {
+		/* Check HPD.  If it's high, we're all good. */
+		if (s5p_gpio_get_value(&gpio1->x0, 7))
+				return 0;
+
+		debug("%s: eDP bridge failed to come up; try %d of %d\n",
+		      __func__, num_tries, MAX_TRIES);
+	}
+
+	/* Immediately go into bridge reset if the hp line is not high */
+	return -ENODEV;
+}
+
 void exynos_cfg_lcd_gpio(void)
 {
 	struct exynos5_gpio_part1 *gpio1 =
@@ -81,4 +128,47 @@ void exynos_set_dp_phy(unsigned int onoff)
 {
 	set_dp_phy_ctrl(onoff);
 }
+
+void exynos_backlight_on(unsigned int onoff)
+{
+	debug("%s(%u)\n", __func__, onoff);
+
+	if (onoff) {
+#ifdef CONFIG_POWER_TPS65090
+		struct exynos5_gpio_part1 *gpio1 =
+			(struct exynos5_gpio_part1 *)
+					samsung_get_base_gpio_part1();
+		int ret;
+
+		ret = tps65090_fet_enable(1); /* Enable FET1, backlight */
+		if (ret)
+			return;
+
+		/* T5 in the LCD timing spec (defined as > 10ms) */
+		mdelay(10);
+
+		/* board_dp_backlight_pwm */
+		s5p_gpio_direction_output(&gpio1->b2, 0, 1);
+
+		/* T6 in the LCD timing spec (defined as > 10ms) */
+		mdelay(10);
+
+		/* board_dp_backlight_en */
+		s5p_gpio_direction_output(&gpio1->x3, 0, 1);
+#endif
+	}
+}
+
+void exynos_lcd_power_on(void)
+{
+	debug("%s\n", __func__);
+
+#ifdef CONFIG_POWER_TPS65090
+	/* board_dp_lcd_vdd */
+	tps65090_fet_enable(6); /* Enable FET6, lcd panel */
+#endif
+
+	board_dp_bridge_setup();
+}
+
 #endif
-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 10/10] initcall: Improve debugging support

[Simon Glass]

Add the ability to display the code offset of an initcall even after it
is relocated. This makes it much easier to relate initcalls back to the
U-Boot System.map file.

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

 include/initcall.h |  2 +-
 lib/initcall.c     | 17 ++++++++++++-----
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/include/initcall.h b/include/initcall.h
index 2378077..65f67dc 100644
--- a/include/initcall.h
+++ b/include/initcall.h
@@ -6,4 +6,4 @@
 
 typedef int (*init_fnc_t)(void);
 
-int initcall_run_list(init_fnc_t init_sequence[]);
+int initcall_run_list(const init_fnc_t init_sequence[]);
diff --git a/lib/initcall.c b/lib/initcall.c
index fa76dd7..7597bad 100644
--- a/lib/initcall.c
+++ b/lib/initcall.c
@@ -7,15 +7,22 @@
 #include <common.h>
 #include <initcall.h>
 
-int initcall_run_list(init_fnc_t init_sequence[])
+DECLARE_GLOBAL_DATA_PTR;
+
+int initcall_run_list(const init_fnc_t init_sequence[])
 {
-	init_fnc_t *init_fnc_ptr;
+	const init_fnc_t *init_fnc_ptr;
 
 	for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
-		debug("initcall: %p\n", *init_fnc_ptr);
+		unsigned long reloc_ofs = 0;
+
+		if (gd->flags & GD_FLG_RELOC)
+			reloc_ofs = gd->reloc_off;
+		debug("initcall: %p\n", (char *)*init_fnc_ptr - reloc_ofs);
 		if ((*init_fnc_ptr)()) {
-			debug("initcall sequence %p failed at call %p\n",
-			      init_sequence, *init_fnc_ptr);
+			printf("initcall sequence %p failed at call %p\n",
+			       init_sequence,
+			       (char *)*init_fnc_ptr - reloc_ofs);
 			return -1;
 		}
 	}
-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight for snow

[Minkyu Kang]

On 27/03/14 02:56, Simon Glass wrote:
> The backlight uses FETs on the TPS65090. Enable this so that the display
> is visible.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
> 
>  board/samsung/smdk5250/exynos5-dt.c | 90 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 90 insertions(+)
> 
> diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c
> index c83b034..a0ae641 100644
> --- a/board/samsung/smdk5250/exynos5-dt.c
> +++ b/board/samsung/smdk5250/exynos5-dt.c
> @@ -20,6 +20,7 @@
>  #include <asm/arch/sromc.h>
>  #include <power/pmic.h>
>  #include <power/max77686_pmic.h>
> +#include <power/tps65090_pmic.h>
>  #include <tmu.h>
>  
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -60,6 +61,52 @@ int checkboard(void)
>  #endif
>  
>  #ifdef CONFIG_LCD
> +static int board_dp_bridge_setup(void)
> +{
> +	struct exynos5_gpio_part1 *gpio1 =
> +		(struct exynos5_gpio_part1 *)samsung_get_base_gpio_part1();
> +	const int MAX_TRIES = 10;
> +	int num_tries;
> +
> +	debug("%s\n", __func__);
> +
> +	/* Setup the GPIOs */
> +
> +	/* PD is ACTIVE_LOW, and initially de-asserted */
> +	s5p_gpio_set_pull(&gpio1->y2, 5, GPIO_PULL_NONE);
> +	s5p_gpio_direction_output(&gpio1->y2, 5, 1);
> +
> +	/* Reset is ACTIVE_LOW */
> +	s5p_gpio_set_pull(&gpio1->x1, 5, GPIO_PULL_NONE);
> +	s5p_gpio_direction_output(&gpio1->x1, 5, 0);
> +
> +	udelay(10);
> +	s5p_gpio_set_value(&gpio1->x1, 5, 1);
> +
> +	s5p_gpio_direction_input(&gpio1->x0, 7);
> +
> +	/*
> +	 * We need to wait for 90ms after bringing up the bridge since there
> +	 * is a phantom "high" on the HPD chip during its bootup.  The phantom
> +	 * high comes within 7ms of de-asserting PD and persists for at least
> +	 * 15ms.  The real high comes roughly 50ms after PD is de-asserted. The
> +	 * phantom high makes it hard for us to know when the NXP chip is up.
> +	 */
> +	mdelay(90);
> +
> +	for (num_tries = 0; num_tries < MAX_TRIES; num_tries++) {
> +		/* Check HPD.  If it's high, we're all good. */
> +		if (s5p_gpio_get_value(&gpio1->x0, 7))
> +				return 0;
> +
> +		debug("%s: eDP bridge failed to come up; try %d of %d\n",
> +		      __func__, num_tries, MAX_TRIES);
> +	}
> +
> +	/* Immediately go into bridge reset if the hp line is not high */
> +	return -ENODEV;
> +}
> +
>  void exynos_cfg_lcd_gpio(void)
>  {
>  	struct exynos5_gpio_part1 *gpio1 =
> @@ -81,4 +128,47 @@ void exynos_set_dp_phy(unsigned int onoff)
>  {
>  	set_dp_phy_ctrl(onoff);
>  }
> +
> +void exynos_backlight_on(unsigned int onoff)
> +{
> +	debug("%s(%u)\n", __func__, onoff);
> +
> +	if (onoff) {

How about return immediately if onoff is 0.
 
	if (!onoff)
		return;

> +#ifdef CONFIG_POWER_TPS65090
> +		struct exynos5_gpio_part1 *gpio1 =
> +			(struct exynos5_gpio_part1 *)
> +					samsung_get_base_gpio_part1();
> +		int ret;
> +
> +		ret = tps65090_fet_enable(1); /* Enable FET1, backlight */
> +		if (ret)
> +			return;
> +
> +		/* T5 in the LCD timing spec (defined as > 10ms) */
> +		mdelay(10);
> +
> +		/* board_dp_backlight_pwm */
> +		s5p_gpio_direction_output(&gpio1->b2, 0, 1);
> +
> +		/* T6 in the LCD timing spec (defined as > 10ms) */
> +		mdelay(10);
> +
> +		/* board_dp_backlight_en */
> +		s5p_gpio_direction_output(&gpio1->x3, 0, 1);
> +#endif
> +	}
> +}
> +
> +void exynos_lcd_power_on(void)
> +{
> +	debug("%s\n", __func__);
> +
> +#ifdef CONFIG_POWER_TPS65090
> +	/* board_dp_lcd_vdd */
> +	tps65090_fet_enable(6); /* Enable FET6, lcd panel */
> +#endif
> +
> +	board_dp_bridge_setup();
> +}
> +
>  #endif
> 

Thanks,
Minkyu Kang.

[U-Boot] [PATCH 05/10] exynos5: support tps65090 pmic

[Minkyu Kang]

On 27/03/14 02:56, Simon Glass wrote:
> From: Aaron Durbin <adurbin@chromium.org>
> 
> The TSP65090 is a PMIC on some exynos5 boards. The init function is
> called for the TPS65090 pmic. If that device is not a part of the device
> tree (returns -ENODEV) then continue. Otherwise return a failure.
> 
> Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> ---
> 
>  board/samsung/common/board.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
> index 3866495..654bdb6 100644
> --- a/board/samsung/common/board.c
> +++ b/board/samsung/common/board.c
> @@ -23,6 +23,7 @@
>  #include <power/pmic.h>
>  #include <asm/arch/sromc.h>
>  #include <power/max77686_pmic.h>
> +#include <power/tps65090_pmic.h>
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -261,6 +262,12 @@ int power_init_board(void)
>  	ret = max77686_init();
>  #endif

What is the base tree of this patch?
looks different with samsung tree.
seems to need rebase?

>  

#ifdef CONFIG_POWER_TPS65090

> +	/* The TPS65090 may not be in the device tree. If so, it is not
> +	 * an error. */

please fix this multi line comment.
It should be
/*
 * ...
 * ...
 */

> +	ret = tps65090_init();
> +	if (ret == 0 || ret == -ENODEV)
> +		return 0;

#endif

> +
>  	return ret;
>  }
>  #endif
> 

Thanks,
Minkyu Kang.

[U-Boot] [PATCH 01/10] power: Rename CONFIG_PMIC_... to CONFIG_POWER_...

[Lukasz Majewski]

Hi Simon,

> Commit be3b51aa did this mostly, but several have been added since.
> Do the job again.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
> 
>  drivers/power/power_fsl.c         | 6 +++---
>  include/configs/arndale.h         | 4 ++--
>  include/configs/exynos5250-dt.h   | 2 +-
>  include/configs/mx25pdk.h         | 2 +-
>  include/configs/mx35pdk.h         | 2 +-
>  include/configs/mx53evk.h         | 2 +-
>  include/configs/mx53loco.h        | 2 +-
>  include/configs/woodburn_common.h | 2 +-
>  8 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/power/power_fsl.c b/drivers/power/power_fsl.c
> index ac0b541..a64161b 100644
> --- a/drivers/power/power_fsl.c
> +++ b/drivers/power/power_fsl.c
> @@ -11,9 +11,9 @@
>  #include <fsl_pmic.h>
>  #include <errno.h>
>  
> -#if defined(CONFIG_PMIC_FSL_MC13892)
> +#if defined(CONFIG_POWER_FSL_MC13892)
>  #define FSL_PMIC_I2C_LENGTH	3
> -#elif defined(CONFIG_PMIC_FSL_MC34704)
> +#elif defined(CONFIG_POWER_FSL_MC34704)
>  #define FSL_PMIC_I2C_LENGTH	1
>  #endif
>  
> @@ -51,7 +51,7 @@ int pmic_init(unsigned char bus)
>  	p->hw.i2c.addr = CONFIG_SYS_FSL_PMIC_I2C_ADDR;
>  	p->hw.i2c.tx_num = FSL_PMIC_I2C_LENGTH;
>  #else
> -#error "You must select CONFIG_POWER_SPI or CONFIG_PMIC_I2C"
> +#error "You must select CONFIG_POWER_SPI or CONFIG_POWER_I2C"
>  #endif
>  
>  	return 0;
> diff --git a/include/configs/arndale.h b/include/configs/arndale.h
> index 515facf..30ecd45 100644
> --- a/include/configs/arndale.h
> +++ b/include/configs/arndale.h
> @@ -224,8 +224,8 @@
>  
>  /* PMIC */
>  #define CONFIG_PMIC
> -#define CONFIG_PMIC_I2C
> -#define CONFIG_PMIC_MAX77686
> +#define CONFIG_POWER_I2C
> +#define CONFIG_POWER_MAX77686
>  
>  #define CONFIG_DEFAULT_DEVICE_TREE	exynos5250-arndale
>  
> diff --git a/include/configs/exynos5250-dt.h
> b/include/configs/exynos5250-dt.h index b7ff472..9d1d56a 100644
> --- a/include/configs/exynos5250-dt.h
> +++ b/include/configs/exynos5250-dt.h
> @@ -45,7 +45,7 @@
>  #define CONFIG_SYS_INIT_SP_ADDR	CONFIG_IRAM_STACK
>  
>  /* PMIC */
> -#define CONFIG_PMIC_MAX77686
> +#define CONFIG_POWER_MAX77686
>  
>  /* Sound */
>  #define CONFIG_CMD_SOUND
> diff --git a/include/configs/mx25pdk.h b/include/configs/mx25pdk.h
> index af6aafa..571d45a 100644
> --- a/include/configs/mx25pdk.h
> +++ b/include/configs/mx25pdk.h
> @@ -106,7 +106,7 @@
>  #define CONFIG_POWER
>  #define CONFIG_POWER_I2C
>  #define CONFIG_POWER_FSL
> -#define CONFIG_PMIC_FSL_MC34704
> +#define CONFIG_POWER_FSL_MC34704
>  #define CONFIG_SYS_FSL_PMIC_I2C_ADDR	0x54
>  
>  #define CONFIG_DOS_PARTITION
> diff --git a/include/configs/mx35pdk.h b/include/configs/mx35pdk.h
> index 0a46f4c..ab48144 100644
> --- a/include/configs/mx35pdk.h
> +++ b/include/configs/mx35pdk.h
> @@ -52,7 +52,7 @@
>  #define CONFIG_POWER
>  #define CONFIG_POWER_I2C
>  #define CONFIG_POWER_FSL
> -#define CONFIG_PMIC_FSL_MC13892
> +#define CONFIG_POWER_FSL_MC13892
>  #define CONFIG_SYS_FSL_PMIC_I2C_ADDR	0x08
>  #define CONFIG_RTC_MC13XXX
>  
> diff --git a/include/configs/mx53evk.h b/include/configs/mx53evk.h
> index 3f0d80a..042cdd0 100644
> --- a/include/configs/mx53evk.h
> +++ b/include/configs/mx53evk.h
> @@ -45,7 +45,7 @@
>  #define CONFIG_POWER_I2C
>  #define CONFIG_POWER_FSL
>  #define CONFIG_SYS_FSL_PMIC_I2C_ADDR    8
> -#define CONFIG_PMIC_FSL_MC13892
> +#define CONFIG_POWER_FSL_MC13892
>  #define CONFIG_RTC_MC13XXX
>  
>  /* MMC Configs */
> diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
> index 1415584..365d072 100644
> --- a/include/configs/mx53loco.h
> +++ b/include/configs/mx53loco.h
> @@ -80,7 +80,7 @@
>  #define CONFIG_POWER_I2C
>  #define CONFIG_DIALOG_POWER
>  #define CONFIG_POWER_FSL
> -#define CONFIG_PMIC_FSL_MC13892
> +#define CONFIG_POWER_FSL_MC13892
>  #define CONFIG_SYS_DIALOG_PMIC_I2C_ADDR	0x48
>  #define CONFIG_SYS_FSL_PMIC_I2C_ADDR	0x8
>  
> diff --git a/include/configs/woodburn_common.h
> b/include/configs/woodburn_common.h index 695bc23..259205e 100644
> --- a/include/configs/woodburn_common.h
> +++ b/include/configs/woodburn_common.h
> @@ -55,7 +55,7 @@
>  #define CONFIG_POWER
>  #define CONFIG_POWER_I2C
>  #define CONFIG_POWER_FSL
> -#define CONFIG_PMIC_FSL_MC13892
> +#define CONFIG_POWER_FSL_MC13892
>  #define CONFIG_SYS_FSL_PMIC_I2C_ADDR	0x8
>  #define CONFIG_RTC_MC13XXX
>  

Acked-by: Lukasz Majewski <l.majewski@samsung.com>

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [PATCH 06/10] exynos: Enable PSHOLD in SPL

[Lukasz Majewski]

Hi Simon,

> There is quite a tight deadline in enabling PSHOLD, less than a
> second. In some cases (e.g. with USB download), U-Boot takes longer
> than that to load, so the board powers off before U-Boot starts.
> 
> Add a call in SPL to enable PSHOLD.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
> 
>  arch/arm/cpu/armv7/exynos/lowlevel_init.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv7/exynos/lowlevel_init.c
> b/arch/arm/cpu/armv7/exynos/lowlevel_init.c index 11fe5b8..48b5511
> 100644 --- a/arch/arm/cpu/armv7/exynos/lowlevel_init.c
> +++ b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
> @@ -48,6 +48,8 @@ int do_lowlevel_init(void)
>  
>  	arch_cpu_init();
>  
> +	set_ps_hold_ctrl();
> +
>  	reset_status = get_reset_status();
>  
>  	switch (reset_status) {

Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [PATCH 08/10] exynos: dts: Enable LCD for snow

[Lukasz Majewski]

Hi Simon,

> Enable LCD for snow. This is a 1366 x 768 panel.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
> 
>  arch/arm/dts/exynos5250-snow.dts | 44
> ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44
> insertions(+)
> 
> diff --git a/arch/arm/dts/exynos5250-snow.dts
> b/arch/arm/dts/exynos5250-snow.dts index 42a687b..725a1bf 100644
> --- a/arch/arm/dts/exynos5250-snow.dts
> +++ b/arch/arm/dts/exynos5250-snow.dts
> @@ -192,4 +192,48 @@
>  			/* UP      LEFT    */
>  			0x070b0067 0x070c0069>;
>  	};
> +
> +	fimd at 14400000 {
> +		samsung,vl-freq = <60>;
> +		samsung,vl-col = <1366>;
> +		samsung,vl-row = <768>;
> +		samsung,vl-width = <1366>;
> +		samsung,vl-height = <768>;
> +
> +		samsung,vl-clkp;
> +		samsung,vl-dp;
> +		samsung,vl-hsp;
> +		samsung,vl-vsp;
> +
> +		samsung,vl-bpix = <4>;
> +
> +		samsung,vl-hspw = <32>;
> +		samsung,vl-hbpd = <80>;
> +		samsung,vl-hfpd = <48>;
> +		samsung,vl-vspw = <5>;
> +		samsung,vl-vbpd = <14>;
> +		samsung,vl-vfpd = <3>;
> +		samsung,vl-cmd-allow-len = <0xf>;
> +
> +		samsung,winid = <0>;
> +		samsung,interface-mode = <1>;
> +		samsung,dp-enabled = <1>;
> +		samsung,dual-lcd-enabled = <0>;
> +	};
> +

I can only now regret that we have not stick to the Linux kernel DTS
format and be ABI compatible with Linux (and add u-boot specific
bindings as an extension).

Now unfortunately it is too late.

> +	dp at 145b0000 {
> +		samsung,lt-status = <0>;
> +
> +		samsung,master-mode = <0>;
> +		samsung,bist-mode = <0>;
> +		samsung,bist-pattern = <0>;
> +		samsung,h-sync-polarity = <0>;
> +		samsung,v-sync-polarity = <0>;
> +		samsung,interlaced = <0>;
> +		samsung,color-space = <0>;
> +		samsung,dynamic-range = <0>;
> +		samsung,ycbcr-coeff = <0>;
> +		samsung,color-depth = <1>;
> +	};
> +
>  };

Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight for snow

[Lukasz Majewski]

Hi Simon,

> The backlight uses FETs on the TPS65090. Enable this so that the
> display is visible.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
> 
>  board/samsung/smdk5250/exynos5-dt.c | 90
> +++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+)
> 
> diff --git a/board/samsung/smdk5250/exynos5-dt.c
> b/board/samsung/smdk5250/exynos5-dt.c index c83b034..a0ae641 100644
> --- a/board/samsung/smdk5250/exynos5-dt.c
> +++ b/board/samsung/smdk5250/exynos5-dt.c
> @@ -20,6 +20,7 @@
>  #include <asm/arch/sromc.h>
>  #include <power/pmic.h>
>  #include <power/max77686_pmic.h>
> +#include <power/tps65090_pmic.h>
>  #include <tmu.h>
>  
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -60,6 +61,52 @@ int checkboard(void)
>  #endif
>  
>  #ifdef CONFIG_LCD
> +static int board_dp_bridge_setup(void)
> +{
> +	struct exynos5_gpio_part1 *gpio1 =
> +		(struct exynos5_gpio_part1
> *)samsung_get_base_gpio_part1();
> +	const int MAX_TRIES = 10;
> +	int num_tries;
> +
> +	debug("%s\n", __func__);
> +
> +	/* Setup the GPIOs */
> +
> +	/* PD is ACTIVE_LOW, and initially de-asserted */
> +	s5p_gpio_set_pull(&gpio1->y2, 5, GPIO_PULL_NONE);
> +	s5p_gpio_direction_output(&gpio1->y2, 5, 1);
> +
> +	/* Reset is ACTIVE_LOW */
> +	s5p_gpio_set_pull(&gpio1->x1, 5, GPIO_PULL_NONE);
> +	s5p_gpio_direction_output(&gpio1->x1, 5, 0);
> +
> +	udelay(10);
> +	s5p_gpio_set_value(&gpio1->x1, 5, 1);
> +
> +	s5p_gpio_direction_input(&gpio1->x0, 7);
> +
> +	/*
> +	 * We need to wait for 90ms after bringing up the bridge
> since there
> +	 * is a phantom "high" on the HPD chip during its bootup.
> The phantom
> +	 * high comes within 7ms of de-asserting PD and persists for
> at least
> +	 * 15ms.  The real high comes roughly 50ms after PD is
> de-asserted. The
> +	 * phantom high makes it hard for us to know when the NXP
> chip is up.
> +	 */
> +	mdelay(90);
> +
> +	for (num_tries = 0; num_tries < MAX_TRIES; num_tries++) {
> +		/* Check HPD.  If it's high, we're all good. */
> +		if (s5p_gpio_get_value(&gpio1->x0, 7))
> +				return 0;
> +
> +		debug("%s: eDP bridge failed to come up; try %d of
> %d\n",
> +		      __func__, num_tries, MAX_TRIES);
> +	}
> +
> +	/* Immediately go into bridge reset if the hp line is not
> high */
> +	return -ENODEV;
> +}
> +
>  void exynos_cfg_lcd_gpio(void)
>  {
>  	struct exynos5_gpio_part1 *gpio1 =
> @@ -81,4 +128,47 @@ void exynos_set_dp_phy(unsigned int onoff)
>  {
>  	set_dp_phy_ctrl(onoff);
>  }
> +
> +void exynos_backlight_on(unsigned int onoff)
> +{
> +	debug("%s(%u)\n", __func__, onoff);
> +
> +	if (onoff) {
> +#ifdef CONFIG_POWER_TPS65090
> +		struct exynos5_gpio_part1 *gpio1 =
> +			(struct exynos5_gpio_part1 *)
> +
> samsung_get_base_gpio_part1();
> +		int ret;
> +
> +		ret = tps65090_fet_enable(1); /* Enable FET1,
> backlight */
> +		if (ret)
> +			return;
> +
> +		/* T5 in the LCD timing spec (defined as > 10ms) */
> +		mdelay(10);
> +
> +		/* board_dp_backlight_pwm */
> +		s5p_gpio_direction_output(&gpio1->b2, 0, 1);
> +
> +		/* T6 in the LCD timing spec (defined as > 10ms) */
> +		mdelay(10);
> +
> +		/* board_dp_backlight_en */
> +		s5p_gpio_direction_output(&gpio1->x3, 0, 1);
> +#endif
> +	}
> +}
> +
> +void exynos_lcd_power_on(void)
> +{
> +	debug("%s\n", __func__);
> +
> +#ifdef CONFIG_POWER_TPS65090
> +	/* board_dp_lcd_vdd */
> +	tps65090_fet_enable(6); /* Enable FET6, lcd panel */
> +#endif
> +
> +	board_dp_bridge_setup();
> +}
> +
>  #endif

Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [PATCH 05/10] exynos5: support tps65090 pmic

[Lukasz Majewski]

Hi Simon,

> From: Aaron Durbin <adurbin@chromium.org>
> 
> The TSP65090 is a PMIC on some exynos5 boards. The init function is
> called for the TPS65090 pmic. If that device is not a part of the
> device tree (returns -ENODEV) then continue. Otherwise return a
> failure.
> 
> Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> ---
> 
>  board/samsung/common/board.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/board/samsung/common/board.c
> b/board/samsung/common/board.c index 3866495..654bdb6 100644
> --- a/board/samsung/common/board.c
> +++ b/board/samsung/common/board.c
> @@ -23,6 +23,7 @@
>  #include <power/pmic.h>
>  #include <asm/arch/sromc.h>
>  #include <power/max77686_pmic.h>
> +#include <power/tps65090_pmic.h>
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -261,6 +262,12 @@ int power_init_board(void)
>  	ret = max77686_init();
>  #endif
>  
> +	/* The TPS65090 may not be in the device tree. If so, it is
> not
> +	 * an error. */
> +	ret = tps65090_init();
> +	if (ret == 0 || ret == -ENODEV)
> +		return 0;
> +
>  	return ret;
>  }
>  #endif

Acked-by: Lukasz Majewski <l.majewski@samsung.com>

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus

[Lukasz Majewski]

Hi Simon, Heiko

> From: Aaron Durbin <adurbin@chromium.org>
> 
> The current pmic i2c code assumes the current i2c bus is
> the same as the pmic device's bus. There is nothing ensuring
> that to be true. Therefore, select the proper bus before performing
> a transaction.
> 
> Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> ---
> 
>  drivers/power/power_i2c.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
> index ac76870..594cd11 100644
> --- a/drivers/power/power_i2c.c
> +++ b/drivers/power/power_i2c.c
> @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
>  	if (check_reg(p, reg))
>  		return -1;
>  
> +	I2C_SET_BUS(p->bus);
> +

Hadn't we had a  discussion about this explicit setting of I2C some time
ago? I thought that this problem was solved within the I2C rework.

Also I might be wrong, so please correct me if I'm wrong. Isn't the
I2C_SET_BUS() macro regarded as a obsolete after the I2C rework?

>  	switch (pmic_i2c_tx_num) {
>  	case 3:
>  		if (p->sensor_byte_order ==
> PMIC_SENSOR_BYTE_ORDER_BIG) { @@ -66,6 +68,8 @@ int
> pmic_reg_read(struct pmic *p, u32 reg, u32 *val) if (check_reg(p,
> reg)) return -1;
>  
> +	I2C_SET_BUS(p->bus);
> +
>  	if (i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num))
>  		return -1;
>  



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.

[Lukasz Majewski]

Hi Simon,

> From: Tom Wai-Hong Tam <waihong@chromium.org>
> 
> This adds driver support for the TPS65090 PMU. Support includes
> hooking into the pmic infrastructure  so that the pmic commands
> can be used on the console. The TPS65090 supports the following
> functionality:
> 
> - fet enable/disable/querying
> - getting and setting of charge state
> 
> Even though it is connected to the pmic infrastructure it does
> not hook into the pmic charging charging infrastructure.

Can I ask what was the problem with adding support for "pmic bat
[state|charge]" command on this PMIC?

Was the framework unfriendly or there was no need to do that? 

> 
> Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
> Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org>
> Signed-off-by: Rong Chang <rongchang@chromium.org>
> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
> Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> ---
> 
>  doc/device-tree-bindings/power/tps65090.txt |  21 ++
>  drivers/power/pmic/Makefile                 |   1 +
>  drivers/power/pmic/pmic_tps65090.c          | 296
> ++++++++++++++++++++++++++++
> include/fdtdec.h                            |   1 +
> include/power/tps65090_pmic.h               |  83 ++++++++
> lib/fdtdec.c                                |   1 + 6 files changed,
> 403 insertions(+) create mode 100644
> doc/device-tree-bindings/power/tps65090.txt create mode 100644
> drivers/power/pmic/pmic_tps65090.c create mode 100644
> include/power/tps65090_pmic.h
> 
> diff --git a/doc/device-tree-bindings/power/tps65090.txt
> b/doc/device-tree-bindings/power/tps65090.txt new file mode 100644
> index 0000000..6a8a884
> --- /dev/null
> +++ b/doc/device-tree-bindings/power/tps65090.txt
> @@ -0,0 +1,21 @@
> +TPSchrome binding
> +=================
> +
> +The device tree node which describes the operation of the Texas
> Instrument +TPS65090 power regulator chip is as follows:
> +
> +Required properties :
> +- compatible : "ti,tps65090"
> +- reg : slave address on the i2c bus
> +
> +The tps65090 node should appear as a subnode of the i2c bus that
> connects it. +
> +Example
> +=======
> +
> +       i2c at 12ca0000 {
> +               power-regulator at 48 {
> +                       compatible = "ti,tps65090"
> +                       reg = <0x48>;
> +               };
> +       };

Those bindings look very different from the one at Linux kernel for
this device. Therefore I assume that there was justification to not
stick to the linux kernel DT format.

> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> index 0b45ffa..7ed55e6 100644
> --- a/drivers/power/pmic/Makefile
> +++ b/drivers/power/pmic/Makefile
> @@ -9,5 +9,6 @@ obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
>  obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
>  obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
>  obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
> +obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
>  obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
>  obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
> diff --git a/drivers/power/pmic/pmic_tps65090.c
> b/drivers/power/pmic/pmic_tps65090.c new file mode 100644
> index 0000000..ef9f911
> --- /dev/null
> +++ b/drivers/power/pmic/pmic_tps65090.c
> @@ -0,0 +1,296 @@
> +/*
> + * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
> + * Use of this source code is governed by a BSD-style license that
> can be
> + * found in the LICENSE file.
> + *
> + * Alternatively, this software may be distributed under the terms
> of the
> + * GNU General Public License ("GPL") version 2 as published by the
> Free
> + * Software Foundation.

Would it be possible to tune this license description to be similar to 
SPDX-License-Identifier:	GPL-2.0+|BSD

> + */
> +
> +#include <common.h>
> +#include <errno.h>
> +#include <fdtdec.h>
> +#include <i2c.h>
> +#include <power/pmic.h>
> +#include <power/tps65090_pmic.h>
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define TPS65090_NAME "TPS65090_PMIC"
> +
> +/* TPS65090 register addresses */
> +enum {
> +       REG_CG_CTRL0 = 4,
> +       REG_CG_STATUS1 = 0xa,
> +       REG_FET1_CTRL = 0x0f,
> +       REG_FET2_CTRL,
> +       REG_FET3_CTRL,
> +       REG_FET4_CTRL,
> +       REG_FET5_CTRL,
> +       REG_FET6_CTRL,
> +       REG_FET7_CTRL,
> +       TPS65090_NUM_REGS,
> +};
> +
> +enum {
> +       CG_CTRL0_ENC_MASK       = 0x01,
> +
> +       MAX_FET_NUM     = 7,
> +       MAX_CTRL_READ_TRIES = 5,
> +
> +       /* TPS65090 FET_CTRL register values */
> +       FET_CTRL_TOFET          = 1 << 7,  /* Timeout, startup,
> overload */
> +       FET_CTRL_PGFET          = 1 << 4,  /* Power good for FET
> status */
> +       FET_CTRL_WAIT           = 3 << 2,  /* Overcurrent timeout max
> */
> +       FET_CTRL_ADENFET        = 1 << 1,  /* Enable output auto
> discharge */
> +       FET_CTRL_ENFET          = 1 << 0,  /* Enable FET */
> +};
> +
> +/**
> + * Checks for a valid FET number
> + *
> + * @param fet_id       FET number to check
> + * @return 0 if ok, -1 if FET value is out of range
> + */
> +static int tps65090_check_fet(unsigned int fet_id)
> +{
> +       if (fet_id == 0 || fet_id > MAX_FET_NUM) {
> +               debug("parameter fet_id is out of range, %u not in 1
> ~ %u\n",
> +                     fet_id, MAX_FET_NUM);
> +               return -1;

In the recent code (like trats/trats2, bugs fixed at existing power
infrastructure) I'm encouraging people to use error descriptions from
<errno.h>, not the -1/-2 values.

Can you fix this globally in this patch?

> +       }
> +
> +       return 0;
> +}
> +
> +/**
> + * Set the power state for a FET
> + *
> + * @param pmic         pmic structure for the tps65090
> + * @param fet_id       Fet number to set (1..MAX_FET_NUM)
> + * @param set          1 to power on FET, 0 to power off
> + * @return FET_ERR_COMMS if we got a comms error, FET_ERR_NOT_READY
> if the
> + * FET failed to change state. If all is ok, returns 0.
> + */
> +static int tps65090_fet_set(struct pmic *pmic, int fet_id, int set)
							      ^^^^
							      maybe
							      bool
							     	
> +{
> +       int retry;
> +       u32 reg, value;
> +
> +       value = FET_CTRL_ADENFET | FET_CTRL_WAIT;
> +       if (set)
> +               value |= FET_CTRL_ENFET;
> +
> +       if (pmic_reg_write(pmic, REG_FET1_CTRL + fet_id - 1, value))
> +               return FET_ERR_COMMS;
> +       /* Try reading until we get a result */
> +       for (retry = 0; retry < MAX_CTRL_READ_TRIES; retry++) {
> +               if (pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1,
> &reg))
> +                       return FET_ERR_COMMS;
> +
> +               /* Check that the fet went into the expected state */
> +               if (!!(reg & FET_CTRL_PGFET) == set)
> +                       return 0;
> +
> +               /* If we got a timeout, there is no point in waiting
> longer */
> +               if (reg & FET_CTRL_TOFET)
> +                       break;
> +
> +               mdelay(1);
> +       }
> +
> +       debug("FET %d: Power good should have set to %d but
> reg=%#02x\n",
> +             fet_id, set, reg);
> +       return FET_ERR_NOT_READY;
> +}
> +
> +int tps65090_fet_enable(unsigned int fet_id)
> +{
> +       int loops;
> +       ulong start;
> +       struct pmic *pmic;
> +       int ret = 0;
> +
> +       if (tps65090_check_fet(fet_id))
> +               return -1;

		As I've described above - maybe -ENODEV?

> +
> +       pmic = pmic_get(TPS65090_NAME);
> +       if (pmic == NULL)
	     It seems like in the code I tend to use:
		if (!pmic)

> +               return -1;
> +
> +       start = get_timer(0);
> +       for (loops = 0;; loops++) {
> +               ret = tps65090_fet_set(pmic, fet_id, 1);
> +               if (!ret)
> +                       break;
> +
> +               if (get_timer(start) > 100)
> +                       break;
> +
> +               /* Turn it off and try again until we time out */
> +               tps65090_fet_set(pmic, fet_id, 0);
> +       }
> +
> +       if (ret) {
> +               debug("%s: FET%d failed to power on: time=%lums,
> loops=%d\n",
> +                     __func__, fet_id, get_timer(start), loops);
> +       } else if (loops) {
> +               debug("%s: FET%d powered on after %lums, loops=%d\n",
> +                     __func__, fet_id, get_timer(start), loops);
> +       }

Here the parenthesis can be omitted.

> +       /*
> +        * Unfortunately, there are some conditions where the power
> +        * good bit will be 0, but the fet still comes up. One such
> +        * case occurs with the lcd backlight. We'll just return 0
> here
> +        * and assume that the fet will eventually come up.
> +        */
> +       if (ret == FET_ERR_NOT_READY)
> +               ret = 0;
> +
> +       return ret;
> +}
> +
> +int tps65090_fet_disable(unsigned int fet_id)
> +{
> +       int ret;
> +       struct pmic *pmic;
> +
> +       if (tps65090_check_fet(fet_id))
> +               return -1;
> +
> +       pmic = pmic_get(TPS65090_NAME);
> +       if (pmic == NULL)
> +               return -1;
> +       ret = tps65090_fet_set(pmic, fet_id, 0);
> +
> +       return ret;
> +}
> +
> +int tps65090_fet_is_enabled(unsigned int fet_id)
> +{
> +       u32 reg;
> +       int ret;
> +       struct pmic *pmic;
> +
> +       if (tps65090_check_fet(fet_id))
> +               return -1;
> +       pmic = pmic_get(TPS65090_NAME);
> +       if (pmic == NULL)
> +               return -1;
> +       ret = pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1, &reg);
> +       if (ret) {
> +               debug("fail to read FET%u_CTRL register over I2C",
> fet_id);
> +               return -2;
> +       }
> +
> +       return reg & FET_CTRL_ENFET;
> +}
> +
> +int tps65090_get_charging(void)
> +{
> +       u32 val;
> +       int ret;
> +       struct pmic *pmic;
> +
> +       pmic = pmic_get(TPS65090_NAME);
> +       if (pmic == NULL)
> +               return -1;
> +       ret = pmic_reg_read(pmic, REG_CG_CTRL0, &val);
> +       if (ret)
> +               return ret;
> +       return val & CG_CTRL0_ENC_MASK ? 1 : 0;
> +}
> +
> +int tps65090_set_charge_enable(int enable)

This can be easily added to be used at "pmic bat charge" command.

Please look into the ./drivers/power/mfd/pmic_max77693.c

> +{
> +       u32 val;
> +       int ret;
> +       struct pmic *pmic;
> +
> +       pmic = pmic_get(TPS65090_NAME);
> +       if (pmic == NULL)
> +               return -1;
> +
> +       ret = pmic_reg_read(pmic, REG_CG_CTRL0, &val);
> +       if (!ret) {
> +               if (enable)
> +                       val |= CG_CTRL0_ENC_MASK;
> +               else
> +                       val &= ~CG_CTRL0_ENC_MASK;
> +               ret = pmic_reg_write(pmic, REG_CG_CTRL0, val);
> +       }
> +       if (ret) {
> +               debug("%s: Failed to read/write register\n",
> __func__);
> +               return ret;
> +       }
> +       return 0;
> +}
> +
> +int tps65090_get_status(void)
> +{
> +       u32 val;
> +       int ret;
> +       struct pmic *pmic;
> +
> +       pmic = pmic_get(TPS65090_NAME);
> +
> +       if (pmic == NULL)
> +               return -1;
> +       ret = pmic_reg_read(pmic, REG_CG_STATUS1, &val);
> +       if (ret)
> +               return ret;
> +       return val;
> +}
> +
> +int tps65090_init(void)
> +{
> +       int bus;
> +       int addr;
> +       struct pmic *p;
> +
> +#ifdef CONFIG_OF_CONTROL
> +       const void *blob = gd->fdt_blob;
> +       int node, parent;
> +
> +       node = fdtdec_next_compatible(blob, 0, COMPAT_TI_TPS65090);
> +       if (node < 0) {
> +               debug("PMIC: No node for PMIC Chip in device tree\n");
> +               debug("node = %d\n", node);
> +               return -ENODEV;
> +       }
> +
> +       parent = fdt_parent_offset(blob, node);
> +       if (parent < 0) {
> +               debug("%s: Cannot find node parent\n", __func__);
> +               return -1;
> +       }
> +
> +       bus = i2c_get_bus_num_fdt(parent);
> +       if (p->bus < 0) {
> +               debug("%s: Cannot find I2C bus\n", __func__);
> +               return -1;
> +       }
> +       addr = fdtdec_get_int(blob, node, "reg", TPS65090_I2C_ADDR);
> +#else
> +       bus = CONFIG_POWER_TPS65090_BUS;
> +       addr = TPS65090_I2C_ADDR;
> +#endif
> +       p = pmic_alloc();
> +
> +       if (!p) {
> +               printf("%s: POWER allocation error!\n", __func__);
> +               return -ENOMEM;
> +       }
> +
> +       p->name = TPS65090_NAME;
> +       p->bus = bus;
> +       p->interface = PMIC_I2C;
> +       p->number_of_regs = TPS65090_NUM_REGS;
> +       p->hw.i2c.addr = addr;
> +       p->hw.i2c.tx_num = 1;
> +
> +       puts("TPS65090 PMIC init\n");
> +
> +       return 0;
> +}
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 6e859ce..8f17ed3 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -90,6 +90,7 @@ enum fdt_compat_id {
>         COMPAT_SAMSUNG_EXYNOS5_I2C,     /* Exynos5 High Speed I2C
> Controller */ COMPAT_SANDBOX_HOST_EMULATION,  /* Sandbox emulation of
> a function */ COMPAT_SANDBOX_LCD_SDL,         /* Sandbox LCD
> emulation with SDL */
> +       COMPAT_TI_TPS65090,             /* Texas Instrument TPS65090
> */
> 
>         COMPAT_COUNT,
>  };
> diff --git a/include/power/tps65090_pmic.h
> b/include/power/tps65090_pmic.h new file mode 100644
> index 0000000..fde30eb
> --- /dev/null
> +++ b/include/power/tps65090_pmic.h
> @@ -0,0 +1,83 @@
> +/*
> + * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
> + * Use of this source code is governed by a BSD-style license that
> can be
> + * found in the LICENSE file.
> + *
> + * Alternatively, this software may be distributed under the terms
> of the
> + * GNU General Public License ("GPL") version 2 as published by the
> Free
> + * Software Foundation.
> + */
> +
> +#ifndef __TPS65090_PMIC_H_
> +#define __TPS65090_PMIC_H_
> +
> +/* I2C device address for TPS65090 PMU */
> +#define TPS65090_I2C_ADDR      0x48
> +
> +enum {
> +       /* Status register fields */
> +       TPS65090_ST1_OTC        = 1 << 0,
> +       TPS65090_ST1_OCC        = 1 << 1,
> +       TPS65090_ST1_STATE_SHIFT = 4,
> +       TPS65090_ST1_STATE_MASK = 0xf << TPS65090_ST1_STATE_SHIFT,
> +};
> +
> +/* FET errors */
> +enum {
> +       FET_ERR_COMMS           = -1,   /* FET comms error */
> +       FET_ERR_NOT_READY       = -2,   /* FET is not yet ready -
> retry */ +};
> +
> +/**
> + * Enable FET
> + *
> + * @param      fet_id  FET ID, value between 1 and 7
> + * @return     0 on success, non-0 on failure
> + */
> +int tps65090_fet_enable(unsigned int fet_id);
> +
> +/**
> + * Disable FET
> + *
> + * @param      fet_id  FET ID, value between 1 and 7
> + * @return     0 on success, non-0 on failure
> + */
> +int tps65090_fet_disable(unsigned int fet_id);
> +
> +/**
> + * Is FET enabled?
> + *
> + * @param      fet_id  FET ID, value between 1 and 7
> + * @return     1 enabled, 0 disabled, negative value on failure
> + */
> +int tps65090_fet_is_enabled(unsigned int fet_id);
> +
> +/**
> + * Enable / disable the battery charger
> + *
> + * @param enable       0 to disable charging, non-zero to enable
> + */
> +int tps65090_set_charge_enable(int enable);
> +
> +/**
> + * Check whether we have enabled battery charging
> + *
> + * @return 1 if enabled, 0 if disabled
> + */
> +int tps65090_get_charging(void);
> +
> +/**
> + * Return the value of the status register
> + *
> + * @return status register value, or -1 on error
> + */
> +int tps65090_get_status(void);
> +
> +/**
> + * Initialize the TPS65090 PMU.
> + *
> + * @return     0 on success, non-0 on failure
> + */
> +int tps65090_init(void);
> +
> +#endif /* __TPS65090_PMIC_H_ */
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index f65ab4f..beee1d0 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -63,6 +63,7 @@ static const char * const
> compat_names[COMPAT_COUNT] = { COMPAT(SAMSUNG_EXYNOS5_I2C,
> "samsung,exynos5-hsi2c"), COMPAT(SANDBOX_HOST_EMULATION,
> "sandbox,host-emulation"), COMPAT(SANDBOX_LCD_SDL, "sandbox,lcd-sdl"),
> +       COMPAT(TI_TPS65090, "ti,tps65090"),
>  };
> 
>  const char *fdtdec_get_compatible(enum fdt_compat_id id)
> --
> 1.9.1.423.g4596e3a



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight for snow

[Ajay kumar]

Hi Simon,

Find my comments below:

On Wed, Mar 26, 2014 at 11:26 PM, Simon Glass <sjg@chromium.org> wrote:

> The backlight uses FETs on the TPS65090. Enable this so that the display
> is visible.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  board/samsung/smdk5250/exynos5-dt.c | 90
> +++++++++++++++++++++++++++++++++++++
>  1 file changed, 90 insertions(+)
>
> diff --git a/board/samsung/smdk5250/exynos5-dt.c
> b/board/samsung/smdk5250/exynos5-dt.c
> index c83b034..a0ae641 100644
> --- a/board/samsung/smdk5250/exynos5-dt.c
> +++ b/board/samsung/smdk5250/exynos5-dt.c
> @@ -20,6 +20,7 @@
>  #include <asm/arch/sromc.h>
>  #include <power/pmic.h>
>  #include <power/max77686_pmic.h>
> +#include <power/tps65090_pmic.h>
>  #include <tmu.h>
>
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -60,6 +61,52 @@ int checkboard(void)
>  #endif
>
>  #ifdef CONFIG_LCD
>
We should make sure this code runs only for snow, and not for SMDK.
Only Snow contains the bridge chip.

> +static int board_dp_bridge_setup(void)
> +{
> +       struct exynos5_gpio_part1 *gpio1 =
> +               (struct exynos5_gpio_part1 *)samsung_get_base_gpio_part1();
> +       const int MAX_TRIES = 10;
> +       int num_tries;
> +
> +       debug("%s\n", __func__);
> +
> +       /* Setup the GPIOs */
> +
> +       /* PD is ACTIVE_LOW, and initially de-asserted */
> +       s5p_gpio_set_pull(&gpio1->y2, 5, GPIO_PULL_NONE);
> +       s5p_gpio_direction_output(&gpio1->y2, 5, 1);
> +
> +       /* Reset is ACTIVE_LOW */
> +       s5p_gpio_set_pull(&gpio1->x1, 5, GPIO_PULL_NONE);
> +       s5p_gpio_direction_output(&gpio1->x1, 5, 0);
> +
> +       udelay(10);
> +       s5p_gpio_set_value(&gpio1->x1, 5, 1);
> +
> +       s5p_gpio_direction_input(&gpio1->x0, 7);
> +
> +       /*
> +        * We need to wait for 90ms after bringing up the bridge since
> there
> +        * is a phantom "high" on the HPD chip during its bootup.  The
> phantom
> +        * high comes within 7ms of de-asserting PD and persists for at
> least
> +        * 15ms.  The real high comes roughly 50ms after PD is
> de-asserted. The
> +        * phantom high makes it hard for us to know when the NXP chip is
> up.
> +        */
> +       mdelay(90);
> +
> +       for (num_tries = 0; num_tries < MAX_TRIES; num_tries++) {
> +               /* Check HPD.  If it's high, we're all good. */
> +               if (s5p_gpio_get_value(&gpio1->x0, 7))
> +                               return 0;
> +
> +               debug("%s: eDP bridge failed to come up; try %d of %d\n",
> +                     __func__, num_tries, MAX_TRIES);
> +       }
> +
> +       /* Immediately go into bridge reset if the hp line is not high */
> +       return -ENODEV;
> +}
> +
>  void exynos_cfg_lcd_gpio(void)
>  {
>         struct exynos5_gpio_part1 *gpio1 =
> @@ -81,4 +128,47 @@ void exynos_set_dp_phy(unsigned int onoff)
>  {
>         set_dp_phy_ctrl(onoff);
>  }
> +
> +void exynos_backlight_on(unsigned int onoff)
> +{
> +       debug("%s(%u)\n", __func__, onoff);
> +
> +       if (onoff) {
> +#ifdef CONFIG_POWER_TPS65090
> +               struct exynos5_gpio_part1 *gpio1 =
> +                       (struct exynos5_gpio_part1 *)
> +                                       samsung_get_base_gpio_part1();
> +               int ret;
> +
> +               ret = tps65090_fet_enable(1); /* Enable FET1, backlight */
> +               if (ret)
> +                       return;
> +
> +               /* T5 in the LCD timing spec (defined as > 10ms) */
> +               mdelay(10);
>
Can you check for backlight without using the above delay?

> +
> +               /* board_dp_backlight_pwm */
> +               s5p_gpio_direction_output(&gpio1->b2, 0, 1);
>
+
> +               /* T6 in the LCD timing spec (defined as > 10ms) */
> +               mdelay(10);
>
Can you check for backlight without using the above delay?

> +
> +               /* board_dp_backlight_en */
> +               s5p_gpio_direction_output(&gpio1->x3, 0, 1);
> +#endif
> +       }
> +}
> +
> +void exynos_lcd_power_on(void)
> +{
> +       debug("%s\n", __func__);
> +
> +#ifdef CONFIG_POWER_TPS65090
> +       /* board_dp_lcd_vdd */
> +       tps65090_fet_enable(6); /* Enable FET6, lcd panel */
> +#endif
> +
> +       board_dp_bridge_setup();
>
returning int. check for return value and print in case of failure.

> +}
> +
>  #endif
> --
> 1.9.1.423.g4596e3a
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>


Regards,
Ajay Kumar

[U-Boot] [PATCH 03/10] exynos5: Enable tps65090 on smdk5250

[Ajay kumar]

Hi,

The patch name, kind of gives wrong impression.
There is no TPS65090 device on SMDK5250.
TPS65090 is present only on snow board based on exynos5250.
Please change it!


On Wed, Mar 26, 2014 at 11:26 PM, Simon Glass <sjg@chromium.org> wrote:

> From: Aaron Durbin <adurbin@chromium.org>
>
> The TPS65090 pmic chip can be on exynos5250 boards. Therefore,
> select the appropriate config option for TPS65090 devices.
>
> This commit should really use exynos5-dt.c, when it is available.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> ---
>
>  include/configs/exynos5-dt.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h
> index 414db42..fbf09f5 100644
> --- a/include/configs/exynos5-dt.h
> +++ b/include/configs/exynos5-dt.h
> @@ -259,6 +259,7 @@
>  /* PMIC */
>  #define CONFIG_POWER
>  #define CONFIG_POWER_I2C
> +#define CONFIG_POWER_TPS65090
>
>  /* Ethernet Controllor Driver */
>  #ifdef CONFIG_CMD_NET
> --
> 1.9.1.423.g4596e3a
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

Regards,
Ajay Kumar

[U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight for snow

[Simon Glass]

Hi Ajay,

On 29 March 2014 16:35, Ajay kumar <ajaynumb@gmail.com> wrote:

> Hi Simon,
>
> Find my comments below:
>
> On Wed, Mar 26, 2014 at 11:26 PM, Simon Glass <sjg@chromium.org> wrote:
>
>> The backlight uses FETs on the TPS65090. Enable this so that the display
>> is visible.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>>  board/samsung/smdk5250/exynos5-dt.c | 90
>> +++++++++++++++++++++++++++++++++++++
>>  1 file changed, 90 insertions(+)
>>
>> diff --git a/board/samsung/smdk5250/exynos5-dt.c
>> b/board/samsung/smdk5250/exynos5-dt.c
>> index c83b034..a0ae641 100644
>> --- a/board/samsung/smdk5250/exynos5-dt.c
>> +++ b/board/samsung/smdk5250/exynos5-dt.c
>> @@ -20,6 +20,7 @@
>>  #include <asm/arch/sromc.h>
>>  #include <power/pmic.h>
>>  #include <power/max77686_pmic.h>
>> +#include <power/tps65090_pmic.h>
>>  #include <tmu.h>
>>
>>  DECLARE_GLOBAL_DATA_PTR;
>> @@ -60,6 +61,52 @@ int checkboard(void)
>>  #endif
>>
>>  #ifdef CONFIG_LCD
>>
> We should make sure this code runs only for snow, and not for SMDK.
> Only Snow contains the bridge chip.
>

I'll add it to the device tree.


> +static int board_dp_bridge_setup(void)
>> +{
>> +       struct exynos5_gpio_part1 *gpio1 =
>> +               (struct exynos5_gpio_part1
>> *)samsung_get_base_gpio_part1();
>> +       const int MAX_TRIES = 10;
>> +       int num_tries;
>> +
>> +       debug("%s\n", __func__);
>> +
>> +       /* Setup the GPIOs */
>> +
>> +       /* PD is ACTIVE_LOW, and initially de-asserted */
>> +       s5p_gpio_set_pull(&gpio1->y2, 5, GPIO_PULL_NONE);
>> +       s5p_gpio_direction_output(&gpio1->y2, 5, 1);
>> +
>> +       /* Reset is ACTIVE_LOW */
>> +       s5p_gpio_set_pull(&gpio1->x1, 5, GPIO_PULL_NONE);
>> +       s5p_gpio_direction_output(&gpio1->x1, 5, 0);
>> +
>> +       udelay(10);
>> +       s5p_gpio_set_value(&gpio1->x1, 5, 1);
>> +
>> +       s5p_gpio_direction_input(&gpio1->x0, 7);
>> +
>> +       /*
>> +        * We need to wait for 90ms after bringing up the bridge since
>> there
>> +        * is a phantom "high" on the HPD chip during its bootup.  The
>> phantom
>> +        * high comes within 7ms of de-asserting PD and persists for at
>> least
>> +        * 15ms.  The real high comes roughly 50ms after PD is
>> de-asserted. The
>> +        * phantom high makes it hard for us to know when the NXP chip is
>> up.
>> +        */
>> +       mdelay(90);
>> +
>> +       for (num_tries = 0; num_tries < MAX_TRIES; num_tries++) {
>> +               /* Check HPD.  If it's high, we're all good. */
>> +               if (s5p_gpio_get_value(&gpio1->x0, 7))
>> +                               return 0;
>> +
>> +               debug("%s: eDP bridge failed to come up; try %d of %d\n",
>> +                     __func__, num_tries, MAX_TRIES);
>> +       }
>> +
>> +       /* Immediately go into bridge reset if the hp line is not high */
>> +       return -ENODEV;
>> +}
>> +
>>  void exynos_cfg_lcd_gpio(void)
>>  {
>>         struct exynos5_gpio_part1 *gpio1 =
>> @@ -81,4 +128,47 @@ void exynos_set_dp_phy(unsigned int onoff)
>>  {
>>         set_dp_phy_ctrl(onoff);
>>  }
>> +
>> +void exynos_backlight_on(unsigned int onoff)
>> +{
>> +       debug("%s(%u)\n", __func__, onoff);
>> +
>> +       if (onoff) {
>> +#ifdef CONFIG_POWER_TPS65090
>> +               struct exynos5_gpio_part1 *gpio1 =
>> +                       (struct exynos5_gpio_part1 *)
>> +                                       samsung_get_base_gpio_part1();
>> +               int ret;
>> +
>> +               ret = tps65090_fet_enable(1); /* Enable FET1, backlight */
>> +               if (ret)
>> +                       return;
>> +
>> +               /* T5 in the LCD timing spec (defined as > 10ms) */
>> +               mdelay(10);
>>
> Can you check for backlight without using the above delay?
>

I think we need to keep these delays due to the LCD timing spec. It often
does work, but we need it to always work.


> +
>> +               /* board_dp_backlight_pwm */
>> +               s5p_gpio_direction_output(&gpio1->b2, 0, 1);
>>
> +
>> +               /* T6 in the LCD timing spec (defined as > 10ms) */
>> +               mdelay(10);
>>
> Can you check for backlight without using the above delay?
>
>> +
>> +               /* board_dp_backlight_en */
>> +               s5p_gpio_direction_output(&gpio1->x3, 0, 1);
>> +#endif
>> +       }
>> +}
>> +
>> +void exynos_lcd_power_on(void)
>> +{
>> +       debug("%s\n", __func__);
>> +
>> +#ifdef CONFIG_POWER_TPS65090
>> +       /* board_dp_lcd_vdd */
>> +       tps65090_fet_enable(6); /* Enable FET6, lcd panel */
>> +#endif
>> +
>> +       board_dp_bridge_setup();
>>
> returning int. check for return value and print in case of failure.
>

Will do.

Regads,
Simon

[U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.

[Simon Glass]

Hi Lukasz,

On 27 March 2014 11:59, Lukasz Majewski <l.majewski@samsung.com> wrote:

> Hi Simon,
>
> > From: Tom Wai-Hong Tam <waihong@chromium.org>
> >
> > This adds driver support for the TPS65090 PMU. Support includes
> > hooking into the pmic infrastructure  so that the pmic commands
> > can be used on the console. The TPS65090 supports the following
> > functionality:
> >
> > - fet enable/disable/querying
> > - getting and setting of charge state
> >
> > Even though it is connected to the pmic infrastructure it does
> > not hook into the pmic charging charging infrastructure.
>
> Can I ask what was the problem with adding support for "pmic bat
> [state|charge]" command on this PMIC?
>
> Was the framework unfriendly or there was no need to do that?
>

It's not great. I spent a bit of time trying again. It think the issues are:

- no device tree support
- no comments in the pmic.h file so it's hard do know what everything is for
- the battery charging command should really be common, not specific to
each driver

I did actually create a battery system in the Chromium source tree a while
back, but never sent it upstream, partly because the pmic stuff was there
and I was not sure how to get it into that framework.

I think maybe if someone can comment the pmic.h file then I could have
another try. But it would be a separate series to this one, which is
focussed on the LCD, not the battery.


>
> >
> > Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
> > Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org>
> > Signed-off-by: Rong Chang <rongchang@chromium.org>
> > Signed-off-by: Sean Paul <seanpaul@chromium.org>
> > Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
> > Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> > ---
> >
> >  doc/device-tree-bindings/power/tps65090.txt |  21 ++
> >  drivers/power/pmic/Makefile                 |   1 +
> >  drivers/power/pmic/pmic_tps65090.c          | 296
> > ++++++++++++++++++++++++++++
> > include/fdtdec.h                            |   1 +
> > include/power/tps65090_pmic.h               |  83 ++++++++
> > lib/fdtdec.c                                |   1 + 6 files changed,
> > 403 insertions(+) create mode 100644
> > doc/device-tree-bindings/power/tps65090.txt create mode 100644
> > drivers/power/pmic/pmic_tps65090.c create mode 100644
> > include/power/tps65090_pmic.h
> >
> > diff --git a/doc/device-tree-bindings/power/tps65090.txt
> > b/doc/device-tree-bindings/power/tps65090.txt new file mode 100644
> > index 0000000..6a8a884
> > --- /dev/null
> > +++ b/doc/device-tree-bindings/power/tps65090.txt
> > @@ -0,0 +1,21 @@
> > +TPSchrome binding
> > +=================
> > +
> > +The device tree node which describes the operation of the Texas
> > Instrument +TPS65090 power regulator chip is as follows:
> > +
> > +Required properties :
> > +- compatible : "ti,tps65090"
> > +- reg : slave address on the i2c bus
> > +
> > +The tps65090 node should appear as a subnode of the i2c bus that
> > connects it. +
> > +Example
> > +=======
> > +
> > +       i2c at 12ca0000 {
> > +               power-regulator at 48 {
> > +                       compatible = "ti,tps65090"
> > +                       reg = <0x48>;
> > +               };
> > +       };
>
> Those bindings look very different from the one at Linux kernel for
> this device. Therefore I assume that there was justification to not
> stick to the linux kernel DT format.
>

Yes they pre-date the kernel. But now that the kernel has support I will
pull those in. For the parts we use it is the same.


>
> > diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> > index 0b45ffa..7ed55e6 100644
> > --- a/drivers/power/pmic/Makefile
> > +++ b/drivers/power/pmic/Makefile
> > @@ -9,5 +9,6 @@ obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
> >  obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
> >  obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
> >  obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
> > +obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
> >  obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
> >  obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
> > diff --git a/drivers/power/pmic/pmic_tps65090.c
> > b/drivers/power/pmic/pmic_tps65090.c new file mode 100644
> > index 0000000..ef9f911
> > --- /dev/null
> > +++ b/drivers/power/pmic/pmic_tps65090.c
> > @@ -0,0 +1,296 @@
> > +/*
> > + * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
> > + * Use of this source code is governed by a BSD-style license that
> > can be
> > + * found in the LICENSE file.
> > + *
> > + * Alternatively, this software may be distributed under the terms
> > of the
> > + * GNU General Public License ("GPL") version 2 as published by the
> > Free
> > + * Software Foundation.
>
> Would it be possible to tune this license description to be similar to
> SPDX-License-Identifier:        GPL-2.0+|BSD
>

Yes, will do.


>
> > + */
> > +
> > +#include <common.h>
> > +#include <errno.h>
> > +#include <fdtdec.h>
> > +#include <i2c.h>
> > +#include <power/pmic.h>
> > +#include <power/tps65090_pmic.h>
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +#define TPS65090_NAME "TPS65090_PMIC"
> > +
> > +/* TPS65090 register addresses */
> > +enum {
> > +       REG_CG_CTRL0 = 4,
> > +       REG_CG_STATUS1 = 0xa,
> > +       REG_FET1_CTRL = 0x0f,
> > +       REG_FET2_CTRL,
> > +       REG_FET3_CTRL,
> > +       REG_FET4_CTRL,
> > +       REG_FET5_CTRL,
> > +       REG_FET6_CTRL,
> > +       REG_FET7_CTRL,
> > +       TPS65090_NUM_REGS,
> > +};
> > +
> > +enum {
> > +       CG_CTRL0_ENC_MASK       = 0x01,
> > +
> > +       MAX_FET_NUM     = 7,
> > +       MAX_CTRL_READ_TRIES = 5,
> > +
> > +       /* TPS65090 FET_CTRL register values */
> > +       FET_CTRL_TOFET          = 1 << 7,  /* Timeout, startup,
> > overload */
> > +       FET_CTRL_PGFET          = 1 << 4,  /* Power good for FET
> > status */
> > +       FET_CTRL_WAIT           = 3 << 2,  /* Overcurrent timeout max
> > */
> > +       FET_CTRL_ADENFET        = 1 << 1,  /* Enable output auto
> > discharge */
> > +       FET_CTRL_ENFET          = 1 << 0,  /* Enable FET */
> > +};
> > +
> > +/**
> > + * Checks for a valid FET number
> > + *
> > + * @param fet_id       FET number to check
> > + * @return 0 if ok, -1 if FET value is out of range
> > + */
> > +static int tps65090_check_fet(unsigned int fet_id)
> > +{
> > +       if (fet_id == 0 || fet_id > MAX_FET_NUM) {
> > +               debug("parameter fet_id is out of range, %u not in 1
> > ~ %u\n",
> > +                     fet_id, MAX_FET_NUM);
> > +               return -1;
>
> In the recent code (like trats/trats2, bugs fixed at existing power
> infrastructure) I'm encouraging people to use error descriptions from
> <errno.h>, not the -1/-2 values.


> Can you fix this globally in this patch?
>

Yes good idea.


>
> > +       }
> > +
> > +       return 0;
> > +}
> > +
> > +/**
> > + * Set the power state for a FET
> > + *
> > + * @param pmic         pmic structure for the tps65090
> > + * @param fet_id       Fet number to set (1..MAX_FET_NUM)
> > + * @param set          1 to power on FET, 0 to power off
> > + * @return FET_ERR_COMMS if we got a comms error, FET_ERR_NOT_READY
> > if the
> > + * FET failed to change state. If all is ok, returns 0.
> > + */
> > +static int tps65090_fet_set(struct pmic *pmic, int fet_id, int set)
>                                                               ^^^^
>                                                               maybe
>                                                               bool
>
> > +{
> > +       int retry;
> > +       u32 reg, value;
> > +
> > +       value = FET_CTRL_ADENFET | FET_CTRL_WAIT;
> > +       if (set)
> > +               value |= FET_CTRL_ENFET;
> > +
> > +       if (pmic_reg_write(pmic, REG_FET1_CTRL + fet_id - 1, value))
> > +               return FET_ERR_COMMS;
> > +       /* Try reading until we get a result */
> > +       for (retry = 0; retry < MAX_CTRL_READ_TRIES; retry++) {
> > +               if (pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1,
> > &reg))
> > +                       return FET_ERR_COMMS;
> > +
> > +               /* Check that the fet went into the expected state */
> > +               if (!!(reg & FET_CTRL_PGFET) == set)
> > +                       return 0;
> > +
> > +               /* If we got a timeout, there is no point in waiting
> > longer */
> > +               if (reg & FET_CTRL_TOFET)
> > +                       break;
> > +
> > +               mdelay(1);
> > +       }
> > +
> > +       debug("FET %d: Power good should have set to %d but
> > reg=%#02x\n",
> > +             fet_id, set, reg);
> > +       return FET_ERR_NOT_READY;
> > +}
> > +
> > +int tps65090_fet_enable(unsigned int fet_id)
> > +{
> > +       int loops;
> > +       ulong start;
> > +       struct pmic *pmic;
> > +       int ret = 0;
> > +
> > +       if (tps65090_check_fet(fet_id))
> > +               return -1;
>
>                 As I've described above - maybe -ENODEV?
>
> > +
> > +       pmic = pmic_get(TPS65090_NAME);
> > +       if (pmic == NULL)
>              It seems like in the code I tend to use:
>                 if (!pmic)
>

OK

>
> > +               return -1;
> > +
> > +       start = get_timer(0);
> > +       for (loops = 0;; loops++) {
> > +               ret = tps65090_fet_set(pmic, fet_id, 1);
> > +               if (!ret)
> > +                       break;
> > +
> > +               if (get_timer(start) > 100)
> > +                       break;
> > +
> > +               /* Turn it off and try again until we time out */
> > +               tps65090_fet_set(pmic, fet_id, 0);
> > +       }
> > +
> > +       if (ret) {
> > +               debug("%s: FET%d failed to power on: time=%lums,
> > loops=%d\n",
> > +                     __func__, fet_id, get_timer(start), loops);
> > +       } else if (loops) {
> > +               debug("%s: FET%d powered on after %lums, loops=%d\n",
> > +                     __func__, fet_id, get_timer(start), loops);
> > +       }
>
> Here the parenthesis can be omitted.
>

OK

>
> > +       /*
> > +        * Unfortunately, there are some conditions where the power
> > +        * good bit will be 0, but the fet still comes up. One such
> > +        * case occurs with the lcd backlight. We'll just return 0
> > here
> > +        * and assume that the fet will eventually come up.
> > +        */
> > +       if (ret == FET_ERR_NOT_READY)
> > +               ret = 0;
> > +
> > +       return ret;
> > +}
> > +
> > +int tps65090_fet_disable(unsigned int fet_id)
> > +{
> > +       int ret;
> > +       struct pmic *pmic;
> > +
> > +       if (tps65090_check_fet(fet_id))
> > +               return -1;
> > +
> > +       pmic = pmic_get(TPS65090_NAME);
> > +       if (pmic == NULL)
> > +               return -1;
> > +       ret = tps65090_fet_set(pmic, fet_id, 0);
> > +
> > +       return ret;
> > +}
> > +
> > +int tps65090_fet_is_enabled(unsigned int fet_id)
> > +{
> > +       u32 reg;
> > +       int ret;
> > +       struct pmic *pmic;
> > +
> > +       if (tps65090_check_fet(fet_id))
> > +               return -1;
> > +       pmic = pmic_get(TPS65090_NAME);
> > +       if (pmic == NULL)
> > +               return -1;
> > +       ret = pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1, &reg);
> > +       if (ret) {
> > +               debug("fail to read FET%u_CTRL register over I2C",
> > fet_id);
> > +               return -2;
> > +       }
> > +
> > +       return reg & FET_CTRL_ENFET;
> > +}
> > +
> > +int tps65090_get_charging(void)
> > +{
> > +       u32 val;
> > +       int ret;
> > +       struct pmic *pmic;
> > +
> > +       pmic = pmic_get(TPS65090_NAME);
> > +       if (pmic == NULL)
> > +               return -1;
> > +       ret = pmic_reg_read(pmic, REG_CG_CTRL0, &val);
> > +       if (ret)
> > +               return ret;
> > +       return val & CG_CTRL0_ENC_MASK ? 1 : 0;
> > +}
> > +
> > +int tps65090_set_charge_enable(int enable)
>
> This can be easily added to be used at "pmic bat charge" command.
>
> Please look into the ./drivers/power/mfd/pmic_max77693.c
>

Not easily. As mentioned above this is quite a bit of work. For a later
series I think.

Regards,
Simon

[U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus

[Simon Glass]

Hi Lukasz,

On 27 March 2014 11:33, Lukasz Majewski <l.majewski@samsung.com> wrote:

> Hi Simon, Heiko
>
> > From: Aaron Durbin <adurbin@chromium.org>
> >
> > The current pmic i2c code assumes the current i2c bus is
> > the same as the pmic device's bus. There is nothing ensuring
> > that to be true. Therefore, select the proper bus before performing
> > a transaction.
> >
> > Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > Reviewed-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> >  drivers/power/power_i2c.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
> > index ac76870..594cd11 100644
> > --- a/drivers/power/power_i2c.c
> > +++ b/drivers/power/power_i2c.c
> > @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
> >       if (check_reg(p, reg))
> >               return -1;
> >
> > +     I2C_SET_BUS(p->bus);
> > +
>
> Hadn't we had a  discussion about this explicit setting of I2C some time
> ago? I thought that this problem was solved within the I2C rework.
>
> Also I might be wrong, so please correct me if I'm wrong. Isn't the
> I2C_SET_BUS() macro regarded as a obsolete after the I2C rework?
>

Agreed that would be ideal, but we would have to pass the bus number of the
i2c_read/write() functions. I don't believe the i2c code has got that far
yet.

Unfortunately it doesn't work without this patch.

Regards,
Simon

[U-Boot] [PATCH 05/10] exynos5: support tps65090 pmic

[Simon Glass]

Hi Minkyu,

On 27 March 2014 06:13, Minkyu Kang <mk7.kang@samsung.com> wrote:

> On 27/03/14 02:56, Simon Glass wrote:
> > From: Aaron Durbin <adurbin@chromium.org>
> >
> > The TSP65090 is a PMIC on some exynos5 boards. The init function is
> > called for the TPS65090 pmic. If that device is not a part of the device
> > tree (returns -ENODEV) then continue. Otherwise return a failure.
> >
> > Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > Reviewed-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> >  board/samsung/common/board.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
> > index 3866495..654bdb6 100644
> > --- a/board/samsung/common/board.c
> > +++ b/board/samsung/common/board.c
> > @@ -23,6 +23,7 @@
> >  #include <power/pmic.h>
> >  #include <asm/arch/sromc.h>
> >  #include <power/max77686_pmic.h>
> > +#include <power/tps65090_pmic.h>
> >
> >  DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -261,6 +262,12 @@ int power_init_board(void)
> >       ret = max77686_init();
> >  #endif
>
> What is the base tree of this patch?
> looks different with samsung tree.
> seems to need rebase?
>

Yes it is based on mainline - I will base in on samsung/master when I
resend.

Regards,
Simon

[U-Boot] [PATCH 03/10] exynos5: Enable tps65090 on smdk5250

[Simon Glass]

Hi Ajay,

On 29 March 2014 16:40, Ajay kumar <ajaynumb@gmail.com> wrote:

> Hi,
>
> The patch name, kind of gives wrong impression.
> There is no TPS65090 device on SMDK5250.
> TPS65090 is present only on snow board based on exynos5250.
> Please change it!
>

Will do.

Regards,
Simon

[U-Boot] [PATCH 08/10] exynos: dts: Enable LCD for snow

[Simon Glass]

Hi Lukasz,

On 27 March 2014 11:23, Lukasz Majewski <l.majewski@samsung.com> wrote:

> Hi Simon,
>
> > Enable LCD for snow. This is a 1366 x 768 panel.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> >  arch/arm/dts/exynos5250-snow.dts | 44
> > ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44
> > insertions(+)
> >
> > diff --git a/arch/arm/dts/exynos5250-snow.dts
> > b/arch/arm/dts/exynos5250-snow.dts index 42a687b..725a1bf 100644
> > --- a/arch/arm/dts/exynos5250-snow.dts
> > +++ b/arch/arm/dts/exynos5250-snow.dts
> > @@ -192,4 +192,48 @@
> >                       /* UP      LEFT    */
> >                       0x070b0067 0x070c0069>;
> >       };
> > +
> > +     fimd at 14400000 {
> > +             samsung,vl-freq = <60>;
> > +             samsung,vl-col = <1366>;
> > +             samsung,vl-row = <768>;
> > +             samsung,vl-width = <1366>;
> > +             samsung,vl-height = <768>;
> > +
> > +             samsung,vl-clkp;
> > +             samsung,vl-dp;
> > +             samsung,vl-hsp;
> > +             samsung,vl-vsp;
> > +
> > +             samsung,vl-bpix = <4>;
> > +
> > +             samsung,vl-hspw = <32>;
> > +             samsung,vl-hbpd = <80>;
> > +             samsung,vl-hfpd = <48>;
> > +             samsung,vl-vspw = <5>;
> > +             samsung,vl-vbpd = <14>;
> > +             samsung,vl-vfpd = <3>;
> > +             samsung,vl-cmd-allow-len = <0xf>;
> > +
> > +             samsung,winid = <0>;
> > +             samsung,interface-mode = <1>;
> > +             samsung,dp-enabled = <1>;
> > +             samsung,dual-lcd-enabled = <0>;
> > +     };
> > +
>
> I can only now regret that we have not stick to the Linux kernel DTS
> format and be ABI compatible with Linux (and add u-boot specific
> bindings as an extension).
>
> Now unfortunately it is too late.
>

I don't think it is too late. But until the GPIO numbering patch lands it's
really tricky to put GPIOs into the device tree on exynos. I think it would
be fairly easy to adjust this later.

Regards,
Simon

[U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus

[Heiko Schocher]

Hello Simon, Lukasz,

Am 30.03.2014 01:17, schrieb Simon Glass:
> Hi Lukasz,
>
> On 27 March 2014 11:33, Lukasz Majewski<l.majewski@samsung.com>  wrote:
>
>> Hi Simon, Heiko
>>
>>> From: Aaron Durbin<adurbin@chromium.org>
>>>
>>> The current pmic i2c code assumes the current i2c bus is
>>> the same as the pmic device's bus. There is nothing ensuring
>>> that to be true. Therefore, select the proper bus before performing
>>> a transaction.
>>>
>>> Signed-off-by: Aaron Durbin<adurbin@chromium.org>
>>> Signed-off-by: Simon Glass<sjg@chromium.org>
>>> Reviewed-by: Simon Glass<sjg@chromium.org>
>>> ---
>>>
>>>   drivers/power/power_i2c.c | 4 ++++
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
>>> index ac76870..594cd11 100644
>>> --- a/drivers/power/power_i2c.c
>>> +++ b/drivers/power/power_i2c.c
>>> @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
>>>        if (check_reg(p, reg))
>>>                return -1;
>>>
>>> +     I2C_SET_BUS(p->bus);
>>> +
>>
>> Hadn't we had a  discussion about this explicit setting of I2C some time
>> ago? I thought that this problem was solved within the I2C rework.
>>
>> Also I might be wrong, so please correct me if I'm wrong. Isn't the
>> I2C_SET_BUS() macro regarded as a obsolete after the I2C rework?
>>
>
> Agreed that would be ideal, but we would have to pass the bus number of the
> i2c_read/write() functions. I don't believe the i2c code has got that far
> yet.

Yes, thats the plan, but first, all i2c driver must be converted to
the new framework. After that we could start with such an approach
(or device model is ready and we can switch to it ...)

> Unfortunately it doesn't work without this patch.

Yes ...

If we have all i2c driver running with the new framework, we can get
rid of I2C_SET_BUS defines, and simply use i2c_set_bus_num() which
is a simple cleanup patch.

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus

[Lukasz Majewski]

Hi Heiko,

> Hello Simon, Lukasz,
> 
> Am 30.03.2014 01:17, schrieb Simon Glass:
> > Hi Lukasz,
> >
> > On 27 March 2014 11:33, Lukasz Majewski<l.majewski@samsung.com>
> > wrote:
> >
> >> Hi Simon, Heiko
> >>
> >>> From: Aaron Durbin<adurbin@chromium.org>
> >>>
> >>> The current pmic i2c code assumes the current i2c bus is
> >>> the same as the pmic device's bus. There is nothing ensuring
> >>> that to be true. Therefore, select the proper bus before
> >>> performing a transaction.
> >>>
> >>> Signed-off-by: Aaron Durbin<adurbin@chromium.org>
> >>> Signed-off-by: Simon Glass<sjg@chromium.org>
> >>> Reviewed-by: Simon Glass<sjg@chromium.org>
> >>> ---
> >>>
> >>>   drivers/power/power_i2c.c | 4 ++++
> >>>   1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
> >>> index ac76870..594cd11 100644
> >>> --- a/drivers/power/power_i2c.c
> >>> +++ b/drivers/power/power_i2c.c
> >>> @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32
> >>> val) if (check_reg(p, reg))
> >>>                return -1;
> >>>
> >>> +     I2C_SET_BUS(p->bus);
> >>> +
> >>
> >> Hadn't we had a  discussion about this explicit setting of I2C
> >> some time ago? I thought that this problem was solved within the
> >> I2C rework.
> >>
> >> Also I might be wrong, so please correct me if I'm wrong. Isn't the
> >> I2C_SET_BUS() macro regarded as a obsolete after the I2C rework?
> >>
> >
> > Agreed that would be ideal, but we would have to pass the bus
> > number of the i2c_read/write() functions. I don't believe the i2c
> > code has got that far yet.
> 
> Yes, thats the plan, but first, all i2c driver must be converted to
> the new framework. After that we could start with such an approach
> (or device model is ready and we can switch to it ...)

I know that there is a time line for introducing device model, but is
there any for switching I2C to the new approach? 

I think about deleting obsolete/unmaintained boards, which will not
switch to new I2C approach.

> 
> > Unfortunately it doesn't work without this patch.
> 
> Yes ...
> 
> If we have all i2c driver running with the new framework, we can get
> rid of I2C_SET_BUS defines, and simply use i2c_set_bus_num() which
> is a simple cleanup patch.

Ok, I see.

> 
> bye,
> Heiko



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.

[Lukasz Majewski]

Hi Simon,

> Hi Lukasz,
> 
> On 27 March 2014 11:59, Lukasz Majewski <l.majewski@samsung.com>
> wrote: Hi Simon,
> 
> > From: Tom Wai-Hong Tam <waihong@chromium.org>
> >
> > This adds driver support for the TPS65090 PMU. Support includes
> > hooking into the pmic infrastructure ?so that the pmic commands
> > can be used on the console. The TPS65090 supports the following
> > functionality:
> >
> > - fet enable/disable/querying
> > - getting and setting of charge state
> >
> > Even though it is connected to the pmic infrastructure it does
> > not hook into the pmic charging charging infrastructure.
> 
> Can I ask what was the problem with adding support for "pmic bat
> [state|charge]" command on this PMIC?
> 
> Was the framework unfriendly or there was no need to do that?
> 
> It's not great. I spent a bit of time trying again. It think the
> issues are:
> 
> - no device tree support
> - no comments in the pmic.h file so it's hard do know what everything
> is for

You are right here - the lack of DT support is the main problem here.

As Tom Rini pointed out - it is problematic in this framework to
support more than one instance of the same PMIC device.

I must confess that I've overlooked this use case.

> - the battery charging command should really be common, not specific
> to each driver

I agree. We can try to discuss one solution suitable for Exynos4 and 5.

> 
> I did actually create a battery system in the Chromium source tree a
> while back, but never sent it upstream, partly because the pmic stuff
> was there and I was not sure how to get it into that framework.
> 
> I think maybe if someone can comment the pmic.h file then I could
> have another try. But it would be a separate series to this one,
> which is focussed on the LCD, not the battery. 

For a quick reference please consider Trats and Trats2. If you need any
more help, then please write an e-mail to me.

> 
> >
> > Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
> > Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org>
> > Signed-off-by: Rong Chang <rongchang@chromium.org>
> > Signed-off-by: Sean Paul <seanpaul@chromium.org>
> > Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
> > Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> > ---
> >
> > ?doc/device-tree-bindings/power/tps65090.txt | ?21 ++
> > ?drivers/power/pmic/Makefile ? ? ? ? ? ? ? ? | ? 1 +
> > ?drivers/power/pmic/pmic_tps65090.c ? ? ? ? ?| 296
> > ++++++++++++++++++++++++++++
> > include/fdtdec.h ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 1 +
> > include/power/tps65090_pmic.h ? ? ? ? ? ? ? | ?83 ++++++++
> > lib/fdtdec.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 1 + 6 files changed,
> > 403 insertions(+) create mode 100644
> > doc/device-tree-bindings/power/tps65090.txt create mode 100644
> > drivers/power/pmic/pmic_tps65090.c create mode 100644
> > include/power/tps65090_pmic.h
> >
> > diff --git a/doc/device-tree-bindings/power/tps65090.txt
> > b/doc/device-tree-bindings/power/tps65090.txt new file mode 100644
> > index 0000000..6a8a884
> > --- /dev/null
> > +++ b/doc/device-tree-bindings/power/tps65090.txt
> > @@ -0,0 +1,21 @@
> > +TPSchrome binding
> > +=================
> > +
> > +The device tree node which describes the operation of the Texas
> > Instrument +TPS65090 power regulator chip is as follows:
> > +
> > +Required properties :
> > +- compatible : "ti,tps65090"
> > +- reg : slave address on the i2c bus
> > +
> > +The tps65090 node should appear as a subnode of the i2c bus that
> > connects it. +
> > +Example
> > +=======
> > +
> > + ? ? ? i2c at 12ca0000 {
> > + ? ? ? ? ? ? ? power-regulator at 48 {
> > + ? ? ? ? ? ? ? ? ? ? ? compatible = "ti,tps65090"
> > + ? ? ? ? ? ? ? ? ? ? ? reg = <0x48>;
> > + ? ? ? ? ? ? ? };
> > + ? ? ? };
> 
> Those bindings look very different from the one at Linux kernel for
> this device. Therefore I assume that there was justification to not
> stick to the linux kernel DT format.
> 
> Yes they pre-date the kernel. But now that the kernel has support I
> will pull those in. For the parts we use it is the same. 

That would be great, thanks.

> 
> > diff --git a/drivers/power/pmic/Makefile
> > b/drivers/power/pmic/Makefile index 0b45ffa..7ed55e6 100644
> > --- a/drivers/power/pmic/Makefile
> > +++ b/drivers/power/pmic/Makefile
> > @@ -9,5 +9,6 @@ obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
> > ?obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
> > ?obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
> > ?obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
> > +obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
> > ?obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
> > ?obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
> > diff --git a/drivers/power/pmic/pmic_tps65090.c
> > b/drivers/power/pmic/pmic_tps65090.c new file mode 100644
> > index 0000000..ef9f911
> > --- /dev/null
> > +++ b/drivers/power/pmic/pmic_tps65090.c
> > @@ -0,0 +1,296 @@
> > +/*
> > + * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
> > + * Use of this source code is governed by a BSD-style license that
> > can be
> > + * found in the LICENSE file.
> > + *
> > + * Alternatively, this software may be distributed under the terms
> > of the
> > + * GNU General Public License ("GPL") version 2 as published by the
> > Free
> > + * Software Foundation.
> 
> Would it be possible to tune this license description to be similar to
> SPDX-License-Identifier: ? ? ? ?GPL-2.0+|BSD
> 
> Yes, will do.
> ?
> 
> > + */
> > +
> > +#include <common.h>
> > +#include <errno.h>
> > +#include <fdtdec.h>
> > +#include <i2c.h>
> > +#include <power/pmic.h>
> > +#include <power/tps65090_pmic.h>
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +#define TPS65090_NAME "TPS65090_PMIC"
> > +
> > +/* TPS65090 register addresses */
> > +enum {
> > + ? ? ? REG_CG_CTRL0 = 4,
> > + ? ? ? REG_CG_STATUS1 = 0xa,
> > + ? ? ? REG_FET1_CTRL = 0x0f,
> > + ? ? ? REG_FET2_CTRL,
> > + ? ? ? REG_FET3_CTRL,
> > + ? ? ? REG_FET4_CTRL,
> > + ? ? ? REG_FET5_CTRL,
> > + ? ? ? REG_FET6_CTRL,
> > + ? ? ? REG_FET7_CTRL,
> > + ? ? ? TPS65090_NUM_REGS,
> > +};
> > +
> > +enum {
> > + ? ? ? CG_CTRL0_ENC_MASK ? ? ? = 0x01,
> > +
> > + ? ? ? MAX_FET_NUM ? ? = 7,
> > + ? ? ? MAX_CTRL_READ_TRIES = 5,
> > +
> > + ? ? ? /* TPS65090 FET_CTRL register values */
> > + ? ? ? FET_CTRL_TOFET ? ? ? ? ?= 1 << 7, ?/* Timeout, startup,
> > overload */
> > + ? ? ? FET_CTRL_PGFET ? ? ? ? ?= 1 << 4, ?/* Power good for FET
> > status */
> > + ? ? ? FET_CTRL_WAIT ? ? ? ? ? = 3 << 2, ?/* Overcurrent timeout
> > max */
> > + ? ? ? FET_CTRL_ADENFET ? ? ? ?= 1 << 1, ?/* Enable output auto
> > discharge */
> > + ? ? ? FET_CTRL_ENFET ? ? ? ? ?= 1 << 0, ?/* Enable FET */
> > +};
> > +
> > +/**
> > + * Checks for a valid FET number
> > + *
> > + * @param fet_id ? ? ? FET number to check
> > + * @return 0 if ok, -1 if FET value is out of range
> > + */
> > +static int tps65090_check_fet(unsigned int fet_id)
> > +{
> > + ? ? ? if (fet_id == 0 || fet_id > MAX_FET_NUM) {
> > + ? ? ? ? ? ? ? debug("parameter fet_id is out of range, %u not in 1
> > ~ %u\n",
> > + ? ? ? ? ? ? ? ? ? ? fet_id, MAX_FET_NUM);
> > + ? ? ? ? ? ? ? return -1;
> 
> In the recent code (like trats/trats2, bugs fixed at existing power
> infrastructure) I'm encouraging people to use error descriptions from
> <errno.h>, not the -1/-2 values.?
> Can you fix this globally in this patch?
> 
> Yes good idea.
> ?
> 
> > + ? ? ? }
> > +
> > + ? ? ? return 0;
> > +}
> > +
> > +/**
> > + * Set the power state for a FET
> > + *
> > + * @param pmic ? ? ? ? pmic structure for the tps65090
> > + * @param fet_id ? ? ? Fet number to set (1..MAX_FET_NUM)
> > + * @param set ? ? ? ? ?1 to power on FET, 0 to power off
> > + * @return FET_ERR_COMMS if we got a comms error, FET_ERR_NOT_READY
> > if the
> > + * FET failed to change state. If all is ok, returns 0.
> > + */
> > +static int tps65090_fet_set(struct pmic *pmic, int fet_id, int set)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^^^^
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? maybe
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bool
> 
> > +{
> > + ? ? ? int retry;
> > + ? ? ? u32 reg, value;
> > +
> > + ? ? ? value = FET_CTRL_ADENFET | FET_CTRL_WAIT;
> > + ? ? ? if (set)
> > + ? ? ? ? ? ? ? value |= FET_CTRL_ENFET;
> > +
> > + ? ? ? if (pmic_reg_write(pmic, REG_FET1_CTRL + fet_id - 1, value))
> > + ? ? ? ? ? ? ? return FET_ERR_COMMS;
> > + ? ? ? /* Try reading until we get a result */
> > + ? ? ? for (retry = 0; retry < MAX_CTRL_READ_TRIES; retry++) {
> > + ? ? ? ? ? ? ? if (pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1,
> > &reg))
> > + ? ? ? ? ? ? ? ? ? ? ? return FET_ERR_COMMS;
> > +
> > + ? ? ? ? ? ? ? /* Check that the fet went into the expected state
> > */
> > + ? ? ? ? ? ? ? if (!!(reg & FET_CTRL_PGFET) == set)
> > + ? ? ? ? ? ? ? ? ? ? ? return 0;
> > +
> > + ? ? ? ? ? ? ? /* If we got a timeout, there is no point in waiting
> > longer */
> > + ? ? ? ? ? ? ? if (reg & FET_CTRL_TOFET)
> > + ? ? ? ? ? ? ? ? ? ? ? break;
> > +
> > + ? ? ? ? ? ? ? mdelay(1);
> > + ? ? ? }
> > +
> > + ? ? ? debug("FET %d: Power good should have set to %d but
> > reg=%#02x\n",
> > + ? ? ? ? ? ? fet_id, set, reg);
> > + ? ? ? return FET_ERR_NOT_READY;
> > +}
> > +
> > +int tps65090_fet_enable(unsigned int fet_id)
> > +{
> > + ? ? ? int loops;
> > + ? ? ? ulong start;
> > + ? ? ? struct pmic *pmic;
> > + ? ? ? int ret = 0;
> > +
> > + ? ? ? if (tps65090_check_fet(fet_id))
> > + ? ? ? ? ? ? ? return -1;
> 
> ? ? ? ? ? ? ? ? As I've described above - maybe -ENODEV?
> 
> > +
> > + ? ? ? pmic = pmic_get(TPS65090_NAME);
> > + ? ? ? if (pmic == NULL)
> ? ? ? ? ? ? ?It seems like in the code I tend to use:
> ? ? ? ? ? ? ? ? if (!pmic)
> 
> OK?
> 
> > + ? ? ? ? ? ? ? return -1;
> > +
> > + ? ? ? start = get_timer(0);
> > + ? ? ? for (loops = 0;; loops++) {
> > + ? ? ? ? ? ? ? ret = tps65090_fet_set(pmic, fet_id, 1);
> > + ? ? ? ? ? ? ? if (!ret)
> > + ? ? ? ? ? ? ? ? ? ? ? break;
> > +
> > + ? ? ? ? ? ? ? if (get_timer(start) > 100)
> > + ? ? ? ? ? ? ? ? ? ? ? break;
> > +
> > + ? ? ? ? ? ? ? /* Turn it off and try again until we time out */
> > + ? ? ? ? ? ? ? tps65090_fet_set(pmic, fet_id, 0);
> > + ? ? ? }
> > +
> > + ? ? ? if (ret) {
> > + ? ? ? ? ? ? ? debug("%s: FET%d failed to power on: time=%lums,
> > loops=%d\n",
> > + ? ? ? ? ? ? ? ? ? ? __func__, fet_id, get_timer(start), loops);
> > + ? ? ? } else if (loops) {
> > + ? ? ? ? ? ? ? debug("%s: FET%d powered on after %lums,
> > loops=%d\n",
> > + ? ? ? ? ? ? ? ? ? ? __func__, fet_id, get_timer(start), loops);
> > + ? ? ? }
> 
> Here the parenthesis can be omitted.
> 
> OK?
> 
> > + ? ? ? /*
> > + ? ? ? ?* Unfortunately, there are some conditions where the power
> > + ? ? ? ?* good bit will be 0, but the fet still comes up. One such
> > + ? ? ? ?* case occurs with the lcd backlight. We'll just return 0
> > here
> > + ? ? ? ?* and assume that the fet will eventually come up.
> > + ? ? ? ?*/
> > + ? ? ? if (ret == FET_ERR_NOT_READY)
> > + ? ? ? ? ? ? ? ret = 0;
> > +
> > + ? ? ? return ret;
> > +}
> > +
> > +int tps65090_fet_disable(unsigned int fet_id)
> > +{
> > + ? ? ? int ret;
> > + ? ? ? struct pmic *pmic;
> > +
> > + ? ? ? if (tps65090_check_fet(fet_id))
> > + ? ? ? ? ? ? ? return -1;
> > +
> > + ? ? ? pmic = pmic_get(TPS65090_NAME);
> > + ? ? ? if (pmic == NULL)
> > + ? ? ? ? ? ? ? return -1;
> > + ? ? ? ret = tps65090_fet_set(pmic, fet_id, 0);
> > +
> > + ? ? ? return ret;
> > +}
> > +
> > +int tps65090_fet_is_enabled(unsigned int fet_id)
> > +{
> > + ? ? ? u32 reg;
> > + ? ? ? int ret;
> > + ? ? ? struct pmic *pmic;
> > +
> > + ? ? ? if (tps65090_check_fet(fet_id))
> > + ? ? ? ? ? ? ? return -1;
> > + ? ? ? pmic = pmic_get(TPS65090_NAME);
> > + ? ? ? if (pmic == NULL)
> > + ? ? ? ? ? ? ? return -1;
> > + ? ? ? ret = pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1, &reg);
> > + ? ? ? if (ret) {
> > + ? ? ? ? ? ? ? debug("fail to read FET%u_CTRL register over I2C",
> > fet_id);
> > + ? ? ? ? ? ? ? return -2;
> > + ? ? ? }
> > +
> > + ? ? ? return reg & FET_CTRL_ENFET;
> > +}
> > +
> > +int tps65090_get_charging(void)
> > +{
> > + ? ? ? u32 val;
> > + ? ? ? int ret;
> > + ? ? ? struct pmic *pmic;
> > +
> > + ? ? ? pmic = pmic_get(TPS65090_NAME);
> > + ? ? ? if (pmic == NULL)
> > + ? ? ? ? ? ? ? return -1;
> > + ? ? ? ret = pmic_reg_read(pmic, REG_CG_CTRL0, &val);
> > + ? ? ? if (ret)
> > + ? ? ? ? ? ? ? return ret;
> > + ? ? ? return val & CG_CTRL0_ENC_MASK ? 1 : 0;
> > +}
> > +
> > +int tps65090_set_charge_enable(int enable)
> 
> This can be easily added to be used at "pmic bat charge" command.
> 
> Please look into the ./drivers/power/mfd/pmic_max77693.c
> 
> Not easily. As mentioned above this is quite a bit of work. For a
> later series I think. 

I'm looking forward for questions :-).

> Regards,
> Simon
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus

[Lukasz Majewski]

Hi Simon,

> Hi Lukasz,
> 
> On 27 March 2014 11:33, Lukasz Majewski <l.majewski@samsung.com>
> wrote: Hi Simon, Heiko
> 
> > From: Aaron Durbin <adurbin@chromium.org>
> >
> > The current pmic i2c code assumes the current i2c bus is
> > the same as the pmic device's bus. There is nothing ensuring
> > that to be true. Therefore, select the proper bus before performing
> > a transaction.
> >
> > Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > Reviewed-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > ?drivers/power/power_i2c.c | 4 ++++
> > ?1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
> > index ac76870..594cd11 100644
> > --- a/drivers/power/power_i2c.c
> > +++ b/drivers/power/power_i2c.c
> > @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32
> > val) if (check_reg(p, reg))
> > ? ? ? ? ? ? ? return -1;
> >
> > + ? ? I2C_SET_BUS(p->bus);
> > +
> 
> Hadn't we had a ?discussion about this explicit setting of I2C some
> time ago? I thought that this problem was solved within the I2C
> rework.
> 
> Also I might be wrong, so please correct me if I'm wrong. Isn't the
> I2C_SET_BUS() macro regarded as a obsolete after the I2C rework?
> 
> Agreed that would be ideal, but we would have to pass the bus number
> of the i2c_read/write() functions. I don't believe the i2c code has
> got that far yet.
> 
> Unfortunately it doesn't work without this patch.

If Heiko doesn't object, then I won't protest. 

> 
> Regards,
> Simon
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.

[Simon Glass]

Hi Lukasz,

On 31 March 2014 08:33, Lukasz Majewski <l.majewski@samsung.com> wrote:
[snip]


> >
> > This can be easily added to be used at "pmic bat charge" command.
> >
> > Please look into the ./drivers/power/mfd/pmic_max77693.c
> >
> > Not easily. As mentioned above this is quite a bit of work. For a
> > later series I think.
>
> I'm looking forward for questions :-).
>

Do you think you might submit a patch that adds comments to the header
files? That would help a lot.

Also now that driver model is merged, do you think we should try to move
PMICs to that, or would it be a later step?

Regards,
Simon

[U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.

[Lukasz Majewski]

Hi Simon,

On Mon, 31 Mar 2014 11:27:11 -0600
Simon Glass <sjg@chromium.org> wrote:

> Hi Lukasz,
> 
> On 31 March 2014 08:33, Lukasz Majewski <l.majewski@samsung.com>
> wrote: [snip]
> 
> 
> > >
> > > This can be easily added to be used at "pmic bat charge" command.
> > >
> > > Please look into the ./drivers/power/mfd/pmic_max77693.c
> > >
> > > Not easily. As mentioned above this is quite a bit of work. For a
> > > later series I think.
> >
> > I'm looking forward for questions :-).
> >
> 
> Do you think you might submit a patch that adds comments to the header
> files? That would help a lot.

I will do my best. Up till then would you consider looking at the
following link:

http://u-boot.10912.n7.nabble.com/PATCH-v7-00-26-pmic-Redesign-PMIC-framework-to-support-multiple-instances-of-devices-tt140662.html#none

It should shed some light on the PMIC design.

> 
> Also now that driver model is merged, do you think we should try to
> move PMICs to that, or would it be a later step?

PMIC should be integrated with the device model. Also it shall support
DT.

When it will happen depends on the effort needed. Help more than
welcome.

> 
> Regards,
> Simon


Best regards,
Lukasz Majewski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140331/0ea8d914/attachment.pgp>

[U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus

[Heiko Schocher]

Hello Lukasz,

Am 31.03.2014 08:17, schrieb Lukasz Majewski:
> Hi Heiko,
>
>> Hello Simon, Lukasz,
>>
>> Am 30.03.2014 01:17, schrieb Simon Glass:
>>> Hi Lukasz,
>>>
>>> On 27 March 2014 11:33, Lukasz Majewski<l.majewski@samsung.com>
>>> wrote:
>>>
>>>> Hi Simon, Heiko
>>>>
>>>>> From: Aaron Durbin<adurbin@chromium.org>
>>>>>
>>>>> The current pmic i2c code assumes the current i2c bus is
>>>>> the same as the pmic device's bus. There is nothing ensuring
>>>>> that to be true. Therefore, select the proper bus before
>>>>> performing a transaction.
>>>>>
>>>>> Signed-off-by: Aaron Durbin<adurbin@chromium.org>
>>>>> Signed-off-by: Simon Glass<sjg@chromium.org>
>>>>> Reviewed-by: Simon Glass<sjg@chromium.org>
>>>>> ---
>>>>>
>>>>>    drivers/power/power_i2c.c | 4 ++++
>>>>>    1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
>>>>> index ac76870..594cd11 100644
>>>>> --- a/drivers/power/power_i2c.c
>>>>> +++ b/drivers/power/power_i2c.c
>>>>> @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32
>>>>> val) if (check_reg(p, reg))
>>>>>                 return -1;
>>>>>
>>>>> +     I2C_SET_BUS(p->bus);
>>>>> +
>>>>
>>>> Hadn't we had a  discussion about this explicit setting of I2C
>>>> some time ago? I thought that this problem was solved within the
>>>> I2C rework.
>>>>
>>>> Also I might be wrong, so please correct me if I'm wrong. Isn't the
>>>> I2C_SET_BUS() macro regarded as a obsolete after the I2C rework?
>>>>
>>>
>>> Agreed that would be ideal, but we would have to pass the bus
>>> number of the i2c_read/write() functions. I don't believe the i2c
>>> code has got that far yet.
>>
>> Yes, thats the plan, but first, all i2c driver must be converted to
>> the new framework. After that we could start with such an approach
>> (or device model is ready and we can switch to it ...)
>
> I know that there is a time line for introducing device model, but is
> there any for switching I2C to the new approach?

I am not aware of a plan ...

> I think about deleting obsolete/unmaintained boards, which will not
> switch to new I2C approach.

Hmm... this would be a long list, as there are the following driver
which need a conversion:

obj-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o
obj-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o
obj-$(CONFIG_DW_I2C) += designware_i2c.o
obj-$(CONFIG_I2C_MVTWSI) += mvtwsi.o
obj-$(CONFIG_I2C_MV) += mv_i2c.o
obj-$(CONFIG_I2C_MXS) += mxs_i2c.o
obj-$(CONFIG_PCA9564_I2C) += pca9564_i2c.o
obj-$(CONFIG_TSI108_I2C) += tsi108_i2c.o
obj-$(CONFIG_U8500_I2C) += u8500_i2c.o
obj-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o

Also some drivers in cpu dirs ... grep for HARD_I2C in u-boot
source (one Goal is to get rid of HARD_I2C).

./arch/powerpc/cpu/mpc8xx/i2c.c
./arch/powerpc/cpu/mpc8260/commproc.c
./arch/powerpc/cpu/mpc8260/i2c.c
./arch/powerpc/cpu/mpc5xxx/i2c.c
./arch/powerpc/cpu/mpc824x/drivers/i2c/i2c.c
./arch/powerpc/cpu/mpc512x/i2c.c

[...]

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus

[Heiko Schocher]

Hello Lukasz,

Am 31.03.2014 16:36, schrieb Lukasz Majewski:
> Hi Simon,
>
>> Hi Lukasz,
>>
>> On 27 March 2014 11:33, Lukasz Majewski<l.majewski@samsung.com>
>> wrote: Hi Simon, Heiko
>>
>>> From: Aaron Durbin<adurbin@chromium.org>
>>>
>>> The current pmic i2c code assumes the current i2c bus is
>>> the same as the pmic device's bus. There is nothing ensuring
>>> that to be true. Therefore, select the proper bus before performing
>>> a transaction.
>>>
>>> Signed-off-by: Aaron Durbin<adurbin@chromium.org>
>>> Signed-off-by: Simon Glass<sjg@chromium.org>
>>> Reviewed-by: Simon Glass<sjg@chromium.org>
>>> ---
>>>
>>>   drivers/power/power_i2c.c | 4 ++++
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
>>> index ac76870..594cd11 100644
>>> --- a/drivers/power/power_i2c.c
>>> +++ b/drivers/power/power_i2c.c
>>> @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32
>>> val) if (check_reg(p, reg))
>>>                return -1;
>>>
>>> +     I2C_SET_BUS(p->bus);
>>> +
>>
>> Hadn't we had a  discussion about this explicit setting of I2C some
>> time ago? I thought that this problem was solved within the I2C
>> rework.
>>
>> Also I might be wrong, so please correct me if I'm wrong. Isn't the
>> I2C_SET_BUS() macro regarded as a obsolete after the I2C rework?
>>
>> Agreed that would be ideal, but we would have to pass the bus number
>> of the i2c_read/write() functions. I don't believe the i2c code has
>> got that far yet.
>>
>> Unfortunately it doesn't work without this patch.
>
> If Heiko doesn't object, then I won't protest.

It s okay for me, so to clarify:

Acked-by: Heiko Schocher <hs@denx.de>

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany