On 03/04/14 08:24, Simon Glass wrote:

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.

The device tree binding is from Linux, but only a small subset of functionality is supported.

Signed-off-by: Tom Wai-Hong Tam waihong@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 Signed-off-by: Simon Glass sjg@chromium.org

---

Changes in v2:

• Removed non-device-tree operation
• Use errno.h for error return codes everywhere
• Plumb into pmic charging framework
• Fix style nit
• Use correct license header
• Use new Linux device tree bindings
• Add partial battery charging support

doc/device-tree-bindings/power/tps65090.txt | 17 ++ doc/device-tree-bindings/regulator/tps65090.txt | 122 +++++++++ drivers/power/pmic/Makefile | 1 + drivers/power/pmic/pmic_tps65090.c | 312 ++++++++++++++++++++++++ include/fdtdec.h | 1 + include/power/tps65090_pmic.h | 73 ++++++ lib/fdtdec.c | 1 + 7 files changed, 527 insertions(+) create mode 100644 doc/device-tree-bindings/power/tps65090.txt create mode 100644 doc/device-tree-bindings/regulator/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..8e5e0d3 --- /dev/null +++ b/doc/device-tree-bindings/power/tps65090.txt @@ -0,0 +1,17 @@ +TPS65090 Frontend PMU with Switchmode Charger

+Required Properties: +-compatible: "ti,tps65090-charger"

+Optional Properties: +-ti,enable-low-current-chrg: Enables charging when a low current is detected

• while the default logic is to stop charging.

+This node is a subnode of the tps65090 PMIC.

+Example:

• tps65090-charger {

• compatible = "ti,tps65090-charger";
  

• ti,enable-low-current-chrg;
  

• };

diff --git a/doc/device-tree-bindings/regulator/tps65090.txt b/doc/device-tree-bindings/regulator/tps65090.txt new file mode 100644 index 0000000..313a60b --- /dev/null +++ b/doc/device-tree-bindings/regulator/tps65090.txt @@ -0,0 +1,122 @@ +TPS65090 regulators

+Required properties: +- compatible: "ti,tps65090" +- reg: I2C slave address +- interrupts: the interrupt outputs of the controller +- regulators: A node that houses a sub-node for each regulator within the

• device. Each sub-node is identified using the node's name, with valid
• values listed below. The content of each sub-node is defined by the
• standard binding for regulators; see regulator.txt.
• dcdc[1-3], fet[1-7] and ldo[1-2] respectively.

+- vsys[1-3]-supply: The input supply for DCDC[1-3] respectively. +- infet[1-7]-supply: The input supply for FET[1-7] respectively. +- vsys-l[1-2]-supply: The input supply for LDO[1-2] respectively.

+Optional properties: +- ti,enable-ext-control: This is applicable for DCDC1, DCDC2 and DCDC3.

• If DCDCs are externally controlled then this property should be there.

+- "dcdc-ext-control-gpios: This is applicable for DCDC1, DCDC2 and DCDC3.

• If DCDCs are externally controlled and if it is from GPIO then GPIO
• number should be provided. If it is externally controlled and no GPIO
• entry then driver will just configure this rails as external control
• and will not provide any enable/disable APIs.

+Each regulator is defined using the standard binding for regulators.

+Example:

