Enable LCD display on snow

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.

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

Signed-off-by Tom Wai-Hong Tam <[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]>

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

---

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

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

new file mode 100644
index 0000000..8e5e0d3
@@ -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;
+	};

doc/device-tree-bindings/regulator/tps65090.txt new file +122 -0

new file mode 100644
index 0000000..313a60b
@@ -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 at 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;
+			};
+		};
+	};

drivers/power/pmic/Makefile +1 -0

index 4129bda..3244f69 100644
@@ -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

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

new file mode 100644
index 0000000..8558b43
@@ -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,
+

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

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

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

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

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

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

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

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

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

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

include/fdtdec.h +1 -0

index 3196cf6..669ab90 100644
@@ -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,
 };

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

new file mode 100644
index 0000000..dcf99c9
@@ -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_
+

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

index 33265ec..e15e0ad 100644

Quoted 48 lines · Simon Glass

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.

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

Signed-off-by Tom Wai-Hong Tam <[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]>

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

---

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

Quoted 46 lines

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

new file mode 100644
index 0000000..8558b43
@@ -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 */

drivers/power/pmic/pmic_tps65090.c line 46

Quoted 6 lines

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

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

Quoted 53 lines

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

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

drivers/power/pmic/pmic_tps65090.c line 104

Quoted 6 lines

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

+             mdelay(1);
+     }
+
+     debug("FET %d: Power good should have set to %d but reg=%#02x\n",
+           fet_id, set, reg);
+     return -EAGAIN;

EAGAIN? why?

Quoted 39 lines

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

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

drivers/power/pmic/pmic_tps65090.c line 147

Quoted 5 lines

drivers/power/pmic/pmic_tps65090.c new file +5 -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
+      * 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.

drivers/power/pmic/pmic_tps65090.c line 149

Quoted 3 lines

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

+     if (ret == -EAGAIN)
+             ret = 0;

It looks weird.

Quoted 49 lines

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

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

drivers/power/pmic/pmic_tps65090.c line 207

Quoted 10 lines

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

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

Quoted 42 lines

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

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

drivers/power/pmic/pmic_tps65090.c line 258

Quoted 10 lines

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

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

drivers/power/pmic/pmic_tps65090.c line 64

Quoted 3 lines

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

+}
+
+

please remove extra blank line.

drivers/power/pmic/pmic_tps65090.c line 272

Quoted 12 lines

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

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

Quoted 72 lines

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

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

include/fdtdec.h +1 -0

index 3196cf6..669ab90 100644
@@ -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,
 };

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

new file mode 100644
index 0000000..dcf99c9
@@ -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 {

include/power/tps65090_pmic.h line 19

Quoted 6 lines

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

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

Quoted 66 lines

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

index 33265ec..e15e0ad 100644
@@ -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"),
 };
 

lib/fdtdec.c static const char * const compat_names[COMPAT_COUNT] = { · line 71

Quoted 2 lines

lib/fdtdec.c +0 -0

 const char *fdtdec_get_compatible(enum fdt_compat_id id)

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

---

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

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

index 1a64b9b..2c1cf8a 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;

Quoted 33 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]>

---

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

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

index 1a64b9b..2c1cf8a 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;

@@ -164,7 +165,19 @@ int exynos_power_init(void)
 

board/samsung/smdk5250/exynos5-dt.c int exynos_power_init(void) · line 174

Quoted 9 lines

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

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

board/samsung/smdk5250/exynos5-dt.c int exynos_power_init(void) · line 183

Quoted 11 lines

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

+      */
+     ret = tps65090_init();
+     if (ret == 0 || ret == -ENODEV)
+             return 0;
+#endif
+
      return ret;
 }
 #endif       /* CONFIG_POWER */

Thanks,
Minkyu Kang.

Hi Minkyu,

Quoted 34 lines · Minkyu Kang

Quoted 33 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]>

---

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

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

index 1a64b9b..2c1cf8a 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;

@@ -164,7 +165,19 @@ int exynos_power_init(void)
 

Quoted 11 lines

board/samsung/smdk5250/exynos5-dt.c int exynos_power_init(void) · line 174

Quoted 9 lines

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

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

Quoted 15 lines

board/samsung/smdk5250/exynos5-dt.c int exynos_power_init(void) · line 183

Quoted 12 lines

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

