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

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@12ca0000 {
  

•           power-regulator@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

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@12ca0000 {
• power-regulator@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

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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

Regards, Ajay Kumar

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

Hi Heiko,

Hello Simon, Lukasz,

Am 30.03.2014 01:17, schrieb Simon Glass:

...

Hi Lukasz,

On 27 March 2014 11:33, Lukasz Majewskil.majewski@samsung.com wrote:

...

Hi Simon, Heiko

...

From: Aaron Durbinadurbin@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 Durbinadurbin@chromium.org Signed-off-by: Simon Glasssjg@chromium.org Reviewed-by: Simon Glasssjg@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

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

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

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

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

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