• tps65090@48 {

• compatible = "ti,tps65090";
  

• reg = <0x48>;
  

• interrupts = <0 88 0x4>;
  

• vsys1-supply = <&some_reg>;
  

• vsys2-supply = <&some_reg>;
  

• vsys3-supply = <&some_reg>;
  

• infet1-supply = <&some_reg>;
  

• infet2-supply = <&some_reg>;
  

• infet3-supply = <&some_reg>;
  

• infet4-supply = <&some_reg>;
  

• infet5-supply = <&some_reg>;
  

• infet6-supply = <&some_reg>;
  

• infet7-supply = <&some_reg>;
  

• vsys_l1-supply = <&some_reg>;
  

• vsys_l2-supply = <&some_reg>;
  

• regulators {
  

• 	dcdc1 {
  

• 		regulator-name = "dcdc1";
  

• 		regulator-boot-on;
  

• 		regulator-always-on;
  

• 		ti,enable-ext-control;
  

• 		dcdc-ext-control-gpios = <&gpio 10 0>;
  

• 	};
  

• 	dcdc2 {
  

• 		regulator-name = "dcdc2";
  

• 		regulator-boot-on;
  

• 		regulator-always-on;
  

• 	};
  

• 	dcdc3 {
  

• 		regulator-name = "dcdc3";
  

• 		regulator-boot-on;
  

• 		regulator-always-on;
  

• 	};
  

• 	fet1 {
  

• 		regulator-name = "fet1";
  

• 		regulator-boot-on;
  

• 		regulator-always-on;
  

• 	};
  

• 	fet2 {
  

• 		regulator-name = "fet2";
  

• 		regulator-boot-on;
  

• 		regulator-always-on;
  

• 	};
  

• 	fet3 {
  

• 		regulator-name = "fet3";
  

• 		regulator-boot-on;
  

• 		regulator-always-on;
  

• 	};
  

• 	fet4 {
  

• 		regulator-name = "fet4";
  

• 		regulator-boot-on;
  

• 		regulator-always-on;
  

• 	};
  

• 	fet5 {
  

• 		regulator-name = "fet5";
  

• 		regulator-boot-on;
  

• 		regulator-always-on;
  

• 	};
  

• 	fet6 {
  

• 		regulator-name = "fet6";
  

• 		regulator-boot-on;
  

• 		regulator-always-on;
  

• 	};
  

• 	fet7 {
  

• 		regulator-name = "fet7";
  

• 		regulator-boot-on;
  

• 		regulator-always-on;
  

• 	};
  

• 	ldo1 {
  

• 		regulator-name = "ldo1";
  

• 		regulator-boot-on;
  

• 		regulator-always-on;
  

• 	};
  

• 	ldo2 {
  

• 		regulator-name = "ldo2";
  

• 		regulator-boot-on;
  

• 		regulator-always-on;
  

• 	};
  

• };
  

• };

diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile index 4129bda..3244f69 100644 --- a/drivers/power/pmic/Makefile +++ b/drivers/power/pmic/Makefile @@ -10,5 +10,6 @@ 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_PFUZE100) += pmic_pfuze100.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..8558b43 --- /dev/null +++ b/drivers/power/pmic/pmic_tps65090.c @@ -0,0 +1,312 @@ +/*

• • Copyright (c) 2012 The Chromium OS Authors.
• • SPDX-License-Identifier: GPL-2.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_IRQ1 = 0,
• 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 {

• IRQ1_VBATG = 1 << 3,
• 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 */

+};

Are there any special reason to use enum?

+/**

• • Checks for a valid FET number
• • @param fet_id FET number to check
• • @return 0 if ok, -EINVAL 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 -EINVAL;
  

• }
• 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 -EIO if we got a comms error, -EAGAIN if the FET failed to
• • change state. If all is ok, returns 0.
• */

+static int tps65090_fet_set(struct pmic *pmic, int fet_id, bool set) +{

• int retry;
• u32 reg, value;
• value = FET_CTRL_ADENFET | FET_CTRL_WAIT;
• if (set)

• value |= FET_CTRL_ENFET;
  

• if (pmic_reg_write(pmic, REG_FET1_CTRL + fet_id - 1, value))

• return -EIO;
  

• /* 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 -EIO;
  

• /* 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 -EAGAIN;

EAGAIN? why?

+}

+int tps65090_fet_enable(unsigned int fet_id) +{

• struct pmic *pmic;
• ulong start;
• int loops;
• int ret;
• ret = tps65090_check_fet(fet_id);
• if (ret)

• return ret;
  

• pmic = pmic_get(TPS65090_NAME);
• if (!pmic)

• return -EACCES;
  

• start = get_timer(0);
• for (loops = 0;; loops++) {

• ret = tps65090_fet_set(pmic, fet_id, true);
  

• 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, false);
  

• }
• if (ret)

• debug("%s: FET%d failed to power on: time=%lums, loops=%d\n",
  

•       __func__, fet_id, get_timer(start), loops);
  

• else if (loops)

• debug("%s: FET%d powered on after %lums, loops=%d\n",
  

•       __func__, fet_id, get_timer(start), loops);
  

• /*

• * Unfortunately, there are some conditions where the power
  

• * good bit will be 0, but the fet still comes up. One such
  

• * case occurs with the lcd backlight. We'll just return 0 here
  

• * and assume that the fet will eventually come up.
  

• */
  

I can't understand it. If it is a special case, then it should be controlled at each caller.

• if (ret == -EAGAIN)

• ret = 0;
  

It looks weird.

• return ret;

+}

