* [PATCH 0/7] Add cros_ec changes for newer boards @ 2014-04-17 17:59 Doug Anderson 2014-04-17 17:59 ` [PATCH 6/7] i2c: ChromeOS EC tunnel driver Doug Anderson ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Doug Anderson @ 2014-04-17 17:59 UTC (permalink / raw) To: Lee Jones, Stephen Warren, Wolfram Sang Cc: Mark Rutland, Andrew Lunn, linux-doc, abrestic, linux-kernel, Thierry Reding, linux-i2c, Matt Porter, Jean Delvare, linux-samsung-soc, Russell King, Samuel Ortiz, Stephen Warren, Bjorn Andersson, Uwe Kleine-König, Kevin Strasser, dgreid, devicetree, Pawel Moll, Ian Campbell, Martin Schwidefsky, Rob Herring, linux-tegra, Vincent Palatin 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] 12+ messages in thread
* [PATCH 6/7] i2c: ChromeOS EC tunnel driver 2014-04-17 17:59 [PATCH 0/7] Add cros_ec changes for newer boards Doug Anderson @ 2014-04-17 17:59 ` Doug Anderson 2014-04-17 18:16 ` Doug Anderson 2014-04-17 17:59 ` [PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 Doug Anderson 2014-04-17 18:23 ` [PATCH 0/7] Add cros_ec changes for newer boards Andrew Bresticker 2 siblings, 1 reply; 12+ messages in thread From: Doug Anderson @ 2014-04-17 17:59 UTC (permalink / raw) To: Lee Jones, Stephen Warren, Wolfram Sang Cc: abrestic, dgreid, Olof Johansson, Simon Glass, linux-samsung-soc, linux-tegra, Doug Anderson, Vincent Palatin, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Randy Dunlap, Samuel Ortiz, Jean Delvare, Shane Huang, Maxime Ripard, Laurent Pinchart, Uwe Kleine-König, Bjorn Andersson, Kevin Strasser, Tony Prisk, Andrew Lunn, Andy Shevchenko, Martin Schwidefsky, Matt Porter, Naveen Krishna Ch, 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> --- .../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] 12+ messages in thread
* Re: [PATCH 6/7] i2c: ChromeOS EC tunnel driver 2014-04-17 17:59 ` [PATCH 6/7] i2c: ChromeOS EC tunnel driver Doug Anderson @ 2014-04-17 18:16 ` Doug Anderson 0 siblings, 0 replies; 12+ messages in thread From: Doug Anderson @ 2014-04-17 18:16 UTC (permalink / raw) To: Lee Jones, Stephen Warren, Wolfram Sang Cc: Andrew Bresticker, Dylan Reid, Olof Johansson, Simon Glass, linux-samsung-soc, linux-tegra@vger.kernel.org, Doug Anderson, 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 On Thu, Apr 17, 2014 at 10:59 AM, Doug Anderson <dianders@chromium.org> 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 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> > --- > .../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(+) Argh, I think patch 6 (and probably the cover letter) hit my favorite "too many characters in the CC list" and didn't make it up to the lists. :( Since I can't quite imagine this being Ack-ed on V1, I'll make sure I address this issue before sending out version 2. If you somehow can't find the patch and want to review it ASAP then please let me know and I'll send it your way. I'll also try to find a way to resend just patch #6 with my current workflow shortly... ;) -Doug ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 2014-04-17 17:59 [PATCH 0/7] Add cros_ec changes for newer boards Doug Anderson 2014-04-17 17:59 ` [PATCH 6/7] i2c: ChromeOS EC tunnel driver Doug Anderson @ 2014-04-17 17:59 ` Doug Anderson 2014-04-21 18:18 ` Stephen Warren [not found] ` <1397757570-19750-8-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> 2014-04-17 18:23 ` [PATCH 0/7] Add cros_ec changes for newer boards Andrew Bresticker 2 siblings, 2 replies; 12+ messages in thread From: Doug Anderson @ 2014-04-17 17:59 UTC (permalink / raw) To: Lee Jones, Stephen Warren, Wolfram Sang Cc: abrestic, dgreid, Olof Johansson, Simon Glass, linux-samsung-soc, linux-tegra, Doug Anderson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Stephen Warren, Thierry Reding, devicetree, linux-arm-kernel, linux-kernel This adds the EC i2c tunnel (and devices under it) to the tegra124-venice2 device tree. Signed-off-by: Doug Anderson <dianders@chromium.org> --- arch/arm/boot/dts/tegra124-venice2.dts | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts index c17283c..df97d15 100644 --- a/arch/arm/boot/dts/tegra124-venice2.dts +++ b/arch/arm/boot/dts/tegra124-venice2.dts @@ -8,6 +8,7 @@ compatible = "nvidia,venice2", "nvidia,tegra124"; aliases { + i2c20 = "/spi@0,7000d400/cros-ec@0/i2c-tunnel"; rtc0 = "/i2c@0,7000d000/pmic@40"; rtc1 = "/rtc@0,7000e000"; }; @@ -813,6 +814,32 @@ google,cros-ec-spi-msg-delay = <2000>; + i2c-tunnel { + compatible = "google,cros-ec-i2c-tunnel"; + #address-cells = <1>; + #size-cells = <0>; + + google,remote-bus = <0>; + + charger: bq24735@9 { + compatible = "ti,bq24735"; + reg = <0x9>; + interrupt-parent = <&gpio>; + interrupts = <TEGRA_GPIO(J, 0) + GPIO_ACTIVE_HIGH>; + ti,ac-detect-gpios = <&gpio + TEGRA_GPIO(J, 0) + GPIO_ACTIVE_HIGH>; + }; + + battery: sbs-battery@b { + compatible = "sbs,sbs-battery"; + reg = <0xb>; + sbs,i2c-retry-count = <2>; + sbs,poll-retry-count = <1>; + }; + }; + cros-ec-keyb { compatible = "google,cros-ec-keyb"; keypad,num-rows = <8>; -- 1.9.1.423.g4596e3a ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 2014-04-17 17:59 ` [PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 Doug Anderson @ 2014-04-21 18:18 ` Stephen Warren [not found] ` <535560E9.5040108-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> [not found] ` <1397757570-19750-8-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> 1 sibling, 1 reply; 12+ messages in thread From: Stephen Warren @ 2014-04-21 18:18 UTC (permalink / raw) To: Doug Anderson, Lee Jones, Stephen Warren, Wolfram Sang Cc: abrestic, dgreid, Olof Johansson, Simon Glass, linux-samsung-soc, linux-tegra, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Thierry Reding, devicetree, linux-arm-kernel, linux-kernel On 04/17/2014 11:59 AM, Doug Anderson wrote: > This adds the EC i2c tunnel (and devices under it) to the > tegra124-venice2 device tree. The series, Tested-by: Stephen Warren <swarren@nvidia.com> I can apply this one patch once the other patches in the series are acked or applied (in order to make sure the DT binding is acceptable to others). I guess I'll send separate patches for tegra_defconfig and multi_v7_defconfig to add the required options once I've applied this, unless you beat me to it. > diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts > aliases { > + i2c20 = "/spi@0,7000d400/cros-ec@0/i2c-tunnel"; Is that needed? I'd prefer not to add it unless there's a specific reason. I don't think I2C buses need specific names, do they? ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <535560E9.5040108-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]
* Re: [PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 [not found] ` <535560E9.5040108-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> @ 2014-04-21 19:35 ` Doug Anderson 2014-04-21 20:03 ` Stephen Warren 0 siblings, 1 reply; 12+ messages in thread From: Doug Anderson @ 2014-04-21 19:35 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Thierry Reding, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Stephen, On Mon, Apr 21, 2014 at 11:18 AM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote: > On 04/17/2014 11:59 AM, Doug Anderson wrote: >> This adds the EC i2c tunnel (and devices under it) to the >> tegra124-venice2 device tree. > > The series, > Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> > > I can apply this one patch once the other patches in the series are > acked or applied (in order to make sure the DT binding is acceptable to > others). Sounds good. If I don't get any feedback (positive or negative) in the next few days I'll resend with your Tested-by. > I guess I'll send separate patches for tegra_defconfig and > multi_v7_defconfig to add the required options once I've applied this, > unless you beat me to it. > >> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts > >> aliases { >> + i2c20 = "/spi@0,7000d400/cros-ec@0/i2c-tunnel"; > > Is that needed? I'd prefer not to add it unless there's a specific > reason. I don't think I2C buses need specific names, do they? It is not strictly needed, but from a usability standpoint it is terribly helpful. It serves to make it obvious to someone looking at the device that it's _not_ an i2c bus associated with the main SoC. If you don't include a number I believe that the i2c core will pick the first available number. It seems worth it to save a few people a few hours of head scratching. ...but this is your dts and if you think it's a terrible idea then I'll remove it. It looks to be less critical on tegra than it is on exynos (which has ~9 i2c busses, they are numbered in the user manual, and if you have one set to "disable" in the dts then the tunnel will end up getting a very confusing number). -Doug ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 2014-04-21 19:35 ` Doug Anderson @ 2014-04-21 20:03 ` Stephen Warren 0 siblings, 0 replies; 12+ messages in thread From: Stephen Warren @ 2014-04-21 20:03 UTC (permalink / raw) To: Doug Anderson Cc: Lee Jones, Stephen Warren, Wolfram Sang, Andrew Bresticker, Dylan Reid, Olof Johansson, Simon Glass, linux-samsung-soc, linux-tegra@vger.kernel.org, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Thierry Reding, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org On 04/21/2014 01:35 PM, Doug Anderson wrote: > Stephen, > > On Mon, Apr 21, 2014 at 11:18 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 04/17/2014 11:59 AM, Doug Anderson wrote: >>> This adds the EC i2c tunnel (and devices under it) to the >>> tegra124-venice2 device tree. >>> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts >> >>> aliases { >>> + i2c20 = "/spi@0,7000d400/cros-ec@0/i2c-tunnel"; >> >> Is that needed? I'd prefer not to add it unless there's a specific >> reason. I don't think I2C buses need specific names, do they? > > It is not strictly needed, but from a usability standpoint it is > terribly helpful. It serves to make it obvious to someone looking at > the device that it's _not_ an i2c bus associated with the main SoC. > If you don't include a number I believe that the i2c core will pick > the first available number. > > It seems worth it to save a few people a few hours of head scratching. > > ...but this is your dts and if you think it's a terrible idea then > I'll remove it. It looks to be less critical on tegra than it is on > exynos (which has ~9 i2c busses, they are numbered in the user manual, > and if you have one set to "disable" in the dts then the tunnel will > end up getting a very confusing number). My opinion is that the in-kernel I2C bus numbering is an entirely unrelated numbering space to the HW controller numbering space precisely because of issues like that. DT aliases are more useful for user-visible port numbering (e.g. HDMI 0, 1 connectors on a case) than purely internal details like this. So, I would leave it out. ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <1397757570-19750-8-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>]
* Re: [PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 [not found] ` <1397757570-19750-8-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> @ 2014-05-15 18:42 ` Stephen Warren [not found] ` <53750A9A.8000808-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 0 siblings, 1 reply; 12+ messages in thread From: Stephen Warren @ 2014-05-15 18:42 UTC (permalink / raw) To: Doug Anderson, Lee Jones, Wolfram Sang Cc: Stephen Warren, abrestic-F7+t8E8rja9g9hUCZPvPmw, dgreid-F7+t8E8rja9g9hUCZPvPmw, Olof Johansson, Simon Glass, linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Thierry Reding, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA On 04/17/2014 11:59 AM, Doug Anderson wrote: > This adds the EC i2c tunnel (and devices under it) to the > tegra124-venice2 device tree. Did the MFD patches at the start of this series get applied yet? I was hoping to apply this one patch to the Tegra tree for 3.16, and that needs to happen by tomorrow morning at the latest since -rc6 is looming fast. However, I'm holding off until the rest of the series is applied to the MFD tree so I can be sure the DT binding is accepted first... ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <53750A9A.8000808-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]
* Re: [PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 [not found] ` <53750A9A.8000808-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> @ 2014-05-15 18:55 ` Doug Anderson 2014-05-15 20:12 ` Olof Johansson 0 siblings, 1 reply; 12+ messages in thread From: Doug Anderson @ 2014-05-15 18:55 UTC (permalink / raw) To: Stephen Warren Cc: Lee Jones, Wolfram Sang, Stephen Warren, Andrew Bresticker, Dylan Reid, Olof Johansson, Simon Glass, linux-samsung-soc, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Thierry Reding, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Stephen, On Thu, May 15, 2014 at 11:42 AM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote: > On 04/17/2014 11:59 AM, Doug Anderson wrote: >> This adds the EC i2c tunnel (and devices under it) to the >> tegra124-venice2 device tree. > > Did the MFD patches at the start of this series get applied yet? I was > hoping to apply this one patch to the Tegra tree for 3.16, and that > needs to happen by tomorrow morning at the latest since -rc6 is looming > fast. However, I'm holding off until the rest of the series is applied > to the MFD tree so I can be sure the DT binding is accepted first... As far as I know, they didn't. Lee was waiting on Wolfram's ack to the i2c tunnel before landing them. ...and I'm still eagerly awaiting Wolfram's next i2c tunnel review. -Doug ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 2014-05-15 18:55 ` Doug Anderson @ 2014-05-15 20:12 ` Olof Johansson 2014-05-19 9:18 ` Lee Jones 0 siblings, 1 reply; 12+ messages in thread From: Olof Johansson @ 2014-05-15 20:12 UTC (permalink / raw) To: Doug Anderson Cc: Stephen Warren, Lee Jones, Wolfram Sang, Stephen Warren, Andrew Bresticker, Dylan Reid, Simon Glass, linux-samsung-soc, linux-tegra@vger.kernel.org, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Thierry Reding, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org On Thu, May 15, 2014 at 11:55 AM, Doug Anderson <dianders@chromium.org> wrote: > Stephen, > > On Thu, May 15, 2014 at 11:42 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 04/17/2014 11:59 AM, Doug Anderson wrote: >>> This adds the EC i2c tunnel (and devices under it) to the >>> tegra124-venice2 device tree. >> >> Did the MFD patches at the start of this series get applied yet? I was >> hoping to apply this one patch to the Tegra tree for 3.16, and that >> needs to happen by tomorrow morning at the latest since -rc6 is looming >> fast. However, I'm holding off until the rest of the series is applied >> to the MFD tree so I can be sure the DT binding is accepted first... > > As far as I know, they didn't. Lee was waiting on Wolfram's ack to > the i2c tunnel before landing them. ...and I'm still eagerly awaiting > Wolfram's next i2c tunnel review. The i2c portion can be revisited if needed, the MFD piece should be possible to land sooner than that... Lee? -Olof ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 2014-05-15 20:12 ` Olof Johansson @ 2014-05-19 9:18 ` Lee Jones 0 siblings, 0 replies; 12+ messages in thread From: Lee Jones @ 2014-05-19 9:18 UTC (permalink / raw) To: Olof Johansson Cc: Doug Anderson, Stephen Warren, Wolfram Sang, Stephen Warren, Andrew Bresticker, Dylan Reid, Simon Glass, linux-samsung-soc, linux-tegra@vger.kernel.org, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Thierry Reding, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org On Thu, 15 May 2014, Olof Johansson wrote: > On Thu, May 15, 2014 at 11:55 AM, Doug Anderson <dianders@chromium.org> wrote: > > Stephen, > > > > On Thu, May 15, 2014 at 11:42 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: > >> On 04/17/2014 11:59 AM, Doug Anderson wrote: > >>> This adds the EC i2c tunnel (and devices under it) to the > >>> tegra124-venice2 device tree. > >> > >> Did the MFD patches at the start of this series get applied yet? I was > >> hoping to apply this one patch to the Tegra tree for 3.16, and that > >> needs to happen by tomorrow morning at the latest since -rc6 is looming > >> fast. However, I'm holding off until the rest of the series is applied > >> to the MFD tree so I can be sure the DT binding is accepted first... > > > > As far as I know, they didn't. Lee was waiting on Wolfram's ack to > > the i2c tunnel before landing them. ...and I'm still eagerly awaiting > > Wolfram's next i2c tunnel review. > > The i2c portion can be revisited if needed, the MFD piece should be > possible to land sooner than that... Lee? The set 'will' make it in during this cycle. The trouble is, once it's applied, the I2C portion will have to wait until the next cycle. By applying late, I'm giving this set every chance to go in as a whole. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 0/7] Add cros_ec changes for newer boards 2014-04-17 17:59 [PATCH 0/7] Add cros_ec changes for newer boards Doug Anderson 2014-04-17 17:59 ` [PATCH 6/7] i2c: ChromeOS EC tunnel driver Doug Anderson 2014-04-17 17:59 ` [PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 Doug Anderson @ 2014-04-17 18:23 ` Andrew Bresticker 2 siblings, 0 replies; 12+ messages in thread From: Andrew Bresticker @ 2014-04-17 18:23 UTC (permalink / raw) To: Doug Anderson Cc: Mark Rutland, Andrew Lunn, Stephen Warren, Wolfram Sang, Thierry Reding, linux-i2c, Vincent Palatin, Matt Porter, Lee Jones, Jean Delvare, linux-samsung-soc, Stephen Warren, Samuel Ortiz, linux-doc, Bjorn Andersson, Uwe Kleine-König, Kevin Strasser, Dylan Reid, devicetree, Pawel Moll, Ian Campbell, Martin Schwidefsky Doug, > 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. I can now talk to the charger and battery over the tunnel on my Venice2 and other communication with the EC still works, so: Tested-by: Andrew Bresticker <abrestic@chromium.org> ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-05-19 9:18 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-04-17 17:59 [PATCH 0/7] Add cros_ec changes for newer boards Doug Anderson 2014-04-17 17:59 ` [PATCH 6/7] i2c: ChromeOS EC tunnel driver Doug Anderson 2014-04-17 18:16 ` Doug Anderson 2014-04-17 17:59 ` [PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 Doug Anderson 2014-04-21 18:18 ` Stephen Warren [not found] ` <535560E9.5040108-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2014-04-21 19:35 ` Doug Anderson 2014-04-21 20:03 ` Stephen Warren [not found] ` <1397757570-19750-8-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> 2014-05-15 18:42 ` Stephen Warren [not found] ` <53750A9A.8000808-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2014-05-15 18:55 ` Doug Anderson 2014-05-15 20:12 ` Olof Johansson 2014-05-19 9:18 ` Lee Jones 2014-04-17 18:23 ` [PATCH 0/7] Add cros_ec changes for newer boards Andrew Bresticker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).