+      */
+     ret = tps65090_init();
+     if (ret == 0 || ret == -ENODEV)
+             return 0;
+#endif
+
      return ret;
 }
 #endif       /* CONFIG_POWER */

Thanks,
Minkyu Kang.

Regards,
Simon

Quoted 49 lines · Simon Glass

Hi Minkyu,

Quoted 45 lines · Minkyu Kang

Quoted 32 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]>

---

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

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

index 1a64b9b..2c1cf8a 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 int exynos_power_init(void) · line 174

Quoted 10 lines

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

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

Quoted 3 lines

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?

Hi Minkyu,

Quoted 50 lines · Minkyu Kang

Quoted 49 lines · Simon Glass

Hi Minkyu,

Quoted 45 lines · Minkyu Kang

Quoted 32 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]>

---

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

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

index 1a64b9b..2c1cf8a 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 int exynos_power_init(void) · line 174

Quoted 10 lines

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

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

Quoted 6 lines

Quoted 3 lines

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.

Quoted 69 lines · Simon Glass

Hi Minkyu,

Quoted 50 lines · Minkyu Kang

Quoted 49 lines · Simon Glass

Hi Minkyu,

Quoted 45 lines · Minkyu Kang

Quoted 32 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]>

---

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

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

index 1a64b9b..2c1cf8a 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 int exynos_power_init(void) · line 174

Quoted 10 lines

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

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

Quoted 6 lines

Quoted 3 lines

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

Quoted 5 lines

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.

Hi Minkyu,

Quoted 71 lines · Minkyu Kang

Quoted 65 lines · Simon Glass

Hi Minkyu,

Quoted 48 lines · Minkyu Kang

Quoted 47 lines · Simon Glass

Hi Minkyu,

Quoted 44 lines · Minkyu Kang

Quoted 32 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]>

---

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

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

index 1a64b9b..2c1cf8a 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 int exynos_power_init(void) · line 174

Quoted 10 lines

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

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

Quoted 5 lines

Quoted 3 lines

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

Quoted 5 lines

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.

Quoted 4 lines

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

Quoted 111 lines · Simon Glass

Hi Minkyu,

Quoted 84 lines · Minkyu Kang

Quoted 77 lines · Simon Glass

Hi Minkyu,

Quoted 57 lines · Minkyu Kang

Quoted 55 lines · Simon Glass

Hi Minkyu,

Quoted 50 lines · Minkyu Kang

Quoted 44 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]>

---

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

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

index 1a64b9b..2c1cf8a 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;

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

Quoted 2 lines

not
+ * an error.

Then, how we can initialise the tps65090?

Quoted 6 lines

Quoted 3 lines

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

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 6 lines

Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot at 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)

Hi Minkyu,

Quoted 76 lines · Minkyu Kang

Quoted 69 lines · Simon Glass

Hi Minkyu,

Quoted 50 lines · Minkyu Kang

Quoted 49 lines · Simon Glass

Hi Minkyu,

Quoted 45 lines · Minkyu Kang

Quoted 32 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]>

---

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

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

index 1a64b9b..2c1cf8a 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 int exynos_power_init(void) · line 174

Quoted 10 lines

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

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

Quoted 6 lines

Quoted 3 lines

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

Quoted 5 lines

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.

Quoted 4 lines

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.

Dear Simon,

Quoted 96 lines · Simon Glass

Hi Minkyu,

Quoted 76 lines · Minkyu Kang

Quoted 69 lines · Simon Glass

Hi Minkyu,

Quoted 50 lines · Minkyu Kang

Quoted 49 lines · Simon Glass

Hi Minkyu,

Quoted 45 lines · Minkyu Kang

Quoted 32 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]>

---

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

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

index 1a64b9b..2c1cf8a 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 int exynos_power_init(void) · line 174

Quoted 10 lines

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

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

Quoted 6 lines

Quoted 3 lines

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

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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.

(quoted diff) +3 -0

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

Hi Minkyu,

Quoted 105 lines · Minkyu Kang

Dear Simon,

Quoted 96 lines · Simon Glass

Hi Minkyu,

Quoted 76 lines · Minkyu Kang

Quoted 69 lines · Simon Glass

Hi Minkyu,

Quoted 50 lines · Minkyu Kang

Quoted 49 lines · Simon Glass

Hi Minkyu,

Quoted 45 lines · Minkyu Kang

Quoted 32 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]>