+int tps65090_fet_disable(unsigned int fet_id) +{

• struct pmic *pmic;
• int ret;
• ret = tps65090_check_fet(fet_id);
• if (ret)

• return ret;
  

• pmic = pmic_get(TPS65090_NAME);
• if (!pmic)

• return -EACCES;
  

• ret = tps65090_fet_set(pmic, fet_id, false);
• return ret;

+}

+int tps65090_fet_is_enabled(unsigned int fet_id) +{

• struct pmic *pmic;
• u32 reg;
• int ret;
• ret = tps65090_check_fet(fet_id);
• if (ret)

• return ret;
  

• pmic = pmic_get(TPS65090_NAME);
• if (!pmic)

• return -ENODEV;
  

• 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 -EIO;
  

• }
• return reg & FET_CTRL_ENFET;

+}

+int tps65090_get_charging(void) +{

• struct pmic *pmic;
• u32 val;
• int ret;
• pmic = pmic_get(TPS65090_NAME);
• if (!pmic)

• return -EACCES;
  

• ret = pmic_reg_read(pmic, REG_CG_CTRL0, &val);
• if (ret)

• return ret;
  

• return val & CG_CTRL0_ENC_MASK ? 1 : 0;

How about it?

return !!(val & CG_CTRL0_ENC_MASK);

+}

+static int tps65090_charger_state(struct pmic *pmic, int state,

• 		  int current)
  

+{

• u32 val;
• int ret;
• ret = pmic_reg_read(pmic, REG_CG_CTRL0, &val);
• if (!ret) {

• if (state == PMIC_CHARGER_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) +{

• struct pmic *pmic;
• u32 val;
• int ret;
• pmic = pmic_get(TPS65090_NAME);
• if (!pmic)

• return -EACCES;
  

• ret = pmic_reg_read(pmic, REG_CG_STATUS1, &val);
• if (ret)

• return ret;
  

• return val;

+}

+static int tps65090_charger_bat_present(struct pmic *pmic) +{

• u32 val;
• int ret;
• ret = pmic_reg_read(pmic, REG_IRQ1, &val);
• if (ret)

• return ret;
  

• return val & IRQ1_VBATG ? true : false;

return !!(val & IRQ1_VBATG);

+}

please remove extra blank line.

+static struct power_chrg power_chrg_pmic_ops = {

• .chrg_bat_present = tps65090_charger_bat_present,
• .chrg_state = tps65090_charger_state,

+};

+int tps65090_init(void) +{

• struct pmic *p;
• int bus;
• int addr;

please remove blank line.

• 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 -EINVAL;
  

• }
• bus = i2c_get_bus_num_fdt(parent);
• if (p->bus < 0) {

• debug("%s: Cannot find I2C bus\n", __func__);
  

• return -ENOENT;
  

• }
• addr = fdtdec_get_int(blob, node, "reg", TPS65090_I2C_ADDR);
• 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;
• p->chrg = &power_chrg_pmic_ops;
• puts("TPS65090 PMIC init\n");
• return 0;

+} diff --git a/include/fdtdec.h b/include/fdtdec.h index 3196cf6..669ab90 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -92,6 +92,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..dcf99c9 --- /dev/null +++ b/include/power/tps65090_pmic.h @@ -0,0 +1,73 @@ +/*

• • Copyright (c) 2012 The Chromium OS Authors.
• • SPDX-License-Identifier: GPL-2.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,

+};

Are there any special reason to use enum?

+/**

• • 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 33265ec..e15e0ad 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -65,6 +65,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)

Thanks, Minkyu Kang.

Hi Minkyu,

On 15 May 2014 00:51, Minkyu Kang mk7.kang@samsung.com wrote:

On 03/04/14 08:24, 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

---

Changes in v2:

• Move code to exynos5-dt.c
• Fix comment style
• Add #ifdef around tps65090 code

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

diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c index 1a64b9b..2c1cf8a 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; @@ -164,7 +165,19 @@ int exynos_power_init(void)

#ifdef CONFIG_POWER_MAX77686 ret = max77686_init();

• if (ret)
  

•         return ret;
  

#endif +#ifdef CONFIG_POWER_TPS65090

• /*
  

•  * The TPS65090 may not be in the device tree. If so, it is not
  

•  * an error.
  

Then, how we can initialise the tps65090?

It is initialised if a suitable node is found in the device tree. If the device tree does not have it, then the hardware is assumed to not have this chip.

...

•  */
  

• ret = tps65090_init();
  

• if (ret == 0 || ret == -ENODEV)
  

•         return 0;
  

+#endif

• return ret;
  

} #endif /* CONFIG_POWER */

