Enable LCD display on snow

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

Signed-off-by Simon Glass <[email protected]>

---

 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(-)

drivers/power/power_fsl.c +3 -3

index ac0b541..a64161b 100644
@@ -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;

include/configs/arndale.h +2 -2

index 515facf..30ecd45 100644
@@ -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
 

(quoted diff) +0 -0

b/include/configs/exynos5250-dt.h index b7ff472..9d1d56a 100644

include/configs/exynos5250-dt.h +1 -1

@@ -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

include/configs/mx25pdk.h +1 -1

index af6aafa..571d45a 100644
@@ -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

include/configs/mx35pdk.h +1 -1

index 0a46f4c..ab48144 100644
@@ -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
 

include/configs/mx53evk.h +1 -1

index 3f0d80a..042cdd0 100644
@@ -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 */

include/configs/mx53loco.h +1 -1

index 1415584..365d072 100644
@@ -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
 

(quoted diff) +0 -0

b/include/configs/woodburn_common.h index 695bc23..259205e 100644

From: Tom Wai-Hong Tam <[email protected]>

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 <[email protected]>

Signed-off-by Simon Glass <[email protected]>

Signed-off-by Hatim Ali <[email protected]>

Signed-off-by Katie Roberts-Hoffman <[email protected]>

Signed-off-by Rong Chang <[email protected]>

Signed-off-by Sean Paul <[email protected]>

Signed-off-by Vincent Palatin <[email protected]>

Signed-off-by Aaron Durbin <[email protected]>

---

 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

(quoted diff) +0 -0

b/doc/device-tree-bindings/power/tps65090.txt new file mode 100644 index 0000000..6a8a884

doc/device-tree-bindings/power/tps65090.txt new file +4 -0

@@ -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:

doc/device-tree-bindings/power/tps65090.txt new file +6 -0

+
+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. +

drivers/power/pmic/Makefile +1 -0

index 0b45ffa..7ed55e6 100644
@@ -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

(quoted diff) +0 -0

b/drivers/power/pmic/pmic_tps65090.c new file mode 100644 index 0000000..ef9f911

drivers/power/pmic/pmic_tps65090.c new file +3 -0

@@ -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.

+ */

drivers/power/pmic/pmic_tps65090.c new file +34 -0

+
+#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 */

drivers/power/pmic/pmic_tps65090.c new file +13 -0

+       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",

drivers/power/pmic/pmic_tps65090.c new file +12 -0

+       }
+
+       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)

drivers/power/pmic/pmic_tps65090.c new file +13 -0

+{
+       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))

drivers/power/pmic/pmic_tps65090.c new file +7 -0

+                       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 */

drivers/power/pmic/pmic_tps65090.c new file +7 -0

+               if (reg & FET_CTRL_TOFET)
+                       break;
+
+               mdelay(1);
+       }
+
+       debug("FET %d: Power good should have set to %d but

reg=%#02x\n",

drivers/power/pmic/pmic_tps65090.c new file +3 -0

+             fet_id, set, reg);
+       return FET_ERR_NOT_READY;
+}

drivers/power/pmic/pmic_tps65090.c new file +17 -0

+               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",

drivers/power/pmic/pmic_tps65090.c new file +4 -0

+       /*
+        * 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

drivers/power/pmic/pmic_tps65090.c new file +38 -0

+        * 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);

drivers/power/pmic/pmic_tps65090.c new file +12 -0

+               return -2;
+       }
+
+       return reg & FET_CTRL_ENFET;
+}
+
+int tps65090_get_charging(void)
+{
+       u32 val;
+       int ret;
+       struct pmic *pmic;
+

drivers/power/pmic/pmic_tps65090.c new file +19 -0

+{
+       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__);

drivers/power/pmic/pmic_tps65090.c new file +72 -0

+               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;
+}

include/fdtdec.h +0 -0

index 6e859ce..8f17ed3 100644
@@ -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,
};

(quoted diff) +0 -0

b/include/power/tps65090_pmic.h new file mode 100644 index 0000000..fde30eb

include/power/tps65090_pmic.h new file +3 -0

@@ -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.
+ */