---

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

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

index 1a64b9b..2c1cf8a 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 int exynos_power_init(void) · line 174

Quoted 10 lines

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

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

Quoted 6 lines

Quoted 3 lines

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

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 6 lines

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.

Dear Simon Glass,

Quoted 115 lines · Simon Glass

Hi Minkyu,

Quoted 105 lines · Minkyu Kang

Dear Simon,

Quoted 96 lines · Simon Glass

Hi Minkyu,

Quoted 76 lines · Minkyu Kang

Quoted 69 lines · Simon Glass

Hi Minkyu,

Quoted 50 lines · Minkyu Kang

Quoted 49 lines · Simon Glass

Hi Minkyu,

Quoted 45 lines · Minkyu Kang

Quoted 32 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]>

---

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

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

index 1a64b9b..2c1cf8a 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 int exynos_power_init(void) · line 174

Quoted 10 lines

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

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

Quoted 6 lines

Quoted 3 lines

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

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 6 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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.

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

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

---

Changes in v2: None

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

Quoted 3 lines · Simon Glass

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

now, gpio patch is merged to u-boot-samsung.

Quoted 5 lines

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

---

Quoted 5 lines

Changes in v2: None

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

Thanks,
Minkyu Kang.

Hi Minkyu,

Quoted 1 line · Minkyu Kang

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

Quoted 5 lines

Quoted 3 lines

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

now, gpio patch is merged to u-boot-samsung.

I don't see it in mainline yet, and there are conflicts. But I'll see if I can send a new series.

Quoted 11 lines

Quoted 10 lines

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

---

Changes in v2: None

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

Quoted 3 lines

Thanks,
Minkyu Kang.

Regards,
Simon

Quoted 8 lines · Simon Glass

Hi Minkyu,

Quoted 5 lines · Minkyu Kang

Quoted 3 lines · Simon Glass

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

Quoted 5 lines

Quoted 1 line

now, gpio patch is merged to u-boot-samsung.

I don't see it in mainline yet, and there are conflicts. But I'll see if I can send a new series.

please find this commit (f6ae1ca05839f92b103aaa0743d1d0012ba9773d)

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

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

---

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

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

index 42a687b..2a6bc78 100644
@@ -88,6 +88,19 @@
 			reg = <0x22>;
 			compatible = "maxim,max98095-codec";
 		};
+
+		ptn3460-bridge at 20 {

Quoted 25 lines · Simon Glass

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

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

---

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

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

index 42a687b..2a6bc78 100644
@@ -88,6 +88,19 @@
                      reg = <0x22>;
                      compatible = "maxim,max98095-codec";
              };
+
+             ptn3460-bridge at 20 {
+                     compatible = "nxp,ptn3460";
+                     reg = <0x20>;
+                     /*
+                      * TODO(sjg at chromium.org): Exynos GPIOs broken

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

Quoted 6 lines

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

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

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

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

Reviewed-by Lukasz Majewski <[email protected]>

---

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

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

index 2c1cf8a..73c9a35 100644

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

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

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

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

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

include/fdtdec.h +1 -0

index 669ab90..ea50d75 100644
@@ -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,
 };

lib/fdtdec.c +0 -0

index e15e0ad..13e3f45 100644

Quoted 25 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]>

Reviewed-by Lukasz Majewski <[email protected]>

---

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

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

index 2c1cf8a..73c9a35 100644
@@ -183,6 +183,61 @@ int exynos_power_init(void)
 #endif       /* CONFIG_POWER */
 

board/samsung/smdk5250/exynos5-dt.c int exynos_power_init(void) · line 190

Quoted 6 lines

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

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

Quoted 22 lines

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

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

board/samsung/smdk5250/exynos5-dt.c int exynos_power_init(void) · line 217

Quoted 6 lines

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

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

Quoted 28 lines

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

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

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

Quoted 5 lines

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

 {
      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"?

Quoted 71 lines

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

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

include/fdtdec.h +1 -0

index 669ab90..ea50d75 100644
@@ -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,
 };

lib/fdtdec.c +1 -0

index e15e0ad..13e3f45 100644
@@ -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"),
 };
 

lib/fdtdec.c static const char * const compat_names[COMPAT_COUNT] = { · line 72

Quoted 2 lines

lib/fdtdec.c +0 -0

 const char *fdtdec_get_compatible(enum fdt_compat_id id)