Thanks, Minkyu Kang.

Regards, Simon

Hi Minkyu,

On 21 May 2014 00:05, Minkyu Kang mk7.kang@samsung.com wrote:

On 20/05/14 20:47, Simon Glass wrote:

...

Hi Minkyu,

On 15 May 2014 00:51, Minkyu Kang mk7.kang@samsung.com wrote:

...

On 03/04/14 08:24, 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

---

Changes in v2:

• Move code to exynos5-dt.c
• Fix comment style
• Add #ifdef around tps65090 code

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

diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c index 1a64b9b..2c1cf8a 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; @@ -164,7 +165,19 @@ int exynos_power_init(void)

#ifdef CONFIG_POWER_MAX77686 ret = max77686_init();

• if (ret)
  

•         return ret;
  

#endif +#ifdef CONFIG_POWER_TPS65090

• /*
  

•  * The TPS65090 may not be in the device tree. If so, it is not
  

•  * an error.
  

Then, how we can initialise the tps65090?

It is initialised if a suitable node is found in the device tree. If the device tree does not have it, then the hardware is assumed to not have this chip.

then I think, it's an error. Why you said, it is not an error?

I may be misunderstanding your question, but I'll try to answer what I think you are asking.

The device tree contains nodes for hardware in the machine that you want to initialise, and information about each one. Devices can be enabled or disabled by including or removing this information from the device tree (or marking a device disabled with a status = "disabled" property in the node).

The tps65090 chip is not used in all exynos5-dt boards, but is used in some. For example smdk5250 does not have it, but snow does. So we use the device tree to specify the difference, including (on snow) things like the tps65090, the display bridge chip, etc.

Regards, Simon

Hi Minkyu,

On 21 May 2014 15:20, Minkyu Kang mk7.kang@samsung.com wrote:

On 22/05/14 03:58, Simon Glass wrote:

...

Hi Minkyu,

On 21 May 2014 00:05, Minkyu Kang mk7.kang@samsung.com wrote:

...

On 20/05/14 20:47, Simon Glass wrote:

...

Hi Minkyu,

On 15 May 2014 00:51, Minkyu Kang mk7.kang@samsung.com wrote:

...

On 03/04/14 08:24, 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

---

Changes in v2:

• Move code to exynos5-dt.c
• Fix comment style
• Add #ifdef around tps65090 code

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

diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c index 1a64b9b..2c1cf8a 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; @@ -164,7 +165,19 @@ int exynos_power_init(void)

#ifdef CONFIG_POWER_MAX77686 ret = max77686_init();

• if (ret)
  

•         return ret;
  

#endif +#ifdef CONFIG_POWER_TPS65090

• /*
  

•  * The TPS65090 may not be in the device tree. If so, it is not
  

•  * an error.
  

Then, how we can initialise the tps65090?

It is initialised if a suitable node is found in the device tree. If the device tree does not have it, then the hardware is assumed to not have this chip.

then I think, it's an error. Why you said, it is not an error?

I may be misunderstanding your question, but I'll try to answer what I think you are asking.

The device tree contains nodes for hardware in the machine that you want to initialise, and information about each one. Devices can be enabled or disabled by including or removing this information from the device tree (or marking a device disabled with a status = "disabled" property in the node).

The tps65090 chip is not used in all exynos5-dt boards, but is used in some. For example smdk5250 does not have it, but snow does. So we use the device tree to specify the difference, including (on snow) things like the tps65090, the display bridge chip, etc.

Hm, it doesn't make sense. Then it(#define CONFIG_POWER_TPS65090) should go into each config files. Not in exynos5-dt.h. Please modify it and patch 6/12 also.

The way it works at present is that there is a single exynos5-dt.h file which is used by all exynos5 boards. To the extent possible we have avoided putting particular features in things like snow.h and smdk5250.h - they just include exynos5-dt.h without changes.

The idea is that we can have one U-Boot binary that runs on any exynos5 device, rather than lots of different options. This makes it much easier to test changes sine we only need to build it once. If every exynos5 board has different #defines then there are more combinations to build and test. This is similar to what the kernel does with arch/arm/mach-exynos/mach-exynos5-dt.c.

Using this approach the only differences between smdk5250, daisy, snow, spring, etc. are in the device tree. I'd really like to avoid changing this now. It is easy enough for people to add their own private variants of these locally if they want to, but for mainline I believe it is better to be more generic.

Regards, Simon

Hi David,

On 22 May 2014 08:24, David Nelson djhenjin1@gmail.com wrote:

On 14-05-22 11:27 AM, Simon Glass wrote:

...

Hi Minkyu,

On 21 May 2014 15:20, Minkyu Kang mk7.kang@samsung.com wrote:

...

On 22/05/14 03:58, Simon Glass wrote:

...

Hi Minkyu,

On 21 May 2014 00:05, Minkyu Kang mk7.kang@samsung.com wrote:

...

On 20/05/14 20:47, Simon Glass wrote:

...

Hi Minkyu,

On 15 May 2014 00:51, Minkyu Kang mk7.kang@samsung.com wrote: > > On 03/04/14 08:24, 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 >> --- >> >> Changes in v2: >> - Move code to exynos5-dt.c >> - Fix comment style >> - Add #ifdef around tps65090 code >> >> board/samsung/smdk5250/exynos5-dt.c | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/board/samsung/smdk5250/exynos5-dt.c >> b/board/samsung/smdk5250/exynos5-dt.c >> index 1a64b9b..2c1cf8a 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; >> @@ -164,7 +165,19 @@ int exynos_power_init(void) >> >> #ifdef CONFIG_POWER_MAX77686 >> ret = max77686_init(); >> + if (ret) >> + return ret; >> #endif >> +#ifdef CONFIG_POWER_TPS65090 >> + /* >> + * The TPS65090 may not be in the device tree. If so, it is >> not >> + * an error. > > Then, how we can initialise the tps65090?

It is initialised if a suitable node is found in the device tree. If the device tree does not have it, then the hardware is assumed to not have this chip.

then I think, it's an error. Why you said, it is not an error?

I may be misunderstanding your question, but I'll try to answer what I think you are asking.

The device tree contains nodes for hardware in the machine that you want to initialise, and information about each one. Devices can be enabled or disabled by including or removing this information from the device tree (or marking a device disabled with a status = "disabled" property in the node).

The tps65090 chip is not used in all exynos5-dt boards, but is used in some. For example smdk5250 does not have it, but snow does. So we use the device tree to specify the difference, including (on snow) things like the tps65090, the display bridge chip, etc.

Hm, it doesn't make sense. Then it(#define CONFIG_POWER_TPS65090) should go into each config files. Not in exynos5-dt.h. Please modify it and patch 6/12 also.

The way it works at present is that there is a single exynos5-dt.h file which is used by all exynos5 boards. To the extent possible we have avoided putting particular features in things like snow.h and smdk5250.h - they just include exynos5-dt.h without changes.

The idea is that we can have one U-Boot binary that runs on any exynos5 device, rather than lots of different options. This makes it much easier to test changes sine we only need to build it once. If every exynos5 board has different #defines then there are more combinations to build and test. This is similar to what the kernel does with arch/arm/mach-exynos/mach-exynos5-dt.c.

Using this approach the only differences between smdk5250, daisy, snow, spring, etc. are in the device tree. I'd really like to avoid changing this now. It is easy enough for people to add their own private variants of these locally if they want to, but for mainline I believe it is better to be more generic.

Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

Simon,

Would you say that we are approaching a state where *all* exynos 5 boards will be ready? I ask because I have the Universal5420 aka sm-t520 and I could really use a bootloader for it so I am eacer to assist any way neccessary. (but i need a little direction because i am a noob)

I'm not familiar with that board. It doesn't seem to be in mainline / have a device tree file in U-Boot or Linux. You may be able to get it to boot just by trying one of the existing configs. If you need to change a device tree file, you could send a patch.

Regards, Simon

Hi Minkyu,

On 25 May 2014 21:15, Minkyu Kang mk7.kang@samsung.com wrote:

Dear Simon,

On 23/05/14 02:27, Simon Glass wrote:

...

Hi Minkyu,

On 21 May 2014 15:20, Minkyu Kang mk7.kang@samsung.com wrote:

...

On 22/05/14 03:58, Simon Glass wrote:

...

Hi Minkyu,

On 21 May 2014 00:05, Minkyu Kang mk7.kang@samsung.com wrote:

...

On 20/05/14 20:47, Simon Glass wrote:

...

Hi Minkyu,

On 15 May 2014 00:51, Minkyu Kang mk7.kang@samsung.com wrote: > On 03/04/14 08:24, 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 >> --- >> >> Changes in v2: >> - Move code to exynos5-dt.c >> - Fix comment style >> - Add #ifdef around tps65090 code >> >> board/samsung/smdk5250/exynos5-dt.c | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c >> index 1a64b9b..2c1cf8a 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; >> @@ -164,7 +165,19 @@ int exynos_power_init(void) >> >> #ifdef CONFIG_POWER_MAX77686 >> ret = max77686_init(); >> + if (ret) >> + return ret; >> #endif >> +#ifdef CONFIG_POWER_TPS65090 >> + /* >> + * The TPS65090 may not be in the device tree. If so, it is not >> + * an error. > > Then, how we can initialise the tps65090?

It is initialised if a suitable node is found in the device tree. If the device tree does not have it, then the hardware is assumed to not have this chip.

then I think, it's an error. Why you said, it is not an error?

I may be misunderstanding your question, but I'll try to answer what I think you are asking.

The device tree contains nodes for hardware in the machine that you want to initialise, and information about each one. Devices can be enabled or disabled by including or removing this information from the device tree (or marking a device disabled with a status = "disabled" property in the node).

The tps65090 chip is not used in all exynos5-dt boards, but is used in some. For example smdk5250 does not have it, but snow does. So we use the device tree to specify the difference, including (on snow) things like the tps65090, the display bridge chip, etc.

Hm, it doesn't make sense. Then it(#define CONFIG_POWER_TPS65090) should go into each config files. Not in exynos5-dt.h. Please modify it and patch 6/12 also.

The way it works at present is that there is a single exynos5-dt.h file which is used by all exynos5 boards. To the extent possible we have avoided putting particular features in things like snow.h and smdk5250.h - they just include exynos5-dt.h without changes.

The idea is that we can have one U-Boot binary that runs on any exynos5 device, rather than lots of different options. This makes it much easier to test changes sine we only need to build it once. If every exynos5 board has different #defines then there are more combinations to build and test. This is similar to what the kernel does with arch/arm/mach-exynos/mach-exynos5-dt.c.

Using this approach the only differences between smdk5250, daisy, snow, spring, etc. are in the device tree. I'd really like to avoid changing this now. It is easy enough for people to add their own private variants of these locally if they want to, but for mainline I believe it is better to be more generic.

I totally understood what you assert. But I can't agree with you. Do you think if we collect all features at exynos5-dt.h then it can be generic? even if some boards doesn't have the device? I think no. It just wrong definition. We should separate exynos5 generic features and board specific features.

Yes my intent is that we have an exynos5 build which (given the right device tree) can support any board. That has been the intent of the device tree effort for a while, and similar to the kernel approach.

What is the objection of having the driver compiled in for a board that doesn't have the device? Is it the extra 1KB of code space for smdk5250 etc.?

Anyway, it doesn't necessarily have to be exynos5-dt.h. If you really don't like that, we could create a new generic exynos5 board and I can target that instead. But I really want to avoid having to build multiple U-Boots for each board if possible.

•   ret = tps65090_init();
  

•   if (ret == 0 || ret == -ENODEV)
  

•           return 0;
  
  

At here.. whatever, the error is an error. If you got NODEV then should return it, because that board does not have device.

Then the caller would need to handle that error. The function is called exynos_power_init(), so I think it should return an error only when it failed to init the power, but in this case there is no problem.

Let me know the best way forward.

Regards, Simon

Hi Minkyu,

On 28 May 2014 07:02, Minkyu Kang mk7.kang@samsung.com wrote:

Dear Simon Glass,

On 27/05/14 09:01, Simon Glass wrote:

...

Hi Minkyu,

On 25 May 2014 21:15, Minkyu Kang mk7.kang@samsung.com wrote:

...

Dear Simon,

On 23/05/14 02:27, Simon Glass wrote:

...

Hi Minkyu,

On 21 May 2014 15:20, Minkyu Kang mk7.kang@samsung.com wrote:

...

On 22/05/14 03:58, Simon Glass wrote:

...

Hi Minkyu,

On 21 May 2014 00:05, Minkyu Kang mk7.kang@samsung.com wrote: > On 20/05/14 20:47, Simon Glass wrote: >> Hi Minkyu, >> >> On 15 May 2014 00:51, Minkyu Kang mk7.kang@samsung.com wrote: >>> On 03/04/14 08:24, 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 >>>> --- >>>> >>>> Changes in v2: >>>> - Move code to exynos5-dt.c >>>> - Fix comment style >>>> - Add #ifdef around tps65090 code >>>> >>>> board/samsung/smdk5250/exynos5-dt.c | 13 +++++++++++++ >>>> 1 file changed, 13 insertions(+) >>>> >>>> diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c >>>> index 1a64b9b..2c1cf8a 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; >>>> @@ -164,7 +165,19 @@ int exynos_power_init(void) >>>> >>>> #ifdef CONFIG_POWER_MAX77686 >>>> ret = max77686_init(); >>>> + if (ret) >>>> + return ret; >>>> #endif >>>> +#ifdef CONFIG_POWER_TPS65090 >>>> + /* >>>> + * The TPS65090 may not be in the device tree. If so, it is not >>>> + * an error. >>> >>> Then, how we can initialise the tps65090? >> >> It is initialised if a suitable node is found in the device tree. If >> the device tree does not have it, then the hardware is assumed to not >> have this chip. > > then I think, it's an error. > Why you said, it is not an error?

I may be misunderstanding your question, but I'll try to answer what I think you are asking.

The device tree contains nodes for hardware in the machine that you want to initialise, and information about each one. Devices can be enabled or disabled by including or removing this information from the device tree (or marking a device disabled with a status = "disabled" property in the node).

The tps65090 chip is not used in all exynos5-dt boards, but is used in some. For example smdk5250 does not have it, but snow does. So we use the device tree to specify the difference, including (on snow) things like the tps65090, the display bridge chip, etc.

Hm, it doesn't make sense. Then it(#define CONFIG_POWER_TPS65090) should go into each config files. Not in exynos5-dt.h. Please modify it and patch 6/12 also.

The way it works at present is that there is a single exynos5-dt.h file which is used by all exynos5 boards. To the extent possible we have avoided putting particular features in things like snow.h and smdk5250.h - they just include exynos5-dt.h without changes.

The idea is that we can have one U-Boot binary that runs on any exynos5 device, rather than lots of different options. This makes it much easier to test changes sine we only need to build it once. If every exynos5 board has different #defines then there are more combinations to build and test. This is similar to what the kernel does with arch/arm/mach-exynos/mach-exynos5-dt.c.

Using this approach the only differences between smdk5250, daisy, snow, spring, etc. are in the device tree. I'd really like to avoid changing this now. It is easy enough for people to add their own private variants of these locally if they want to, but for mainline I believe it is better to be more generic.

I totally understood what you assert. But I can't agree with you. Do you think if we collect all features at exynos5-dt.h then it can be generic? even if some boards doesn't have the device? I think no. It just wrong definition. We should separate exynos5 generic features and board specific features.

Yes my intent is that we have an exynos5 build which (given the right device tree) can support any board. That has been the intent of the device tree effort for a while, and similar to the kernel approach.

What is the objection of having the driver compiled in for a board that doesn't have the device? Is it the extra 1KB of code space for smdk5250 etc.?

Yes, it's a tiny part of binary. But if we allow such things.. then it can be grew more and more.

...

Anyway, it doesn't necessarily have to be exynos5-dt.h. If you really don't like that, we could create a new generic exynos5 board and I can target that instead. But I really want to avoid having to build multiple U-Boots for each board if possible.

I want to define CONFIG_POWER_TPS65090 at snow.h and other each board's config file that have a device. But, I know what you want. So I will merge this patchset. But at future, I'll not allow any exception. It was not right way I think. I just want to keep clean our codes. That's all.

Thanks for being flexible. It is good to get this applied.

I'll take a look at how to improve this to separate out the 'generic' board from the others.

Regards, Simon

On 03/04/14 08:24, Simon Glass wrote:

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

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

Changes in v2:

• Add a device tree node for the snow EDP bridge chip

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

diff --git a/arch/arm/dts/exynos5250-snow.dts b/arch/arm/dts/exynos5250-snow.dts index 42a687b..2a6bc78 100644 --- a/arch/arm/dts/exynos5250-snow.dts +++ b/arch/arm/dts/exynos5250-snow.dts @@ -88,6 +88,19 @@ reg = <0x22>; compatible = "maxim,max98095-codec"; };

• ptn3460-bridge@20 {
  

• 	compatible = "nxp,ptn3460";
  

• 	reg = <0x20>;
  

• 	/*
  

• 	 * TODO(sjg@chromium.org): Exynos GPIOs broken
  

• 	 * powerdown-gpio = <&gpy2 5 0>;
  

• 	 * reset-gpio = <&gpx1 5 0>;
  

• 	 * edid-emulation = <5>;
  

• 	 * pinctrl-names = "default";
  

• 	 * pinctrl-0 = <&ptn3460_gpios>;
  

• 	 */
  