include/power/tps65090_pmic.h new file +19 -0

+
+#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 */ +};

include/power/tps65090_pmic.h new file +54 -0

+
+/**
+ * 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_ */

lib/fdtdec.c +1 -1

index f65ab4f..beee1d0 100644
@@ -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

Hi Simon,

Quoted 10 lines

From: Tom Wai-Hong Tam <[email protected]>

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

Quoted 2 lines

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?

Quoted 47 lines

Signed-off-by Tom Wai-Hong Tam <[email protected]>

Signed-off-by Simon Glass <[email protected]>

Signed-off-by Hatim Ali <[email protected]>

Signed-off-by Katie Roberts-Hoffman <[email protected]>

Signed-off-by Rong Chang <[email protected]>

Signed-off-by Sean Paul <[email protected]>

Signed-off-by Vincent Palatin <[email protected]>

Signed-off-by Aaron Durbin <[email protected]>

---

 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

(quoted diff) +0 -0

b/doc/device-tree-bindings/power/tps65090.txt new file mode 100644 index 0000000..6a8a884

doc/device-tree-bindings/power/tps65090.txt new file +4 -0

@@ -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:

doc/device-tree-bindings/power/tps65090.txt new file +6 -0

+
+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. +

doc/device-tree-bindings/power/tps65090.txt new file +5 -0

+Example
+=======
+
+       i2c at 12ca0000 {
+               power-regulator at 48 {

doc/device-tree-bindings/power/tps65090.txt line 21

Quoted 4 lines

doc/device-tree-bindings/power/tps65090.txt new file +4 -0

+                       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.

Quoted 24 lines

drivers/power/pmic/Makefile +1 -0

index 0b45ffa..7ed55e6 100644
@@ -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

(quoted diff) +0 -0

b/drivers/power/pmic/pmic_tps65090.c new file mode 100644 index 0000000..ef9f911

drivers/power/pmic/pmic_tps65090.c new file +3 -0

@@ -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.
+ *

Quoted 5 lines

+ * 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

Quoted 57 lines

+ */

drivers/power/pmic/pmic_tps65090.c new file +34 -0

+
+#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 */

drivers/power/pmic/pmic_tps65090.c new file +13 -0

+       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",

drivers/power/pmic/pmic_tps65090.c

Quoted 2 lines

drivers/power/pmic/pmic_tps65090.c new file +2 -0

+                     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?

Quoted 13 lines

drivers/power/pmic/pmic_tps65090.c new file +12 -0

+       }
+
+       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

Quoted 4 lines

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

Quoted 33 lines

drivers/power/pmic/pmic_tps65090.c new file +13 -0

+{
+       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))

drivers/power/pmic/pmic_tps65090.c new file +7 -0

+                       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 */

drivers/power/pmic/pmic_tps65090.c new file +7 -0

+               if (reg & FET_CTRL_TOFET)
+                       break;
+
+               mdelay(1);
+       }
+
+       debug("FET %d: Power good should have set to %d but

reg=%#02x\n",

drivers/power/pmic/pmic_tps65090.c new file +3 -0

+             fet_id, set, reg);
+       return FET_ERR_NOT_READY;
+}

drivers/power/pmic/pmic_tps65090.c line 116

Quoted 10 lines

drivers/power/pmic/pmic_tps65090.c new file +10 -0

+
+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?

drivers/power/pmic/pmic_tps65090.c line 119

Quoted 3 lines

drivers/power/pmic/pmic_tps65090.c new file +3 -0

+
+       pmic = pmic_get(TPS65090_NAME);
+       if (pmic == NULL)

It seems like in the code I tend to use:
if (!pmic)

Quoted 18 lines

drivers/power/pmic/pmic_tps65090.c new file +17 -0

+               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,

drivers/power/pmic/pmic_tps65090.c line 141

Quoted 6 lines

loops=%d\n",

drivers/power/pmic/pmic_tps65090.c new file +5 -0

+                     __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.

Quoted 57 lines

drivers/power/pmic/pmic_tps65090.c new file +4 -0

