Re: [U-Boot] [PATCH v2 06/19] cros_ec: Support the LDO access method used by spring

2015-08-09 Thread Simon Glass
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote:
 Add a driver to support the special LDO access used by spring. This is a
 custom method in the cros_ec protocol - it does not use an I2C
 pass-through.

 There are two implementation choices:

 1. Write a special LDO driver which can talk across the EC. Duplicate all
 the logic from TPS65090 for retrying when the LDO fails to come up.

 2. Write a special I2C bus driver which pretends to be a TPS65090 and
 transfers reads and writes using the LDO message.

 Either is distasteful. The latter method is chosen since it results in less
 code duplication and a fairly simple (30-line) implementation of the core
 logic.

 The crosec 'ldo' subcommand could be removed (since i2c md/mw will work
 instead) but is retained as a convenience.

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

 Changes in v2: None

  drivers/i2c/Kconfig   | 13 
  drivers/i2c/Makefile  |  1 +
  drivers/i2c/cros_ec_ldo.c | 77 
 +++
  drivers/misc/cros_ec.c| 21 +++--
  include/cros_ec.h |  4 +--
  5 files changed, 104 insertions(+), 12 deletions(-)
  create mode 100644 drivers/i2c/cros_ec_ldo.c

Applied to u-boot-dm.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 06/19] cros_ec: Support the LDO access method used by spring

2015-08-03 Thread Simon Glass
Add a driver to support the special LDO access used by spring. This is a
custom method in the cros_ec protocol - it does not use an I2C
pass-through.

There are two implementation choices:

1. Write a special LDO driver which can talk across the EC. Duplicate all
the logic from TPS65090 for retrying when the LDO fails to come up.

2. Write a special I2C bus driver which pretends to be a TPS65090 and
transfers reads and writes using the LDO message.

Either is distasteful. The latter method is chosen since it results in less
code duplication and a fairly simple (30-line) implementation of the core
logic.

The crosec 'ldo' subcommand could be removed (since i2c md/mw will work
instead) but is retained as a convenience.

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

Changes in v2: None

 drivers/i2c/Kconfig   | 13 
 drivers/i2c/Makefile  |  1 +
 drivers/i2c/cros_ec_ldo.c | 77 +++
 drivers/misc/cros_ec.c| 21 +++--
 include/cros_ec.h |  4 +--
 5 files changed, 104 insertions(+), 12 deletions(-)
 create mode 100644 drivers/i2c/cros_ec_ldo.c

diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index e861b53..9a62ddd 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -29,6 +29,19 @@ config I2C_CROS_EC_TUNNEL
  I2C or LPC). Some Chromebooks use this when the hardware design
  does not allow direct access to the main PMIC from the AP.
 
+config I2C_CROS_EC_LDO
+   bool Provide access to LDOs on the Chrome OS EC
+   depends on CROS_EC
+   ---help---
+   On many Chromebooks the main PMIC is inaccessible to the AP. This is
+   often dealt with by using an I2C pass-through interface provided by
+   the EC. On some unfortunate models (e.g. Spring) the pass-through
+   is not available, and an LDO message is available instead. This
+   option enables a driver which provides very basic access to those
+   regulators, via the EC. We implement this as an I2C bus which
+   emulates just the TPS65090 messages we know about. This is done to
+   avoid duplicating the logic in the TPS65090 regulator driver for
+   enabling/disabling an LDO.
 
 config DM_I2C_GPIO
bool Enable Driver Model for software emulated I2C bus driver
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 7f01fce..9b45248 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DM_I2C) += i2c-uclass.o
 obj-$(CONFIG_DM_I2C_COMPAT) += i2c-uclass-compat.o
 obj-$(CONFIG_DM_I2C_GPIO) += i2c-gpio.o
 obj-$(CONFIG_I2C_CROS_EC_TUNNEL) += cros_ec_tunnel.o
+obj-$(CONFIG_I2C_CROS_EC_LDO) += cros_ec_ldo.o
 
 obj-$(CONFIG_SYS_I2C_ADI) += adi_i2c.o
 obj-$(CONFIG_I2C_MV) += mv_i2c.o
diff --git a/drivers/i2c/cros_ec_ldo.c b/drivers/i2c/cros_ec_ldo.c
new file mode 100644
index 000..b817c61
--- /dev/null
+++ b/drivers/i2c/cros_ec_ldo.c
@@ -0,0 +1,77 @@
+/*
+ * Copyright (c) 2015 Google, Inc
+ * Written by Simon Glass s...@chromium.org
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include cros_ec.h
+#include errno.h
+#include i2c.h
+#include power/tps65090.h
+
+static int cros_ec_ldo_set_bus_speed(struct udevice *dev, unsigned int speed)
+{
+   return 0;
+}
+
+static int cros_ec_ldo_xfer(struct udevice *dev, struct i2c_msg *msg,
+   int nmsgs)
+{
+   bool is_read = nmsgs  1;
+   int fet_id, ret;
+
+   /*
+* Look for reads and writes of the LDO registers. In either case the
+* first message is a write with the register number as the first byte.
+*/
+   if (!nmsgs || !msg-len || (msg-flags  I2C_M_RD)) {
+   debug(%s: Invalid message\n, __func__);
+   goto err;
+   }
+
+   fet_id = msg-buf[0] - REG_FET_BASE;
+   if (fet_id  1 || fet_id  MAX_FET_NUM) {
+   debug(%s: Invalid FET %d\n, __func__, fet_id);
+   goto err;
+   }
+
+   if (is_read) {
+   uint8_t state;
+
+   ret = cros_ec_get_ldo(dev-parent, fet_id, state);
+   if (!ret)
+   msg[1].buf[0] = state ?
+   FET_CTRL_ENFET | FET_CTRL_PGFET : 0;
+   } else {
+   bool on = msg-buf[1]  FET_CTRL_ENFET;
+
+   ret = cros_ec_set_ldo(dev-parent, fet_id, on);
+   }
+
+   return ret;
+
+err:
+   /* Indicate that the message is unimplemented */
+   return -ENOSYS;
+}
+
+static const struct dm_i2c_ops cros_ec_i2c_ops = {
+   .xfer   = cros_ec_ldo_xfer,
+   .set_bus_speed  = cros_ec_ldo_set_bus_speed,
+};
+
+static const struct udevice_id cros_ec_i2c_ids[] = {
+   { .compatible = google,cros-ec-ldo-tunnel },
+   { }
+};
+
+U_BOOT_DRIVER(cros_ec_ldo) = {
+   .name   = cros_ec_ldo_tunnel,
+   .id = UCLASS_I2C,
+   .of_match = cros_ec_i2c_ids,
+   .per_child_auto_alloc_size = sizeof(struct