Now you can use GPIOs.

Thanks, Minkyu Kang.

Hi Minkyu,

On 15 May 2014 00:51, Minkyu Kang mk7.kang@samsung.com wrote:

On 03/04/14 08:24, Simon Glass wrote:

...

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

Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Lukasz Majewski l.majewski@samsung.com

---

Changes in v2:

• Only set up the EDP bridge for snow
• Add a device tree compatibility string for the EDP bridge
• Check for EDP failure and print an error in that case
• Return immediately in exynos_backlight_on() if needed

board/samsung/smdk5250/exynos5-dt.c | 103 ++++++++++++++++++++++++++++++++++++ include/fdtdec.h | 1 + lib/fdtdec.c | 1 + 3 files changed, 105 insertions(+)

diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c index 2c1cf8a..73c9a35 100644 --- a/board/samsung/smdk5250/exynos5-dt.c +++ b/board/samsung/smdk5250/exynos5-dt.c @@ -183,6 +183,61 @@ int exynos_power_init(void) #endif /* CONFIG_POWER */

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

please don't use upper case at local variable. If need, please define it.

Done

...

• int num_tries, node;
  

• /*
  

•  * TODO(sjg): Use device tree for GPIOs when exynos GPIO
  

•  * numbering patch is in mainline.
  

•  */
  