+       /*
+        * 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

drivers/power/pmic/pmic_tps65090.c new file +38 -0

+        * 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);

drivers/power/pmic/pmic_tps65090.c new file +12 -0

+               return -2;
+       }
+
+       return reg & FET_CTRL_ENFET;
+}
+
+int tps65090_get_charging(void)
+{
+       u32 val;
+       int ret;
+       struct pmic *pmic;
+

drivers/power/pmic/pmic_tps65090.c line 205

Quoted 10 lines

drivers/power/pmic/pmic_tps65090.c new file +10 -0

+       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

Hi Lukasz,

On 27 March 2014 11:59, Lukasz Majewski <[email protected]>
wrote: Hi Simon,

Quoted 7 lines

From: Tom Wai-Hong Tam <[email protected]>

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:

Quoted 5 lines

- 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.

Quoted 42 lines

Signed-off-by Tom Wai-Hong Tam <[email protected]>

Signed-off-by Simon Glass <[email protected]>

Signed-off-by Hatim Ali <[email protected]>

Signed-off-by Katie Roberts-Hoffman <[email protected]>

Signed-off-by Rong Chang <[email protected]>

Signed-off-by Sean Paul <[email protected]>

Signed-off-by Vincent Palatin <[email protected]>

Signed-off-by Aaron Durbin <[email protected]>

---

?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

(quoted diff) +0 -0

b/doc/device-tree-bindings/power/tps65090.txt new file mode 100644 index 0000000..6a8a884

doc/device-tree-bindings/power/tps65090.txt new file +4 -0

@@ -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:

doc/device-tree-bindings/power/tps65090.txt new file +6 -0

+
+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. +

doc/device-tree-bindings/power/tps65090.txt

Quoted 9 lines

doc/device-tree-bindings/power/tps65090.txt new file +9 -0

+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.

Quoted 21 lines

(quoted diff) +0 -0

b/drivers/power/pmic/Makefile index 0b45ffa..7ed55e6 100644

drivers/power/pmic/Makefile +0 -0

@@ -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

(quoted diff) +0 -0

b/drivers/power/pmic/pmic_tps65090.c new file mode 100644 index 0000000..ef9f911

drivers/power/pmic/pmic_tps65090.c new file +3 -0

@@ -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

Quoted 8 lines

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.
?

Quoted 55 lines

+ */

drivers/power/pmic/pmic_tps65090.c new file +34 -0

+
+#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 */

drivers/power/pmic/pmic_tps65090.c new file +12 -0

