* [U-Boot] [PATCH 01/10] power: Rename CONFIG_PMIC_... to CONFIG_POWER_...
2014-03-26 17:56 [U-Boot] [PATCH 0/10] Enable LCD display on snow Simon Glass
@ 2014-03-26 17:56 ` Simon Glass
2014-03-27 16:32 ` Lukasz Majewski
2014-03-26 17:56 ` [U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip Simon Glass
` (8 subsequent siblings)
9 siblings, 1 reply; 36+ messages in thread
From: Simon Glass @ 2014-03-26 17:56 UTC (permalink / raw)
To: u-boot
Commit be3b51aa did this mostly, but several have been added since. Do the
job again.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
drivers/power/power_fsl.c | 6 +++---
include/configs/arndale.h | 4 ++--
include/configs/exynos5250-dt.h | 2 +-
include/configs/mx25pdk.h | 2 +-
include/configs/mx35pdk.h | 2 +-
include/configs/mx53evk.h | 2 +-
include/configs/mx53loco.h | 2 +-
include/configs/woodburn_common.h | 2 +-
8 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/power/power_fsl.c b/drivers/power/power_fsl.c
index ac0b541..a64161b 100644
--- a/drivers/power/power_fsl.c
+++ b/drivers/power/power_fsl.c
@@ -11,9 +11,9 @@
#include <fsl_pmic.h>
#include <errno.h>
-#if defined(CONFIG_PMIC_FSL_MC13892)
+#if defined(CONFIG_POWER_FSL_MC13892)
#define FSL_PMIC_I2C_LENGTH 3
-#elif defined(CONFIG_PMIC_FSL_MC34704)
+#elif defined(CONFIG_POWER_FSL_MC34704)
#define FSL_PMIC_I2C_LENGTH 1
#endif
@@ -51,7 +51,7 @@ int pmic_init(unsigned char bus)
p->hw.i2c.addr = CONFIG_SYS_FSL_PMIC_I2C_ADDR;
p->hw.i2c.tx_num = FSL_PMIC_I2C_LENGTH;
#else
-#error "You must select CONFIG_POWER_SPI or CONFIG_PMIC_I2C"
+#error "You must select CONFIG_POWER_SPI or CONFIG_POWER_I2C"
#endif
return 0;
diff --git a/include/configs/arndale.h b/include/configs/arndale.h
index 515facf..30ecd45 100644
--- a/include/configs/arndale.h
+++ b/include/configs/arndale.h
@@ -224,8 +224,8 @@
/* PMIC */
#define CONFIG_PMIC
-#define CONFIG_PMIC_I2C
-#define CONFIG_PMIC_MAX77686
+#define CONFIG_POWER_I2C
+#define CONFIG_POWER_MAX77686
#define CONFIG_DEFAULT_DEVICE_TREE exynos5250-arndale
diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index b7ff472..9d1d56a 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -45,7 +45,7 @@
#define CONFIG_SYS_INIT_SP_ADDR CONFIG_IRAM_STACK
/* PMIC */
-#define CONFIG_PMIC_MAX77686
+#define CONFIG_POWER_MAX77686
/* Sound */
#define CONFIG_CMD_SOUND
diff --git a/include/configs/mx25pdk.h b/include/configs/mx25pdk.h
index af6aafa..571d45a 100644
--- a/include/configs/mx25pdk.h
+++ b/include/configs/mx25pdk.h
@@ -106,7 +106,7 @@
#define CONFIG_POWER
#define CONFIG_POWER_I2C
#define CONFIG_POWER_FSL
-#define CONFIG_PMIC_FSL_MC34704
+#define CONFIG_POWER_FSL_MC34704
#define CONFIG_SYS_FSL_PMIC_I2C_ADDR 0x54
#define CONFIG_DOS_PARTITION
diff --git a/include/configs/mx35pdk.h b/include/configs/mx35pdk.h
index 0a46f4c..ab48144 100644
--- a/include/configs/mx35pdk.h
+++ b/include/configs/mx35pdk.h
@@ -52,7 +52,7 @@
#define CONFIG_POWER
#define CONFIG_POWER_I2C
#define CONFIG_POWER_FSL
-#define CONFIG_PMIC_FSL_MC13892
+#define CONFIG_POWER_FSL_MC13892
#define CONFIG_SYS_FSL_PMIC_I2C_ADDR 0x08
#define CONFIG_RTC_MC13XXX
diff --git a/include/configs/mx53evk.h b/include/configs/mx53evk.h
index 3f0d80a..042cdd0 100644
--- a/include/configs/mx53evk.h
+++ b/include/configs/mx53evk.h
@@ -45,7 +45,7 @@
#define CONFIG_POWER_I2C
#define CONFIG_POWER_FSL
#define CONFIG_SYS_FSL_PMIC_I2C_ADDR 8
-#define CONFIG_PMIC_FSL_MC13892
+#define CONFIG_POWER_FSL_MC13892
#define CONFIG_RTC_MC13XXX
/* MMC Configs */
diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index 1415584..365d072 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -80,7 +80,7 @@
#define CONFIG_POWER_I2C
#define CONFIG_DIALOG_POWER
#define CONFIG_POWER_FSL
-#define CONFIG_PMIC_FSL_MC13892
+#define CONFIG_POWER_FSL_MC13892
#define CONFIG_SYS_DIALOG_PMIC_I2C_ADDR 0x48
#define CONFIG_SYS_FSL_PMIC_I2C_ADDR 0x8
diff --git a/include/configs/woodburn_common.h b/include/configs/woodburn_common.h
index 695bc23..259205e 100644
--- a/include/configs/woodburn_common.h
+++ b/include/configs/woodburn_common.h
@@ -55,7 +55,7 @@
#define CONFIG_POWER
#define CONFIG_POWER_I2C
#define CONFIG_POWER_FSL
-#define CONFIG_PMIC_FSL_MC13892
+#define CONFIG_POWER_FSL_MC13892
#define CONFIG_SYS_FSL_PMIC_I2C_ADDR 0x8
#define CONFIG_RTC_MC13XXX
--
1.9.1.423.g4596e3a
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 01/10] power: Rename CONFIG_PMIC_... to CONFIG_POWER_...
2014-03-26 17:56 ` [U-Boot] [PATCH 01/10] power: Rename CONFIG_PMIC_... to CONFIG_POWER_ Simon Glass
@ 2014-03-27 16:32 ` Lukasz Majewski
0 siblings, 0 replies; 36+ messages in thread
From: Lukasz Majewski @ 2014-03-27 16:32 UTC (permalink / raw)
To: u-boot
Hi Simon,
> Commit be3b51aa did this mostly, but several have been added since.
> Do the job again.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> drivers/power/power_fsl.c | 6 +++---
> include/configs/arndale.h | 4 ++--
> include/configs/exynos5250-dt.h | 2 +-
> include/configs/mx25pdk.h | 2 +-
> include/configs/mx35pdk.h | 2 +-
> include/configs/mx53evk.h | 2 +-
> include/configs/mx53loco.h | 2 +-
> include/configs/woodburn_common.h | 2 +-
> 8 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/power/power_fsl.c b/drivers/power/power_fsl.c
> index ac0b541..a64161b 100644
> --- a/drivers/power/power_fsl.c
> +++ b/drivers/power/power_fsl.c
> @@ -11,9 +11,9 @@
> #include <fsl_pmic.h>
> #include <errno.h>
>
> -#if defined(CONFIG_PMIC_FSL_MC13892)
> +#if defined(CONFIG_POWER_FSL_MC13892)
> #define FSL_PMIC_I2C_LENGTH 3
> -#elif defined(CONFIG_PMIC_FSL_MC34704)
> +#elif defined(CONFIG_POWER_FSL_MC34704)
> #define FSL_PMIC_I2C_LENGTH 1
> #endif
>
> @@ -51,7 +51,7 @@ int pmic_init(unsigned char bus)
> p->hw.i2c.addr = CONFIG_SYS_FSL_PMIC_I2C_ADDR;
> p->hw.i2c.tx_num = FSL_PMIC_I2C_LENGTH;
> #else
> -#error "You must select CONFIG_POWER_SPI or CONFIG_PMIC_I2C"
> +#error "You must select CONFIG_POWER_SPI or CONFIG_POWER_I2C"
> #endif
>
> return 0;
> diff --git a/include/configs/arndale.h b/include/configs/arndale.h
> index 515facf..30ecd45 100644
> --- a/include/configs/arndale.h
> +++ b/include/configs/arndale.h
> @@ -224,8 +224,8 @@
>
> /* PMIC */
> #define CONFIG_PMIC
> -#define CONFIG_PMIC_I2C
> -#define CONFIG_PMIC_MAX77686
> +#define CONFIG_POWER_I2C
> +#define CONFIG_POWER_MAX77686
>
> #define CONFIG_DEFAULT_DEVICE_TREE exynos5250-arndale
>
> diff --git a/include/configs/exynos5250-dt.h
> b/include/configs/exynos5250-dt.h index b7ff472..9d1d56a 100644
> --- a/include/configs/exynos5250-dt.h
> +++ b/include/configs/exynos5250-dt.h
> @@ -45,7 +45,7 @@
> #define CONFIG_SYS_INIT_SP_ADDR CONFIG_IRAM_STACK
>
> /* PMIC */
> -#define CONFIG_PMIC_MAX77686
> +#define CONFIG_POWER_MAX77686
>
> /* Sound */
> #define CONFIG_CMD_SOUND
> diff --git a/include/configs/mx25pdk.h b/include/configs/mx25pdk.h
> index af6aafa..571d45a 100644
> --- a/include/configs/mx25pdk.h
> +++ b/include/configs/mx25pdk.h
> @@ -106,7 +106,7 @@
> #define CONFIG_POWER
> #define CONFIG_POWER_I2C
> #define CONFIG_POWER_FSL
> -#define CONFIG_PMIC_FSL_MC34704
> +#define CONFIG_POWER_FSL_MC34704
> #define CONFIG_SYS_FSL_PMIC_I2C_ADDR 0x54
>
> #define CONFIG_DOS_PARTITION
> diff --git a/include/configs/mx35pdk.h b/include/configs/mx35pdk.h
> index 0a46f4c..ab48144 100644
> --- a/include/configs/mx35pdk.h
> +++ b/include/configs/mx35pdk.h
> @@ -52,7 +52,7 @@
> #define CONFIG_POWER
> #define CONFIG_POWER_I2C
> #define CONFIG_POWER_FSL
> -#define CONFIG_PMIC_FSL_MC13892
> +#define CONFIG_POWER_FSL_MC13892
> #define CONFIG_SYS_FSL_PMIC_I2C_ADDR 0x08
> #define CONFIG_RTC_MC13XXX
>
> diff --git a/include/configs/mx53evk.h b/include/configs/mx53evk.h
> index 3f0d80a..042cdd0 100644
> --- a/include/configs/mx53evk.h
> +++ b/include/configs/mx53evk.h
> @@ -45,7 +45,7 @@
> #define CONFIG_POWER_I2C
> #define CONFIG_POWER_FSL
> #define CONFIG_SYS_FSL_PMIC_I2C_ADDR 8
> -#define CONFIG_PMIC_FSL_MC13892
> +#define CONFIG_POWER_FSL_MC13892
> #define CONFIG_RTC_MC13XXX
>
> /* MMC Configs */
> diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
> index 1415584..365d072 100644
> --- a/include/configs/mx53loco.h
> +++ b/include/configs/mx53loco.h
> @@ -80,7 +80,7 @@
> #define CONFIG_POWER_I2C
> #define CONFIG_DIALOG_POWER
> #define CONFIG_POWER_FSL
> -#define CONFIG_PMIC_FSL_MC13892
> +#define CONFIG_POWER_FSL_MC13892
> #define CONFIG_SYS_DIALOG_PMIC_I2C_ADDR 0x48
> #define CONFIG_SYS_FSL_PMIC_I2C_ADDR 0x8
>
> diff --git a/include/configs/woodburn_common.h
> b/include/configs/woodburn_common.h index 695bc23..259205e 100644
> --- a/include/configs/woodburn_common.h
> +++ b/include/configs/woodburn_common.h
> @@ -55,7 +55,7 @@
> #define CONFIG_POWER
> #define CONFIG_POWER_I2C
> #define CONFIG_POWER_FSL
> -#define CONFIG_PMIC_FSL_MC13892
> +#define CONFIG_POWER_FSL_MC13892
> #define CONFIG_SYS_FSL_PMIC_I2C_ADDR 0x8
> #define CONFIG_RTC_MC13XXX
>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.
2014-03-26 17:56 [U-Boot] [PATCH 0/10] Enable LCD display on snow Simon Glass
2014-03-26 17:56 ` [U-Boot] [PATCH 01/10] power: Rename CONFIG_PMIC_... to CONFIG_POWER_ Simon Glass
@ 2014-03-26 17:56 ` Simon Glass
2014-03-27 17:59 ` Lukasz Majewski
2014-03-26 17:56 ` [U-Boot] [PATCH 03/10] exynos5: Enable tps65090 on smdk5250 Simon Glass
` (7 subsequent siblings)
9 siblings, 1 reply; 36+ messages in thread
From: Simon Glass @ 2014-03-26 17:56 UTC (permalink / raw)
To: u-boot
From: Tom Wai-Hong Tam <waihong@chromium.org>
This adds driver support for the TPS65090 PMU. Support includes
hooking into the pmic infrastructure so that the pmic commands
can be used on the console. The TPS65090 supports the following
functionality:
- fet enable/disable/querying
- getting and setting of charge state
Even though it is connected to the pmic infrastructure it does
not hook into the pmic charging charging infrastructure.
Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org>
Signed-off-by: Rong Chang <rongchang@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
---
doc/device-tree-bindings/power/tps65090.txt | 21 ++
drivers/power/pmic/Makefile | 1 +
drivers/power/pmic/pmic_tps65090.c | 296 ++++++++++++++++++++++++++++
include/fdtdec.h | 1 +
include/power/tps65090_pmic.h | 83 ++++++++
lib/fdtdec.c | 1 +
6 files changed, 403 insertions(+)
create mode 100644 doc/device-tree-bindings/power/tps65090.txt
create mode 100644 drivers/power/pmic/pmic_tps65090.c
create mode 100644 include/power/tps65090_pmic.h
diff --git a/doc/device-tree-bindings/power/tps65090.txt b/doc/device-tree-bindings/power/tps65090.txt
new file mode 100644
index 0000000..6a8a884
--- /dev/null
+++ b/doc/device-tree-bindings/power/tps65090.txt
@@ -0,0 +1,21 @@
+TPSchrome binding
+=================
+
+The device tree node which describes the operation of the Texas Instrument
+TPS65090 power regulator chip is as follows:
+
+Required properties :
+- compatible : "ti,tps65090"
+- reg : slave address on the i2c bus
+
+The tps65090 node should appear as a subnode of the i2c bus that connects it.
+
+Example
+=======
+
+ i2c at 12ca0000 {
+ power-regulator at 48 {
+ compatible = "ti,tps65090"
+ reg = <0x48>;
+ };
+ };
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 0b45ffa..7ed55e6 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -9,5 +9,6 @@ obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
+obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
diff --git a/drivers/power/pmic/pmic_tps65090.c b/drivers/power/pmic/pmic_tps65090.c
new file mode 100644
index 0000000..ef9f911
--- /dev/null
+++ b/drivers/power/pmic/pmic_tps65090.c
@@ -0,0 +1,296 @@
+/*
+ * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ */
+
+#include <common.h>
+#include <errno.h>
+#include <fdtdec.h>
+#include <i2c.h>
+#include <power/pmic.h>
+#include <power/tps65090_pmic.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define TPS65090_NAME "TPS65090_PMIC"
+
+/* TPS65090 register addresses */
+enum {
+ REG_CG_CTRL0 = 4,
+ REG_CG_STATUS1 = 0xa,
+ REG_FET1_CTRL = 0x0f,
+ REG_FET2_CTRL,
+ REG_FET3_CTRL,
+ REG_FET4_CTRL,
+ REG_FET5_CTRL,
+ REG_FET6_CTRL,
+ REG_FET7_CTRL,
+ TPS65090_NUM_REGS,
+};
+
+enum {
+ CG_CTRL0_ENC_MASK = 0x01,
+
+ MAX_FET_NUM = 7,
+ MAX_CTRL_READ_TRIES = 5,
+
+ /* TPS65090 FET_CTRL register values */
+ FET_CTRL_TOFET = 1 << 7, /* Timeout, startup, overload */
+ FET_CTRL_PGFET = 1 << 4, /* Power good for FET status */
+ FET_CTRL_WAIT = 3 << 2, /* Overcurrent timeout max */
+ FET_CTRL_ADENFET = 1 << 1, /* Enable output auto discharge */
+ FET_CTRL_ENFET = 1 << 0, /* Enable FET */
+};
+
+/**
+ * Checks for a valid FET number
+ *
+ * @param fet_id FET number to check
+ * @return 0 if ok, -1 if FET value is out of range
+ */
+static int tps65090_check_fet(unsigned int fet_id)
+{
+ if (fet_id == 0 || fet_id > MAX_FET_NUM) {
+ debug("parameter fet_id is out of range, %u not in 1 ~ %u\n",
+ fet_id, MAX_FET_NUM);
+ return -1;
+ }
+
+ return 0;
+}
+
+/**
+ * Set the power state for a FET
+ *
+ * @param pmic pmic structure for the tps65090
+ * @param fet_id Fet number to set (1..MAX_FET_NUM)
+ * @param set 1 to power on FET, 0 to power off
+ * @return FET_ERR_COMMS if we got a comms error, FET_ERR_NOT_READY if the
+ * FET failed to change state. If all is ok, returns 0.
+ */
+static int tps65090_fet_set(struct pmic *pmic, int fet_id, int set)
+{
+ int retry;
+ u32 reg, value;
+
+ value = FET_CTRL_ADENFET | FET_CTRL_WAIT;
+ if (set)
+ value |= FET_CTRL_ENFET;
+
+ if (pmic_reg_write(pmic, REG_FET1_CTRL + fet_id - 1, value))
+ return FET_ERR_COMMS;
+ /* Try reading until we get a result */
+ for (retry = 0; retry < MAX_CTRL_READ_TRIES; retry++) {
+ if (pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1, ®))
+ return FET_ERR_COMMS;
+
+ /* Check that the fet went into the expected state */
+ if (!!(reg & FET_CTRL_PGFET) == set)
+ return 0;
+
+ /* If we got a timeout, there is no point in waiting longer */
+ if (reg & FET_CTRL_TOFET)
+ break;
+
+ mdelay(1);
+ }
+
+ debug("FET %d: Power good should have set to %d but reg=%#02x\n",
+ fet_id, set, reg);
+ return FET_ERR_NOT_READY;
+}
+
+int tps65090_fet_enable(unsigned int fet_id)
+{
+ int loops;
+ ulong start;
+ struct pmic *pmic;
+ int ret = 0;
+
+ if (tps65090_check_fet(fet_id))
+ return -1;
+
+ pmic = pmic_get(TPS65090_NAME);
+ if (pmic == NULL)
+ return -1;
+
+ start = get_timer(0);
+ for (loops = 0;; loops++) {
+ ret = tps65090_fet_set(pmic, fet_id, 1);
+ if (!ret)
+ break;
+
+ if (get_timer(start) > 100)
+ break;
+
+ /* Turn it off and try again until we time out */
+ tps65090_fet_set(pmic, fet_id, 0);
+ }
+
+ if (ret) {
+ debug("%s: FET%d failed to power on: time=%lums, loops=%d\n",
+ __func__, fet_id, get_timer(start), loops);
+ } else if (loops) {
+ debug("%s: FET%d powered on after %lums, loops=%d\n",
+ __func__, fet_id, get_timer(start), loops);
+ }
+ /*
+ * Unfortunately, there are some conditions where the power
+ * good bit will be 0, but the fet still comes up. One such
+ * case occurs with the lcd backlight. We'll just return 0 here
+ * and assume that the fet will eventually come up.
+ */
+ if (ret == FET_ERR_NOT_READY)
+ ret = 0;
+
+ return ret;
+}
+
+int tps65090_fet_disable(unsigned int fet_id)
+{
+ int ret;
+ struct pmic *pmic;
+
+ if (tps65090_check_fet(fet_id))
+ return -1;
+
+ pmic = pmic_get(TPS65090_NAME);
+ if (pmic == NULL)
+ return -1;
+ ret = tps65090_fet_set(pmic, fet_id, 0);
+
+ return ret;
+}
+
+int tps65090_fet_is_enabled(unsigned int fet_id)
+{
+ u32 reg;
+ int ret;
+ struct pmic *pmic;
+
+ if (tps65090_check_fet(fet_id))
+ return -1;
+ pmic = pmic_get(TPS65090_NAME);
+ if (pmic == NULL)
+ return -1;
+ ret = pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1, ®);
+ if (ret) {
+ debug("fail to read FET%u_CTRL register over I2C", fet_id);
+ return -2;
+ }
+
+ return reg & FET_CTRL_ENFET;
+}
+
+int tps65090_get_charging(void)
+{
+ u32 val;
+ int ret;
+ struct pmic *pmic;
+
+ pmic = pmic_get(TPS65090_NAME);
+ if (pmic == NULL)
+ return -1;
+ ret = pmic_reg_read(pmic, REG_CG_CTRL0, &val);
+ if (ret)
+ return ret;
+ return val & CG_CTRL0_ENC_MASK ? 1 : 0;
+}
+
+int tps65090_set_charge_enable(int enable)
+{
+ u32 val;
+ int ret;
+ struct pmic *pmic;
+
+ pmic = pmic_get(TPS65090_NAME);
+ if (pmic == NULL)
+ return -1;
+
+ ret = pmic_reg_read(pmic, REG_CG_CTRL0, &val);
+ if (!ret) {
+ if (enable)
+ val |= CG_CTRL0_ENC_MASK;
+ else
+ val &= ~CG_CTRL0_ENC_MASK;
+ ret = pmic_reg_write(pmic, REG_CG_CTRL0, val);
+ }
+ if (ret) {
+ debug("%s: Failed to read/write register\n", __func__);
+ return ret;
+ }
+ return 0;
+}
+
+int tps65090_get_status(void)
+{
+ u32 val;
+ int ret;
+ struct pmic *pmic;
+
+ pmic = pmic_get(TPS65090_NAME);
+
+ if (pmic == NULL)
+ return -1;
+ ret = pmic_reg_read(pmic, REG_CG_STATUS1, &val);
+ if (ret)
+ return ret;
+ return val;
+}
+
+int tps65090_init(void)
+{
+ int bus;
+ int addr;
+ struct pmic *p;
+
+#ifdef CONFIG_OF_CONTROL
+ const void *blob = gd->fdt_blob;
+ int node, parent;
+
+ node = fdtdec_next_compatible(blob, 0, COMPAT_TI_TPS65090);
+ if (node < 0) {
+ debug("PMIC: No node for PMIC Chip in device tree\n");
+ debug("node = %d\n", node);
+ return -ENODEV;
+ }
+
+ parent = fdt_parent_offset(blob, node);
+ if (parent < 0) {
+ debug("%s: Cannot find node parent\n", __func__);
+ return -1;
+ }
+
+ bus = i2c_get_bus_num_fdt(parent);
+ if (p->bus < 0) {
+ debug("%s: Cannot find I2C bus\n", __func__);
+ return -1;
+ }
+ addr = fdtdec_get_int(blob, node, "reg", TPS65090_I2C_ADDR);
+#else
+ bus = CONFIG_POWER_TPS65090_BUS;
+ addr = TPS65090_I2C_ADDR;
+#endif
+ p = pmic_alloc();
+
+ if (!p) {
+ printf("%s: POWER allocation error!\n", __func__);
+ return -ENOMEM;
+ }
+
+ p->name = TPS65090_NAME;
+ p->bus = bus;
+ p->interface = PMIC_I2C;
+ p->number_of_regs = TPS65090_NUM_REGS;
+ p->hw.i2c.addr = addr;
+ p->hw.i2c.tx_num = 1;
+
+ puts("TPS65090 PMIC init\n");
+
+ return 0;
+}
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 6e859ce..8f17ed3 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -90,6 +90,7 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_EXYNOS5_I2C, /* Exynos5 High Speed I2C Controller */
COMPAT_SANDBOX_HOST_EMULATION, /* Sandbox emulation of a function */
COMPAT_SANDBOX_LCD_SDL, /* Sandbox LCD emulation with SDL */
+ COMPAT_TI_TPS65090, /* Texas Instrument TPS65090 */
COMPAT_COUNT,
};
diff --git a/include/power/tps65090_pmic.h b/include/power/tps65090_pmic.h
new file mode 100644
index 0000000..fde30eb
--- /dev/null
+++ b/include/power/tps65090_pmic.h
@@ -0,0 +1,83 @@
+/*
+ * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ */
+
+#ifndef __TPS65090_PMIC_H_
+#define __TPS65090_PMIC_H_
+
+/* I2C device address for TPS65090 PMU */
+#define TPS65090_I2C_ADDR 0x48
+
+enum {
+ /* Status register fields */
+ TPS65090_ST1_OTC = 1 << 0,
+ TPS65090_ST1_OCC = 1 << 1,
+ TPS65090_ST1_STATE_SHIFT = 4,
+ TPS65090_ST1_STATE_MASK = 0xf << TPS65090_ST1_STATE_SHIFT,
+};
+
+/* FET errors */
+enum {
+ FET_ERR_COMMS = -1, /* FET comms error */
+ FET_ERR_NOT_READY = -2, /* FET is not yet ready - retry */
+};
+
+/**
+ * Enable FET
+ *
+ * @param fet_id FET ID, value between 1 and 7
+ * @return 0 on success, non-0 on failure
+ */
+int tps65090_fet_enable(unsigned int fet_id);
+
+/**
+ * Disable FET
+ *
+ * @param fet_id FET ID, value between 1 and 7
+ * @return 0 on success, non-0 on failure
+ */
+int tps65090_fet_disable(unsigned int fet_id);
+
+/**
+ * Is FET enabled?
+ *
+ * @param fet_id FET ID, value between 1 and 7
+ * @return 1 enabled, 0 disabled, negative value on failure
+ */
+int tps65090_fet_is_enabled(unsigned int fet_id);
+
+/**
+ * Enable / disable the battery charger
+ *
+ * @param enable 0 to disable charging, non-zero to enable
+ */
+int tps65090_set_charge_enable(int enable);
+
+/**
+ * Check whether we have enabled battery charging
+ *
+ * @return 1 if enabled, 0 if disabled
+ */
+int tps65090_get_charging(void);
+
+/**
+ * Return the value of the status register
+ *
+ * @return status register value, or -1 on error
+ */
+int tps65090_get_status(void);
+
+/**
+ * Initialize the TPS65090 PMU.
+ *
+ * @return 0 on success, non-0 on failure
+ */
+int tps65090_init(void);
+
+#endif /* __TPS65090_PMIC_H_ */
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index f65ab4f..beee1d0 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -63,6 +63,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_EXYNOS5_I2C, "samsung,exynos5-hsi2c"),
COMPAT(SANDBOX_HOST_EMULATION, "sandbox,host-emulation"),
COMPAT(SANDBOX_LCD_SDL, "sandbox,lcd-sdl"),
+ COMPAT(TI_TPS65090, "ti,tps65090"),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.9.1.423.g4596e3a
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.
2014-03-26 17:56 ` [U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip Simon Glass
@ 2014-03-27 17:59 ` Lukasz Majewski
2014-03-30 0:14 ` Simon Glass
0 siblings, 1 reply; 36+ messages in thread
From: Lukasz Majewski @ 2014-03-27 17:59 UTC (permalink / raw)
To: u-boot
Hi Simon,
> From: Tom Wai-Hong Tam <waihong@chromium.org>
>
> This adds driver support for the TPS65090 PMU. Support includes
> hooking into the pmic infrastructure so that the pmic commands
> can be used on the console. The TPS65090 supports the following
> functionality:
>
> - fet enable/disable/querying
> - getting and setting of charge state
>
> Even though it is connected to the pmic infrastructure it does
> not hook into the pmic charging charging infrastructure.
Can I ask what was the problem with adding support for "pmic bat
[state|charge]" command on this PMIC?
Was the framework unfriendly or there was no need to do that?
>
> Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
> Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org>
> Signed-off-by: Rong Chang <rongchang@chromium.org>
> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
> Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> ---
>
> doc/device-tree-bindings/power/tps65090.txt | 21 ++
> drivers/power/pmic/Makefile | 1 +
> drivers/power/pmic/pmic_tps65090.c | 296
> ++++++++++++++++++++++++++++
> include/fdtdec.h | 1 +
> include/power/tps65090_pmic.h | 83 ++++++++
> lib/fdtdec.c | 1 + 6 files changed,
> 403 insertions(+) create mode 100644
> doc/device-tree-bindings/power/tps65090.txt create mode 100644
> drivers/power/pmic/pmic_tps65090.c create mode 100644
> include/power/tps65090_pmic.h
>
> diff --git a/doc/device-tree-bindings/power/tps65090.txt
> b/doc/device-tree-bindings/power/tps65090.txt new file mode 100644
> index 0000000..6a8a884
> --- /dev/null
> +++ b/doc/device-tree-bindings/power/tps65090.txt
> @@ -0,0 +1,21 @@
> +TPSchrome binding
> +=================
> +
> +The device tree node which describes the operation of the Texas
> Instrument +TPS65090 power regulator chip is as follows:
> +
> +Required properties :
> +- compatible : "ti,tps65090"
> +- reg : slave address on the i2c bus
> +
> +The tps65090 node should appear as a subnode of the i2c bus that
> connects it. +
> +Example
> +=======
> +
> + i2c at 12ca0000 {
> + power-regulator at 48 {
> + compatible = "ti,tps65090"
> + reg = <0x48>;
> + };
> + };
Those bindings look very different from the one at Linux kernel for
this device. Therefore I assume that there was justification to not
stick to the linux kernel DT format.
> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> index 0b45ffa..7ed55e6 100644
> --- a/drivers/power/pmic/Makefile
> +++ b/drivers/power/pmic/Makefile
> @@ -9,5 +9,6 @@ obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
> obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
> obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
> obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
> +obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
> obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
> obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
> diff --git a/drivers/power/pmic/pmic_tps65090.c
> b/drivers/power/pmic/pmic_tps65090.c new file mode 100644
> index 0000000..ef9f911
> --- /dev/null
> +++ b/drivers/power/pmic/pmic_tps65090.c
> @@ -0,0 +1,296 @@
> +/*
> + * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
> + * Use of this source code is governed by a BSD-style license that
> can be
> + * found in the LICENSE file.
> + *
> + * Alternatively, this software may be distributed under the terms
> of the
> + * GNU General Public License ("GPL") version 2 as published by the
> Free
> + * Software Foundation.
Would it be possible to tune this license description to be similar to
SPDX-License-Identifier: GPL-2.0+|BSD
> + */
> +
> +#include <common.h>
> +#include <errno.h>
> +#include <fdtdec.h>
> +#include <i2c.h>
> +#include <power/pmic.h>
> +#include <power/tps65090_pmic.h>
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define TPS65090_NAME "TPS65090_PMIC"
> +
> +/* TPS65090 register addresses */
> +enum {
> + REG_CG_CTRL0 = 4,
> + REG_CG_STATUS1 = 0xa,
> + REG_FET1_CTRL = 0x0f,
> + REG_FET2_CTRL,
> + REG_FET3_CTRL,
> + REG_FET4_CTRL,
> + REG_FET5_CTRL,
> + REG_FET6_CTRL,
> + REG_FET7_CTRL,
> + TPS65090_NUM_REGS,
> +};
> +
> +enum {
> + CG_CTRL0_ENC_MASK = 0x01,
> +
> + MAX_FET_NUM = 7,
> + MAX_CTRL_READ_TRIES = 5,
> +
> + /* TPS65090 FET_CTRL register values */
> + FET_CTRL_TOFET = 1 << 7, /* Timeout, startup,
> overload */
> + FET_CTRL_PGFET = 1 << 4, /* Power good for FET
> status */
> + FET_CTRL_WAIT = 3 << 2, /* Overcurrent timeout max
> */
> + FET_CTRL_ADENFET = 1 << 1, /* Enable output auto
> discharge */
> + FET_CTRL_ENFET = 1 << 0, /* Enable FET */
> +};
> +
> +/**
> + * Checks for a valid FET number
> + *
> + * @param fet_id FET number to check
> + * @return 0 if ok, -1 if FET value is out of range
> + */
> +static int tps65090_check_fet(unsigned int fet_id)
> +{
> + if (fet_id == 0 || fet_id > MAX_FET_NUM) {
> + debug("parameter fet_id is out of range, %u not in 1
> ~ %u\n",
> + fet_id, MAX_FET_NUM);
> + return -1;
In the recent code (like trats/trats2, bugs fixed at existing power
infrastructure) I'm encouraging people to use error descriptions from
<errno.h>, not the -1/-2 values.
Can you fix this globally in this patch?
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * Set the power state for a FET
> + *
> + * @param pmic pmic structure for the tps65090
> + * @param fet_id Fet number to set (1..MAX_FET_NUM)
> + * @param set 1 to power on FET, 0 to power off
> + * @return FET_ERR_COMMS if we got a comms error, FET_ERR_NOT_READY
> if the
> + * FET failed to change state. If all is ok, returns 0.
> + */
> +static int tps65090_fet_set(struct pmic *pmic, int fet_id, int set)
^^^^
maybe
bool
> +{
> + int retry;
> + u32 reg, value;
> +
> + value = FET_CTRL_ADENFET | FET_CTRL_WAIT;
> + if (set)
> + value |= FET_CTRL_ENFET;
> +
> + if (pmic_reg_write(pmic, REG_FET1_CTRL + fet_id - 1, value))
> + return FET_ERR_COMMS;
> + /* Try reading until we get a result */
> + for (retry = 0; retry < MAX_CTRL_READ_TRIES; retry++) {
> + if (pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1,
> ®))
> + return FET_ERR_COMMS;
> +
> + /* Check that the fet went into the expected state */
> + if (!!(reg & FET_CTRL_PGFET) == set)
> + return 0;
> +
> + /* If we got a timeout, there is no point in waiting
> longer */
> + if (reg & FET_CTRL_TOFET)
> + break;
> +
> + mdelay(1);
> + }
> +
> + debug("FET %d: Power good should have set to %d but
> reg=%#02x\n",
> + fet_id, set, reg);
> + return FET_ERR_NOT_READY;
> +}
> +
> +int tps65090_fet_enable(unsigned int fet_id)
> +{
> + int loops;
> + ulong start;
> + struct pmic *pmic;
> + int ret = 0;
> +
> + if (tps65090_check_fet(fet_id))
> + return -1;
As I've described above - maybe -ENODEV?
> +
> + pmic = pmic_get(TPS65090_NAME);
> + if (pmic == NULL)
It seems like in the code I tend to use:
if (!pmic)
> + return -1;
> +
> + start = get_timer(0);
> + for (loops = 0;; loops++) {
> + ret = tps65090_fet_set(pmic, fet_id, 1);
> + if (!ret)
> + break;
> +
> + if (get_timer(start) > 100)
> + break;
> +
> + /* Turn it off and try again until we time out */
> + tps65090_fet_set(pmic, fet_id, 0);
> + }
> +
> + if (ret) {
> + debug("%s: FET%d failed to power on: time=%lums,
> loops=%d\n",
> + __func__, fet_id, get_timer(start), loops);
> + } else if (loops) {
> + debug("%s: FET%d powered on after %lums, loops=%d\n",
> + __func__, fet_id, get_timer(start), loops);
> + }
Here the parenthesis can be omitted.
> + /*
> + * Unfortunately, there are some conditions where the power
> + * good bit will be 0, but the fet still comes up. One such
> + * case occurs with the lcd backlight. We'll just return 0
> here
> + * and assume that the fet will eventually come up.
> + */
> + if (ret == FET_ERR_NOT_READY)
> + ret = 0;
> +
> + return ret;
> +}
> +
> +int tps65090_fet_disable(unsigned int fet_id)
> +{
> + int ret;
> + struct pmic *pmic;
> +
> + if (tps65090_check_fet(fet_id))
> + return -1;
> +
> + pmic = pmic_get(TPS65090_NAME);
> + if (pmic == NULL)
> + return -1;
> + ret = tps65090_fet_set(pmic, fet_id, 0);
> +
> + return ret;
> +}
> +
> +int tps65090_fet_is_enabled(unsigned int fet_id)
> +{
> + u32 reg;
> + int ret;
> + struct pmic *pmic;
> +
> + if (tps65090_check_fet(fet_id))
> + return -1;
> + pmic = pmic_get(TPS65090_NAME);
> + if (pmic == NULL)
> + return -1;
> + ret = pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1, ®);
> + if (ret) {
> + debug("fail to read FET%u_CTRL register over I2C",
> fet_id);
> + return -2;
> + }
> +
> + return reg & FET_CTRL_ENFET;
> +}
> +
> +int tps65090_get_charging(void)
> +{
> + u32 val;
> + int ret;
> + struct pmic *pmic;
> +
> + pmic = pmic_get(TPS65090_NAME);
> + if (pmic == NULL)
> + return -1;
> + ret = pmic_reg_read(pmic, REG_CG_CTRL0, &val);
> + if (ret)
> + return ret;
> + return val & CG_CTRL0_ENC_MASK ? 1 : 0;
> +}
> +
> +int tps65090_set_charge_enable(int enable)
This can be easily added to be used at "pmic bat charge" command.
Please look into the ./drivers/power/mfd/pmic_max77693.c
> +{
> + u32 val;
> + int ret;
> + struct pmic *pmic;
> +
> + pmic = pmic_get(TPS65090_NAME);
> + if (pmic == NULL)
> + return -1;
> +
> + ret = pmic_reg_read(pmic, REG_CG_CTRL0, &val);
> + if (!ret) {
> + if (enable)
> + val |= CG_CTRL0_ENC_MASK;
> + else
> + val &= ~CG_CTRL0_ENC_MASK;
> + ret = pmic_reg_write(pmic, REG_CG_CTRL0, val);
> + }
> + if (ret) {
> + debug("%s: Failed to read/write register\n",
> __func__);
> + return ret;
> + }
> + return 0;
> +}
> +
> +int tps65090_get_status(void)
> +{
> + u32 val;
> + int ret;
> + struct pmic *pmic;
> +
> + pmic = pmic_get(TPS65090_NAME);
> +
> + if (pmic == NULL)
> + return -1;
> + ret = pmic_reg_read(pmic, REG_CG_STATUS1, &val);
> + if (ret)
> + return ret;
> + return val;
> +}
> +
> +int tps65090_init(void)
> +{
> + int bus;
> + int addr;
> + struct pmic *p;
> +
> +#ifdef CONFIG_OF_CONTROL
> + const void *blob = gd->fdt_blob;
> + int node, parent;
> +
> + node = fdtdec_next_compatible(blob, 0, COMPAT_TI_TPS65090);
> + if (node < 0) {
> + debug("PMIC: No node for PMIC Chip in device tree\n");
> + debug("node = %d\n", node);
> + return -ENODEV;
> + }
> +
> + parent = fdt_parent_offset(blob, node);
> + if (parent < 0) {
> + debug("%s: Cannot find node parent\n", __func__);
> + return -1;
> + }
> +
> + bus = i2c_get_bus_num_fdt(parent);
> + if (p->bus < 0) {
> + debug("%s: Cannot find I2C bus\n", __func__);
> + return -1;
> + }
> + addr = fdtdec_get_int(blob, node, "reg", TPS65090_I2C_ADDR);
> +#else
> + bus = CONFIG_POWER_TPS65090_BUS;
> + addr = TPS65090_I2C_ADDR;
> +#endif
> + p = pmic_alloc();
> +
> + if (!p) {
> + printf("%s: POWER allocation error!\n", __func__);
> + return -ENOMEM;
> + }
> +
> + p->name = TPS65090_NAME;
> + p->bus = bus;
> + p->interface = PMIC_I2C;
> + p->number_of_regs = TPS65090_NUM_REGS;
> + p->hw.i2c.addr = addr;
> + p->hw.i2c.tx_num = 1;
> +
> + puts("TPS65090 PMIC init\n");
> +
> + return 0;
> +}
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 6e859ce..8f17ed3 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -90,6 +90,7 @@ enum fdt_compat_id {
> COMPAT_SAMSUNG_EXYNOS5_I2C, /* Exynos5 High Speed I2C
> Controller */ COMPAT_SANDBOX_HOST_EMULATION, /* Sandbox emulation of
> a function */ COMPAT_SANDBOX_LCD_SDL, /* Sandbox LCD
> emulation with SDL */
> + COMPAT_TI_TPS65090, /* Texas Instrument TPS65090
> */
>
> COMPAT_COUNT,
> };
> diff --git a/include/power/tps65090_pmic.h
> b/include/power/tps65090_pmic.h new file mode 100644
> index 0000000..fde30eb
> --- /dev/null
> +++ b/include/power/tps65090_pmic.h
> @@ -0,0 +1,83 @@
> +/*
> + * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
> + * Use of this source code is governed by a BSD-style license that
> can be
> + * found in the LICENSE file.
> + *
> + * Alternatively, this software may be distributed under the terms
> of the
> + * GNU General Public License ("GPL") version 2 as published by the
> Free
> + * Software Foundation.
> + */
> +
> +#ifndef __TPS65090_PMIC_H_
> +#define __TPS65090_PMIC_H_
> +
> +/* I2C device address for TPS65090 PMU */
> +#define TPS65090_I2C_ADDR 0x48
> +
> +enum {
> + /* Status register fields */
> + TPS65090_ST1_OTC = 1 << 0,
> + TPS65090_ST1_OCC = 1 << 1,
> + TPS65090_ST1_STATE_SHIFT = 4,
> + TPS65090_ST1_STATE_MASK = 0xf << TPS65090_ST1_STATE_SHIFT,
> +};
> +
> +/* FET errors */
> +enum {
> + FET_ERR_COMMS = -1, /* FET comms error */
> + FET_ERR_NOT_READY = -2, /* FET is not yet ready -
> retry */ +};
> +
> +/**
> + * Enable FET
> + *
> + * @param fet_id FET ID, value between 1 and 7
> + * @return 0 on success, non-0 on failure
> + */
> +int tps65090_fet_enable(unsigned int fet_id);
> +
> +/**
> + * Disable FET
> + *
> + * @param fet_id FET ID, value between 1 and 7
> + * @return 0 on success, non-0 on failure
> + */
> +int tps65090_fet_disable(unsigned int fet_id);
> +
> +/**
> + * Is FET enabled?
> + *
> + * @param fet_id FET ID, value between 1 and 7
> + * @return 1 enabled, 0 disabled, negative value on failure
> + */
> +int tps65090_fet_is_enabled(unsigned int fet_id);
> +
> +/**
> + * Enable / disable the battery charger
> + *
> + * @param enable 0 to disable charging, non-zero to enable
> + */
> +int tps65090_set_charge_enable(int enable);
> +
> +/**
> + * Check whether we have enabled battery charging
> + *
> + * @return 1 if enabled, 0 if disabled
> + */
> +int tps65090_get_charging(void);
> +
> +/**
> + * Return the value of the status register
> + *
> + * @return status register value, or -1 on error
> + */
> +int tps65090_get_status(void);
> +
> +/**
> + * Initialize the TPS65090 PMU.
> + *
> + * @return 0 on success, non-0 on failure
> + */
> +int tps65090_init(void);
> +
> +#endif /* __TPS65090_PMIC_H_ */
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index f65ab4f..beee1d0 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -63,6 +63,7 @@ static const char * const
> compat_names[COMPAT_COUNT] = { COMPAT(SAMSUNG_EXYNOS5_I2C,
> "samsung,exynos5-hsi2c"), COMPAT(SANDBOX_HOST_EMULATION,
> "sandbox,host-emulation"), COMPAT(SANDBOX_LCD_SDL, "sandbox,lcd-sdl"),
> + COMPAT(TI_TPS65090, "ti,tps65090"),
> };
>
> const char *fdtdec_get_compatible(enum fdt_compat_id id)
> --
> 1.9.1.423.g4596e3a
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.
2014-03-27 17:59 ` Lukasz Majewski
@ 2014-03-30 0:14 ` Simon Glass
2014-03-31 14:33 ` Lukasz Majewski
0 siblings, 1 reply; 36+ messages in thread
From: Simon Glass @ 2014-03-30 0:14 UTC (permalink / raw)
To: u-boot
Hi Lukasz,
On 27 March 2014 11:59, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Hi Simon,
>
> > From: Tom Wai-Hong Tam <waihong@chromium.org>
> >
> > This adds driver support for the TPS65090 PMU. Support includes
> > hooking into the pmic infrastructure so that the pmic commands
> > can be used on the console. The TPS65090 supports the following
> > functionality:
> >
> > - fet enable/disable/querying
> > - getting and setting of charge state
> >
> > Even though it is connected to the pmic infrastructure it does
> > not hook into the pmic charging charging infrastructure.
>
> Can I ask what was the problem with adding support for "pmic bat
> [state|charge]" command on this PMIC?
>
> Was the framework unfriendly or there was no need to do that?
>
It's not great. I spent a bit of time trying again. It think the issues are:
- no device tree support
- no comments in the pmic.h file so it's hard do know what everything is for
- the battery charging command should really be common, not specific to
each driver
I did actually create a battery system in the Chromium source tree a while
back, but never sent it upstream, partly because the pmic stuff was there
and I was not sure how to get it into that framework.
I think maybe if someone can comment the pmic.h file then I could have
another try. But it would be a separate series to this one, which is
focussed on the LCD, not the battery.
>
> >
> > Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
> > Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org>
> > Signed-off-by: Rong Chang <rongchang@chromium.org>
> > Signed-off-by: Sean Paul <seanpaul@chromium.org>
> > Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
> > Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> > ---
> >
> > doc/device-tree-bindings/power/tps65090.txt | 21 ++
> > drivers/power/pmic/Makefile | 1 +
> > drivers/power/pmic/pmic_tps65090.c | 296
> > ++++++++++++++++++++++++++++
> > include/fdtdec.h | 1 +
> > include/power/tps65090_pmic.h | 83 ++++++++
> > lib/fdtdec.c | 1 + 6 files changed,
> > 403 insertions(+) create mode 100644
> > doc/device-tree-bindings/power/tps65090.txt create mode 100644
> > drivers/power/pmic/pmic_tps65090.c create mode 100644
> > include/power/tps65090_pmic.h
> >
> > diff --git a/doc/device-tree-bindings/power/tps65090.txt
> > b/doc/device-tree-bindings/power/tps65090.txt new file mode 100644
> > index 0000000..6a8a884
> > --- /dev/null
> > +++ b/doc/device-tree-bindings/power/tps65090.txt
> > @@ -0,0 +1,21 @@
> > +TPSchrome binding
> > +=================
> > +
> > +The device tree node which describes the operation of the Texas
> > Instrument +TPS65090 power regulator chip is as follows:
> > +
> > +Required properties :
> > +- compatible : "ti,tps65090"
> > +- reg : slave address on the i2c bus
> > +
> > +The tps65090 node should appear as a subnode of the i2c bus that
> > connects it. +
> > +Example
> > +=======
> > +
> > + i2c at 12ca0000 {
> > + power-regulator at 48 {
> > + compatible = "ti,tps65090"
> > + reg = <0x48>;
> > + };
> > + };
>
> Those bindings look very different from the one at Linux kernel for
> this device. Therefore I assume that there was justification to not
> stick to the linux kernel DT format.
>
Yes they pre-date the kernel. But now that the kernel has support I will
pull those in. For the parts we use it is the same.
>
> > diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> > index 0b45ffa..7ed55e6 100644
> > --- a/drivers/power/pmic/Makefile
> > +++ b/drivers/power/pmic/Makefile
> > @@ -9,5 +9,6 @@ obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
> > obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
> > obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
> > obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
> > +obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
> > obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
> > obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
> > diff --git a/drivers/power/pmic/pmic_tps65090.c
> > b/drivers/power/pmic/pmic_tps65090.c new file mode 100644
> > index 0000000..ef9f911
> > --- /dev/null
> > +++ b/drivers/power/pmic/pmic_tps65090.c
> > @@ -0,0 +1,296 @@
> > +/*
> > + * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
> > + * Use of this source code is governed by a BSD-style license that
> > can be
> > + * found in the LICENSE file.
> > + *
> > + * Alternatively, this software may be distributed under the terms
> > of the
> > + * GNU General Public License ("GPL") version 2 as published by the
> > Free
> > + * Software Foundation.
>
> Would it be possible to tune this license description to be similar to
> SPDX-License-Identifier: GPL-2.0+|BSD
>
Yes, will do.
>
> > + */
> > +
> > +#include <common.h>
> > +#include <errno.h>
> > +#include <fdtdec.h>
> > +#include <i2c.h>
> > +#include <power/pmic.h>
> > +#include <power/tps65090_pmic.h>
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +#define TPS65090_NAME "TPS65090_PMIC"
> > +
> > +/* TPS65090 register addresses */
> > +enum {
> > + REG_CG_CTRL0 = 4,
> > + REG_CG_STATUS1 = 0xa,
> > + REG_FET1_CTRL = 0x0f,
> > + REG_FET2_CTRL,
> > + REG_FET3_CTRL,
> > + REG_FET4_CTRL,
> > + REG_FET5_CTRL,
> > + REG_FET6_CTRL,
> > + REG_FET7_CTRL,
> > + TPS65090_NUM_REGS,
> > +};
> > +
> > +enum {
> > + CG_CTRL0_ENC_MASK = 0x01,
> > +
> > + MAX_FET_NUM = 7,
> > + MAX_CTRL_READ_TRIES = 5,
> > +
> > + /* TPS65090 FET_CTRL register values */
> > + FET_CTRL_TOFET = 1 << 7, /* Timeout, startup,
> > overload */
> > + FET_CTRL_PGFET = 1 << 4, /* Power good for FET
> > status */
> > + FET_CTRL_WAIT = 3 << 2, /* Overcurrent timeout max
> > */
> > + FET_CTRL_ADENFET = 1 << 1, /* Enable output auto
> > discharge */
> > + FET_CTRL_ENFET = 1 << 0, /* Enable FET */
> > +};
> > +
> > +/**
> > + * Checks for a valid FET number
> > + *
> > + * @param fet_id FET number to check
> > + * @return 0 if ok, -1 if FET value is out of range
> > + */
> > +static int tps65090_check_fet(unsigned int fet_id)
> > +{
> > + if (fet_id == 0 || fet_id > MAX_FET_NUM) {
> > + debug("parameter fet_id is out of range, %u not in 1
> > ~ %u\n",
> > + fet_id, MAX_FET_NUM);
> > + return -1;
>
> In the recent code (like trats/trats2, bugs fixed at existing power
> infrastructure) I'm encouraging people to use error descriptions from
> <errno.h>, not the -1/-2 values.
> Can you fix this globally in this patch?
>
Yes good idea.
>
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * Set the power state for a FET
> > + *
> > + * @param pmic pmic structure for the tps65090
> > + * @param fet_id Fet number to set (1..MAX_FET_NUM)
> > + * @param set 1 to power on FET, 0 to power off
> > + * @return FET_ERR_COMMS if we got a comms error, FET_ERR_NOT_READY
> > if the
> > + * FET failed to change state. If all is ok, returns 0.
> > + */
> > +static int tps65090_fet_set(struct pmic *pmic, int fet_id, int set)
> ^^^^
> maybe
> bool
>
> > +{
> > + int retry;
> > + u32 reg, value;
> > +
> > + value = FET_CTRL_ADENFET | FET_CTRL_WAIT;
> > + if (set)
> > + value |= FET_CTRL_ENFET;
> > +
> > + if (pmic_reg_write(pmic, REG_FET1_CTRL + fet_id - 1, value))
> > + return FET_ERR_COMMS;
> > + /* Try reading until we get a result */
> > + for (retry = 0; retry < MAX_CTRL_READ_TRIES; retry++) {
> > + if (pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1,
> > ®))
> > + return FET_ERR_COMMS;
> > +
> > + /* Check that the fet went into the expected state */
> > + if (!!(reg & FET_CTRL_PGFET) == set)
> > + return 0;
> > +
> > + /* If we got a timeout, there is no point in waiting
> > longer */
> > + if (reg & FET_CTRL_TOFET)
> > + break;
> > +
> > + mdelay(1);
> > + }
> > +
> > + debug("FET %d: Power good should have set to %d but
> > reg=%#02x\n",
> > + fet_id, set, reg);
> > + return FET_ERR_NOT_READY;
> > +}
> > +
> > +int tps65090_fet_enable(unsigned int fet_id)
> > +{
> > + int loops;
> > + ulong start;
> > + struct pmic *pmic;
> > + int ret = 0;
> > +
> > + if (tps65090_check_fet(fet_id))
> > + return -1;
>
> As I've described above - maybe -ENODEV?
>
> > +
> > + pmic = pmic_get(TPS65090_NAME);
> > + if (pmic == NULL)
> It seems like in the code I tend to use:
> if (!pmic)
>
OK
>
> > + return -1;
> > +
> > + start = get_timer(0);
> > + for (loops = 0;; loops++) {
> > + ret = tps65090_fet_set(pmic, fet_id, 1);
> > + if (!ret)
> > + break;
> > +
> > + if (get_timer(start) > 100)
> > + break;
> > +
> > + /* Turn it off and try again until we time out */
> > + tps65090_fet_set(pmic, fet_id, 0);
> > + }
> > +
> > + if (ret) {
> > + debug("%s: FET%d failed to power on: time=%lums,
> > loops=%d\n",
> > + __func__, fet_id, get_timer(start), loops);
> > + } else if (loops) {
> > + debug("%s: FET%d powered on after %lums, loops=%d\n",
> > + __func__, fet_id, get_timer(start), loops);
> > + }
>
> Here the parenthesis can be omitted.
>
OK
>
> > + /*
> > + * Unfortunately, there are some conditions where the power
> > + * good bit will be 0, but the fet still comes up. One such
> > + * case occurs with the lcd backlight. We'll just return 0
> > here
> > + * and assume that the fet will eventually come up.
> > + */
> > + if (ret == FET_ERR_NOT_READY)
> > + ret = 0;
> > +
> > + return ret;
> > +}
> > +
> > +int tps65090_fet_disable(unsigned int fet_id)
> > +{
> > + int ret;
> > + struct pmic *pmic;
> > +
> > + if (tps65090_check_fet(fet_id))
> > + return -1;
> > +
> > + pmic = pmic_get(TPS65090_NAME);
> > + if (pmic == NULL)
> > + return -1;
> > + ret = tps65090_fet_set(pmic, fet_id, 0);
> > +
> > + return ret;
> > +}
> > +
> > +int tps65090_fet_is_enabled(unsigned int fet_id)
> > +{
> > + u32 reg;
> > + int ret;
> > + struct pmic *pmic;
> > +
> > + if (tps65090_check_fet(fet_id))
> > + return -1;
> > + pmic = pmic_get(TPS65090_NAME);
> > + if (pmic == NULL)
> > + return -1;
> > + ret = pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1, ®);
> > + if (ret) {
> > + debug("fail to read FET%u_CTRL register over I2C",
> > fet_id);
> > + return -2;
> > + }
> > +
> > + return reg & FET_CTRL_ENFET;
> > +}
> > +
> > +int tps65090_get_charging(void)
> > +{
> > + u32 val;
> > + int ret;
> > + struct pmic *pmic;
> > +
> > + pmic = pmic_get(TPS65090_NAME);
> > + if (pmic == NULL)
> > + return -1;
> > + ret = pmic_reg_read(pmic, REG_CG_CTRL0, &val);
> > + if (ret)
> > + return ret;
> > + return val & CG_CTRL0_ENC_MASK ? 1 : 0;
> > +}
> > +
> > +int tps65090_set_charge_enable(int enable)
>
> This can be easily added to be used at "pmic bat charge" command.
>
> Please look into the ./drivers/power/mfd/pmic_max77693.c
>
Not easily. As mentioned above this is quite a bit of work. For a later
series I think.
Regards,
Simon
^ permalink raw reply [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.
2014-03-30 0:14 ` Simon Glass
@ 2014-03-31 14:33 ` Lukasz Majewski
2014-03-31 17:27 ` Simon Glass
0 siblings, 1 reply; 36+ messages in thread
From: Lukasz Majewski @ 2014-03-31 14:33 UTC (permalink / raw)
To: u-boot
Hi Simon,
> Hi Lukasz,
>
> On 27 March 2014 11:59, Lukasz Majewski <l.majewski@samsung.com>
> wrote: Hi Simon,
>
> > From: Tom Wai-Hong Tam <waihong@chromium.org>
> >
> > This adds driver support for the TPS65090 PMU. Support includes
> > hooking into the pmic infrastructure ?so that the pmic commands
> > can be used on the console. The TPS65090 supports the following
> > functionality:
> >
> > - fet enable/disable/querying
> > - getting and setting of charge state
> >
> > Even though it is connected to the pmic infrastructure it does
> > not hook into the pmic charging charging infrastructure.
>
> Can I ask what was the problem with adding support for "pmic bat
> [state|charge]" command on this PMIC?
>
> Was the framework unfriendly or there was no need to do that?
>
> It's not great. I spent a bit of time trying again. It think the
> issues are:
>
> - no device tree support
> - no comments in the pmic.h file so it's hard do know what everything
> is for
You are right here - the lack of DT support is the main problem here.
As Tom Rini pointed out - it is problematic in this framework to
support more than one instance of the same PMIC device.
I must confess that I've overlooked this use case.
> - the battery charging command should really be common, not specific
> to each driver
I agree. We can try to discuss one solution suitable for Exynos4 and 5.
>
> I did actually create a battery system in the Chromium source tree a
> while back, but never sent it upstream, partly because the pmic stuff
> was there and I was not sure how to get it into that framework.
>
> I think maybe if someone can comment the pmic.h file then I could
> have another try. But it would be a separate series to this one,
> which is focussed on the LCD, not the battery.
For a quick reference please consider Trats and Trats2. If you need any
more help, then please write an e-mail to me.
>
> >
> > Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
> > Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org>
> > Signed-off-by: Rong Chang <rongchang@chromium.org>
> > Signed-off-by: Sean Paul <seanpaul@chromium.org>
> > Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
> > Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> > ---
> >
> > ?doc/device-tree-bindings/power/tps65090.txt | ?21 ++
> > ?drivers/power/pmic/Makefile ? ? ? ? ? ? ? ? | ? 1 +
> > ?drivers/power/pmic/pmic_tps65090.c ? ? ? ? ?| 296
> > ++++++++++++++++++++++++++++
> > include/fdtdec.h ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 1 +
> > include/power/tps65090_pmic.h ? ? ? ? ? ? ? | ?83 ++++++++
> > lib/fdtdec.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 1 + 6 files changed,
> > 403 insertions(+) create mode 100644
> > doc/device-tree-bindings/power/tps65090.txt create mode 100644
> > drivers/power/pmic/pmic_tps65090.c create mode 100644
> > include/power/tps65090_pmic.h
> >
> > diff --git a/doc/device-tree-bindings/power/tps65090.txt
> > b/doc/device-tree-bindings/power/tps65090.txt new file mode 100644
> > index 0000000..6a8a884
> > --- /dev/null
> > +++ b/doc/device-tree-bindings/power/tps65090.txt
> > @@ -0,0 +1,21 @@
> > +TPSchrome binding
> > +=================
> > +
> > +The device tree node which describes the operation of the Texas
> > Instrument +TPS65090 power regulator chip is as follows:
> > +
> > +Required properties :
> > +- compatible : "ti,tps65090"
> > +- reg : slave address on the i2c bus
> > +
> > +The tps65090 node should appear as a subnode of the i2c bus that
> > connects it. +
> > +Example
> > +=======
> > +
> > + ? ? ? i2c at 12ca0000 {
> > + ? ? ? ? ? ? ? power-regulator at 48 {
> > + ? ? ? ? ? ? ? ? ? ? ? compatible = "ti,tps65090"
> > + ? ? ? ? ? ? ? ? ? ? ? reg = <0x48>;
> > + ? ? ? ? ? ? ? };
> > + ? ? ? };
>
> Those bindings look very different from the one at Linux kernel for
> this device. Therefore I assume that there was justification to not
> stick to the linux kernel DT format.
>
> Yes they pre-date the kernel. But now that the kernel has support I
> will pull those in. For the parts we use it is the same.
That would be great, thanks.
>
> > diff --git a/drivers/power/pmic/Makefile
> > b/drivers/power/pmic/Makefile index 0b45ffa..7ed55e6 100644
> > --- a/drivers/power/pmic/Makefile
> > +++ b/drivers/power/pmic/Makefile
> > @@ -9,5 +9,6 @@ obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
> > ?obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
> > ?obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
> > ?obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
> > +obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
> > ?obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
> > ?obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
> > diff --git a/drivers/power/pmic/pmic_tps65090.c
> > b/drivers/power/pmic/pmic_tps65090.c new file mode 100644
> > index 0000000..ef9f911
> > --- /dev/null
> > +++ b/drivers/power/pmic/pmic_tps65090.c
> > @@ -0,0 +1,296 @@
> > +/*
> > + * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
> > + * Use of this source code is governed by a BSD-style license that
> > can be
> > + * found in the LICENSE file.
> > + *
> > + * Alternatively, this software may be distributed under the terms
> > of the
> > + * GNU General Public License ("GPL") version 2 as published by the
> > Free
> > + * Software Foundation.
>
> Would it be possible to tune this license description to be similar to
> SPDX-License-Identifier: ? ? ? ?GPL-2.0+|BSD
>
> Yes, will do.
> ?
>
> > + */
> > +
> > +#include <common.h>
> > +#include <errno.h>
> > +#include <fdtdec.h>
> > +#include <i2c.h>
> > +#include <power/pmic.h>
> > +#include <power/tps65090_pmic.h>
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +#define TPS65090_NAME "TPS65090_PMIC"
> > +
> > +/* TPS65090 register addresses */
> > +enum {
> > + ? ? ? REG_CG_CTRL0 = 4,
> > + ? ? ? REG_CG_STATUS1 = 0xa,
> > + ? ? ? REG_FET1_CTRL = 0x0f,
> > + ? ? ? REG_FET2_CTRL,
> > + ? ? ? REG_FET3_CTRL,
> > + ? ? ? REG_FET4_CTRL,
> > + ? ? ? REG_FET5_CTRL,
> > + ? ? ? REG_FET6_CTRL,
> > + ? ? ? REG_FET7_CTRL,
> > + ? ? ? TPS65090_NUM_REGS,
> > +};
> > +
> > +enum {
> > + ? ? ? CG_CTRL0_ENC_MASK ? ? ? = 0x01,
> > +
> > + ? ? ? MAX_FET_NUM ? ? = 7,
> > + ? ? ? MAX_CTRL_READ_TRIES = 5,
> > +
> > + ? ? ? /* TPS65090 FET_CTRL register values */
> > + ? ? ? FET_CTRL_TOFET ? ? ? ? ?= 1 << 7, ?/* Timeout, startup,
> > overload */
> > + ? ? ? FET_CTRL_PGFET ? ? ? ? ?= 1 << 4, ?/* Power good for FET
> > status */
> > + ? ? ? FET_CTRL_WAIT ? ? ? ? ? = 3 << 2, ?/* Overcurrent timeout
> > max */
> > + ? ? ? FET_CTRL_ADENFET ? ? ? ?= 1 << 1, ?/* Enable output auto
> > discharge */
> > + ? ? ? FET_CTRL_ENFET ? ? ? ? ?= 1 << 0, ?/* Enable FET */
> > +};
> > +
> > +/**
> > + * Checks for a valid FET number
> > + *
> > + * @param fet_id ? ? ? FET number to check
> > + * @return 0 if ok, -1 if FET value is out of range
> > + */
> > +static int tps65090_check_fet(unsigned int fet_id)
> > +{
> > + ? ? ? if (fet_id == 0 || fet_id > MAX_FET_NUM) {
> > + ? ? ? ? ? ? ? debug("parameter fet_id is out of range, %u not in 1
> > ~ %u\n",
> > + ? ? ? ? ? ? ? ? ? ? fet_id, MAX_FET_NUM);
> > + ? ? ? ? ? ? ? return -1;
>
> In the recent code (like trats/trats2, bugs fixed at existing power
> infrastructure) I'm encouraging people to use error descriptions from
> <errno.h>, not the -1/-2 values.?
> Can you fix this globally in this patch?
>
> Yes good idea.
> ?
>
> > + ? ? ? }
> > +
> > + ? ? ? return 0;
> > +}
> > +
> > +/**
> > + * Set the power state for a FET
> > + *
> > + * @param pmic ? ? ? ? pmic structure for the tps65090
> > + * @param fet_id ? ? ? Fet number to set (1..MAX_FET_NUM)
> > + * @param set ? ? ? ? ?1 to power on FET, 0 to power off
> > + * @return FET_ERR_COMMS if we got a comms error, FET_ERR_NOT_READY
> > if the
> > + * FET failed to change state. If all is ok, returns 0.
> > + */
> > +static int tps65090_fet_set(struct pmic *pmic, int fet_id, int set)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^^^^
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? maybe
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bool
>
> > +{
> > + ? ? ? int retry;
> > + ? ? ? u32 reg, value;
> > +
> > + ? ? ? value = FET_CTRL_ADENFET | FET_CTRL_WAIT;
> > + ? ? ? if (set)
> > + ? ? ? ? ? ? ? value |= FET_CTRL_ENFET;
> > +
> > + ? ? ? if (pmic_reg_write(pmic, REG_FET1_CTRL + fet_id - 1, value))
> > + ? ? ? ? ? ? ? return FET_ERR_COMMS;
> > + ? ? ? /* Try reading until we get a result */
> > + ? ? ? for (retry = 0; retry < MAX_CTRL_READ_TRIES; retry++) {
> > + ? ? ? ? ? ? ? if (pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1,
> > ®))
> > + ? ? ? ? ? ? ? ? ? ? ? return FET_ERR_COMMS;
> > +
> > + ? ? ? ? ? ? ? /* Check that the fet went into the expected state
> > */
> > + ? ? ? ? ? ? ? if (!!(reg & FET_CTRL_PGFET) == set)
> > + ? ? ? ? ? ? ? ? ? ? ? return 0;
> > +
> > + ? ? ? ? ? ? ? /* If we got a timeout, there is no point in waiting
> > longer */
> > + ? ? ? ? ? ? ? if (reg & FET_CTRL_TOFET)
> > + ? ? ? ? ? ? ? ? ? ? ? break;
> > +
> > + ? ? ? ? ? ? ? mdelay(1);
> > + ? ? ? }
> > +
> > + ? ? ? debug("FET %d: Power good should have set to %d but
> > reg=%#02x\n",
> > + ? ? ? ? ? ? fet_id, set, reg);
> > + ? ? ? return FET_ERR_NOT_READY;
> > +}
> > +
> > +int tps65090_fet_enable(unsigned int fet_id)
> > +{
> > + ? ? ? int loops;
> > + ? ? ? ulong start;
> > + ? ? ? struct pmic *pmic;
> > + ? ? ? int ret = 0;
> > +
> > + ? ? ? if (tps65090_check_fet(fet_id))
> > + ? ? ? ? ? ? ? return -1;
>
> ? ? ? ? ? ? ? ? As I've described above - maybe -ENODEV?
>
> > +
> > + ? ? ? pmic = pmic_get(TPS65090_NAME);
> > + ? ? ? if (pmic == NULL)
> ? ? ? ? ? ? ?It seems like in the code I tend to use:
> ? ? ? ? ? ? ? ? if (!pmic)
>
> OK?
>
> > + ? ? ? ? ? ? ? return -1;
> > +
> > + ? ? ? start = get_timer(0);
> > + ? ? ? for (loops = 0;; loops++) {
> > + ? ? ? ? ? ? ? ret = tps65090_fet_set(pmic, fet_id, 1);
> > + ? ? ? ? ? ? ? if (!ret)
> > + ? ? ? ? ? ? ? ? ? ? ? break;
> > +
> > + ? ? ? ? ? ? ? if (get_timer(start) > 100)
> > + ? ? ? ? ? ? ? ? ? ? ? break;
> > +
> > + ? ? ? ? ? ? ? /* Turn it off and try again until we time out */
> > + ? ? ? ? ? ? ? tps65090_fet_set(pmic, fet_id, 0);
> > + ? ? ? }
> > +
> > + ? ? ? if (ret) {
> > + ? ? ? ? ? ? ? debug("%s: FET%d failed to power on: time=%lums,
> > loops=%d\n",
> > + ? ? ? ? ? ? ? ? ? ? __func__, fet_id, get_timer(start), loops);
> > + ? ? ? } else if (loops) {
> > + ? ? ? ? ? ? ? debug("%s: FET%d powered on after %lums,
> > loops=%d\n",
> > + ? ? ? ? ? ? ? ? ? ? __func__, fet_id, get_timer(start), loops);
> > + ? ? ? }
>
> Here the parenthesis can be omitted.
>
> OK?
>
> > + ? ? ? /*
> > + ? ? ? ?* Unfortunately, there are some conditions where the power
> > + ? ? ? ?* good bit will be 0, but the fet still comes up. One such
> > + ? ? ? ?* case occurs with the lcd backlight. We'll just return 0
> > here
> > + ? ? ? ?* and assume that the fet will eventually come up.
> > + ? ? ? ?*/
> > + ? ? ? if (ret == FET_ERR_NOT_READY)
> > + ? ? ? ? ? ? ? ret = 0;
> > +
> > + ? ? ? return ret;
> > +}
> > +
> > +int tps65090_fet_disable(unsigned int fet_id)
> > +{
> > + ? ? ? int ret;
> > + ? ? ? struct pmic *pmic;
> > +
> > + ? ? ? if (tps65090_check_fet(fet_id))
> > + ? ? ? ? ? ? ? return -1;
> > +
> > + ? ? ? pmic = pmic_get(TPS65090_NAME);
> > + ? ? ? if (pmic == NULL)
> > + ? ? ? ? ? ? ? return -1;
> > + ? ? ? ret = tps65090_fet_set(pmic, fet_id, 0);
> > +
> > + ? ? ? return ret;
> > +}
> > +
> > +int tps65090_fet_is_enabled(unsigned int fet_id)
> > +{
> > + ? ? ? u32 reg;
> > + ? ? ? int ret;
> > + ? ? ? struct pmic *pmic;
> > +
> > + ? ? ? if (tps65090_check_fet(fet_id))
> > + ? ? ? ? ? ? ? return -1;
> > + ? ? ? pmic = pmic_get(TPS65090_NAME);
> > + ? ? ? if (pmic == NULL)
> > + ? ? ? ? ? ? ? return -1;
> > + ? ? ? ret = pmic_reg_read(pmic, REG_FET1_CTRL + fet_id - 1, ®);
> > + ? ? ? if (ret) {
> > + ? ? ? ? ? ? ? debug("fail to read FET%u_CTRL register over I2C",
> > fet_id);
> > + ? ? ? ? ? ? ? return -2;
> > + ? ? ? }
> > +
> > + ? ? ? return reg & FET_CTRL_ENFET;
> > +}
> > +
> > +int tps65090_get_charging(void)
> > +{
> > + ? ? ? u32 val;
> > + ? ? ? int ret;
> > + ? ? ? struct pmic *pmic;
> > +
> > + ? ? ? pmic = pmic_get(TPS65090_NAME);
> > + ? ? ? if (pmic == NULL)
> > + ? ? ? ? ? ? ? return -1;
> > + ? ? ? ret = pmic_reg_read(pmic, REG_CG_CTRL0, &val);
> > + ? ? ? if (ret)
> > + ? ? ? ? ? ? ? return ret;
> > + ? ? ? return val & CG_CTRL0_ENC_MASK ? 1 : 0;
> > +}
> > +
> > +int tps65090_set_charge_enable(int enable)
>
> This can be easily added to be used at "pmic bat charge" command.
>
> Please look into the ./drivers/power/mfd/pmic_max77693.c
>
> Not easily. As mentioned above this is quite a bit of work. For a
> later series I think.
I'm looking forward for questions :-).
> Regards,
> Simon
>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.
2014-03-31 14:33 ` Lukasz Majewski
@ 2014-03-31 17:27 ` Simon Glass
2014-03-31 20:59 ` Lukasz Majewski
0 siblings, 1 reply; 36+ messages in thread
From: Simon Glass @ 2014-03-31 17:27 UTC (permalink / raw)
To: u-boot
Hi Lukasz,
On 31 March 2014 08:33, Lukasz Majewski <l.majewski@samsung.com> wrote:
[snip]
> >
> > This can be easily added to be used at "pmic bat charge" command.
> >
> > Please look into the ./drivers/power/mfd/pmic_max77693.c
> >
> > Not easily. As mentioned above this is quite a bit of work. For a
> > later series I think.
>
> I'm looking forward for questions :-).
>
Do you think you might submit a patch that adds comments to the header
files? That would help a lot.
Also now that driver model is merged, do you think we should try to move
PMICs to that, or would it be a later step?
Regards,
Simon
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.
2014-03-31 17:27 ` Simon Glass
@ 2014-03-31 20:59 ` Lukasz Majewski
0 siblings, 0 replies; 36+ messages in thread
From: Lukasz Majewski @ 2014-03-31 20:59 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Mon, 31 Mar 2014 11:27:11 -0600
Simon Glass <sjg@chromium.org> wrote:
> Hi Lukasz,
>
> On 31 March 2014 08:33, Lukasz Majewski <l.majewski@samsung.com>
> wrote: [snip]
>
>
> > >
> > > This can be easily added to be used at "pmic bat charge" command.
> > >
> > > Please look into the ./drivers/power/mfd/pmic_max77693.c
> > >
> > > Not easily. As mentioned above this is quite a bit of work. For a
> > > later series I think.
> >
> > I'm looking forward for questions :-).
> >
>
> Do you think you might submit a patch that adds comments to the header
> files? That would help a lot.
I will do my best. Up till then would you consider looking at the
following link:
http://u-boot.10912.n7.nabble.com/PATCH-v7-00-26-pmic-Redesign-PMIC-framework-to-support-multiple-instances-of-devices-tt140662.html#none
It should shed some light on the PMIC design.
>
> Also now that driver model is merged, do you think we should try to
> move PMICs to that, or would it be a later step?
PMIC should be integrated with the device model. Also it shall support
DT.
When it will happen depends on the effort needed. Help more than
welcome.
>
> Regards,
> Simon
Best regards,
Lukasz Majewski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140331/0ea8d914/attachment.pgp>
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 03/10] exynos5: Enable tps65090 on smdk5250
2014-03-26 17:56 [U-Boot] [PATCH 0/10] Enable LCD display on snow Simon Glass
2014-03-26 17:56 ` [U-Boot] [PATCH 01/10] power: Rename CONFIG_PMIC_... to CONFIG_POWER_ Simon Glass
2014-03-26 17:56 ` [U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip Simon Glass
@ 2014-03-26 17:56 ` Simon Glass
2014-03-29 22:40 ` Ajay kumar
2014-03-26 17:56 ` [U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus Simon Glass
` (6 subsequent siblings)
9 siblings, 1 reply; 36+ messages in thread
From: Simon Glass @ 2014-03-26 17:56 UTC (permalink / raw)
To: u-boot
From: Aaron Durbin <adurbin@chromium.org>
The TPS65090 pmic chip can be on exynos5250 boards. Therefore,
select the appropriate config option for TPS65090 devices.
This commit should really use exynos5-dt.c, when it is available.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
include/configs/exynos5-dt.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h
index 414db42..fbf09f5 100644
--- a/include/configs/exynos5-dt.h
+++ b/include/configs/exynos5-dt.h
@@ -259,6 +259,7 @@
/* PMIC */
#define CONFIG_POWER
#define CONFIG_POWER_I2C
+#define CONFIG_POWER_TPS65090
/* Ethernet Controllor Driver */
#ifdef CONFIG_CMD_NET
--
1.9.1.423.g4596e3a
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 03/10] exynos5: Enable tps65090 on smdk5250
2014-03-26 17:56 ` [U-Boot] [PATCH 03/10] exynos5: Enable tps65090 on smdk5250 Simon Glass
@ 2014-03-29 22:40 ` Ajay kumar
2014-03-30 0:22 ` Simon Glass
0 siblings, 1 reply; 36+ messages in thread
From: Ajay kumar @ 2014-03-29 22:40 UTC (permalink / raw)
To: u-boot
Hi,
The patch name, kind of gives wrong impression.
There is no TPS65090 device on SMDK5250.
TPS65090 is present only on snow board based on exynos5250.
Please change it!
On Wed, Mar 26, 2014 at 11:26 PM, Simon Glass <sjg@chromium.org> wrote:
> From: Aaron Durbin <adurbin@chromium.org>
>
> The TPS65090 pmic chip can be on exynos5250 boards. Therefore,
> select the appropriate config option for TPS65090 devices.
>
> This commit should really use exynos5-dt.c, when it is available.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> ---
>
> include/configs/exynos5-dt.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h
> index 414db42..fbf09f5 100644
> --- a/include/configs/exynos5-dt.h
> +++ b/include/configs/exynos5-dt.h
> @@ -259,6 +259,7 @@
> /* PMIC */
> #define CONFIG_POWER
> #define CONFIG_POWER_I2C
> +#define CONFIG_POWER_TPS65090
>
> /* Ethernet Controllor Driver */
> #ifdef CONFIG_CMD_NET
> --
> 1.9.1.423.g4596e3a
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
Regards,
Ajay Kumar
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus
2014-03-26 17:56 [U-Boot] [PATCH 0/10] Enable LCD display on snow Simon Glass
` (2 preceding siblings ...)
2014-03-26 17:56 ` [U-Boot] [PATCH 03/10] exynos5: Enable tps65090 on smdk5250 Simon Glass
@ 2014-03-26 17:56 ` Simon Glass
2014-03-27 17:33 ` Lukasz Majewski
2014-03-26 17:56 ` [U-Boot] [PATCH 05/10] exynos5: support tps65090 pmic Simon Glass
` (5 subsequent siblings)
9 siblings, 1 reply; 36+ messages in thread
From: Simon Glass @ 2014-03-26 17:56 UTC (permalink / raw)
To: u-boot
From: Aaron Durbin <adurbin@chromium.org>
The current pmic i2c code assumes the current i2c bus is
the same as the pmic device's bus. There is nothing ensuring
that to be true. Therefore, select the proper bus before performing
a transaction.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
drivers/power/power_i2c.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
index ac76870..594cd11 100644
--- a/drivers/power/power_i2c.c
+++ b/drivers/power/power_i2c.c
@@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
if (check_reg(p, reg))
return -1;
+ I2C_SET_BUS(p->bus);
+
switch (pmic_i2c_tx_num) {
case 3:
if (p->sensor_byte_order == PMIC_SENSOR_BYTE_ORDER_BIG) {
@@ -66,6 +68,8 @@ int pmic_reg_read(struct pmic *p, u32 reg, u32 *val)
if (check_reg(p, reg))
return -1;
+ I2C_SET_BUS(p->bus);
+
if (i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num))
return -1;
--
1.9.1.423.g4596e3a
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus
2014-03-26 17:56 ` [U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus Simon Glass
@ 2014-03-27 17:33 ` Lukasz Majewski
2014-03-30 0:17 ` Simon Glass
0 siblings, 1 reply; 36+ messages in thread
From: Lukasz Majewski @ 2014-03-27 17:33 UTC (permalink / raw)
To: u-boot
Hi Simon, Heiko
> From: Aaron Durbin <adurbin@chromium.org>
>
> The current pmic i2c code assumes the current i2c bus is
> the same as the pmic device's bus. There is nothing ensuring
> that to be true. Therefore, select the proper bus before performing
> a transaction.
>
> Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> ---
>
> drivers/power/power_i2c.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
> index ac76870..594cd11 100644
> --- a/drivers/power/power_i2c.c
> +++ b/drivers/power/power_i2c.c
> @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
> if (check_reg(p, reg))
> return -1;
>
> + I2C_SET_BUS(p->bus);
> +
Hadn't we had a discussion about this explicit setting of I2C some time
ago? I thought that this problem was solved within the I2C rework.
Also I might be wrong, so please correct me if I'm wrong. Isn't the
I2C_SET_BUS() macro regarded as a obsolete after the I2C rework?
> switch (pmic_i2c_tx_num) {
> case 3:
> if (p->sensor_byte_order ==
> PMIC_SENSOR_BYTE_ORDER_BIG) { @@ -66,6 +68,8 @@ int
> pmic_reg_read(struct pmic *p, u32 reg, u32 *val) if (check_reg(p,
> reg)) return -1;
>
> + I2C_SET_BUS(p->bus);
> +
> if (i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num))
> return -1;
>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus
2014-03-27 17:33 ` Lukasz Majewski
@ 2014-03-30 0:17 ` Simon Glass
2014-03-31 5:17 ` Heiko Schocher
2014-03-31 14:36 ` Lukasz Majewski
0 siblings, 2 replies; 36+ messages in thread
From: Simon Glass @ 2014-03-30 0:17 UTC (permalink / raw)
To: u-boot
Hi Lukasz,
On 27 March 2014 11:33, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Hi Simon, Heiko
>
> > From: Aaron Durbin <adurbin@chromium.org>
> >
> > The current pmic i2c code assumes the current i2c bus is
> > the same as the pmic device's bus. There is nothing ensuring
> > that to be true. Therefore, select the proper bus before performing
> > a transaction.
> >
> > Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > Reviewed-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > drivers/power/power_i2c.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
> > index ac76870..594cd11 100644
> > --- a/drivers/power/power_i2c.c
> > +++ b/drivers/power/power_i2c.c
> > @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
> > if (check_reg(p, reg))
> > return -1;
> >
> > + I2C_SET_BUS(p->bus);
> > +
>
> Hadn't we had a discussion about this explicit setting of I2C some time
> ago? I thought that this problem was solved within the I2C rework.
>
> Also I might be wrong, so please correct me if I'm wrong. Isn't the
> I2C_SET_BUS() macro regarded as a obsolete after the I2C rework?
>
Agreed that would be ideal, but we would have to pass the bus number of the
i2c_read/write() functions. I don't believe the i2c code has got that far
yet.
Unfortunately it doesn't work without this patch.
Regards,
Simon
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus
2014-03-30 0:17 ` Simon Glass
@ 2014-03-31 5:17 ` Heiko Schocher
2014-03-31 6:17 ` Lukasz Majewski
2014-03-31 14:36 ` Lukasz Majewski
1 sibling, 1 reply; 36+ messages in thread
From: Heiko Schocher @ 2014-03-31 5:17 UTC (permalink / raw)
To: u-boot
Hello Simon, Lukasz,
Am 30.03.2014 01:17, schrieb Simon Glass:
> Hi Lukasz,
>
> On 27 March 2014 11:33, Lukasz Majewski<l.majewski@samsung.com> wrote:
>
>> Hi Simon, Heiko
>>
>>> From: Aaron Durbin<adurbin@chromium.org>
>>>
>>> The current pmic i2c code assumes the current i2c bus is
>>> the same as the pmic device's bus. There is nothing ensuring
>>> that to be true. Therefore, select the proper bus before performing
>>> a transaction.
>>>
>>> Signed-off-by: Aaron Durbin<adurbin@chromium.org>
>>> Signed-off-by: Simon Glass<sjg@chromium.org>
>>> Reviewed-by: Simon Glass<sjg@chromium.org>
>>> ---
>>>
>>> drivers/power/power_i2c.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
>>> index ac76870..594cd11 100644
>>> --- a/drivers/power/power_i2c.c
>>> +++ b/drivers/power/power_i2c.c
>>> @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
>>> if (check_reg(p, reg))
>>> return -1;
>>>
>>> + I2C_SET_BUS(p->bus);
>>> +
>>
>> Hadn't we had a discussion about this explicit setting of I2C some time
>> ago? I thought that this problem was solved within the I2C rework.
>>
>> Also I might be wrong, so please correct me if I'm wrong. Isn't the
>> I2C_SET_BUS() macro regarded as a obsolete after the I2C rework?
>>
>
> Agreed that would be ideal, but we would have to pass the bus number of the
> i2c_read/write() functions. I don't believe the i2c code has got that far
> yet.
Yes, thats the plan, but first, all i2c driver must be converted to
the new framework. After that we could start with such an approach
(or device model is ready and we can switch to it ...)
> Unfortunately it doesn't work without this patch.
Yes ...
If we have all i2c driver running with the new framework, we can get
rid of I2C_SET_BUS defines, and simply use i2c_set_bus_num() which
is a simple cleanup patch.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus
2014-03-31 5:17 ` Heiko Schocher
@ 2014-03-31 6:17 ` Lukasz Majewski
2014-04-01 4:58 ` Heiko Schocher
0 siblings, 1 reply; 36+ messages in thread
From: Lukasz Majewski @ 2014-03-31 6:17 UTC (permalink / raw)
To: u-boot
Hi Heiko,
> Hello Simon, Lukasz,
>
> Am 30.03.2014 01:17, schrieb Simon Glass:
> > Hi Lukasz,
> >
> > On 27 March 2014 11:33, Lukasz Majewski<l.majewski@samsung.com>
> > wrote:
> >
> >> Hi Simon, Heiko
> >>
> >>> From: Aaron Durbin<adurbin@chromium.org>
> >>>
> >>> The current pmic i2c code assumes the current i2c bus is
> >>> the same as the pmic device's bus. There is nothing ensuring
> >>> that to be true. Therefore, select the proper bus before
> >>> performing a transaction.
> >>>
> >>> Signed-off-by: Aaron Durbin<adurbin@chromium.org>
> >>> Signed-off-by: Simon Glass<sjg@chromium.org>
> >>> Reviewed-by: Simon Glass<sjg@chromium.org>
> >>> ---
> >>>
> >>> drivers/power/power_i2c.c | 4 ++++
> >>> 1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
> >>> index ac76870..594cd11 100644
> >>> --- a/drivers/power/power_i2c.c
> >>> +++ b/drivers/power/power_i2c.c
> >>> @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32
> >>> val) if (check_reg(p, reg))
> >>> return -1;
> >>>
> >>> + I2C_SET_BUS(p->bus);
> >>> +
> >>
> >> Hadn't we had a discussion about this explicit setting of I2C
> >> some time ago? I thought that this problem was solved within the
> >> I2C rework.
> >>
> >> Also I might be wrong, so please correct me if I'm wrong. Isn't the
> >> I2C_SET_BUS() macro regarded as a obsolete after the I2C rework?
> >>
> >
> > Agreed that would be ideal, but we would have to pass the bus
> > number of the i2c_read/write() functions. I don't believe the i2c
> > code has got that far yet.
>
> Yes, thats the plan, but first, all i2c driver must be converted to
> the new framework. After that we could start with such an approach
> (or device model is ready and we can switch to it ...)
I know that there is a time line for introducing device model, but is
there any for switching I2C to the new approach?
I think about deleting obsolete/unmaintained boards, which will not
switch to new I2C approach.
>
> > Unfortunately it doesn't work without this patch.
>
> Yes ...
>
> If we have all i2c driver running with the new framework, we can get
> rid of I2C_SET_BUS defines, and simply use i2c_set_bus_num() which
> is a simple cleanup patch.
Ok, I see.
>
> bye,
> Heiko
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus
2014-03-31 6:17 ` Lukasz Majewski
@ 2014-04-01 4:58 ` Heiko Schocher
0 siblings, 0 replies; 36+ messages in thread
From: Heiko Schocher @ 2014-04-01 4:58 UTC (permalink / raw)
To: u-boot
Hello Lukasz,
Am 31.03.2014 08:17, schrieb Lukasz Majewski:
> Hi Heiko,
>
>> Hello Simon, Lukasz,
>>
>> Am 30.03.2014 01:17, schrieb Simon Glass:
>>> Hi Lukasz,
>>>
>>> On 27 March 2014 11:33, Lukasz Majewski<l.majewski@samsung.com>
>>> wrote:
>>>
>>>> Hi Simon, Heiko
>>>>
>>>>> From: Aaron Durbin<adurbin@chromium.org>
>>>>>
>>>>> The current pmic i2c code assumes the current i2c bus is
>>>>> the same as the pmic device's bus. There is nothing ensuring
>>>>> that to be true. Therefore, select the proper bus before
>>>>> performing a transaction.
>>>>>
>>>>> Signed-off-by: Aaron Durbin<adurbin@chromium.org>
>>>>> Signed-off-by: Simon Glass<sjg@chromium.org>
>>>>> Reviewed-by: Simon Glass<sjg@chromium.org>
>>>>> ---
>>>>>
>>>>> drivers/power/power_i2c.c | 4 ++++
>>>>> 1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
>>>>> index ac76870..594cd11 100644
>>>>> --- a/drivers/power/power_i2c.c
>>>>> +++ b/drivers/power/power_i2c.c
>>>>> @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32
>>>>> val) if (check_reg(p, reg))
>>>>> return -1;
>>>>>
>>>>> + I2C_SET_BUS(p->bus);
>>>>> +
>>>>
>>>> Hadn't we had a discussion about this explicit setting of I2C
>>>> some time ago? I thought that this problem was solved within the
>>>> I2C rework.
>>>>
>>>> Also I might be wrong, so please correct me if I'm wrong. Isn't the
>>>> I2C_SET_BUS() macro regarded as a obsolete after the I2C rework?
>>>>
>>>
>>> Agreed that would be ideal, but we would have to pass the bus
>>> number of the i2c_read/write() functions. I don't believe the i2c
>>> code has got that far yet.
>>
>> Yes, thats the plan, but first, all i2c driver must be converted to
>> the new framework. After that we could start with such an approach
>> (or device model is ready and we can switch to it ...)
>
> I know that there is a time line for introducing device model, but is
> there any for switching I2C to the new approach?
I am not aware of a plan ...
> I think about deleting obsolete/unmaintained boards, which will not
> switch to new I2C approach.
Hmm... this would be a long list, as there are the following driver
which need a conversion:
obj-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o
obj-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o
obj-$(CONFIG_DW_I2C) += designware_i2c.o
obj-$(CONFIG_I2C_MVTWSI) += mvtwsi.o
obj-$(CONFIG_I2C_MV) += mv_i2c.o
obj-$(CONFIG_I2C_MXS) += mxs_i2c.o
obj-$(CONFIG_PCA9564_I2C) += pca9564_i2c.o
obj-$(CONFIG_TSI108_I2C) += tsi108_i2c.o
obj-$(CONFIG_U8500_I2C) += u8500_i2c.o
obj-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o
Also some drivers in cpu dirs ... grep for HARD_I2C in u-boot
source (one Goal is to get rid of HARD_I2C).
./arch/powerpc/cpu/mpc8xx/i2c.c
./arch/powerpc/cpu/mpc8260/commproc.c
./arch/powerpc/cpu/mpc8260/i2c.c
./arch/powerpc/cpu/mpc5xxx/i2c.c
./arch/powerpc/cpu/mpc824x/drivers/i2c/i2c.c
./arch/powerpc/cpu/mpc512x/i2c.c
[...]
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus
2014-03-30 0:17 ` Simon Glass
2014-03-31 5:17 ` Heiko Schocher
@ 2014-03-31 14:36 ` Lukasz Majewski
2014-04-01 4:59 ` Heiko Schocher
1 sibling, 1 reply; 36+ messages in thread
From: Lukasz Majewski @ 2014-03-31 14:36 UTC (permalink / raw)
To: u-boot
Hi Simon,
> Hi Lukasz,
>
> On 27 March 2014 11:33, Lukasz Majewski <l.majewski@samsung.com>
> wrote: Hi Simon, Heiko
>
> > From: Aaron Durbin <adurbin@chromium.org>
> >
> > The current pmic i2c code assumes the current i2c bus is
> > the same as the pmic device's bus. There is nothing ensuring
> > that to be true. Therefore, select the proper bus before performing
> > a transaction.
> >
> > Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > Reviewed-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > ?drivers/power/power_i2c.c | 4 ++++
> > ?1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
> > index ac76870..594cd11 100644
> > --- a/drivers/power/power_i2c.c
> > +++ b/drivers/power/power_i2c.c
> > @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32
> > val) if (check_reg(p, reg))
> > ? ? ? ? ? ? ? return -1;
> >
> > + ? ? I2C_SET_BUS(p->bus);
> > +
>
> Hadn't we had a ?discussion about this explicit setting of I2C some
> time ago? I thought that this problem was solved within the I2C
> rework.
>
> Also I might be wrong, so please correct me if I'm wrong. Isn't the
> I2C_SET_BUS() macro regarded as a obsolete after the I2C rework?
>
> Agreed that would be ideal, but we would have to pass the bus number
> of the i2c_read/write() functions. I don't believe the i2c code has
> got that far yet.
>
> Unfortunately it doesn't work without this patch.
If Heiko doesn't object, then I won't protest.
>
> Regards,
> Simon
>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus
2014-03-31 14:36 ` Lukasz Majewski
@ 2014-04-01 4:59 ` Heiko Schocher
0 siblings, 0 replies; 36+ messages in thread
From: Heiko Schocher @ 2014-04-01 4:59 UTC (permalink / raw)
To: u-boot
Hello Lukasz,
Am 31.03.2014 16:36, schrieb Lukasz Majewski:
> Hi Simon,
>
>> Hi Lukasz,
>>
>> On 27 March 2014 11:33, Lukasz Majewski<l.majewski@samsung.com>
>> wrote: Hi Simon, Heiko
>>
>>> From: Aaron Durbin<adurbin@chromium.org>
>>>
>>> The current pmic i2c code assumes the current i2c bus is
>>> the same as the pmic device's bus. There is nothing ensuring
>>> that to be true. Therefore, select the proper bus before performing
>>> a transaction.
>>>
>>> Signed-off-by: Aaron Durbin<adurbin@chromium.org>
>>> Signed-off-by: Simon Glass<sjg@chromium.org>
>>> Reviewed-by: Simon Glass<sjg@chromium.org>
>>> ---
>>>
>>> drivers/power/power_i2c.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
>>> index ac76870..594cd11 100644
>>> --- a/drivers/power/power_i2c.c
>>> +++ b/drivers/power/power_i2c.c
>>> @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32
>>> val) if (check_reg(p, reg))
>>> return -1;
>>>
>>> + I2C_SET_BUS(p->bus);
>>> +
>>
>> Hadn't we had a discussion about this explicit setting of I2C some
>> time ago? I thought that this problem was solved within the I2C
>> rework.
>>
>> Also I might be wrong, so please correct me if I'm wrong. Isn't the
>> I2C_SET_BUS() macro regarded as a obsolete after the I2C rework?
>>
>> Agreed that would be ideal, but we would have to pass the bus number
>> of the i2c_read/write() functions. I don't believe the i2c code has
>> got that far yet.
>>
>> Unfortunately it doesn't work without this patch.
>
> If Heiko doesn't object, then I won't protest.
It s okay for me, so to clarify:
Acked-by: Heiko Schocher <hs@denx.de>
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 05/10] exynos5: support tps65090 pmic
2014-03-26 17:56 [U-Boot] [PATCH 0/10] Enable LCD display on snow Simon Glass
` (3 preceding siblings ...)
2014-03-26 17:56 ` [U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus Simon Glass
@ 2014-03-26 17:56 ` Simon Glass
2014-03-27 12:13 ` Minkyu Kang
2014-03-27 17:28 ` Lukasz Majewski
2014-03-26 17:56 ` [U-Boot] [PATCH 06/10] exynos: Enable PSHOLD in SPL Simon Glass
` (4 subsequent siblings)
9 siblings, 2 replies; 36+ messages in thread
From: Simon Glass @ 2014-03-26 17:56 UTC (permalink / raw)
To: u-boot
From: Aaron Durbin <adurbin@chromium.org>
The TSP65090 is a PMIC on some exynos5 boards. The init function is
called for the TPS65090 pmic. If that device is not a part of the device
tree (returns -ENODEV) then continue. Otherwise return a failure.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
board/samsung/common/board.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 3866495..654bdb6 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -23,6 +23,7 @@
#include <power/pmic.h>
#include <asm/arch/sromc.h>
#include <power/max77686_pmic.h>
+#include <power/tps65090_pmic.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -261,6 +262,12 @@ int power_init_board(void)
ret = max77686_init();
#endif
+ /* The TPS65090 may not be in the device tree. If so, it is not
+ * an error. */
+ ret = tps65090_init();
+ if (ret == 0 || ret == -ENODEV)
+ return 0;
+
return ret;
}
#endif
--
1.9.1.423.g4596e3a
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 05/10] exynos5: support tps65090 pmic
2014-03-26 17:56 ` [U-Boot] [PATCH 05/10] exynos5: support tps65090 pmic Simon Glass
@ 2014-03-27 12:13 ` Minkyu Kang
2014-03-30 0:18 ` Simon Glass
2014-03-27 17:28 ` Lukasz Majewski
1 sibling, 1 reply; 36+ messages in thread
From: Minkyu Kang @ 2014-03-27 12:13 UTC (permalink / raw)
To: u-boot
On 27/03/14 02:56, Simon Glass wrote:
> From: Aaron Durbin <adurbin@chromium.org>
>
> The TSP65090 is a PMIC on some exynos5 boards. The init function is
> called for the TPS65090 pmic. If that device is not a part of the device
> tree (returns -ENODEV) then continue. Otherwise return a failure.
>
> Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> ---
>
> board/samsung/common/board.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
> index 3866495..654bdb6 100644
> --- a/board/samsung/common/board.c
> +++ b/board/samsung/common/board.c
> @@ -23,6 +23,7 @@
> #include <power/pmic.h>
> #include <asm/arch/sromc.h>
> #include <power/max77686_pmic.h>
> +#include <power/tps65090_pmic.h>
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -261,6 +262,12 @@ int power_init_board(void)
> ret = max77686_init();
> #endif
What is the base tree of this patch?
looks different with samsung tree.
seems to need rebase?
>
#ifdef CONFIG_POWER_TPS65090
> + /* The TPS65090 may not be in the device tree. If so, it is not
> + * an error. */
please fix this multi line comment.
It should be
/*
* ...
* ...
*/
> + ret = tps65090_init();
> + if (ret == 0 || ret == -ENODEV)
> + return 0;
#endif
> +
> return ret;
> }
> #endif
>
Thanks,
Minkyu Kang.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 05/10] exynos5: support tps65090 pmic
2014-03-27 12:13 ` Minkyu Kang
@ 2014-03-30 0:18 ` Simon Glass
0 siblings, 0 replies; 36+ messages in thread
From: Simon Glass @ 2014-03-30 0:18 UTC (permalink / raw)
To: u-boot
Hi Minkyu,
On 27 March 2014 06:13, Minkyu Kang <mk7.kang@samsung.com> wrote:
> On 27/03/14 02:56, Simon Glass wrote:
> > From: Aaron Durbin <adurbin@chromium.org>
> >
> > The TSP65090 is a PMIC on some exynos5 boards. The init function is
> > called for the TPS65090 pmic. If that device is not a part of the device
> > tree (returns -ENODEV) then continue. Otherwise return a failure.
> >
> > Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > Reviewed-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > board/samsung/common/board.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
> > index 3866495..654bdb6 100644
> > --- a/board/samsung/common/board.c
> > +++ b/board/samsung/common/board.c
> > @@ -23,6 +23,7 @@
> > #include <power/pmic.h>
> > #include <asm/arch/sromc.h>
> > #include <power/max77686_pmic.h>
> > +#include <power/tps65090_pmic.h>
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -261,6 +262,12 @@ int power_init_board(void)
> > ret = max77686_init();
> > #endif
>
> What is the base tree of this patch?
> looks different with samsung tree.
> seems to need rebase?
>
Yes it is based on mainline - I will base in on samsung/master when I
resend.
Regards,
Simon
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 05/10] exynos5: support tps65090 pmic
2014-03-26 17:56 ` [U-Boot] [PATCH 05/10] exynos5: support tps65090 pmic Simon Glass
2014-03-27 12:13 ` Minkyu Kang
@ 2014-03-27 17:28 ` Lukasz Majewski
1 sibling, 0 replies; 36+ messages in thread
From: Lukasz Majewski @ 2014-03-27 17:28 UTC (permalink / raw)
To: u-boot
Hi Simon,
> From: Aaron Durbin <adurbin@chromium.org>
>
> The TSP65090 is a PMIC on some exynos5 boards. The init function is
> called for the TPS65090 pmic. If that device is not a part of the
> device tree (returns -ENODEV) then continue. Otherwise return a
> failure.
>
> Signed-off-by: Aaron Durbin <adurbin@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> ---
>
> board/samsung/common/board.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/board/samsung/common/board.c
> b/board/samsung/common/board.c index 3866495..654bdb6 100644
> --- a/board/samsung/common/board.c
> +++ b/board/samsung/common/board.c
> @@ -23,6 +23,7 @@
> #include <power/pmic.h>
> #include <asm/arch/sromc.h>
> #include <power/max77686_pmic.h>
> +#include <power/tps65090_pmic.h>
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -261,6 +262,12 @@ int power_init_board(void)
> ret = max77686_init();
> #endif
>
> + /* The TPS65090 may not be in the device tree. If so, it is
> not
> + * an error. */
> + ret = tps65090_init();
> + if (ret == 0 || ret == -ENODEV)
> + return 0;
> +
> return ret;
> }
> #endif
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 06/10] exynos: Enable PSHOLD in SPL
2014-03-26 17:56 [U-Boot] [PATCH 0/10] Enable LCD display on snow Simon Glass
` (4 preceding siblings ...)
2014-03-26 17:56 ` [U-Boot] [PATCH 05/10] exynos5: support tps65090 pmic Simon Glass
@ 2014-03-26 17:56 ` Simon Glass
2014-03-27 17:13 ` Lukasz Majewski
2014-03-26 17:56 ` [U-Boot] [PATCH 07/10] exynos: dts: Disable cros_ec interrupts due to broken GPIOs Simon Glass
` (3 subsequent siblings)
9 siblings, 1 reply; 36+ messages in thread
From: Simon Glass @ 2014-03-26 17:56 UTC (permalink / raw)
To: u-boot
There is quite a tight deadline in enabling PSHOLD, less than a second.
In some cases (e.g. with USB download), U-Boot takes longer than that
to load, so the board powers off before U-Boot starts.
Add a call in SPL to enable PSHOLD.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/arm/cpu/armv7/exynos/lowlevel_init.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/cpu/armv7/exynos/lowlevel_init.c b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
index 11fe5b8..48b5511 100644
--- a/arch/arm/cpu/armv7/exynos/lowlevel_init.c
+++ b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
@@ -48,6 +48,8 @@ int do_lowlevel_init(void)
arch_cpu_init();
+ set_ps_hold_ctrl();
+
reset_status = get_reset_status();
switch (reset_status) {
--
1.9.1.423.g4596e3a
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 06/10] exynos: Enable PSHOLD in SPL
2014-03-26 17:56 ` [U-Boot] [PATCH 06/10] exynos: Enable PSHOLD in SPL Simon Glass
@ 2014-03-27 17:13 ` Lukasz Majewski
0 siblings, 0 replies; 36+ messages in thread
From: Lukasz Majewski @ 2014-03-27 17:13 UTC (permalink / raw)
To: u-boot
Hi Simon,
> There is quite a tight deadline in enabling PSHOLD, less than a
> second. In some cases (e.g. with USB download), U-Boot takes longer
> than that to load, so the board powers off before U-Boot starts.
>
> Add a call in SPL to enable PSHOLD.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> arch/arm/cpu/armv7/exynos/lowlevel_init.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/cpu/armv7/exynos/lowlevel_init.c
> b/arch/arm/cpu/armv7/exynos/lowlevel_init.c index 11fe5b8..48b5511
> 100644 --- a/arch/arm/cpu/armv7/exynos/lowlevel_init.c
> +++ b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
> @@ -48,6 +48,8 @@ int do_lowlevel_init(void)
>
> arch_cpu_init();
>
> + set_ps_hold_ctrl();
> +
> reset_status = get_reset_status();
>
> switch (reset_status) {
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 07/10] exynos: dts: Disable cros_ec interrupts due to broken GPIOs
2014-03-26 17:56 [U-Boot] [PATCH 0/10] Enable LCD display on snow Simon Glass
` (5 preceding siblings ...)
2014-03-26 17:56 ` [U-Boot] [PATCH 06/10] exynos: Enable PSHOLD in SPL Simon Glass
@ 2014-03-26 17:56 ` Simon Glass
2014-03-26 17:56 ` [U-Boot] [PATCH 08/10] exynos: dts: Enable LCD for snow Simon Glass
` (2 subsequent siblings)
9 siblings, 0 replies; 36+ messages in thread
From: Simon Glass @ 2014-03-26 17:56 UTC (permalink / raw)
To: u-boot
At present the GPIO numbering patch has not been applied, so exynos GPIO
numbering is inconsistent (there are large gaps). Disable interrupts to
avoid a crash on boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/arm/dts/exynos5250-snow.dts | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/exynos5250-snow.dts b/arch/arm/dts/exynos5250-snow.dts
index 9b48a0c..42a687b 100644
--- a/arch/arm/dts/exynos5250-snow.dts
+++ b/arch/arm/dts/exynos5250-snow.dts
@@ -44,7 +44,11 @@
reg = <0x1e>;
compatible = "google,cros-ec";
i2c-max-frequency = <100000>;
- ec-interrupt = <&gpio 782 1>;
+ /*
+ * GPIO numbering is broken on exynos at present
+ *
+ * ec-interrupt = <&gpio 782 1>;
+ */
};
power-regulator at 48 {
@@ -60,7 +64,11 @@
reg = <0>;
compatible = "google,cros-ec";
spi-max-frequency = <5000000>;
- ec-interrupt = <&gpio 782 1>;
+ /*
+ * GPIO numbering is broken on exynos at present
+ *
+ * ec-interrupt = <&gpio 782 1>;
+ */
optimise-flash-write;
status = "disabled";
};
--
1.9.1.423.g4596e3a
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 08/10] exynos: dts: Enable LCD for snow
2014-03-26 17:56 [U-Boot] [PATCH 0/10] Enable LCD display on snow Simon Glass
` (6 preceding siblings ...)
2014-03-26 17:56 ` [U-Boot] [PATCH 07/10] exynos: dts: Disable cros_ec interrupts due to broken GPIOs Simon Glass
@ 2014-03-26 17:56 ` Simon Glass
2014-03-27 17:23 ` Lukasz Majewski
2014-03-26 17:56 ` [U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight " Simon Glass
2014-03-26 17:56 ` [U-Boot] [PATCH 10/10] initcall: Improve debugging support Simon Glass
9 siblings, 1 reply; 36+ messages in thread
From: Simon Glass @ 2014-03-26 17:56 UTC (permalink / raw)
To: u-boot
Enable LCD for snow. This is a 1366 x 768 panel.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/arm/dts/exynos5250-snow.dts | 44 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/arch/arm/dts/exynos5250-snow.dts b/arch/arm/dts/exynos5250-snow.dts
index 42a687b..725a1bf 100644
--- a/arch/arm/dts/exynos5250-snow.dts
+++ b/arch/arm/dts/exynos5250-snow.dts
@@ -192,4 +192,48 @@
/* UP LEFT */
0x070b0067 0x070c0069>;
};
+
+ fimd at 14400000 {
+ samsung,vl-freq = <60>;
+ samsung,vl-col = <1366>;
+ samsung,vl-row = <768>;
+ samsung,vl-width = <1366>;
+ samsung,vl-height = <768>;
+
+ samsung,vl-clkp;
+ samsung,vl-dp;
+ samsung,vl-hsp;
+ samsung,vl-vsp;
+
+ samsung,vl-bpix = <4>;
+
+ samsung,vl-hspw = <32>;
+ samsung,vl-hbpd = <80>;
+ samsung,vl-hfpd = <48>;
+ samsung,vl-vspw = <5>;
+ samsung,vl-vbpd = <14>;
+ samsung,vl-vfpd = <3>;
+ samsung,vl-cmd-allow-len = <0xf>;
+
+ samsung,winid = <0>;
+ samsung,interface-mode = <1>;
+ samsung,dp-enabled = <1>;
+ samsung,dual-lcd-enabled = <0>;
+ };
+
+ dp at 145b0000 {
+ samsung,lt-status = <0>;
+
+ samsung,master-mode = <0>;
+ samsung,bist-mode = <0>;
+ samsung,bist-pattern = <0>;
+ samsung,h-sync-polarity = <0>;
+ samsung,v-sync-polarity = <0>;
+ samsung,interlaced = <0>;
+ samsung,color-space = <0>;
+ samsung,dynamic-range = <0>;
+ samsung,ycbcr-coeff = <0>;
+ samsung,color-depth = <1>;
+ };
+
};
--
1.9.1.423.g4596e3a
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 08/10] exynos: dts: Enable LCD for snow
2014-03-26 17:56 ` [U-Boot] [PATCH 08/10] exynos: dts: Enable LCD for snow Simon Glass
@ 2014-03-27 17:23 ` Lukasz Majewski
2014-03-30 0:24 ` Simon Glass
0 siblings, 1 reply; 36+ messages in thread
From: Lukasz Majewski @ 2014-03-27 17:23 UTC (permalink / raw)
To: u-boot
Hi Simon,
> Enable LCD for snow. This is a 1366 x 768 panel.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> arch/arm/dts/exynos5250-snow.dts | 44
> ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44
> insertions(+)
>
> diff --git a/arch/arm/dts/exynos5250-snow.dts
> b/arch/arm/dts/exynos5250-snow.dts index 42a687b..725a1bf 100644
> --- a/arch/arm/dts/exynos5250-snow.dts
> +++ b/arch/arm/dts/exynos5250-snow.dts
> @@ -192,4 +192,48 @@
> /* UP LEFT */
> 0x070b0067 0x070c0069>;
> };
> +
> + fimd at 14400000 {
> + samsung,vl-freq = <60>;
> + samsung,vl-col = <1366>;
> + samsung,vl-row = <768>;
> + samsung,vl-width = <1366>;
> + samsung,vl-height = <768>;
> +
> + samsung,vl-clkp;
> + samsung,vl-dp;
> + samsung,vl-hsp;
> + samsung,vl-vsp;
> +
> + samsung,vl-bpix = <4>;
> +
> + samsung,vl-hspw = <32>;
> + samsung,vl-hbpd = <80>;
> + samsung,vl-hfpd = <48>;
> + samsung,vl-vspw = <5>;
> + samsung,vl-vbpd = <14>;
> + samsung,vl-vfpd = <3>;
> + samsung,vl-cmd-allow-len = <0xf>;
> +
> + samsung,winid = <0>;
> + samsung,interface-mode = <1>;
> + samsung,dp-enabled = <1>;
> + samsung,dual-lcd-enabled = <0>;
> + };
> +
I can only now regret that we have not stick to the Linux kernel DTS
format and be ABI compatible with Linux (and add u-boot specific
bindings as an extension).
Now unfortunately it is too late.
> + dp at 145b0000 {
> + samsung,lt-status = <0>;
> +
> + samsung,master-mode = <0>;
> + samsung,bist-mode = <0>;
> + samsung,bist-pattern = <0>;
> + samsung,h-sync-polarity = <0>;
> + samsung,v-sync-polarity = <0>;
> + samsung,interlaced = <0>;
> + samsung,color-space = <0>;
> + samsung,dynamic-range = <0>;
> + samsung,ycbcr-coeff = <0>;
> + samsung,color-depth = <1>;
> + };
> +
> };
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 08/10] exynos: dts: Enable LCD for snow
2014-03-27 17:23 ` Lukasz Majewski
@ 2014-03-30 0:24 ` Simon Glass
0 siblings, 0 replies; 36+ messages in thread
From: Simon Glass @ 2014-03-30 0:24 UTC (permalink / raw)
To: u-boot
Hi Lukasz,
On 27 March 2014 11:23, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Hi Simon,
>
> > Enable LCD for snow. This is a 1366 x 768 panel.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > arch/arm/dts/exynos5250-snow.dts | 44
> > ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44
> > insertions(+)
> >
> > diff --git a/arch/arm/dts/exynos5250-snow.dts
> > b/arch/arm/dts/exynos5250-snow.dts index 42a687b..725a1bf 100644
> > --- a/arch/arm/dts/exynos5250-snow.dts
> > +++ b/arch/arm/dts/exynos5250-snow.dts
> > @@ -192,4 +192,48 @@
> > /* UP LEFT */
> > 0x070b0067 0x070c0069>;
> > };
> > +
> > + fimd at 14400000 {
> > + samsung,vl-freq = <60>;
> > + samsung,vl-col = <1366>;
> > + samsung,vl-row = <768>;
> > + samsung,vl-width = <1366>;
> > + samsung,vl-height = <768>;
> > +
> > + samsung,vl-clkp;
> > + samsung,vl-dp;
> > + samsung,vl-hsp;
> > + samsung,vl-vsp;
> > +
> > + samsung,vl-bpix = <4>;
> > +
> > + samsung,vl-hspw = <32>;
> > + samsung,vl-hbpd = <80>;
> > + samsung,vl-hfpd = <48>;
> > + samsung,vl-vspw = <5>;
> > + samsung,vl-vbpd = <14>;
> > + samsung,vl-vfpd = <3>;
> > + samsung,vl-cmd-allow-len = <0xf>;
> > +
> > + samsung,winid = <0>;
> > + samsung,interface-mode = <1>;
> > + samsung,dp-enabled = <1>;
> > + samsung,dual-lcd-enabled = <0>;
> > + };
> > +
>
> I can only now regret that we have not stick to the Linux kernel DTS
> format and be ABI compatible with Linux (and add u-boot specific
> bindings as an extension).
>
> Now unfortunately it is too late.
>
I don't think it is too late. But until the GPIO numbering patch lands it's
really tricky to put GPIOs into the device tree on exynos. I think it would
be fairly easy to adjust this later.
Regards,
Simon
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight for snow
2014-03-26 17:56 [U-Boot] [PATCH 0/10] Enable LCD display on snow Simon Glass
` (7 preceding siblings ...)
2014-03-26 17:56 ` [U-Boot] [PATCH 08/10] exynos: dts: Enable LCD for snow Simon Glass
@ 2014-03-26 17:56 ` Simon Glass
2014-03-27 12:13 ` Minkyu Kang
` (2 more replies)
2014-03-26 17:56 ` [U-Boot] [PATCH 10/10] initcall: Improve debugging support Simon Glass
9 siblings, 3 replies; 36+ messages in thread
From: Simon Glass @ 2014-03-26 17:56 UTC (permalink / raw)
To: u-boot
The backlight uses FETs on the TPS65090. Enable this so that the display
is visible.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
board/samsung/smdk5250/exynos5-dt.c | 90 +++++++++++++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c
index c83b034..a0ae641 100644
--- a/board/samsung/smdk5250/exynos5-dt.c
+++ b/board/samsung/smdk5250/exynos5-dt.c
@@ -20,6 +20,7 @@
#include <asm/arch/sromc.h>
#include <power/pmic.h>
#include <power/max77686_pmic.h>
+#include <power/tps65090_pmic.h>
#include <tmu.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -60,6 +61,52 @@ int checkboard(void)
#endif
#ifdef CONFIG_LCD
+static int board_dp_bridge_setup(void)
+{
+ struct exynos5_gpio_part1 *gpio1 =
+ (struct exynos5_gpio_part1 *)samsung_get_base_gpio_part1();
+ const int MAX_TRIES = 10;
+ int num_tries;
+
+ debug("%s\n", __func__);
+
+ /* Setup the GPIOs */
+
+ /* PD is ACTIVE_LOW, and initially de-asserted */
+ s5p_gpio_set_pull(&gpio1->y2, 5, GPIO_PULL_NONE);
+ s5p_gpio_direction_output(&gpio1->y2, 5, 1);
+
+ /* Reset is ACTIVE_LOW */
+ s5p_gpio_set_pull(&gpio1->x1, 5, GPIO_PULL_NONE);
+ s5p_gpio_direction_output(&gpio1->x1, 5, 0);
+
+ udelay(10);
+ s5p_gpio_set_value(&gpio1->x1, 5, 1);
+
+ s5p_gpio_direction_input(&gpio1->x0, 7);
+
+ /*
+ * We need to wait for 90ms after bringing up the bridge since there
+ * is a phantom "high" on the HPD chip during its bootup. The phantom
+ * high comes within 7ms of de-asserting PD and persists for at least
+ * 15ms. The real high comes roughly 50ms after PD is de-asserted. The
+ * phantom high makes it hard for us to know when the NXP chip is up.
+ */
+ mdelay(90);
+
+ for (num_tries = 0; num_tries < MAX_TRIES; num_tries++) {
+ /* Check HPD. If it's high, we're all good. */
+ if (s5p_gpio_get_value(&gpio1->x0, 7))
+ return 0;
+
+ debug("%s: eDP bridge failed to come up; try %d of %d\n",
+ __func__, num_tries, MAX_TRIES);
+ }
+
+ /* Immediately go into bridge reset if the hp line is not high */
+ return -ENODEV;
+}
+
void exynos_cfg_lcd_gpio(void)
{
struct exynos5_gpio_part1 *gpio1 =
@@ -81,4 +128,47 @@ void exynos_set_dp_phy(unsigned int onoff)
{
set_dp_phy_ctrl(onoff);
}
+
+void exynos_backlight_on(unsigned int onoff)
+{
+ debug("%s(%u)\n", __func__, onoff);
+
+ if (onoff) {
+#ifdef CONFIG_POWER_TPS65090
+ struct exynos5_gpio_part1 *gpio1 =
+ (struct exynos5_gpio_part1 *)
+ samsung_get_base_gpio_part1();
+ int ret;
+
+ ret = tps65090_fet_enable(1); /* Enable FET1, backlight */
+ if (ret)
+ return;
+
+ /* T5 in the LCD timing spec (defined as > 10ms) */
+ mdelay(10);
+
+ /* board_dp_backlight_pwm */
+ s5p_gpio_direction_output(&gpio1->b2, 0, 1);
+
+ /* T6 in the LCD timing spec (defined as > 10ms) */
+ mdelay(10);
+
+ /* board_dp_backlight_en */
+ s5p_gpio_direction_output(&gpio1->x3, 0, 1);
+#endif
+ }
+}
+
+void exynos_lcd_power_on(void)
+{
+ debug("%s\n", __func__);
+
+#ifdef CONFIG_POWER_TPS65090
+ /* board_dp_lcd_vdd */
+ tps65090_fet_enable(6); /* Enable FET6, lcd panel */
+#endif
+
+ board_dp_bridge_setup();
+}
+
#endif
--
1.9.1.423.g4596e3a
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight for snow
2014-03-26 17:56 ` [U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight " Simon Glass
@ 2014-03-27 12:13 ` Minkyu Kang
2014-03-27 17:25 ` Lukasz Majewski
2014-03-29 22:35 ` Ajay kumar
2 siblings, 0 replies; 36+ messages in thread
From: Minkyu Kang @ 2014-03-27 12:13 UTC (permalink / raw)
To: u-boot
On 27/03/14 02:56, Simon Glass wrote:
> The backlight uses FETs on the TPS65090. Enable this so that the display
> is visible.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> board/samsung/smdk5250/exynos5-dt.c | 90 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 90 insertions(+)
>
> diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c
> index c83b034..a0ae641 100644
> --- a/board/samsung/smdk5250/exynos5-dt.c
> +++ b/board/samsung/smdk5250/exynos5-dt.c
> @@ -20,6 +20,7 @@
> #include <asm/arch/sromc.h>
> #include <power/pmic.h>
> #include <power/max77686_pmic.h>
> +#include <power/tps65090_pmic.h>
> #include <tmu.h>
>
> DECLARE_GLOBAL_DATA_PTR;
> @@ -60,6 +61,52 @@ int checkboard(void)
> #endif
>
> #ifdef CONFIG_LCD
> +static int board_dp_bridge_setup(void)
> +{
> + struct exynos5_gpio_part1 *gpio1 =
> + (struct exynos5_gpio_part1 *)samsung_get_base_gpio_part1();
> + const int MAX_TRIES = 10;
> + int num_tries;
> +
> + debug("%s\n", __func__);
> +
> + /* Setup the GPIOs */
> +
> + /* PD is ACTIVE_LOW, and initially de-asserted */
> + s5p_gpio_set_pull(&gpio1->y2, 5, GPIO_PULL_NONE);
> + s5p_gpio_direction_output(&gpio1->y2, 5, 1);
> +
> + /* Reset is ACTIVE_LOW */
> + s5p_gpio_set_pull(&gpio1->x1, 5, GPIO_PULL_NONE);
> + s5p_gpio_direction_output(&gpio1->x1, 5, 0);
> +
> + udelay(10);
> + s5p_gpio_set_value(&gpio1->x1, 5, 1);
> +
> + s5p_gpio_direction_input(&gpio1->x0, 7);
> +
> + /*
> + * We need to wait for 90ms after bringing up the bridge since there
> + * is a phantom "high" on the HPD chip during its bootup. The phantom
> + * high comes within 7ms of de-asserting PD and persists for at least
> + * 15ms. The real high comes roughly 50ms after PD is de-asserted. The
> + * phantom high makes it hard for us to know when the NXP chip is up.
> + */
> + mdelay(90);
> +
> + for (num_tries = 0; num_tries < MAX_TRIES; num_tries++) {
> + /* Check HPD. If it's high, we're all good. */
> + if (s5p_gpio_get_value(&gpio1->x0, 7))
> + return 0;
> +
> + debug("%s: eDP bridge failed to come up; try %d of %d\n",
> + __func__, num_tries, MAX_TRIES);
> + }
> +
> + /* Immediately go into bridge reset if the hp line is not high */
> + return -ENODEV;
> +}
> +
> void exynos_cfg_lcd_gpio(void)
> {
> struct exynos5_gpio_part1 *gpio1 =
> @@ -81,4 +128,47 @@ void exynos_set_dp_phy(unsigned int onoff)
> {
> set_dp_phy_ctrl(onoff);
> }
> +
> +void exynos_backlight_on(unsigned int onoff)
> +{
> + debug("%s(%u)\n", __func__, onoff);
> +
> + if (onoff) {
How about return immediately if onoff is 0.
if (!onoff)
return;
> +#ifdef CONFIG_POWER_TPS65090
> + struct exynos5_gpio_part1 *gpio1 =
> + (struct exynos5_gpio_part1 *)
> + samsung_get_base_gpio_part1();
> + int ret;
> +
> + ret = tps65090_fet_enable(1); /* Enable FET1, backlight */
> + if (ret)
> + return;
> +
> + /* T5 in the LCD timing spec (defined as > 10ms) */
> + mdelay(10);
> +
> + /* board_dp_backlight_pwm */
> + s5p_gpio_direction_output(&gpio1->b2, 0, 1);
> +
> + /* T6 in the LCD timing spec (defined as > 10ms) */
> + mdelay(10);
> +
> + /* board_dp_backlight_en */
> + s5p_gpio_direction_output(&gpio1->x3, 0, 1);
> +#endif
> + }
> +}
> +
> +void exynos_lcd_power_on(void)
> +{
> + debug("%s\n", __func__);
> +
> +#ifdef CONFIG_POWER_TPS65090
> + /* board_dp_lcd_vdd */
> + tps65090_fet_enable(6); /* Enable FET6, lcd panel */
> +#endif
> +
> + board_dp_bridge_setup();
> +}
> +
> #endif
>
Thanks,
Minkyu Kang.
^ permalink raw reply [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight for snow
2014-03-26 17:56 ` [U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight " Simon Glass
2014-03-27 12:13 ` Minkyu Kang
@ 2014-03-27 17:25 ` Lukasz Majewski
2014-03-29 22:35 ` Ajay kumar
2 siblings, 0 replies; 36+ messages in thread
From: Lukasz Majewski @ 2014-03-27 17:25 UTC (permalink / raw)
To: u-boot
Hi Simon,
> The backlight uses FETs on the TPS65090. Enable this so that the
> display is visible.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> board/samsung/smdk5250/exynos5-dt.c | 90
> +++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+)
>
> diff --git a/board/samsung/smdk5250/exynos5-dt.c
> b/board/samsung/smdk5250/exynos5-dt.c index c83b034..a0ae641 100644
> --- a/board/samsung/smdk5250/exynos5-dt.c
> +++ b/board/samsung/smdk5250/exynos5-dt.c
> @@ -20,6 +20,7 @@
> #include <asm/arch/sromc.h>
> #include <power/pmic.h>
> #include <power/max77686_pmic.h>
> +#include <power/tps65090_pmic.h>
> #include <tmu.h>
>
> DECLARE_GLOBAL_DATA_PTR;
> @@ -60,6 +61,52 @@ int checkboard(void)
> #endif
>
> #ifdef CONFIG_LCD
> +static int board_dp_bridge_setup(void)
> +{
> + struct exynos5_gpio_part1 *gpio1 =
> + (struct exynos5_gpio_part1
> *)samsung_get_base_gpio_part1();
> + const int MAX_TRIES = 10;
> + int num_tries;
> +
> + debug("%s\n", __func__);
> +
> + /* Setup the GPIOs */
> +
> + /* PD is ACTIVE_LOW, and initially de-asserted */
> + s5p_gpio_set_pull(&gpio1->y2, 5, GPIO_PULL_NONE);
> + s5p_gpio_direction_output(&gpio1->y2, 5, 1);
> +
> + /* Reset is ACTIVE_LOW */
> + s5p_gpio_set_pull(&gpio1->x1, 5, GPIO_PULL_NONE);
> + s5p_gpio_direction_output(&gpio1->x1, 5, 0);
> +
> + udelay(10);
> + s5p_gpio_set_value(&gpio1->x1, 5, 1);
> +
> + s5p_gpio_direction_input(&gpio1->x0, 7);
> +
> + /*
> + * We need to wait for 90ms after bringing up the bridge
> since there
> + * is a phantom "high" on the HPD chip during its bootup.
> The phantom
> + * high comes within 7ms of de-asserting PD and persists for
> at least
> + * 15ms. The real high comes roughly 50ms after PD is
> de-asserted. The
> + * phantom high makes it hard for us to know when the NXP
> chip is up.
> + */
> + mdelay(90);
> +
> + for (num_tries = 0; num_tries < MAX_TRIES; num_tries++) {
> + /* Check HPD. If it's high, we're all good. */
> + if (s5p_gpio_get_value(&gpio1->x0, 7))
> + return 0;
> +
> + debug("%s: eDP bridge failed to come up; try %d of
> %d\n",
> + __func__, num_tries, MAX_TRIES);
> + }
> +
> + /* Immediately go into bridge reset if the hp line is not
> high */
> + return -ENODEV;
> +}
> +
> void exynos_cfg_lcd_gpio(void)
> {
> struct exynos5_gpio_part1 *gpio1 =
> @@ -81,4 +128,47 @@ void exynos_set_dp_phy(unsigned int onoff)
> {
> set_dp_phy_ctrl(onoff);
> }
> +
> +void exynos_backlight_on(unsigned int onoff)
> +{
> + debug("%s(%u)\n", __func__, onoff);
> +
> + if (onoff) {
> +#ifdef CONFIG_POWER_TPS65090
> + struct exynos5_gpio_part1 *gpio1 =
> + (struct exynos5_gpio_part1 *)
> +
> samsung_get_base_gpio_part1();
> + int ret;
> +
> + ret = tps65090_fet_enable(1); /* Enable FET1,
> backlight */
> + if (ret)
> + return;
> +
> + /* T5 in the LCD timing spec (defined as > 10ms) */
> + mdelay(10);
> +
> + /* board_dp_backlight_pwm */
> + s5p_gpio_direction_output(&gpio1->b2, 0, 1);
> +
> + /* T6 in the LCD timing spec (defined as > 10ms) */
> + mdelay(10);
> +
> + /* board_dp_backlight_en */
> + s5p_gpio_direction_output(&gpio1->x3, 0, 1);
> +#endif
> + }
> +}
> +
> +void exynos_lcd_power_on(void)
> +{
> + debug("%s\n", __func__);
> +
> +#ifdef CONFIG_POWER_TPS65090
> + /* board_dp_lcd_vdd */
> + tps65090_fet_enable(6); /* Enable FET6, lcd panel */
> +#endif
> +
> + board_dp_bridge_setup();
> +}
> +
> #endif
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight for snow
2014-03-26 17:56 ` [U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight " Simon Glass
2014-03-27 12:13 ` Minkyu Kang
2014-03-27 17:25 ` Lukasz Majewski
@ 2014-03-29 22:35 ` Ajay kumar
2014-03-30 0:06 ` Simon Glass
2 siblings, 1 reply; 36+ messages in thread
From: Ajay kumar @ 2014-03-29 22:35 UTC (permalink / raw)
To: u-boot
Hi Simon,
Find my comments below:
On Wed, Mar 26, 2014 at 11:26 PM, Simon Glass <sjg@chromium.org> wrote:
> The backlight uses FETs on the TPS65090. Enable this so that the display
> is visible.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> board/samsung/smdk5250/exynos5-dt.c | 90
> +++++++++++++++++++++++++++++++++++++
> 1 file changed, 90 insertions(+)
>
> diff --git a/board/samsung/smdk5250/exynos5-dt.c
> b/board/samsung/smdk5250/exynos5-dt.c
> index c83b034..a0ae641 100644
> --- a/board/samsung/smdk5250/exynos5-dt.c
> +++ b/board/samsung/smdk5250/exynos5-dt.c
> @@ -20,6 +20,7 @@
> #include <asm/arch/sromc.h>
> #include <power/pmic.h>
> #include <power/max77686_pmic.h>
> +#include <power/tps65090_pmic.h>
> #include <tmu.h>
>
> DECLARE_GLOBAL_DATA_PTR;
> @@ -60,6 +61,52 @@ int checkboard(void)
> #endif
>
> #ifdef CONFIG_LCD
>
We should make sure this code runs only for snow, and not for SMDK.
Only Snow contains the bridge chip.
> +static int board_dp_bridge_setup(void)
> +{
> + struct exynos5_gpio_part1 *gpio1 =
> + (struct exynos5_gpio_part1 *)samsung_get_base_gpio_part1();
> + const int MAX_TRIES = 10;
> + int num_tries;
> +
> + debug("%s\n", __func__);
> +
> + /* Setup the GPIOs */
> +
> + /* PD is ACTIVE_LOW, and initially de-asserted */
> + s5p_gpio_set_pull(&gpio1->y2, 5, GPIO_PULL_NONE);
> + s5p_gpio_direction_output(&gpio1->y2, 5, 1);
> +
> + /* Reset is ACTIVE_LOW */
> + s5p_gpio_set_pull(&gpio1->x1, 5, GPIO_PULL_NONE);
> + s5p_gpio_direction_output(&gpio1->x1, 5, 0);
> +
> + udelay(10);
> + s5p_gpio_set_value(&gpio1->x1, 5, 1);
> +
> + s5p_gpio_direction_input(&gpio1->x0, 7);
> +
> + /*
> + * We need to wait for 90ms after bringing up the bridge since
> there
> + * is a phantom "high" on the HPD chip during its bootup. The
> phantom
> + * high comes within 7ms of de-asserting PD and persists for at
> least
> + * 15ms. The real high comes roughly 50ms after PD is
> de-asserted. The
> + * phantom high makes it hard for us to know when the NXP chip is
> up.
> + */
> + mdelay(90);
> +
> + for (num_tries = 0; num_tries < MAX_TRIES; num_tries++) {
> + /* Check HPD. If it's high, we're all good. */
> + if (s5p_gpio_get_value(&gpio1->x0, 7))
> + return 0;
> +
> + debug("%s: eDP bridge failed to come up; try %d of %d\n",
> + __func__, num_tries, MAX_TRIES);
> + }
> +
> + /* Immediately go into bridge reset if the hp line is not high */
> + return -ENODEV;
> +}
> +
> void exynos_cfg_lcd_gpio(void)
> {
> struct exynos5_gpio_part1 *gpio1 =
> @@ -81,4 +128,47 @@ void exynos_set_dp_phy(unsigned int onoff)
> {
> set_dp_phy_ctrl(onoff);
> }
> +
> +void exynos_backlight_on(unsigned int onoff)
> +{
> + debug("%s(%u)\n", __func__, onoff);
> +
> + if (onoff) {
> +#ifdef CONFIG_POWER_TPS65090
> + struct exynos5_gpio_part1 *gpio1 =
> + (struct exynos5_gpio_part1 *)
> + samsung_get_base_gpio_part1();
> + int ret;
> +
> + ret = tps65090_fet_enable(1); /* Enable FET1, backlight */
> + if (ret)
> + return;
> +
> + /* T5 in the LCD timing spec (defined as > 10ms) */
> + mdelay(10);
>
Can you check for backlight without using the above delay?
> +
> + /* board_dp_backlight_pwm */
> + s5p_gpio_direction_output(&gpio1->b2, 0, 1);
>
+
> + /* T6 in the LCD timing spec (defined as > 10ms) */
> + mdelay(10);
>
Can you check for backlight without using the above delay?
> +
> + /* board_dp_backlight_en */
> + s5p_gpio_direction_output(&gpio1->x3, 0, 1);
> +#endif
> + }
> +}
> +
> +void exynos_lcd_power_on(void)
> +{
> + debug("%s\n", __func__);
> +
> +#ifdef CONFIG_POWER_TPS65090
> + /* board_dp_lcd_vdd */
> + tps65090_fet_enable(6); /* Enable FET6, lcd panel */
> +#endif
> +
> + board_dp_bridge_setup();
>
returning int. check for return value and print in case of failure.
> +}
> +
> #endif
> --
> 1.9.1.423.g4596e3a
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
Regards,
Ajay Kumar
^ permalink raw reply [flat|nested] 36+ messages in thread* [U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight for snow
2014-03-29 22:35 ` Ajay kumar
@ 2014-03-30 0:06 ` Simon Glass
0 siblings, 0 replies; 36+ messages in thread
From: Simon Glass @ 2014-03-30 0:06 UTC (permalink / raw)
To: u-boot
Hi Ajay,
On 29 March 2014 16:35, Ajay kumar <ajaynumb@gmail.com> wrote:
> Hi Simon,
>
> Find my comments below:
>
> On Wed, Mar 26, 2014 at 11:26 PM, Simon Glass <sjg@chromium.org> wrote:
>
>> The backlight uses FETs on the TPS65090. Enable this so that the display
>> is visible.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>> board/samsung/smdk5250/exynos5-dt.c | 90
>> +++++++++++++++++++++++++++++++++++++
>> 1 file changed, 90 insertions(+)
>>
>> diff --git a/board/samsung/smdk5250/exynos5-dt.c
>> b/board/samsung/smdk5250/exynos5-dt.c
>> index c83b034..a0ae641 100644
>> --- a/board/samsung/smdk5250/exynos5-dt.c
>> +++ b/board/samsung/smdk5250/exynos5-dt.c
>> @@ -20,6 +20,7 @@
>> #include <asm/arch/sromc.h>
>> #include <power/pmic.h>
>> #include <power/max77686_pmic.h>
>> +#include <power/tps65090_pmic.h>
>> #include <tmu.h>
>>
>> DECLARE_GLOBAL_DATA_PTR;
>> @@ -60,6 +61,52 @@ int checkboard(void)
>> #endif
>>
>> #ifdef CONFIG_LCD
>>
> We should make sure this code runs only for snow, and not for SMDK.
> Only Snow contains the bridge chip.
>
I'll add it to the device tree.
> +static int board_dp_bridge_setup(void)
>> +{
>> + struct exynos5_gpio_part1 *gpio1 =
>> + (struct exynos5_gpio_part1
>> *)samsung_get_base_gpio_part1();
>> + const int MAX_TRIES = 10;
>> + int num_tries;
>> +
>> + debug("%s\n", __func__);
>> +
>> + /* Setup the GPIOs */
>> +
>> + /* PD is ACTIVE_LOW, and initially de-asserted */
>> + s5p_gpio_set_pull(&gpio1->y2, 5, GPIO_PULL_NONE);
>> + s5p_gpio_direction_output(&gpio1->y2, 5, 1);
>> +
>> + /* Reset is ACTIVE_LOW */
>> + s5p_gpio_set_pull(&gpio1->x1, 5, GPIO_PULL_NONE);
>> + s5p_gpio_direction_output(&gpio1->x1, 5, 0);
>> +
>> + udelay(10);
>> + s5p_gpio_set_value(&gpio1->x1, 5, 1);
>> +
>> + s5p_gpio_direction_input(&gpio1->x0, 7);
>> +
>> + /*
>> + * We need to wait for 90ms after bringing up the bridge since
>> there
>> + * is a phantom "high" on the HPD chip during its bootup. The
>> phantom
>> + * high comes within 7ms of de-asserting PD and persists for at
>> least
>> + * 15ms. The real high comes roughly 50ms after PD is
>> de-asserted. The
>> + * phantom high makes it hard for us to know when the NXP chip is
>> up.
>> + */
>> + mdelay(90);
>> +
>> + for (num_tries = 0; num_tries < MAX_TRIES; num_tries++) {
>> + /* Check HPD. If it's high, we're all good. */
>> + if (s5p_gpio_get_value(&gpio1->x0, 7))
>> + return 0;
>> +
>> + debug("%s: eDP bridge failed to come up; try %d of %d\n",
>> + __func__, num_tries, MAX_TRIES);
>> + }
>> +
>> + /* Immediately go into bridge reset if the hp line is not high */
>> + return -ENODEV;
>> +}
>> +
>> void exynos_cfg_lcd_gpio(void)
>> {
>> struct exynos5_gpio_part1 *gpio1 =
>> @@ -81,4 +128,47 @@ void exynos_set_dp_phy(unsigned int onoff)
>> {
>> set_dp_phy_ctrl(onoff);
>> }
>> +
>> +void exynos_backlight_on(unsigned int onoff)
>> +{
>> + debug("%s(%u)\n", __func__, onoff);
>> +
>> + if (onoff) {
>> +#ifdef CONFIG_POWER_TPS65090
>> + struct exynos5_gpio_part1 *gpio1 =
>> + (struct exynos5_gpio_part1 *)
>> + samsung_get_base_gpio_part1();
>> + int ret;
>> +
>> + ret = tps65090_fet_enable(1); /* Enable FET1, backlight */
>> + if (ret)
>> + return;
>> +
>> + /* T5 in the LCD timing spec (defined as > 10ms) */
>> + mdelay(10);
>>
> Can you check for backlight without using the above delay?
>
I think we need to keep these delays due to the LCD timing spec. It often
does work, but we need it to always work.
> +
>> + /* board_dp_backlight_pwm */
>> + s5p_gpio_direction_output(&gpio1->b2, 0, 1);
>>
> +
>> + /* T6 in the LCD timing spec (defined as > 10ms) */
>> + mdelay(10);
>>
> Can you check for backlight without using the above delay?
>
>> +
>> + /* board_dp_backlight_en */
>> + s5p_gpio_direction_output(&gpio1->x3, 0, 1);
>> +#endif
>> + }
>> +}
>> +
>> +void exynos_lcd_power_on(void)
>> +{
>> + debug("%s\n", __func__);
>> +
>> +#ifdef CONFIG_POWER_TPS65090
>> + /* board_dp_lcd_vdd */
>> + tps65090_fet_enable(6); /* Enable FET6, lcd panel */
>> +#endif
>> +
>> + board_dp_bridge_setup();
>>
> returning int. check for return value and print in case of failure.
>
Will do.
Regads,
Simon
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH 10/10] initcall: Improve debugging support
2014-03-26 17:56 [U-Boot] [PATCH 0/10] Enable LCD display on snow Simon Glass
` (8 preceding siblings ...)
2014-03-26 17:56 ` [U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight " Simon Glass
@ 2014-03-26 17:56 ` Simon Glass
9 siblings, 0 replies; 36+ messages in thread
From: Simon Glass @ 2014-03-26 17:56 UTC (permalink / raw)
To: u-boot
Add the ability to display the code offset of an initcall even after it
is relocated. This makes it much easier to relate initcalls back to the
U-Boot System.map file.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
include/initcall.h | 2 +-
lib/initcall.c | 17 ++++++++++++-----
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/include/initcall.h b/include/initcall.h
index 2378077..65f67dc 100644
--- a/include/initcall.h
+++ b/include/initcall.h
@@ -6,4 +6,4 @@
typedef int (*init_fnc_t)(void);
-int initcall_run_list(init_fnc_t init_sequence[]);
+int initcall_run_list(const init_fnc_t init_sequence[]);
diff --git a/lib/initcall.c b/lib/initcall.c
index fa76dd7..7597bad 100644
--- a/lib/initcall.c
+++ b/lib/initcall.c
@@ -7,15 +7,22 @@
#include <common.h>
#include <initcall.h>
-int initcall_run_list(init_fnc_t init_sequence[])
+DECLARE_GLOBAL_DATA_PTR;
+
+int initcall_run_list(const init_fnc_t init_sequence[])
{
- init_fnc_t *init_fnc_ptr;
+ const init_fnc_t *init_fnc_ptr;
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
- debug("initcall: %p\n", *init_fnc_ptr);
+ unsigned long reloc_ofs = 0;
+
+ if (gd->flags & GD_FLG_RELOC)
+ reloc_ofs = gd->reloc_off;
+ debug("initcall: %p\n", (char *)*init_fnc_ptr - reloc_ofs);
if ((*init_fnc_ptr)()) {
- debug("initcall sequence %p failed at call %p\n",
- init_sequence, *init_fnc_ptr);
+ printf("initcall sequence %p failed at call %p\n",
+ init_sequence,
+ (char *)*init_fnc_ptr - reloc_ofs);
return -1;
}
}
--
1.9.1.423.g4596e3a
^ permalink raw reply related [flat|nested] 36+ messages in thread