• debug("%s\n", __func__);
  

• node = fdtdec_next_compatible(gd->fdt_blob, 0, COMPAT_NXP_PTN3460);
  

• if (node < 0) {
  

•         debug("%s: No node for DP bridge in device tree\n", __func__);
  

•         return -ENODEV;
  

• }
  

• /* 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);
  

seems to need rebase this patch.

Done

...

• /*
  

•  * 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 = @@ -204,4 +259,52 @@ void exynos_set_dp_phy(unsigned int onoff) { set_dp_phy_ctrl(onoff); }

+void exynos_backlight_on(unsigned int onoff)

onoff, then value is 1. is it on or off? How about rename it to "on"?

Done

...

+{

• debug("%s(%u)\n", __func__, onoff);
  

• if (!onoff)
  

•         return;
  

+#ifdef CONFIG_POWER_TPS65090

• struct exynos5_gpio_part1 *gpio1 =
  

•         (struct exynos5_gpio_part1 *)
  

•                         samsung_get_base_gpio_part1();
  

• int ret;
  

• ret = tps65090_fet_enable(1); /* Enable FET1, backlight */
  

• if (ret)
  

•         return;
  

• /* T5 in the LCD timing spec (defined as > 10ms) */
  

• mdelay(10);
  

• /* board_dp_backlight_pwm */
  

