* [RESEND PATCH 0/7] Add cros_ec changes for newer boards
@ 2014-04-17 18:36 ` Doug Anderson
0 siblings, 0 replies; 7+ messages in thread
From: Doug Anderson @ 2014-04-17 18:36 UTC (permalink / raw
To: lee.jones, swarren, wsa
Cc: abrestic, dgreid, olof, sjg, linux-samsung-soc, linux-tegra,
Doug Anderson, mark.rutland, andrew, swarren, thierry.reding,
linux-i2c, matt.porter, jdelvare, laurent.pinchart+renesas,
vpalatin, sameo, linux-doc, bjorn.andersson, u.kleine-koenig,
kevin.strasser, devicetree, pawel.moll, ijc+devicetree, robh+dt,
linux, andriy.shevchenko, ch.naveen, linux-arm-kernel,
shane.huang, rdunlap, linux-kernel, linux, galak, schwidefsky,
maxime.ripard
This series adds the most critical cros_ec changes for newer boards
using cros_ec. Specifically:
* Fixes timing/locking issues with the previously upstreamed (but
never used upstream) cros_ec_spi driver.
* Updates the cros_ec header file to the latest version which allows
us to use newer EC features like i2c tunneling.
* Adds an i2c tunnel driver to allow communication to the EC's i2c
devices.
This _doesn't_ get the EC driver fully up to speed with what's in the
current Chromium OS trees. There are a whole slew of cleanup patches
there, an addition of an LPC transport mode, and exports of functions
to userspace. Once these patches land and we have functionality we
can continue to pick more cleanup patches.
Bill Richardson (1):
mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources
David Hendricks (1):
mfd: cros_ec: spi: calculate delay between transfers correctly
Doug Anderson (5):
mfd: cros_ec: spi: Add mutex to cros_ec_spi
mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable
mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms
i2c: ChromeOS EC tunnel driver
ARM: tegra: Add the EC i2c tunnel to tegra124-venice2
.../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt | 36 +
arch/arm/boot/dts/tegra124-venice2.dts | 27 +
drivers/i2c/busses/Kconfig | 9 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 304 ++++++
drivers/mfd/cros_ec.c | 7 +-
drivers/mfd/cros_ec_spi.c | 67 +-
include/linux/mfd/cros_ec.h | 4 +-
include/linux/mfd/cros_ec_commands.h | 1128 ++++++++++++++++++--
9 files changed, 1491 insertions(+), 92 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c
--
1.9.1.423.g4596e3a
^ permalink raw reply [flat|nested] 7+ messages in thread
* [RESEND PATCH 0/7] Add cros_ec changes for newer boards
@ 2014-04-17 18:36 ` Doug Anderson
0 siblings, 0 replies; 7+ messages in thread
From: Doug Anderson @ 2014-04-17 18:36 UTC (permalink / raw
To: lee.jones-QSEj5FYQhm4dnm+yROfE0A, swarren-DDmLM1+adcrQT0dZR+AlfA,
wsa-z923LK4zBo2bacvFa/9K2g
Cc: abrestic-F7+t8E8rja9g9hUCZPvPmw, dgreid-F7+t8E8rja9g9hUCZPvPmw,
olof-nZhT3qVonbNeoWH0uzbU5w, sjg-F7+t8E8rja9g9hUCZPvPmw,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Doug Anderson,
mark.rutland-5wv7dgnIgG8, andrew-g2DYL2Zd6BY,
swarren-3lzwWm7+Weoh9ZMKESR00Q,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
matt.porter-QSEj5FYQhm4dnm+yROfE0A, jdelvare-l3A5Bk7waGM,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw,
vpalatin-F7+t8E8rja9g9hUCZPvPmw, sameo-VuQAYsv1563Yd54FQh9/CA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ,
kevin.strasser-VuQAYsv1563Yd54FQh9/CA,
devicetree-u79uwXL29TY76Z2rM5mHXA, pawel.moll-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, linux-lFZ/pmaqli7XmaaqVzeoHQ,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
ch.naveen-Sze3O3UU22JBDgjK7y7TUQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
shane.huang-5C7GfCeVMHo, rdunlap-wEGCiKHe2LqWVfeAwA7xHQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-ci5G2KO2hbZ+pU9mqzGVBQ,
galak
This series adds the most critical cros_ec changes for newer boards
using cros_ec. Specifically:
* Fixes timing/locking issues with the previously upstreamed (but
never used upstream) cros_ec_spi driver.
* Updates the cros_ec header file to the latest version which allows
us to use newer EC features like i2c tunneling.
* Adds an i2c tunnel driver to allow communication to the EC's i2c
devices.
This _doesn't_ get the EC driver fully up to speed with what's in the
current Chromium OS trees. There are a whole slew of cleanup patches
there, an addition of an LPC transport mode, and exports of functions
to userspace. Once these patches land and we have functionality we
can continue to pick more cleanup patches.
Bill Richardson (1):
mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources
David Hendricks (1):
mfd: cros_ec: spi: calculate delay between transfers correctly
Doug Anderson (5):
mfd: cros_ec: spi: Add mutex to cros_ec_spi
mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable
mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms
i2c: ChromeOS EC tunnel driver
ARM: tegra: Add the EC i2c tunnel to tegra124-venice2
.../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt | 36 +
arch/arm/boot/dts/tegra124-venice2.dts | 27 +
drivers/i2c/busses/Kconfig | 9 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 304 ++++++
drivers/mfd/cros_ec.c | 7 +-
drivers/mfd/cros_ec_spi.c | 67 +-
include/linux/mfd/cros_ec.h | 4 +-
include/linux/mfd/cros_ec_commands.h | 1128 ++++++++++++++++++--
9 files changed, 1491 insertions(+), 92 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c
--
1.9.1.423.g4596e3a
^ permalink raw reply [flat|nested] 7+ messages in thread
* [RESEND PATCH 0/7] Add cros_ec changes for newer boards
@ 2014-04-17 18:36 ` Doug Anderson
0 siblings, 0 replies; 7+ messages in thread
From: Doug Anderson @ 2014-04-17 18:36 UTC (permalink / raw
To: linux-arm-kernel
This series adds the most critical cros_ec changes for newer boards
using cros_ec. Specifically:
* Fixes timing/locking issues with the previously upstreamed (but
never used upstream) cros_ec_spi driver.
* Updates the cros_ec header file to the latest version which allows
us to use newer EC features like i2c tunneling.
* Adds an i2c tunnel driver to allow communication to the EC's i2c
devices.
This _doesn't_ get the EC driver fully up to speed with what's in the
current Chromium OS trees. There are a whole slew of cleanup patches
there, an addition of an LPC transport mode, and exports of functions
to userspace. Once these patches land and we have functionality we
can continue to pick more cleanup patches.
Bill Richardson (1):
mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources
David Hendricks (1):
mfd: cros_ec: spi: calculate delay between transfers correctly
Doug Anderson (5):
mfd: cros_ec: spi: Add mutex to cros_ec_spi
mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable
mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms
i2c: ChromeOS EC tunnel driver
ARM: tegra: Add the EC i2c tunnel to tegra124-venice2
.../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt | 36 +
arch/arm/boot/dts/tegra124-venice2.dts | 27 +
drivers/i2c/busses/Kconfig | 9 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 304 ++++++
drivers/mfd/cros_ec.c | 7 +-
drivers/mfd/cros_ec_spi.c | 67 +-
include/linux/mfd/cros_ec.h | 4 +-
include/linux/mfd/cros_ec_commands.h | 1128 ++++++++++++++++++--
9 files changed, 1491 insertions(+), 92 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c
--
1.9.1.423.g4596e3a
^ permalink raw reply [flat|nested] 7+ messages in thread
* [RESEND PATCH 6/7] i2c: ChromeOS EC tunnel driver
@ 2014-04-17 18:36 ` Doug Anderson
0 siblings, 0 replies; 7+ messages in thread
From: Doug Anderson @ 2014-04-17 18:36 UTC (permalink / raw
To: lee.jones, swarren, wsa
Cc: abrestic, dgreid, olof, sjg, linux-samsung-soc, linux-tegra,
Doug Anderson, Vincent Palatin, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, rdunlap, sameo, jdelvare, shane.huang,
maxime.ripard, laurent.pinchart+renesas, u.kleine-koenig,
bjorn.andersson, kevin.strasser, linux, andrew, andriy.shevchenko,
schwidefsky, matt.porter, ch.naveen, devicetree, linux-doc,
linux-kernel, linux-i2c
On ARM Chromebooks we have a few devices that are accessed by both the
AP (the main "Application Processor") and the EC (the Embedded
Controller). These are:
* The battery (sbs-battery).
* The power management unit tps65090.
On the original Samsung ARM Chromebook these devices were on an I2C
bus that was shared between the AP and the EC and arbitrated using
some extranal GPIOs (see i2c-arb-gpio-challenge).
The original arbitration scheme worked well enough but had some
downsides:
* It was nonstandard (not using standard I2C multimaster)
* It only worked if the EC-AP communication was I2C
* It was relatively hard to debug problems (hard to tell if i2c issues
were caused by the EC, the AP, or some device on the bus).
On the HP Chromebook 11 the design was changed to:
* The AP/EC comms were still i2c, but the battery/tps65090 were no
longer on the bus used for AP/EC communication. The battery was
exposed to the AP through a limited i2c tunnel and tps65090 was
exposed to the AP through a custom Linux driver.
On the Samsung ARM Chromebook 2 the scheme is changed yet again, now:
* The AP/EC comms are now using SPI for faster speeds.
* The EC's i2c bus is exposed to the AP through a full i2c tunnel.
The upstream "tegra124-venice2" uses the same scheme as the Samsung
ARM Chromebook 2, though it has a different set of components on the
other side of the bus.
This driver supports the scheme used by the Samsung ARM Chromebook 2.
Future patches to this driver could add support for the battery tunnel
on the HP Chromebook 11 (and perhaps could even be used to access
tps65090 on the HP Chromebook 11 instead of using a special driver,
but I haven't researched that enough).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
---
.../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt | 36 +++
drivers/i2c/busses/Kconfig | 9 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 304 +++++++++++++++++++++
drivers/mfd/cros_ec.c | 5 +
5 files changed, 355 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
new file mode 100644
index 0000000..30776bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
@@ -0,0 +1,36 @@
+I2C bus that tunnels through the ChromeOS EC (cros-ec)
+======================================================
+On some ChromeOS board designs we've got a connection to the EC (embedded
+controller) but no direct connection to some devices on the other side of
+the EC (like a battery and PMIC). To get access to those devices we need
+to tunnel our i2c commands through the EC.
+
+The node for this device should be under a cros-ec node like google,cros-ec-spi
+or google,cros-ec-i2c.
+
+
+Required properties:
+- compatible: google,cros-ec-i2c-tunnel
+- google,remote-bus: The EC bus we'd like to talk to.
+
+
+Example:
+ cros-ec@0 {
+ compatible = "google,cros-ec-spi";
+
+ ...
+
+ i2c-tunnel {
+ compatible = "google,cros-ec-i2c-tunnel";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ google,remote-bus = <0>;
+
+ battery: sbs-battery@b {
+ compatible = "sbs,sbs-battery";
+ reg = <0xb>;
+ sbs,poll-retry-count = <1>;
+ };
+ };
+ }
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c94db1c..9a0a6cc 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -993,6 +993,15 @@ config I2C_SIBYTE
help
Supports the SiByte SOC on-chip I2C interfaces (2 channels).
+config I2C_CROS_EC_TUNNEL
+ tristate "ChromeOS EC tunnel I2C bus"
+ depends on MFD_CROS_EC
+ help
+ If you say yes here you get an I2C bus that will tunnel i2c commands
+ through to the other side of the ChromeOS EC to the i2c bus
+ connected there. This will work whatever the interface used to
+ talk to the EC (SPI, I2C or LPC).
+
config SCx200_I2C
tristate "NatSemi SCx200 I2C using GPIO pins (DEPRECATED)"
depends on SCx200_GPIO
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 18d18ff..e110ca9 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -95,6 +95,7 @@ obj-$(CONFIG_I2C_VIPERBOARD) += i2c-viperboard.o
# Other I2C/SMBus bus drivers
obj-$(CONFIG_I2C_ACORN) += i2c-acorn.o
obj-$(CONFIG_I2C_BCM_KONA) += i2c-bcm-kona.o
+obj-$(CONFIG_I2C_CROS_EC_TUNNEL) += i2c-cros-ec-tunnel.o
obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
obj-$(CONFIG_I2C_PCA_ISA) += i2c-pca-isa.o
obj-$(CONFIG_I2C_SIBYTE) += i2c-sibyte.o
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
new file mode 100644
index 0000000..7e53fcb
--- /dev/null
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -0,0 +1,304 @@
+/*
+ * Copyright (C) 2013 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Expose an I2C passthrough to the ChromeOS EC.
+ */
+
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/mfd/cros_ec.h>
+#include <linux/mfd/cros_ec_commands.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+/**
+ * struct ec_i2c_device - Driver data for I2C tunnel
+ *
+ * @dev: Device node
+ * @adap: I2C adapter
+ * @ec: Pointer to EC device
+ * @remote_bus: The EC bus number we tunnel to on the other side.
+ * @request_buf: Buffer for transmitting data; we expect most transfers to fit.
+ * @response_buf: Buffer for receiving data; we expect most transfers to fit.
+ */
+
+struct ec_i2c_device {
+ struct device *dev;
+ struct i2c_adapter adap;
+ struct cros_ec_device *ec;
+
+ u16 remote_bus;
+
+ u8 request_buf[256];
+ u8 response_buf[256];
+};
+
+/**
+ * ec_i2c_construct_message - construct a message to go to the EC
+ *
+ * This function effectively stuffs the standard i2c_msg format of Linux into
+ * a format that the EC understands.
+ *
+ * @buf: The buffer to fill. Can pass NULL to count how many bytes the message
+ * would be.
+ * @i2c_msgs: The i2c messages to read.
+ * @num: The number of i2c messages.
+ * @bus_num: The remote bus number we want to talk to.
+ *
+ * Returns the number of bytes that the message would take up or a negative
+ * error number.
+ */
+static int ec_i2c_construct_message(u8 *buf, const struct i2c_msg i2c_msgs[],
+ int num, u16 bus_num)
+{
+ struct ec_params_i2c_passthru *params;
+ u8 *out_data;
+ int i;
+ int size;
+
+ size = sizeof(struct ec_params_i2c_passthru);
+ size += num * sizeof(struct ec_params_i2c_passthru_msg);
+ out_data = buf + size;
+ for (i = 0; i < num; i++)
+ if (!(i2c_msgs[i].flags & I2C_M_RD))
+ size += i2c_msgs[i].len;
+
+ /* If there is no buffer, we can't build the message */
+ if (!buf)
+ return size;
+
+ params = (struct ec_params_i2c_passthru *)buf;
+ params->port = bus_num;
+ params->num_msgs = num;
+ for (i = 0; i < num; i++) {
+ const struct i2c_msg *i2c_msg = &i2c_msgs[i];
+ struct ec_params_i2c_passthru_msg *msg = ¶ms->msg[i];
+
+ msg->len = i2c_msg->len;
+ msg->addr_flags = i2c_msg->addr;
+
+ if (i2c_msg->flags & I2C_M_TEN)
+ msg->addr_flags |= EC_I2C_FLAG_10BIT;
+
+ if (i2c_msg->flags & I2C_M_RD) {
+ msg->addr_flags |= EC_I2C_FLAG_READ;
+ } else {
+ memcpy(out_data, i2c_msg->buf, msg->len);
+ out_data += msg->len;
+ }
+ }
+
+ return size;
+}
+
+/**
+ * ec_i2c_parse_response - Parse a response from the EC
+ *
+ * We'll take the EC's response and copy it back into msgs.
+ *
+ * @buf: The buffer to parse. Can pass NULL to count how many bytes we expect
+ * the response to be. Otherwise we assume that the right number of
+ * bytes are available.
+ * @i2c_msgs: The i2c messages to to fill up.
+ * @num: The number of i2c messages; will be modified to include the actual
+ * number received.
+ *
+ * Returns the number of response bytes or a negative error number.
+ */
+static int ec_i2c_parse_response(const u8 *buf, struct i2c_msg i2c_msgs[],
+ int *num)
+{
+ const struct ec_response_i2c_passthru *resp;
+ const u8 *in_data;
+ int size;
+ int i;
+
+ size = sizeof(struct ec_response_i2c_passthru);
+ in_data = buf + size;
+ for (i = 0; i < *num; i++)
+ if (i2c_msgs[i].flags & I2C_M_RD)
+ size += i2c_msgs[i].len;
+
+ if (buf == NULL)
+ return size;
+
+ resp = (const struct ec_response_i2c_passthru *)buf;
+ if (resp->i2c_status & EC_I2C_STATUS_TIMEOUT)
+ return -ETIMEDOUT;
+ else if (resp->i2c_status & EC_I2C_STATUS_ERROR)
+ return -EREMOTEIO;
+
+ /* Other side could send us back fewer messages, but not more */
+ if (resp->num_msgs > *num)
+ return -EPROTO;
+ *num = resp->num_msgs;
+
+ for (i = 0; i < *num; i++) {
+ struct i2c_msg *i2c_msg = &i2c_msgs[i];
+
+ if (i2c_msgs[i].flags & I2C_M_RD) {
+ memcpy(i2c_msg->buf, in_data, i2c_msg->len);
+ in_data += i2c_msg->len;
+ }
+ }
+
+ return size;
+}
+
+static int ec_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg i2c_msgs[],
+ int num)
+{
+ struct ec_i2c_device *bus = adap->algo_data;
+ struct device *dev = bus->dev;
+ const u16 bus_num = bus->remote_bus;
+ int request_len;
+ int response_len;
+ u8 *request = NULL;
+ u8 *response = NULL;
+ int result;
+
+ request_len = ec_i2c_construct_message(NULL, i2c_msgs, num, bus_num);
+ if (request_len < 0) {
+ dev_warn(dev, "Error constructing message %d\n", request_len);
+ result = request_len;
+ goto exit;
+ }
+ response_len = ec_i2c_parse_response(NULL, i2c_msgs, &num);
+ if (response_len < 0) {
+ /* Unexpected; no errors should come when NULL response */
+ dev_warn(dev, "Error preparing response %d\n", response_len);
+ result = response_len;
+ goto exit;
+ }
+
+ if (request_len <= ARRAY_SIZE(bus->request_buf)) {
+ request = bus->request_buf;
+ } else {
+ request = kzalloc(request_len, GFP_KERNEL);
+ if (request == NULL) {
+ result = -ENOMEM;
+ goto exit;
+ }
+ }
+ if (response_len <= ARRAY_SIZE(bus->response_buf)) {
+ response = bus->response_buf;
+ } else {
+ response = kzalloc(response_len, GFP_KERNEL);
+ if (response == NULL) {
+ result = -ENOMEM;
+ goto exit;
+ }
+ }
+
+ ec_i2c_construct_message(request, i2c_msgs, num, bus_num);
+ result = bus->ec->command_sendrecv(bus->ec, EC_CMD_I2C_PASSTHRU,
+ request, request_len,
+ response, response_len);
+ if (result)
+ goto exit;
+
+ result = ec_i2c_parse_response(response, i2c_msgs, &num);
+ if (result < 0)
+ goto exit;
+
+ /* Indicate success by saying how many messages were sent */
+ result = num;
+exit:
+ if (request != bus->request_buf)
+ kfree(request);
+ if (response != bus->response_buf)
+ kfree(response);
+
+ return result;
+}
+
+static u32 ec_i2c_functionality(struct i2c_adapter *adap)
+{
+ return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+}
+
+static const struct i2c_algorithm ec_i2c_algorithm = {
+ .master_xfer = ec_i2c_xfer,
+ .functionality = ec_i2c_functionality,
+};
+
+static int ec_i2c_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct cros_ec_device *ec = dev_get_drvdata(pdev->dev.parent);
+ struct device *dev = &pdev->dev;
+ struct ec_i2c_device *bus = NULL;
+ u32 remote_bus;
+ int err;
+
+ dev_dbg(dev, "Probing\n");
+
+ if (!np) {
+ dev_err(dev, "no device node\n");
+ return -ENOENT;
+ }
+
+ bus = devm_kzalloc(dev, sizeof(*bus), GFP_KERNEL);
+ if (bus == NULL) {
+ dev_err(dev, "cannot allocate bus device\n");
+ return -ENOMEM;
+ }
+
+ err = of_property_read_u32(np, "google,remote-bus", &remote_bus);
+ if (err) {
+ dev_err(dev, "Couldn't read remote-bus property\n");
+ return err;
+ }
+ bus->remote_bus = remote_bus;
+
+ bus->ec = ec;
+ bus->dev = dev;
+
+ bus->adap.owner = THIS_MODULE;
+ strlcpy(bus->adap.name, "cros-ec-i2c-tunnel", sizeof(bus->adap.name));
+ bus->adap.algo = &ec_i2c_algorithm;
+ bus->adap.algo_data = bus;
+ bus->adap.dev.parent = &pdev->dev;
+ bus->adap.dev.of_node = np;
+
+ err = i2c_add_adapter(&bus->adap);
+ if (err) {
+ dev_err(dev, "cannot register i2c adapter\n");
+ return err;
+ }
+ platform_set_drvdata(pdev, bus);
+
+ dev_dbg(dev, "ChromeOS EC I2C tunnel adapter\n");
+
+ return err;
+}
+
+static int ec_i2c_remove(struct platform_device *dev)
+{
+ struct ec_i2c_device *bus = platform_get_drvdata(dev);
+
+ platform_set_drvdata(dev, NULL);
+
+ i2c_del_adapter(&bus->adap);
+
+ return 0;
+}
+
+static struct platform_driver ec_i2c_tunnel_driver = {
+ .probe = ec_i2c_probe,
+ .remove = ec_i2c_remove,
+ .driver = {
+ .name = "cros-ec-i2c-tunnel",
+ },
+};
+
+module_platform_driver(ec_i2c_tunnel_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("EC I2C tunnel driver");
+MODULE_ALIAS("platform:cros-ec-i2c-tunnel");
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index c58ab96..61bc909 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -90,6 +90,11 @@ static const struct mfd_cell cros_devs[] = {
.id = 1,
.of_compatible = "google,cros-ec-keyb",
},
+ {
+ .name = "cros-ec-i2c-tunnel",
+ .id = 2,
+ .of_compatible = "google,cros-ec-i2c-tunnel",
+ },
};
int cros_ec_register(struct cros_ec_device *ec_dev)
--
1.9.1.423.g4596e3a
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [RESEND PATCH 6/7] i2c: ChromeOS EC tunnel driver
@ 2014-04-17 18:36 ` Doug Anderson
0 siblings, 0 replies; 7+ messages in thread
From: Doug Anderson @ 2014-04-17 18:36 UTC (permalink / raw
To: lee.jones-QSEj5FYQhm4dnm+yROfE0A, swarren-DDmLM1+adcrQT0dZR+AlfA,
wsa-z923LK4zBo2bacvFa/9K2g
Cc: abrestic-F7+t8E8rja9g9hUCZPvPmw, dgreid-F7+t8E8rja9g9hUCZPvPmw,
olof-nZhT3qVonbNeoWH0uzbU5w, sjg-F7+t8E8rja9g9hUCZPvPmw,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Doug Anderson,
Vincent Palatin, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, rdunlap-wEGCiKHe2LqWVfeAwA7xHQ,
sameo-VuQAYsv1563Yd54FQh9/CA, jdelvare-l3A5Bk7waGM,
shane.huang-5C7GfCeVMHo,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ,
bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g,
kevin.strasser-VuQAYsv1563Yd54FQh9/CA,
linux-ci5G2KO2hbZ+pU9mqzGVBQ, andrew-g2DYL2Zd6BY,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
schwidefsky-tA70FqPdS9bQT0dZR+AlfA,
matt.porter-QSEj5FYQhm4dnm+yROfE0A,
ch.naveen-Sze3O3UU22JBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
On ARM Chromebooks we have a few devices that are accessed by both the
AP (the main "Application Processor") and the EC (the Embedded
Controller). These are:
* The battery (sbs-battery).
* The power management unit tps65090.
On the original Samsung ARM Chromebook these devices were on an I2C
bus that was shared between the AP and the EC and arbitrated using
some extranal GPIOs (see i2c-arb-gpio-challenge).
The original arbitration scheme worked well enough but had some
downsides:
* It was nonstandard (not using standard I2C multimaster)
* It only worked if the EC-AP communication was I2C
* It was relatively hard to debug problems (hard to tell if i2c issues
were caused by the EC, the AP, or some device on the bus).
On the HP Chromebook 11 the design was changed to:
* The AP/EC comms were still i2c, but the battery/tps65090 were no
longer on the bus used for AP/EC communication. The battery was
exposed to the AP through a limited i2c tunnel and tps65090 was
exposed to the AP through a custom Linux driver.
On the Samsung ARM Chromebook 2 the scheme is changed yet again, now:
* The AP/EC comms are now using SPI for faster speeds.
* The EC's i2c bus is exposed to the AP through a full i2c tunnel.
The upstream "tegra124-venice2" uses the same scheme as the Samsung
ARM Chromebook 2, though it has a different set of components on the
other side of the bus.
This driver supports the scheme used by the Samsung ARM Chromebook 2.
Future patches to this driver could add support for the battery tunnel
on the HP Chromebook 11 (and perhaps could even be used to access
tps65090 on the HP Chromebook 11 instead of using a special driver,
but I haven't researched that enough).
Signed-off-by: Vincent Palatin <vpalatin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Tested-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
.../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt | 36 +++
drivers/i2c/busses/Kconfig | 9 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 304 +++++++++++++++++++++
drivers/mfd/cros_ec.c | 5 +
5 files changed, 355 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
new file mode 100644
index 0000000..30776bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
@@ -0,0 +1,36 @@
+I2C bus that tunnels through the ChromeOS EC (cros-ec)
+======================================================
+On some ChromeOS board designs we've got a connection to the EC (embedded
+controller) but no direct connection to some devices on the other side of
+the EC (like a battery and PMIC). To get access to those devices we need
+to tunnel our i2c commands through the EC.
+
+The node for this device should be under a cros-ec node like google,cros-ec-spi
+or google,cros-ec-i2c.
+
+
+Required properties:
+- compatible: google,cros-ec-i2c-tunnel
+- google,remote-bus: The EC bus we'd like to talk to.
+
+
+Example:
+ cros-ec@0 {
+ compatible = "google,cros-ec-spi";
+
+ ...
+
+ i2c-tunnel {
+ compatible = "google,cros-ec-i2c-tunnel";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ google,remote-bus = <0>;
+
+ battery: sbs-battery@b {
+ compatible = "sbs,sbs-battery";
+ reg = <0xb>;
+ sbs,poll-retry-count = <1>;
+ };
+ };
+ }
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c94db1c..9a0a6cc 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -993,6 +993,15 @@ config I2C_SIBYTE
help
Supports the SiByte SOC on-chip I2C interfaces (2 channels).
+config I2C_CROS_EC_TUNNEL
+ tristate "ChromeOS EC tunnel I2C bus"
+ depends on MFD_CROS_EC
+ help
+ If you say yes here you get an I2C bus that will tunnel i2c commands
+ through to the other side of the ChromeOS EC to the i2c bus
+ connected there. This will work whatever the interface used to
+ talk to the EC (SPI, I2C or LPC).
+
config SCx200_I2C
tristate "NatSemi SCx200 I2C using GPIO pins (DEPRECATED)"
depends on SCx200_GPIO
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 18d18ff..e110ca9 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -95,6 +95,7 @@ obj-$(CONFIG_I2C_VIPERBOARD) += i2c-viperboard.o
# Other I2C/SMBus bus drivers
obj-$(CONFIG_I2C_ACORN) += i2c-acorn.o
obj-$(CONFIG_I2C_BCM_KONA) += i2c-bcm-kona.o
+obj-$(CONFIG_I2C_CROS_EC_TUNNEL) += i2c-cros-ec-tunnel.o
obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
obj-$(CONFIG_I2C_PCA_ISA) += i2c-pca-isa.o
obj-$(CONFIG_I2C_SIBYTE) += i2c-sibyte.o
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
new file mode 100644
index 0000000..7e53fcb
--- /dev/null
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -0,0 +1,304 @@
+/*
+ * Copyright (C) 2013 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Expose an I2C passthrough to the ChromeOS EC.
+ */
+
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/mfd/cros_ec.h>
+#include <linux/mfd/cros_ec_commands.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+/**
+ * struct ec_i2c_device - Driver data for I2C tunnel
+ *
+ * @dev: Device node
+ * @adap: I2C adapter
+ * @ec: Pointer to EC device
+ * @remote_bus: The EC bus number we tunnel to on the other side.
+ * @request_buf: Buffer for transmitting data; we expect most transfers to fit.
+ * @response_buf: Buffer for receiving data; we expect most transfers to fit.
+ */
+
+struct ec_i2c_device {
+ struct device *dev;
+ struct i2c_adapter adap;
+ struct cros_ec_device *ec;
+
+ u16 remote_bus;
+
+ u8 request_buf[256];
+ u8 response_buf[256];
+};
+
+/**
+ * ec_i2c_construct_message - construct a message to go to the EC
+ *
+ * This function effectively stuffs the standard i2c_msg format of Linux into
+ * a format that the EC understands.
+ *
+ * @buf: The buffer to fill. Can pass NULL to count how many bytes the message
+ * would be.
+ * @i2c_msgs: The i2c messages to read.
+ * @num: The number of i2c messages.
+ * @bus_num: The remote bus number we want to talk to.
+ *
+ * Returns the number of bytes that the message would take up or a negative
+ * error number.
+ */
+static int ec_i2c_construct_message(u8 *buf, const struct i2c_msg i2c_msgs[],
+ int num, u16 bus_num)
+{
+ struct ec_params_i2c_passthru *params;
+ u8 *out_data;
+ int i;
+ int size;
+
+ size = sizeof(struct ec_params_i2c_passthru);
+ size += num * sizeof(struct ec_params_i2c_passthru_msg);
+ out_data = buf + size;
+ for (i = 0; i < num; i++)
+ if (!(i2c_msgs[i].flags & I2C_M_RD))
+ size += i2c_msgs[i].len;
+
+ /* If there is no buffer, we can't build the message */
+ if (!buf)
+ return size;
+
+ params = (struct ec_params_i2c_passthru *)buf;
+ params->port = bus_num;
+ params->num_msgs = num;
+ for (i = 0; i < num; i++) {
+ const struct i2c_msg *i2c_msg = &i2c_msgs[i];
+ struct ec_params_i2c_passthru_msg *msg = ¶ms->msg[i];
+
+ msg->len = i2c_msg->len;
+ msg->addr_flags = i2c_msg->addr;
+
+ if (i2c_msg->flags & I2C_M_TEN)
+ msg->addr_flags |= EC_I2C_FLAG_10BIT;
+
+ if (i2c_msg->flags & I2C_M_RD) {
+ msg->addr_flags |= EC_I2C_FLAG_READ;
+ } else {
+ memcpy(out_data, i2c_msg->buf, msg->len);
+ out_data += msg->len;
+ }
+ }
+
+ return size;
+}
+
+/**
+ * ec_i2c_parse_response - Parse a response from the EC
+ *
+ * We'll take the EC's response and copy it back into msgs.
+ *
+ * @buf: The buffer to parse. Can pass NULL to count how many bytes we expect
+ * the response to be. Otherwise we assume that the right number of
+ * bytes are available.
+ * @i2c_msgs: The i2c messages to to fill up.
+ * @num: The number of i2c messages; will be modified to include the actual
+ * number received.
+ *
+ * Returns the number of response bytes or a negative error number.
+ */
+static int ec_i2c_parse_response(const u8 *buf, struct i2c_msg i2c_msgs[],
+ int *num)
+{
+ const struct ec_response_i2c_passthru *resp;
+ const u8 *in_data;
+ int size;
+ int i;
+
+ size = sizeof(struct ec_response_i2c_passthru);
+ in_data = buf + size;
+ for (i = 0; i < *num; i++)
+ if (i2c_msgs[i].flags & I2C_M_RD)
+ size += i2c_msgs[i].len;
+
+ if (buf == NULL)
+ return size;
+
+ resp = (const struct ec_response_i2c_passthru *)buf;
+ if (resp->i2c_status & EC_I2C_STATUS_TIMEOUT)
+ return -ETIMEDOUT;
+ else if (resp->i2c_status & EC_I2C_STATUS_ERROR)
+ return -EREMOTEIO;
+
+ /* Other side could send us back fewer messages, but not more */
+ if (resp->num_msgs > *num)
+ return -EPROTO;
+ *num = resp->num_msgs;
+
+ for (i = 0; i < *num; i++) {
+ struct i2c_msg *i2c_msg = &i2c_msgs[i];
+
+ if (i2c_msgs[i].flags & I2C_M_RD) {
+ memcpy(i2c_msg->buf, in_data, i2c_msg->len);
+ in_data += i2c_msg->len;
+ }
+ }
+
+ return size;
+}
+
+static int ec_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg i2c_msgs[],
+ int num)
+{
+ struct ec_i2c_device *bus = adap->algo_data;
+ struct device *dev = bus->dev;
+ const u16 bus_num = bus->remote_bus;
+ int request_len;
+ int response_len;
+ u8 *request = NULL;
+ u8 *response = NULL;
+ int result;
+
+ request_len = ec_i2c_construct_message(NULL, i2c_msgs, num, bus_num);
+ if (request_len < 0) {
+ dev_warn(dev, "Error constructing message %d\n", request_len);
+ result = request_len;
+ goto exit;
+ }
+ response_len = ec_i2c_parse_response(NULL, i2c_msgs, &num);
+ if (response_len < 0) {
+ /* Unexpected; no errors should come when NULL response */
+ dev_warn(dev, "Error preparing response %d\n", response_len);
+ result = response_len;
+ goto exit;
+ }
+
+ if (request_len <= ARRAY_SIZE(bus->request_buf)) {
+ request = bus->request_buf;
+ } else {
+ request = kzalloc(request_len, GFP_KERNEL);
+ if (request == NULL) {
+ result = -ENOMEM;
+ goto exit;
+ }
+ }
+ if (response_len <= ARRAY_SIZE(bus->response_buf)) {
+ response = bus->response_buf;
+ } else {
+ response = kzalloc(response_len, GFP_KERNEL);
+ if (response == NULL) {
+ result = -ENOMEM;
+ goto exit;
+ }
+ }
+
+ ec_i2c_construct_message(request, i2c_msgs, num, bus_num);
+ result = bus->ec->command_sendrecv(bus->ec, EC_CMD_I2C_PASSTHRU,
+ request, request_len,
+ response, response_len);
+ if (result)
+ goto exit;
+
+ result = ec_i2c_parse_response(response, i2c_msgs, &num);
+ if (result < 0)
+ goto exit;
+
+ /* Indicate success by saying how many messages were sent */
+ result = num;
+exit:
+ if (request != bus->request_buf)
+ kfree(request);
+ if (response != bus->response_buf)
+ kfree(response);
+
+ return result;
+}
+
+static u32 ec_i2c_functionality(struct i2c_adapter *adap)
+{
+ return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+}
+
+static const struct i2c_algorithm ec_i2c_algorithm = {
+ .master_xfer = ec_i2c_xfer,
+ .functionality = ec_i2c_functionality,
+};
+
+static int ec_i2c_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct cros_ec_device *ec = dev_get_drvdata(pdev->dev.parent);
+ struct device *dev = &pdev->dev;
+ struct ec_i2c_device *bus = NULL;
+ u32 remote_bus;
+ int err;
+
+ dev_dbg(dev, "Probing\n");
+
+ if (!np) {
+ dev_err(dev, "no device node\n");
+ return -ENOENT;
+ }
+
+ bus = devm_kzalloc(dev, sizeof(*bus), GFP_KERNEL);
+ if (bus == NULL) {
+ dev_err(dev, "cannot allocate bus device\n");
+ return -ENOMEM;
+ }
+
+ err = of_property_read_u32(np, "google,remote-bus", &remote_bus);
+ if (err) {
+ dev_err(dev, "Couldn't read remote-bus property\n");
+ return err;
+ }
+ bus->remote_bus = remote_bus;
+
+ bus->ec = ec;
+ bus->dev = dev;
+
+ bus->adap.owner = THIS_MODULE;
+ strlcpy(bus->adap.name, "cros-ec-i2c-tunnel", sizeof(bus->adap.name));
+ bus->adap.algo = &ec_i2c_algorithm;
+ bus->adap.algo_data = bus;
+ bus->adap.dev.parent = &pdev->dev;
+ bus->adap.dev.of_node = np;
+
+ err = i2c_add_adapter(&bus->adap);
+ if (err) {
+ dev_err(dev, "cannot register i2c adapter\n");
+ return err;
+ }
+ platform_set_drvdata(pdev, bus);
+
+ dev_dbg(dev, "ChromeOS EC I2C tunnel adapter\n");
+
+ return err;
+}
+
+static int ec_i2c_remove(struct platform_device *dev)
+{
+ struct ec_i2c_device *bus = platform_get_drvdata(dev);
+
+ platform_set_drvdata(dev, NULL);
+
+ i2c_del_adapter(&bus->adap);
+
+ return 0;
+}
+
+static struct platform_driver ec_i2c_tunnel_driver = {
+ .probe = ec_i2c_probe,
+ .remove = ec_i2c_remove,
+ .driver = {
+ .name = "cros-ec-i2c-tunnel",
+ },
+};
+
+module_platform_driver(ec_i2c_tunnel_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("EC I2C tunnel driver");
+MODULE_ALIAS("platform:cros-ec-i2c-tunnel");
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index c58ab96..61bc909 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -90,6 +90,11 @@ static const struct mfd_cell cros_devs[] = {
.id = 1,
.of_compatible = "google,cros-ec-keyb",
},
+ {
+ .name = "cros-ec-i2c-tunnel",
+ .id = 2,
+ .of_compatible = "google,cros-ec-i2c-tunnel",
+ },
};
int cros_ec_register(struct cros_ec_device *ec_dev)
--
1.9.1.423.g4596e3a
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [RESEND PATCH 6/7] i2c: ChromeOS EC tunnel driver
2014-04-17 18:36 ` Doug Anderson
(?)
@ 2014-04-21 17:53 ` Stephen Warren
2014-04-21 19:25 ` Doug Anderson
-1 siblings, 1 reply; 7+ messages in thread
From: Stephen Warren @ 2014-04-21 17:53 UTC (permalink / raw
To: Doug Anderson, lee.jones, swarren, wsa
Cc: abrestic, dgreid, olof, sjg, linux-samsung-soc, linux-tegra,
Vincent Palatin, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, rdunlap, sameo, jdelvare, shane.huang,
maxime.ripard, laurent.pinchart+renesas, u.kleine-koenig,
bjorn.andersson, kevin.strasser, linux, andrew, andriy.shevchenko,
schwidefsky, matt.porter, ch.naveen, devicetree, linux-doc,
linux-kernel, linux-i2c
On 04/17/2014 12:36 PM, Doug Anderson wrote:
> On ARM Chromebooks we have a few devices that are accessed by both the
> AP (the main "Application Processor") and the EC (the Embedded
> Controller). These are:
> * The battery (sbs-battery).
> * The power management unit tps65090.
...
> On the Samsung ARM Chromebook 2 the scheme is changed yet again, now:
> * The AP/EC comms are now using SPI for faster speeds.
> * The EC's i2c bus is exposed to the AP through a full i2c tunnel.
...
> This driver supports the scheme used by the Samsung ARM Chromebook 2.
> Future patches to this driver could add support for the battery tunnel
> on the HP Chromebook 11 (and perhaps could even be used to access
> tps65090 on the HP Chromebook 11 instead of using a special driver,
> but I haven't researched that enough).
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
> +I2C bus that tunnels through the ChromeOS EC (cros-ec)
> +======================================================
> +On some ChromeOS board designs we've got a connection to the EC (embedded
> +controller) but no direct connection to some devices on the other side of
> +the EC (like a battery and PMIC). To get access to those devices we need
> +to tunnel our i2c commands through the EC.
> +
> +The node for this device should be under a cros-ec node like google,cros-ec-spi
> +or google,cros-ec-i2c.
> +
> +
> +Required properties:
> +- compatible: google,cros-ec-i2c-tunnel
> +- google,remote-bus: The EC bus we'd like to talk to.
It's probably worth mentioning here that the node represents a single
I2C bus, and hence is expected to contain child nodes representing I2C
devices. Perhaps:
Optional child nodes:
- One node per I2C device connected to the tunnelled I2C bus.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RESEND PATCH 6/7] i2c: ChromeOS EC tunnel driver
2014-04-21 17:53 ` Stephen Warren
@ 2014-04-21 19:25 ` Doug Anderson
0 siblings, 0 replies; 7+ messages in thread
From: Doug Anderson @ 2014-04-21 19:25 UTC (permalink / raw
To: Stephen Warren
Cc: Lee Jones, Stephen Warren, Wolfram Sang, Andrew Bresticker,
Dylan Reid, Olof Johansson, Simon Glass, linux-samsung-soc,
linux-tegra@vger.kernel.org, Vincent Palatin, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Randy Dunlap,
Samuel Ortiz, jdelvare, shane.huang, maxime.ripard,
laurent.pinchart+renesas, u.kleine-koenig, bjorn.andersson,
kevin.strasser, linux, andrew, andriy.shevchenko, schwidefsky,
matt.porter, naveen krishna, devicetree@vger.kernel.org,
linux-doc, linux-kernel@vger.kernel.org,
linux-i2c@vger.kernel.org
Stephen,
On Mon, Apr 21, 2014 at 10:53 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 04/17/2014 12:36 PM, Doug Anderson wrote:
>> On ARM Chromebooks we have a few devices that are accessed by both the
>> AP (the main "Application Processor") and the EC (the Embedded
>> Controller). These are:
>> * The battery (sbs-battery).
>> * The power management unit tps65090.
> ...
>> On the Samsung ARM Chromebook 2 the scheme is changed yet again, now:
>> * The AP/EC comms are now using SPI for faster speeds.
>> * The EC's i2c bus is exposed to the AP through a full i2c tunnel.
> ...
>> This driver supports the scheme used by the Samsung ARM Chromebook 2.
>> Future patches to this driver could add support for the battery tunnel
>> on the HP Chromebook 11 (and perhaps could even be used to access
>> tps65090 on the HP Chromebook 11 instead of using a special driver,
>> but I haven't researched that enough).
>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
>
>> +I2C bus that tunnels through the ChromeOS EC (cros-ec)
>> +======================================================
>> +On some ChromeOS board designs we've got a connection to the EC (embedded
>> +controller) but no direct connection to some devices on the other side of
>> +the EC (like a battery and PMIC). To get access to those devices we need
>> +to tunnel our i2c commands through the EC.
>> +
>> +The node for this device should be under a cros-ec node like google,cros-ec-spi
>> +or google,cros-ec-i2c.
>> +
>> +
>> +Required properties:
>> +- compatible: google,cros-ec-i2c-tunnel
>> +- google,remote-bus: The EC bus we'd like to talk to.
>
> It's probably worth mentioning here that the node represents a single
> I2C bus, and hence is expected to contain child nodes representing I2C
> devices. Perhaps:
>
> Optional child nodes:
> - One node per I2C device connected to the tunnelled I2C bus.
That sounds great. I'll wait another day or two for additional
feedback and then send out with this fix.
-Doug
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-04-21 19:25 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-04-17 18:36 [RESEND PATCH 0/7] Add cros_ec changes for newer boards Doug Anderson
2014-04-17 18:36 ` Doug Anderson
2014-04-17 18:36 ` Doug Anderson
2014-04-17 18:36 ` [RESEND PATCH 6/7] i2c: ChromeOS EC tunnel driver Doug Anderson
2014-04-17 18:36 ` Doug Anderson
2014-04-21 17:53 ` Stephen Warren
2014-04-21 19:25 ` Doug Anderson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.