+};
+
+/**
+ * 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

Quoted 3 lines

~ %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.
?

Quoted 12 lines

+ ? ? ? }

drivers/power/pmic/pmic_tps65090.c new file +11 -0

+
+ ? ? ? 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

Quoted 4 lines

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

Quoted 34 lines

drivers/power/pmic/pmic_tps65090.c new file +13 -0

+{
+ ? ? ? 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;

drivers/power/pmic/pmic_tps65090.c new file +5 -0

+
+ ? ? ? ? ? ? ? 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;

drivers/power/pmic/pmic_tps65090.c new file +1 -0

+}

drivers/power/pmic/pmic_tps65090.c

Quoted 10 lines

drivers/power/pmic/pmic_tps65090.c new file +10 -0

+
+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?

Quoted 3 lines

+
+ ? ? ? pmic = pmic_get(TPS65090_NAME);
+ ? ? ? if (pmic == NULL)

? ? ? ? ? ? ?It seems like in the code I tend to use:
? ? ? ? ? ? ? ? if (!pmic)

OK?

Quoted 17 lines

+ ? ? ? ? ? ? ? return -1;

drivers/power/pmic/pmic_tps65090.c new file +16 -0

+
+ ? ? ? 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,

Quoted 7 lines

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?

Quoted 56 lines

+ ? ? ? /*
+ ? ? ? ?* 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;

drivers/power/pmic/pmic_tps65090.c new file +34 -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;
+ ? ? ? }

drivers/power/pmic/pmic_tps65090.c new file +10 -0

+
+ ? ? ? return reg & FET_CTRL_ENFET;
+}
+
+int tps65090_get_charging(void)
+{
+ ? ? ? u32 val;
+ ? ? ? int ret;
+ ? ? ? struct pmic *pmic;
+

drivers/power/pmic/pmic_tps65090.c

Quoted 10 lines

drivers/power/pmic/pmic_tps65090.c new file +10 -0

+ ? ? ? 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

Quoted 7 lines

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 :-).

Hi Lukasz,

On 31 March 2014 08:33, Lukasz Majewski <[email protected]>
wrote: [snip]

Quoted 5 lines

Quoted 5 lines

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

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

Quoted 5 lines

Quoted 2 lines

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

From: Aaron Durbin <[email protected]>

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 <[email protected]>

Reviewed-by Simon Glass <[email protected]>

---

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

include/configs/exynos5-dt.h +1 -1

index 414db42..fbf09f5 100644
@@ -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

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!

From: Aaron Durbin <[email protected]>

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 <[email protected]>

Signed-off-by Simon Glass <[email protected]>

Reviewed-by Simon Glass <[email protected]>

---

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

drivers/power/power_i2c.c +0 -0

index ac76870..594cd11 100644

drivers/power/power_i2c.c +0 -0

 	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;

drivers/power/power_i2c.c +2 -0

+	I2C_SET_BUS(p->bus);
+
 	if (i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num))
 		return -1;

Hi Simon, Heiko

Quoted 23 lines

From: Aaron Durbin <[email protected]>

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 <[email protected]>

Signed-off-by Simon Glass <[email protected]>

Reviewed-by Simon Glass <[email protected]>

---

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

drivers/power/power_i2c.c +0 -0

index ac76870..594cd11 100644
@@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
      if (check_reg(p, reg))
              return -1;
 

drivers/power/power_i2c.c int pmic_reg_write(struct pmic *p, u32 reg, u32 val) · line 27

Quoted 2 lines

drivers/power/power_i2c.c +2 -0

+     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?

Hi Lukasz,

Quoted 31 lines · Lukasz Majewski

Hi Simon, Heiko

Quoted 20 lines

From: Aaron Durbin<[email protected]>

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<[email protected]>

Signed-off-by Simon Glass<[email protected]>

Reviewed-by Simon Glass<[email protected]>

---

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

drivers/power/power_i2c.c +0 -0

index ac76870..594cd11 100644

drivers/power/power_i2c.c int pmic_reg_write(struct pmic *p, u32 reg, u32 val) · line 27

Quoted 5 lines

drivers/power/power_i2c.c +2 -0

@@ -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.

Quoted 3 lines

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.

Hello Simon, Lukasz,

Am 30.03.2014 01:17, schrieb Simon Glass:

Quoted 41 lines

Hi Lukasz,

Quoted 35 lines · Lukasz Majewski

Hi Simon, Heiko

Quoted 20 lines

From: Aaron Durbin<[email protected]>

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<[email protected]>

Signed-off-by Simon Glass<[email protected]>

Reviewed-by Simon Glass<[email protected]>

---

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

drivers/power/power_i2c.c +0 -0

index ac76870..594cd11 100644

drivers/power/power_i2c.c int pmic_reg_write(struct pmic *p, u32 reg, u32 · line 27

Quoted 5 lines

drivers/power/power_i2c.c +2 -0

@@ -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?

Quoted 3 lines

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 ...)

Quoted 2 lines

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

Hi Heiko,

Quoted 48 lines

Hello Simon, Lukasz,

Am 30.03.2014 01:17, schrieb Simon Glass:

Quoted 44 lines

Hi Lukasz,

Quoted 32 lines · Lukasz Majewski

Hi Simon, Heiko

Quoted 20 lines

From: Aaron Durbin<[email protected]>

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<[email protected]>

Signed-off-by Simon Glass<[email protected]>

Reviewed-by Simon Glass<[email protected]>

---

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

drivers/power/power_i2c.c +0 -0

index ac76870..594cd11 100644

drivers/power/power_i2c.c int pmic_reg_write(struct pmic *p, u32 reg, u32 · line 27

Quoted 5 lines

drivers/power/power_i2c.c +2 -0

@@ -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.

Quoted 3 lines

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.

Quoted 3 lines

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.

Hi Lukasz,

On 27 March 2014 11:33, Lukasz Majewski <[email protected]>
wrote: Hi Simon, Heiko

Quoted 20 lines

From: Aaron Durbin <[email protected]>

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 <[email protected]>

Signed-off-by Simon Glass <[email protected]>

Reviewed-by Simon Glass <[email protected]>

---

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

drivers/power/power_i2c.c +0 -0

index ac76870..594cd11 100644

drivers/power/power_i2c.c int pmic_reg_write(struct pmic *p, u32 reg, u32 · line 27

Quoted 5 lines

drivers/power/power_i2c.c +2 -0

@@ -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

Hi Simon,

Quoted 38 lines

Hi Lukasz,

On 27 March 2014 11:33, Lukasz Majewski<[email protected]>
wrote: Hi Simon, Heiko

Quoted 20 lines

From: Aaron Durbin<[email protected]>

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<[email protected]>

Signed-off-by Simon Glass<[email protected]>

Reviewed-by Simon Glass<[email protected]>

---

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

drivers/power/power_i2c.c +0 -0

index ac76870..594cd11 100644

drivers/power/power_i2c.c int pmic_reg_write(struct pmic *p, u32 reg, u32 · line 27

Quoted 5 lines

drivers/power/power_i2c.c +2 -0

@@ -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?

Quoted 5 lines

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.

From: Aaron Durbin <[email protected]>

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 <[email protected]>

Signed-off-by Simon Glass <[email protected]>

Reviewed-by Simon Glass <[email protected]>

---

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

board/samsung/common/board.c +1 -0

index 3866495..654bdb6 100644
@@ -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;
 

Quoted 26 lines · Simon Glass

From: Aaron Durbin <[email protected]>

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 <[email protected]>

Signed-off-by Simon Glass <[email protected]>

Reviewed-by Simon Glass <[email protected]>

---

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

board/samsung/common/board.c +1 -0

index 3866495..654bdb6 100644
@@ -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;
 

board/samsung/common/board.c int power_init_board(void) · line 263

Quoted 3 lines

board/samsung/common/board.c +0 -0

@@ -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?

From: Aaron Durbin <[email protected]>

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 <[email protected]>

Signed-off-by Simon Glass <[email protected]>

Reviewed-by Simon Glass <[email protected]>

---

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

(quoted diff) +0 -0

b/board/samsung/common/board.c index 3866495..654bdb6 100644

board/samsung/common/board.c +2 -0

@@ -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

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 <[email protected]>

---

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

(quoted diff) +0 -0

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

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

Signed-off-by Simon Glass <[email protected]>

---

 arch/arm/dts/exynos5250-snow.dts | 44

++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+)

(quoted diff) +0 -0

b/arch/arm/dts/exynos5250-snow.dts index 42a687b..725a1bf 100644

arch/arm/dts/exynos5250-snow.dts +19 -0

@@ -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>;

arch/arm/dts/exynos5250-snow.dts +6 -0

+	dp at 145b0000 {
+		samsung,lt-status = <0>;
+
+		samsung,master-mode = <0>;
+		samsung,bist-mode = <0>;
+		samsung,bist-pattern = <0>;

Hi Simon,

Quoted 36 lines

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

Signed-off-by Simon Glass <[email protected]>

---

 arch/arm/dts/exynos5250-snow.dts | 44

++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+)

(quoted diff) +0 -0

b/arch/arm/dts/exynos5250-snow.dts index 42a687b..725a1bf 100644

arch/arm/dts/exynos5250-snow.dts +19 -0

@@ -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>;

arch/arm/dts/exynos5250-snow.dts line 223

Quoted 10 lines

arch/arm/dts/exynos5250-snow.dts +10 -0

+             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.

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

Signed-off-by Simon Glass <[email protected]>

---

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

board/samsung/smdk5250/exynos5-dt.c +47 -0

index c83b034..a0ae641 100644
@@ -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 =

board/samsung/smdk5250/exynos5-dt.c +28 -0

+#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__);

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

Signed-off-by Simon Glass <[email protected]>

---

 board/samsung/smdk5250/exynos5-dt.c | 90

+++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+)

(quoted diff) +0 -0

b/board/samsung/smdk5250/exynos5-dt.c index c83b034..a0ae641 100644

board/samsung/smdk5250/exynos5-dt.c +27 -0

@@ -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

board/samsung/smdk5250/exynos5-dt.c +1 -0

+	 * is a phantom "high" on the HPD chip during its bootup.

The phantom

board/samsung/smdk5250/exynos5-dt.c +1 -0

+	 * high comes within 7ms of de-asserting PD and persists for

at least

board/samsung/smdk5250/exynos5-dt.c +1 -0

+	 * 15ms.  The real high comes roughly 50ms after PD is

de-asserted. The

board/samsung/smdk5250/exynos5-dt.c +1 -0

+	 * phantom high makes it hard for us to know when the NXP

chip is up.

board/samsung/smdk5250/exynos5-dt.c +9 -0

+	 */
+	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",