• s5p_gpio_direction_output(&gpio1->b2, 0, 1);
  

• /* T6 in the LCD timing spec (defined as > 10ms) */
  

• mdelay(10);
  

• /* board_dp_backlight_en */
  

• s5p_gpio_direction_output(&gpio1->x3, 0, 1);
  

+#endif +}

+void exynos_lcd_power_on(void) +{

• int ret;
  

• debug("%s\n", __func__);
  

+#ifdef CONFIG_POWER_TPS65090

• /* board_dp_lcd_vdd */
  

• tps65090_fet_enable(6); /* Enable FET6, lcd panel */
  

+#endif

• ret = board_dp_bridge_setup();
  

• if (ret && ret != -ENODEV)
  

•         printf("LCD bridge failed to enable: %d\n", ret);
  

+}

#endif diff --git a/include/fdtdec.h b/include/fdtdec.h index 669ab90..ea50d75 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -93,6 +93,7 @@ enum fdt_compat_id { 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_NXP_PTN3460,             /* NXP PTN3460 DP/LVDS bridge */
  
  COMPAT_COUNT,
  

}; diff --git a/lib/fdtdec.c b/lib/fdtdec.c index e15e0ad..13e3f45 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -66,6 +66,7 @@ static const char * const compat_names[COMPAT_COUNT] = { COMPAT(SANDBOX_HOST_EMULATION, "sandbox,host-emulation"), COMPAT(SANDBOX_LCD_SDL, "sandbox,lcd-sdl"), COMPAT(TI_TPS65090, "ti,tps65090"),

• COMPAT(COMPAT_NXP_PTN3460, "nxp,ptn3460"),
  

};

const char *fdtdec_get_compatible(enum fdt_compat_id id)

Regards, Simon