board/samsung/smdk5250/exynos5-dt.c +4 -0

+		      __func__, num_tries, MAX_TRIES);
+	}
+
+	/* Immediately go into bridge reset if the hp line is not

high */

board/samsung/smdk5250/exynos5-dt.c +16 -0

+	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 */

board/samsung/smdk5250/exynos5-dt.c +21 -0

+		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__);

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

Signed-off-by Simon Glass <[email protected]>

---

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

board/samsung/smdk5250/exynos5-dt.c +1 -0

index c83b034..a0ae641 100644
@@ -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;

board/samsung/smdk5250/exynos5-dt.c +26 -0

+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.

board/samsung/smdk5250/exynos5-dt.c +25 -0

+        */
+       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 *)

board/samsung/smdk5250/exynos5-dt.c +7 -0

+
+               /* board_dp_backlight_en */
+               s5p_gpio_direction_output(&gpio1->x3, 0, 1);
+#endif
+       }
+}
+

board/samsung/smdk5250/exynos5-dt.c +2 -1

+}
+
 #endif
--

1.9.1.423.g4596e3a

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Hi Simon,

Find my comments below:

Quoted 22 lines · Simon Glass

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

Signed-off-by Simon Glass <[email protected]>

---

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

board/samsung/smdk5250/exynos5-dt.c +1 -0

index c83b034..a0ae641 100644
@@ -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>
 

board/samsung/smdk5250/exynos5-dt.c int checkboard(void) · line 64

Quoted 6 lines

board/samsung/smdk5250/exynos5-dt.c +0 -0

 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)

Quoted 70 lines

board/samsung/smdk5250/exynos5-dt.c +25 -0

+{
+       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.

board/samsung/smdk5250/exynos5-dt.c +28 -0

+        */
+       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;
+

board/samsung/smdk5250/exynos5-dt.c void exynos_set_dp_phy(unsigned int onoff)

Quoted 7 lines

board/samsung/smdk5250/exynos5-dt.c +6 -0

+               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/samsung/smdk5250/exynos5-dt.c void exynos_set_dp_phy(unsigned int onoff) · line 151

Quoted 3 lines

board/samsung/smdk5250/exynos5-dt.c +2 -0

+               /* board_dp_backlight_pwm */
+               s5p_gpio_direction_output(&gpio1->b2, 0, 1);

+

board/samsung/smdk5250/exynos5-dt.c void exynos_set_dp_phy(unsigned int onoff) · line 154

Quoted 3 lines

board/samsung/smdk5250/exynos5-dt.c +2 -0

+               /* T6 in the LCD timing spec (defined as > 10ms) */
+               mdelay(10);

Can you check for backlight without using the above delay?

Quoted 11 lines

board/samsung/smdk5250/exynos5-dt.c +11 -0

+
+               /* board_dp_backlight_en */
+               s5p_gpio_direction_output(&gpio1->x3, 0, 1);
+#endif
+       }
+}
+
+void exynos_lcd_power_on(void)
+{
+       debug("%s\n", __func__);
+

board/samsung/smdk5250/exynos5-dt.c void exynos_set_dp_phy(unsigned int onoff) · line 171

Quoted 7 lines

board/samsung/smdk5250/exynos5-dt.c +6 -0

+#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.