[PATCH v2 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[PATCH v2 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Doug Anderson]

The i2c-arbitrator-cros-ec driver implements the arbitration scheme
that the Embedded Controller (EC) on the ARM Chromebook expects to use
for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
be used in other places where standard I2C bus arbitration can't be
used and two extra GPIOs are available for arbitration.

This driver is based on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
mux driver is as suggested by Grant Likely.  See
<https://patchwork.kernel.org/patch/1877311/> for some history.

Signed-off-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
Changes in v2:
- Renamed to i2c-arbitrator-cros-ec.
- Documented "microsecond" properties as optional; removed
  "bus-arbitration" prefix since it was just extra wordy.
- Split GPIOs into two properties to make it cleaner.
- Capitalized I2C in freeform text.
- Get GPIO active_low from device tree.

 .../bindings/i2c/i2c-arbitrator-cros-ec.txt        |  76 +++++++
 drivers/i2c/muxes/Kconfig                          |  11 +
 drivers/i2c/muxes/Makefile                         |   2 +
 drivers/i2c/muxes/i2c-arbitrator-cros-ec.c         | 232 +++++++++++++++++++++
 4 files changed, 321 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
 create mode 100644 drivers/i2c/muxes/i2c-arbitrator-cros-ec.c

diff --git a/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt b/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
new file mode 100644
index 0000000..1f893e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
@@ -0,0 +1,76 @@
+GPIO-based Arbitration used by the ARM Chromebook (exynos5250-snow)
+===================================================================
+This uses GPIO lines between the AP (Application Processor) and an attached
+EC (Embedded Controller) which both want to talk on the same I2C bus as master.
+
+The AP and EC each have a 'bus claim' line, which is an output that the
+other can see. These are both active low, with pull-ups enabled.
+
+- AP_CLAIM: output from AP, signalling to the EC that the AP wants the bus
+- EC_CLAIM: output from EC, signalling to the AP that the EC wants the bus
+
+This mechanism is used instead of standard I2C multimaster to avoid some of the
+subtle driver and silicon bugs that are often present with I2C multimaster.
+
+
+Algorithm:
+
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also. A detailed explanation is best
+done with an example.
+
+Let's say the AP wants to claim the bus. It:
+1. Asserts AP_CLAIM.
+2. Waits a little bit for the other side to notice (slew time, say 10
+   microseconds).
+3. Checks EC_CLAIM. If this is not asserted then the AP has the bus and we are
+   done.
+4. Otherwise, wait for a few milliseconds and see if EC_CLAIM is released.
+5. If not, back off, release the claim and wait for a few more milliseconds.
+6. Go back to 1 (until retry time has expired).
+
+
+Required properties:
+- compatible: i2c-arbitrator-cros-ec
+- ap-claim-gpio: The GPIO that we (the AP) use to claim the bus.
+- ec-claim-gpio: The GPIO that the other side (the EC) uses the claim the bus.
+- Standard I2C mux properties. See mux.txt in this directory.
+- Single I2C child bus node at reg 0. See mux.txt in this directory.
+
+Optional properties:
+- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
+- wait-retry-us: we'll attempt another claim after this many microseconds.
+    Default is 3000 us.
+- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
+
+
+Example:
+	i2c@12CA0000 {
+		compatible = "acme,some-i2c-device";
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+	i2c-arbitrator {
+		compatible = "i2c-arbitrator-cros-ec";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		ap-claim-gpio = <&gpf0 3 1 0x10000 0>;
+		ec-claim-gpio = <&gpe0 4 0 0x10003 0>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			i2c@52 {
+				// Normal I2C device
+			};
+		};
+	};
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 0be5b83..ca19378 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -5,6 +5,17 @@
 menu "Multiplexer I2C Chip support"
 	depends on I2C_MUX
 
+config I2C_ARBITRATOR_CROS_EC
+	tristate "GPIO-based I2C arbitrator used on exynos5250-snow"
+	depends on GENERIC_GPIO && OF
+	help
+	  If you say yes to this option, support will be included for an
+	  I2C multimaster arbitration scheme using GPIOs that is used in
+	  the Samsung ARM Chromebook (exynos5250-snow).
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called i2c-arbitrator-cros-ec.
+
 config I2C_MUX_GPIO
 	tristate "GPIO-based I2C multiplexer"
 	depends on GENERIC_GPIO
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 76da869..e60dcc1 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -1,6 +1,8 @@
 #
 # Makefile for multiplexer I2C chip drivers.
 
+obj-$(CONFIG_I2C_ARBITRATOR_CROS_EC)	+= i2c-arbitrator-cros-ec.o
+
 obj-$(CONFIG_I2C_MUX_GPIO)	+= i2c-mux-gpio.o
 obj-$(CONFIG_I2C_MUX_PCA9541)	+= i2c-mux-pca9541.o
 obj-$(CONFIG_I2C_MUX_PCA954x)	+= i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c b/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c
new file mode 100644
index 0000000..5aa36b8
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c
@@ -0,0 +1,232 @@
+/*
+ * I2C arbitrator driver for the ARM Chromebook
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/kernel.h>
+#include <linux/i2c.h>
+#include <linux/i2c-mux.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_i2c.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+
+/**
+ * struct i2c_arbitrator_data - Driver data for I2C arbitrator
+ *
+ * @parent: Parent adapter
+ * @child: Child bus
+ * @ap_gpio: GPIO we'll use to claim.
+ * @ap_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO == this
+ *   then consider it released.
+ * @ec_gpio: GPIO that the other side will use to claim.
+ * @ec_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO == this
+ *   then consider it released.
+ * @slew_delay_us: microseconds to wait for a GPIO to go high.
+ * @wait_retry_us: we'll attempt another claim after this many microseconds.
+ * @wait_free_us: we'll give up after this many microseconds.
+ */
+
+struct i2c_arbitrator_data {
+	struct i2c_adapter *parent;
+	struct i2c_adapter *child;
+
+	int		ap_gpio;
+	int		ap_gpio_release;
+	int		ec_gpio;
+	int		ec_gpio_release;
+	unsigned int	slew_delay_us;
+	unsigned int	wait_retry_us;
+	unsigned int	wait_free_us;
+};
+
+
+/**
+ * i2c_arbitrator_select - claim the I2C bus
+ *
+ * Use the GPIO-based signalling protocol; return -EBUSY if we fail.
+ */
+static int i2c_arbitrator_select(struct i2c_adapter *adap, void *data, u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+	unsigned long stop_retry, stop_time;
+
+	/* Start a round of trying to claim the bus */
+	stop_time = jiffies + usecs_to_jiffies(arb->wait_free_us) + 1;
+	do {
+		/* Indicate that we want to claim the bus */
+		gpio_set_value(arb->ap_gpio, !arb->ap_gpio_release);
+		udelay(arb->slew_delay_us);
+
+		/* Wait for the EC to release it */
+		stop_retry = jiffies + usecs_to_jiffies(arb->wait_retry_us) + 1;
+		while (time_before(jiffies, stop_retry)) {
+			int gpio_val = !!gpio_get_value(arb->ec_gpio);
+
+			if (gpio_val == arb->ec_gpio_release) {
+				/* We got it, so return */
+				return 0;
+			}
+
+			usleep_range(50, 200);
+		}
+
+		/* It didn't release, so give up, wait, and try again */
+		gpio_set_value(arb->ap_gpio, arb->ap_gpio_release);
+
+		usleep_range(arb->wait_retry_us, arb->wait_retry_us * 2);
+	} while (time_before(jiffies, stop_time));
+
+	/* Give up, release our claim */
+	gpio_set_value(arb->ap_gpio, arb->ap_gpio_release);
+	udelay(arb->slew_delay_us);
+	dev_err(&adap->dev, "Could not claim bus, timeout\n");
+	return -EBUSY;
+}
+
+/**
+ * i2c_arbitrator_deselect - release the I2C bus
+ *
+ * Release the I2C bus using the GPIO-based signalling protocol.
+ */
+static int i2c_arbitrator_deselect(struct i2c_adapter *adap, void *data,
+				   u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+
+	/* Release the bus and wait for the EC to notice */
+	gpio_set_value(arb->ap_gpio, arb->ap_gpio_release);
+	udelay(arb->slew_delay_us);
+
+	return 0;
+}
+
+static int i2c_arbitrator_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *parent_np;
+	struct i2c_arbitrator_data *arb;
+	enum of_gpio_flags gpio_flags;
+	unsigned long out_init;
+	int ret;
+
+	/* We only support probing from device tree; no platform_data */
+	if (WARN_ON(!np))
+		return -ENODEV;
+	if (WARN_ON(pdev->dev.platform_data))
+		return -EINVAL;
+
+	arb = devm_kzalloc(&pdev->dev, sizeof(*arb), GFP_KERNEL);
+	if (WARN_ON(!arb))
+		return -ENOMEM;
+	platform_set_drvdata(pdev, arb);
+
+	/* Find our parent */
+	parent_np = of_parse_phandle(np, "i2c-parent", 0);
+	if (WARN_ON(!parent_np))
+		return -EINVAL;
+	arb->parent = of_find_i2c_adapter_by_node(parent_np);
+	if (WARN_ON(!arb->parent))
+		return -EINVAL;
+
+	/* Request GPIOs */
+	ret = of_get_named_gpio_flags(np, "ap-claim-gpio", 0, &gpio_flags);
+	if (WARN_ON(!gpio_is_valid(ret)))
+		return ret;
+	arb->ap_gpio = ret;
+	arb->ap_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	out_init = (gpio_flags & OF_GPIO_ACTIVE_LOW) ?
+		GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
+	ret = devm_gpio_request_one(&pdev->dev, arb->ap_gpio, out_init,
+				    "ap-claim-gpio");
+	if (WARN_ON(ret))
+		return ret;
+
+	ret = of_get_named_gpio_flags(np, "ec-claim-gpio", 0, &gpio_flags);
+	if (WARN_ON(!gpio_is_valid(ret)))
+		return ret;
+	arb->ec_gpio = ret;
+	arb->ec_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	ret = devm_gpio_request_one(&pdev->dev, arb->ec_gpio, GPIOF_IN,
+				    "ec-claim-gpio");
+	if (WARN_ON(ret))
+		return ret;
+
+	/* Arbitration parameters */
+	if (of_property_read_u32(np, "slew-delay-us", &arb->slew_delay_us))
+		arb->slew_delay_us = 10;
+	if (of_property_read_u32(np, "wait-retry-us", &arb->wait_retry_us))
+		arb->wait_retry_us = 3000;
+	if (of_property_read_u32(np, "wait-free-us", &arb->wait_free_us))
+		arb->wait_free_us = 50000;
+
+	/* Actually add the mux adapter */
+	arb->child = i2c_add_mux_adapter(arb->parent, &pdev->dev, arb, 0, 0, 0,
+					 i2c_arbitrator_select,
+					 i2c_arbitrator_deselect);
+	if (WARN_ON(!arb->child)) {
+		ret = -ENODEV;
+		i2c_put_adapter(arb->parent);
+	}
+
+	return ret;
+}
+
+static int i2c_arbitrator_remove(struct platform_device *pdev)
+{
+	struct i2c_arbitrator_data *arb = platform_get_drvdata(pdev);
+
+	i2c_del_mux_adapter(arb->child);
+	i2c_put_adapter(arb->parent);
+
+	return 0;
+}
+
+static const struct of_device_id i2c_arbitrator_of_match[] = {
+	{ .compatible = "i2c-arbitrator-cros-ec", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, i2c_arbitrator_of_match);
+
+static struct platform_driver i2c_arbitrator_driver = {
+	.probe	= i2c_arbitrator_probe,
+	.remove	= i2c_arbitrator_remove,
+	.driver	= {
+		.owner	= THIS_MODULE,
+		.name	= "i2c-arbitrator-cros-ec",
+		.of_match_table = of_match_ptr(i2c_arbitrator_of_match),
+	},
+};
+
+static int __init i2c_arbitrator_init(void)
+{
+	return platform_driver_register(&i2c_arbitrator_driver);
+}
+subsys_initcall(i2c_arbitrator_init);
+
+static void __exit i2c_arbitrator_exit(void)
+{
+	platform_driver_unregister(&i2c_arbitrator_driver);
+}
+module_exit(i2c_arbitrator_exit);
+
+MODULE_DESCRIPTION("I2C arbitrator driver for the ARM Chromebook");
+MODULE_AUTHOR("Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:i2c-arbitrator-cros-ec");
-- 
1.8.1

[PATCH v2 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Doug Anderson]

We need to use the i2c-arbitrator to talk to any of the devices on i2c
bus 4 on exynos5250-snow so that we don't confuse the embedded
controller (EC).  Add the i2c-arbitrator to the device tree.  As we
add future devices (keyboard, sbs, tps65090) we'll add them on top of
this.

The arbitrated bus is numbered 104 simply as a convenience to make it
easier for people poking around to guess that it might have something
to do with the physical bus 4.

The addition is split between the cros5250-common and the snow device
tree file since not all cros5250-class devices use arbitration.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v2:
- Use new device tree property names / compatible string.
- Include that the GPIOs for arbitration are active low.

 arch/arm/boot/dts/cros5250-common.dtsi |  5 ++++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 46c0980..f451375 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -58,7 +58,10 @@
 	};
 
 	i2c@12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
+		gpios = <&gpa2 0 3 3 0>,
+			<&gpa2 1 3 3 0>;
 	};
 
 	i2c@12CB0000 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 17dd951..d2d4b48 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -16,6 +16,10 @@
 	model = "Google Snow";
 	compatible = "google,snow", "samsung,exynos5250";
 
+	aliases {
+		i2c104 = &i2c_104;
+	};
+
 	gpio-keys {
 		compatible = "gpio-keys";
 
@@ -29,6 +33,27 @@
 		};
 	};
 
+	i2c-arbitrator {
+		compatible = "i2c-arbitrator-cros-ec";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		ap-claim-gpio = <&gpf0 3 1 0x10000 0>;
+		ec-claim-gpio = <&gpe0 4 0 0x10003 0>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		/* Use ID 104 as a hint that we're on physical bus 4 */
+		i2c_104: i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	/*
 	 * On Snow we've got SIP WiFi and so can keep drive strengths low to
 	 * reduce EMI.
-- 
1.8.1

[PATCH v2 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Doug Anderson]

We need to use the i2c-arbitrator to talk to any of the devices on i2c
bus 4 on exynos5250-snow so that we don't confuse the embedded
controller (EC).  Add the i2c-arbitrator to the device tree.  As we
add future devices (keyboard, sbs, tps65090) we'll add them on top of
this.

The arbitrated bus is numbered 104 simply as a convenience to make it
easier for people poking around to guess that it might have something
to do with the physical bus 4.

The addition is split between the cros5250-common and the snow device
tree file since not all cros5250-class devices use arbitration.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v2:
- Use new device tree property names / compatible string.
- Include that the GPIOs for arbitration are active low.

 arch/arm/boot/dts/cros5250-common.dtsi |  5 ++++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 46c0980..f451375 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -58,7 +58,10 @@
 	};
 
 	i2c at 12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
+		gpios = <&gpa2 0 3 3 0>,
+			<&gpa2 1 3 3 0>;
 	};
 
 	i2c at 12CB0000 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 17dd951..d2d4b48 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -16,6 +16,10 @@
 	model = "Google Snow";
 	compatible = "google,snow", "samsung,exynos5250";
 
+	aliases {
+		i2c104 = &i2c_104;
+	};
+
 	gpio-keys {
 		compatible = "gpio-keys";
 
@@ -29,6 +33,27 @@
 		};
 	};
 
+	i2c-arbitrator {
+		compatible = "i2c-arbitrator-cros-ec";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		ap-claim-gpio = <&gpf0 3 1 0x10000 0>;
+		ec-claim-gpio = <&gpe0 4 0 0x10003 0>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		/* Use ID 104 as a hint that we're on physical bus 4 */
+		i2c_104: i2c at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	/*
 	 * On Snow we've got SIP WiFi and so can keep drive strengths low to
 	 * reduce EMI.
-- 
1.8.1

[PATCH v2 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

Now that we have i2c-arbitrator in place on bus 4 we can add the
sbs-battery driver.  Future devices will be added onto bus 4 once
drivers are in good shape.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v2: None

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index d2d4b48..2127386 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -51,6 +51,12 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			battery: sbs-battery@b {
+				compatible = "sbs,sbs-battery";
+				reg = <0xb>;
+				sbs,poll-retry-count = <1>;
+			};
 		};
 	};
 
-- 
1.8.1

[PATCH v2 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

[Doug Anderson]

Now that we have i2c-arbitrator in place on bus 4 we can add the
sbs-battery driver.  Future devices will be added onto bus 4 once
drivers are in good shape.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v2: None

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index d2d4b48..2127386 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -51,6 +51,12 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			battery: sbs-battery at b {
+				compatible = "sbs,sbs-battery";
+				reg = <0xb>;
+				sbs,poll-retry-count = <1>;
+			};
 		};
 	};
 
-- 
1.8.1

Re: [PATCH v2 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Stephen Warren]

On 02/14/2013 05:21 PM, Doug Anderson wrote:
> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
> that the Embedded Controller (EC) on the ARM Chromebook expects to use
> for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
> be used in other places where standard I2C bus arbitration can't be
> used and two extra GPIOs are available for arbitration.
> 
> This driver is based on code that Simon Glass added to the i2c-s3c2410
> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
> mux driver is as suggested by Grant Likely.  See
> <https://patchwork.kernel.org/patch/1877311/> for some history.

> diff --git a/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c b/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c

> +static int i2c_arbitrator_probe(struct platform_device *pdev)

> +	arb->parent = of_find_i2c_adapter_by_node(parent_np);
> +	if (WARN_ON(!arb->parent))
> +		return -EINVAL;

I think for all error paths after this point, a call to
i2c_put_adapter() is needed.

> +	/* Request GPIOs */
> +	ret = of_get_named_gpio_flags(np, "ap-claim-gpio", 0, &gpio_flags);
> +	if (WARN_ON(!gpio_is_valid(ret)))
> +		return ret;

You shouldn't warn in all cases; -EPROBE_DEFER can quite legitimately
happen and only temporarily prevents probe() - it's retried later.

> +	arb->ap_gpio = ret;

Nit: Perhaps simply assign arb->ap_gpio directly from the
of_get_named_gpio_flags call? It would make that call slightly clearer.

> +	arb->ap_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
> +	out_init = (gpio_flags & OF_GPIO_ACTIVE_LOW) ?
> +		GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;

Nit: I'd be tempted to test arb->ap_gpio_release here, rather than
extracting the value from the flags again. Semantically equivalent, but
it seems to slightly more directly show why it's being tested.

> +subsys_initcall(i2c_arbitrator_init);

You mentioned that you only saw problems using
module_init/module_platform_driver in your downstream tree, so the
problem doesn't affect upstream. Presumably those problems would be
fixed when upstreaming any other drivers into the mainline kernel. I'd
still be tempted to just use module_platform_driver here. But, I guess
I'm fine with the patch either way; I'll leave the call to Wolfram.

Re: [PATCH v2 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Stephen Warren]

On 02/14/2013 05:21 PM, Doug Anderson wrote:
> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
> that the Embedded Controller (EC) on the ARM Chromebook expects to use
> for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
> be used in other places where standard I2C bus arbitration can't be
> used and two extra GPIOs are available for arbitration.
> 
> This driver is based on code that Simon Glass added to the i2c-s3c2410
> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
> mux driver is as suggested by Grant Likely.  See
> <https://patchwork.kernel.org/patch/1877311/> for some history.

> diff --git a/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c b/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c

> +static int i2c_arbitrator_probe(struct platform_device *pdev)

> +	arb->parent = of_find_i2c_adapter_by_node(parent_np);
> +	if (WARN_ON(!arb->parent))
> +		return -EINVAL;

I think for all error paths after this point, a call to
i2c_put_adapter() is needed.

> +	/* Request GPIOs */
> +	ret = of_get_named_gpio_flags(np, "ap-claim-gpio", 0, &gpio_flags);
> +	if (WARN_ON(!gpio_is_valid(ret)))
> +		return ret;

You shouldn't warn in all cases; -EPROBE_DEFER can quite legitimately
happen and only temporarily prevents probe() - it's retried later.

> +	arb->ap_gpio = ret;

Nit: Perhaps simply assign arb->ap_gpio directly from the
of_get_named_gpio_flags call? It would make that call slightly clearer.

> +	arb->ap_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
> +	out_init = (gpio_flags & OF_GPIO_ACTIVE_LOW) ?
> +		GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;

Nit: I'd be tempted to test arb->ap_gpio_release here, rather than
extracting the value from the flags again. Semantically equivalent, but
it seems to slightly more directly show why it's being tested.

> +subsys_initcall(i2c_arbitrator_init);

You mentioned that you only saw problems using
module_init/module_platform_driver in your downstream tree, so the
problem doesn't affect upstream. Presumably those problems would be
fixed when upstreaming any other drivers into the mainline kernel. I'd
still be tempted to just use module_platform_driver here. But, I guess
I'm fine with the patch either way; I'll leave the call to Wolfram.

Re: [PATCH v2 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Doug Anderson]

Stephen,

New version will come shortly with fixes below...


On Fri, Feb 15, 2013 at 8:39 AM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
> On 02/14/2013 05:21 PM, Doug Anderson wrote:
>> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
>> that the Embedded Controller (EC) on the ARM Chromebook expects to use
>> for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
>> be used in other places where standard I2C bus arbitration can't be
>> used and two extra GPIOs are available for arbitration.
>>
>> This driver is based on code that Simon Glass added to the i2c-s3c2410
>> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
>> mux driver is as suggested by Grant Likely.  See
>> <https://patchwork.kernel.org/patch/1877311/> for some history.
>
>> diff --git a/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c b/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c
>
>> +static int i2c_arbitrator_probe(struct platform_device *pdev)
>
>> +     arb->parent = of_find_i2c_adapter_by_node(parent_np);
>> +     if (WARN_ON(!arb->parent))
>> +             return -EINVAL;
>
> I think for all error paths after this point, a call to
> i2c_put_adapter() is needed.

Right.  I messed that up when I reworked.  I'll reorder this one to
last since it's the only one that needs cleanup.  Thanks for catching!


>> +     /* Request GPIOs */
>> +     ret = of_get_named_gpio_flags(np, "ap-claim-gpio", 0, &gpio_flags);
>> +     if (WARN_ON(!gpio_is_valid(ret)))
>> +             return ret;
>
> You shouldn't warn in all cases; -EPROBE_DEFER can quite legitimately
> happen and only temporarily prevents probe() - it's retried later.

Done.


>> +     arb->ap_gpio = ret;
>
> Nit: Perhaps simply assign arb->ap_gpio directly from the
> of_get_named_gpio_flags call? It would make that call slightly clearer.

With the addition of checks for -EPROBE_DEFER this causes several line
wraps including the "if" test so not doing.


>> +     arb->ap_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
>> +     out_init = (gpio_flags & OF_GPIO_ACTIVE_LOW) ?
>> +             GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
>
> Nit: I'd be tempted to test arb->ap_gpio_release here, rather than
> extracting the value from the flags again. Semantically equivalent, but
> it seems to slightly more directly show why it's being tested.

I wrote it both ways and decided I liked this way better.  IMHO the
symmetry between the ec_gpio_release code and the ap_gpio_release code
is worth the extra test.  ...but I can see both sides of the argument
so will change it if you wish.


>> +subsys_initcall(i2c_arbitrator_init);
>
> You mentioned that you only saw problems using
> module_init/module_platform_driver in your downstream tree, so the
> problem doesn't affect upstream. Presumably those problems would be
> fixed when upstreaming any other drivers into the mainline kernel. I'd
> still be tempted to just use module_platform_driver here. But, I guess
> I'm fine with the patch either way; I'll leave the call to Wolfram.

I take it you thought my "since this provides a bus it should be a
subsystem" argument was BS?  It seems like the "it needs to be this
way for correctness" is a pretty weak argument, but even if we fix the
other problems it still seems like it is more ideal for bus providers
to be registered as subsystems just to avoid defers (so you get a
faster boot).

If it will make the patch more palatable I'll move it to
module_platform_driver() and we'll figure out how to make it work.


-Doug

Re: [PATCH v2 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Stephen Warren]

On 02/15/2013 10:25 AM, Doug Anderson wrote:
> Stephen,
> 
> New version will come shortly with fixes below...
> 
> 
> On Fri, Feb 15, 2013 at 8:39 AM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
>> On 02/14/2013 05:21 PM, Doug Anderson wrote:
>>> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
>>> that the Embedded Controller (EC) on the ARM Chromebook expects to use
>>> for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
>>> be used in other places where standard I2C bus arbitration can't be
>>> used and two extra GPIOs are available for arbitration.
...
>>> +subsys_initcall(i2c_arbitrator_init);
>>
>> You mentioned that you only saw problems using
>> module_init/module_platform_driver in your downstream tree, so the
>> problem doesn't affect upstream. Presumably those problems would be
>> fixed when upstreaming any other drivers into the mainline kernel. I'd
>> still be tempted to just use module_platform_driver here. But, I guess
>> I'm fine with the patch either way; I'll leave the call to Wolfram.
> 
> I take it you thought my "since this provides a bus it should be a
> subsystem" argument was BS?

I think subsystem and bus are different things. A driver for a specific
device provides a bus, and happens to use the facilities (or be part of)
a specific subsystem. Generally the subsystem isn't actually the bus
itself (although perhaps something like PCI could be an exception).

Admittedly I have no history/experience really with what the different
initcall levels are really intended for, but my suspicion is that
subsys_initcall is intended for whole subsystems to initialize their
infra-structure before handling drivers or serving requests out to other
code. But, who knows.

Either way though, I believe that upstream, no driver should be relying
on specific initcall levels in order to get dependencies/initialization
ordering correct.

Re: [PATCH v2 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

On Fri, Feb 15, 2013 at 10:38:29AM -0700, Stephen Warren wrote:

> Either way though, I believe that upstream, no driver should be relying
> on specific initcall levels in order to get dependencies/initialization
> ordering correct.

Right, in the past we did bodges like this but in the glorious new
present where deferred probing is available it shouldn't be needed any
more except for a few fun cases like cpufreq that are outside the device
model.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

On Fri, Feb 15, 2013 at 10:38:29AM -0700, Stephen Warren wrote:

> Either way though, I believe that upstream, no driver should be relying
> on specific initcall levels in order to get dependencies/initialization
> ordering correct.

Right, in the past we did bodges like this but in the glorious new
present where deferred probing is available it shouldn't be needed any
more except for a few fun cases like cpufreq that are outside the device
model.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Doug Anderson]

On Fri, Feb 15, 2013 at 9:44 AM, Mark Brown
<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> wrote:
> On Fri, Feb 15, 2013 at 10:38:29AM -0700, Stephen Warren wrote:
>
>> Either way though, I believe that upstream, no driver should be relying
>> on specific initcall levels in order to get dependencies/initialization
>> ordering correct.
>
> Right, in the past we did bodges like this but in the glorious new
> present where deferred probing is available it shouldn't be needed any
> more except for a few fun cases like cpufreq that are outside the device
> model.

OK, thanks to all.  I will submit with module_platform_driver() shortly.

[PATCH v3 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Doug Anderson]

The i2c-arbitrator-cros-ec driver implements the arbitration scheme
that the Embedded Controller (EC) on the ARM Chromebook expects to use
for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
be used in other places where standard I2C bus arbitration can't be
used and two extra GPIOs are available for arbitration.

This driver is based on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
mux driver is as suggested by Grant Likely.  See
<https://patchwork.kernel.org/patch/1877311/> for some history.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
---
Changes in v3:
- Handle of_find_i2c_adapter_by_node() failure more properly by
  changing init order.
- Don't warn on -EPROBE_DEFER from calls that could return it.
- Move to module_platform_driver().  As we pull in parts of the system
  that rely on devices under this i2c bus we'll need to make sure they
  can handle the fact that they'll be initted later now.

Changes in v2:
- Renamed to i2c-arbitrator-cros-ec.
- Documented "microsecond" properties as optional; removed
  "bus-arbitration" prefix since it was just extra wordy.
- Split GPIOs into two properties to make it cleaner.
- Capitalized I2C in freeform text.
- Get 'active low' from device tree.

 .../bindings/i2c/i2c-arbitrator-cros-ec.txt        |  76 +++++++
 drivers/i2c/muxes/Kconfig                          |  11 +
 drivers/i2c/muxes/Makefile                         |   2 +
 drivers/i2c/muxes/i2c-arbitrator-cros-ec.c         | 222 +++++++++++++++++++++
 4 files changed, 311 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
 create mode 100644 drivers/i2c/muxes/i2c-arbitrator-cros-ec.c

diff --git a/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt b/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
new file mode 100644
index 0000000..1f893e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
@@ -0,0 +1,76 @@
+GPIO-based Arbitration used by the ARM Chromebook (exynos5250-snow)
+===================================================================
+This uses GPIO lines between the AP (Application Processor) and an attached
+EC (Embedded Controller) which both want to talk on the same I2C bus as master.
+
+The AP and EC each have a 'bus claim' line, which is an output that the
+other can see. These are both active low, with pull-ups enabled.
+
+- AP_CLAIM: output from AP, signalling to the EC that the AP wants the bus
+- EC_CLAIM: output from EC, signalling to the AP that the EC wants the bus
+
+This mechanism is used instead of standard I2C multimaster to avoid some of the
+subtle driver and silicon bugs that are often present with I2C multimaster.
+
+
+Algorithm:
+
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also. A detailed explanation is best
+done with an example.
+
+Let's say the AP wants to claim the bus. It:
+1. Asserts AP_CLAIM.
+2. Waits a little bit for the other side to notice (slew time, say 10
+   microseconds).
+3. Checks EC_CLAIM. If this is not asserted then the AP has the bus and we are
+   done.
+4. Otherwise, wait for a few milliseconds and see if EC_CLAIM is released.
+5. If not, back off, release the claim and wait for a few more milliseconds.
+6. Go back to 1 (until retry time has expired).
+
+
+Required properties:
+- compatible: i2c-arbitrator-cros-ec
+- ap-claim-gpio: The GPIO that we (the AP) use to claim the bus.
+- ec-claim-gpio: The GPIO that the other side (the EC) uses the claim the bus.
+- Standard I2C mux properties. See mux.txt in this directory.
+- Single I2C child bus node at reg 0. See mux.txt in this directory.
+
+Optional properties:
+- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
+- wait-retry-us: we'll attempt another claim after this many microseconds.
+    Default is 3000 us.
+- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
+
+
+Example:
+	i2c@12CA0000 {
+		compatible = "acme,some-i2c-device";
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+	i2c-arbitrator {
+		compatible = "i2c-arbitrator-cros-ec";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		ap-claim-gpio = <&gpf0 3 1 0x10000 0>;
+		ec-claim-gpio = <&gpe0 4 0 0x10003 0>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			i2c@52 {
+				// Normal I2C device
+			};
+		};
+	};
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 0be5b83..ca19378 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -5,6 +5,17 @@
 menu "Multiplexer I2C Chip support"
 	depends on I2C_MUX
 
+config I2C_ARBITRATOR_CROS_EC
+	tristate "GPIO-based I2C arbitrator used on exynos5250-snow"
+	depends on GENERIC_GPIO && OF
+	help
+	  If you say yes to this option, support will be included for an
+	  I2C multimaster arbitration scheme using GPIOs that is used in
+	  the Samsung ARM Chromebook (exynos5250-snow).
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called i2c-arbitrator-cros-ec.
+
 config I2C_MUX_GPIO
 	tristate "GPIO-based I2C multiplexer"
 	depends on GENERIC_GPIO
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 76da869..e60dcc1 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -1,6 +1,8 @@
 #
 # Makefile for multiplexer I2C chip drivers.
 
+obj-$(CONFIG_I2C_ARBITRATOR_CROS_EC)	+= i2c-arbitrator-cros-ec.o
+
 obj-$(CONFIG_I2C_MUX_GPIO)	+= i2c-mux-gpio.o
 obj-$(CONFIG_I2C_MUX_PCA9541)	+= i2c-mux-pca9541.o
 obj-$(CONFIG_I2C_MUX_PCA954x)	+= i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c b/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c
new file mode 100644
index 0000000..f95b591
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c
@@ -0,0 +1,222 @@
+/*
+ * I2C arbitrator driver for the ARM Chromebook
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/kernel.h>
+#include <linux/i2c.h>
+#include <linux/i2c-mux.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_i2c.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+
+/**
+ * struct i2c_arbitrator_data - Driver data for I2C arbitrator
+ *
+ * @parent: Parent adapter
+ * @child: Child bus
+ * @ap_gpio: GPIO we'll use to claim.
+ * @ap_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO == this
+ *   then consider it released.
+ * @ec_gpio: GPIO that the other side will use to claim.
+ * @ec_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO == this
+ *   then consider it released.
+ * @slew_delay_us: microseconds to wait for a GPIO to go high.
+ * @wait_retry_us: we'll attempt another claim after this many microseconds.
+ * @wait_free_us: we'll give up after this many microseconds.
+ */
+
+struct i2c_arbitrator_data {
+	struct i2c_adapter *parent;
+	struct i2c_adapter *child;
+
+	int		ap_gpio;
+	int		ap_gpio_release;
+	int		ec_gpio;
+	int		ec_gpio_release;
+	unsigned int	slew_delay_us;
+	unsigned int	wait_retry_us;
+	unsigned int	wait_free_us;
+};
+
+
+/**
+ * i2c_arbitrator_select - claim the I2C bus
+ *
+ * Use the GPIO-based signalling protocol; return -EBUSY if we fail.
+ */
+static int i2c_arbitrator_select(struct i2c_adapter *adap, void *data, u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+	unsigned long stop_retry, stop_time;
+
+	/* Start a round of trying to claim the bus */
+	stop_time = jiffies + usecs_to_jiffies(arb->wait_free_us) + 1;
+	do {
+		/* Indicate that we want to claim the bus */
+		gpio_set_value(arb->ap_gpio, !arb->ap_gpio_release);
+		udelay(arb->slew_delay_us);
+
+		/* Wait for the EC to release it */
+		stop_retry = jiffies + usecs_to_jiffies(arb->wait_retry_us) + 1;
+		while (time_before(jiffies, stop_retry)) {
+			int gpio_val = !!gpio_get_value(arb->ec_gpio);
+
+			if (gpio_val == arb->ec_gpio_release) {
+				/* We got it, so return */
+				return 0;
+			}
+
+			usleep_range(50, 200);
+		}
+
+		/* It didn't release, so give up, wait, and try again */
+		gpio_set_value(arb->ap_gpio, arb->ap_gpio_release);
+
+		usleep_range(arb->wait_retry_us, arb->wait_retry_us * 2);
+	} while (time_before(jiffies, stop_time));
+
+	/* Give up, release our claim */
+	gpio_set_value(arb->ap_gpio, arb->ap_gpio_release);
+	udelay(arb->slew_delay_us);
+	dev_err(&adap->dev, "Could not claim bus, timeout\n");
+	return -EBUSY;
+}
+
+/**
+ * i2c_arbitrator_deselect - release the I2C bus
+ *
+ * Release the I2C bus using the GPIO-based signalling protocol.
+ */
+static int i2c_arbitrator_deselect(struct i2c_adapter *adap, void *data,
+				   u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+
+	/* Release the bus and wait for the EC to notice */
+	gpio_set_value(arb->ap_gpio, arb->ap_gpio_release);
+	udelay(arb->slew_delay_us);
+
+	return 0;
+}
+
+static int i2c_arbitrator_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *parent_np;
+	struct i2c_arbitrator_data *arb;
+	enum of_gpio_flags gpio_flags;
+	unsigned long out_init;
+	int ret;
+
+	/* We only support probing from device tree; no platform_data */
+	if (WARN_ON(!np))
+		return -ENODEV;
+	if (WARN_ON(pdev->dev.platform_data))
+		return -EINVAL;
+
+	arb = devm_kzalloc(&pdev->dev, sizeof(*arb), GFP_KERNEL);
+	if (WARN_ON(!arb))
+		return -ENOMEM;
+	platform_set_drvdata(pdev, arb);
+
+	/* Request GPIOs */
+	ret = of_get_named_gpio_flags(np, "ap-claim-gpio", 0, &gpio_flags);
+	if (ret == -EPROBE_DEFER || WARN_ON(!gpio_is_valid(ret)))
+		return ret;
+	arb->ap_gpio = ret;
+	arb->ap_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	out_init = (gpio_flags & OF_GPIO_ACTIVE_LOW) ?
+		GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
+	ret = devm_gpio_request_one(&pdev->dev, arb->ap_gpio, out_init,
+				    "ap-claim-gpio");
+	if (ret == -EPROBE_DEFER || WARN_ON(ret))
+		return ret;
+
+	ret = of_get_named_gpio_flags(np, "ec-claim-gpio", 0, &gpio_flags);
+	if (ret == -EPROBE_DEFER || WARN_ON(!gpio_is_valid(ret)))
+		return ret;
+	arb->ec_gpio = ret;
+	arb->ec_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	ret = devm_gpio_request_one(&pdev->dev, arb->ec_gpio, GPIOF_IN,
+				    "ec-claim-gpio");
+	if (ret == -EPROBE_DEFER || WARN_ON(ret))
+		return ret;
+
+	/* Arbitration parameters */
+	if (of_property_read_u32(np, "slew-delay-us", &arb->slew_delay_us))
+		arb->slew_delay_us = 10;
+	if (of_property_read_u32(np, "wait-retry-us", &arb->wait_retry_us))
+		arb->wait_retry_us = 3000;
+	if (of_property_read_u32(np, "wait-free-us", &arb->wait_free_us))
+		arb->wait_free_us = 50000;
+
+	/* Find our parent */
+	parent_np = of_parse_phandle(np, "i2c-parent", 0);
+	if (WARN_ON(!parent_np))
+		return -EINVAL;
+	arb->parent = of_find_i2c_adapter_by_node(parent_np);
+	if (WARN_ON(!arb->parent))
+		return -EINVAL;
+
+	/* Actually add the mux adapter */
+	arb->child = i2c_add_mux_adapter(arb->parent, &pdev->dev, arb, 0, 0, 0,
+					 i2c_arbitrator_select,
+					 i2c_arbitrator_deselect);
+	if (WARN_ON(!arb->child)) {
+		ret = -ENODEV;
+		i2c_put_adapter(arb->parent);
+	}
+
+	return ret;
+}
+
+static int i2c_arbitrator_remove(struct platform_device *pdev)
+{
+	struct i2c_arbitrator_data *arb = platform_get_drvdata(pdev);
+
+	i2c_del_mux_adapter(arb->child);
+	i2c_put_adapter(arb->parent);
+
+	return 0;
+}
+
+static const struct of_device_id i2c_arbitrator_of_match[] = {
+	{ .compatible = "i2c-arbitrator-cros-ec", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, i2c_arbitrator_of_match);
+
+static struct platform_driver i2c_arbitrator_driver = {
+	.probe	= i2c_arbitrator_probe,
+	.remove	= i2c_arbitrator_remove,
+	.driver	= {
+		.owner	= THIS_MODULE,
+		.name	= "i2c-arbitrator-cros-ec",
+		.of_match_table = of_match_ptr(i2c_arbitrator_of_match),
+	},
+};
+
+module_platform_driver(i2c_arbitrator_driver);
+
+MODULE_DESCRIPTION("I2C arbitrator driver for the ARM Chromebook");
+MODULE_AUTHOR("Doug Anderson <dianders@chromium.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:i2c-arbitrator-cros-ec");
-- 
1.8.1

[PATCH v3 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Doug Anderson]

The i2c-arbitrator-cros-ec driver implements the arbitration scheme
that the Embedded Controller (EC) on the ARM Chromebook expects to use
for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
be used in other places where standard I2C bus arbitration can't be
used and two extra GPIOs are available for arbitration.

This driver is based on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
mux driver is as suggested by Grant Likely.  See
<https://patchwork.kernel.org/patch/1877311/> for some history.

Signed-off-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
Changes in v3:
- Handle of_find_i2c_adapter_by_node() failure more properly by
  changing init order.
- Don't warn on -EPROBE_DEFER from calls that could return it.
- Move to module_platform_driver().  As we pull in parts of the system
  that rely on devices under this i2c bus we'll need to make sure they
  can handle the fact that they'll be initted later now.

Changes in v2:
- Renamed to i2c-arbitrator-cros-ec.
- Documented "microsecond" properties as optional; removed
  "bus-arbitration" prefix since it was just extra wordy.
- Split GPIOs into two properties to make it cleaner.
- Capitalized I2C in freeform text.
- Get 'active low' from device tree.

 .../bindings/i2c/i2c-arbitrator-cros-ec.txt        |  76 +++++++
 drivers/i2c/muxes/Kconfig                          |  11 +
 drivers/i2c/muxes/Makefile                         |   2 +
 drivers/i2c/muxes/i2c-arbitrator-cros-ec.c         | 222 +++++++++++++++++++++
 4 files changed, 311 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
 create mode 100644 drivers/i2c/muxes/i2c-arbitrator-cros-ec.c

diff --git a/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt b/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
new file mode 100644
index 0000000..1f893e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
@@ -0,0 +1,76 @@
+GPIO-based Arbitration used by the ARM Chromebook (exynos5250-snow)
+===================================================================
+This uses GPIO lines between the AP (Application Processor) and an attached
+EC (Embedded Controller) which both want to talk on the same I2C bus as master.
+
+The AP and EC each have a 'bus claim' line, which is an output that the
+other can see. These are both active low, with pull-ups enabled.
+
+- AP_CLAIM: output from AP, signalling to the EC that the AP wants the bus
+- EC_CLAIM: output from EC, signalling to the AP that the EC wants the bus
+
+This mechanism is used instead of standard I2C multimaster to avoid some of the
+subtle driver and silicon bugs that are often present with I2C multimaster.
+
+
+Algorithm:
+
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also. A detailed explanation is best
+done with an example.
+
+Let's say the AP wants to claim the bus. It:
+1. Asserts AP_CLAIM.
+2. Waits a little bit for the other side to notice (slew time, say 10
+   microseconds).
+3. Checks EC_CLAIM. If this is not asserted then the AP has the bus and we are
+   done.
+4. Otherwise, wait for a few milliseconds and see if EC_CLAIM is released.
+5. If not, back off, release the claim and wait for a few more milliseconds.
+6. Go back to 1 (until retry time has expired).
+
+
+Required properties:
+- compatible: i2c-arbitrator-cros-ec
+- ap-claim-gpio: The GPIO that we (the AP) use to claim the bus.
+- ec-claim-gpio: The GPIO that the other side (the EC) uses the claim the bus.
+- Standard I2C mux properties. See mux.txt in this directory.
+- Single I2C child bus node at reg 0. See mux.txt in this directory.
+
+Optional properties:
+- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
+- wait-retry-us: we'll attempt another claim after this many microseconds.
+    Default is 3000 us.
+- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
+
+
+Example:
+	i2c@12CA0000 {
+		compatible = "acme,some-i2c-device";
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+	i2c-arbitrator {
+		compatible = "i2c-arbitrator-cros-ec";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		ap-claim-gpio = <&gpf0 3 1 0x10000 0>;
+		ec-claim-gpio = <&gpe0 4 0 0x10003 0>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			i2c@52 {
+				// Normal I2C device
+			};
+		};
+	};
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 0be5b83..ca19378 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -5,6 +5,17 @@
 menu "Multiplexer I2C Chip support"
 	depends on I2C_MUX
 
+config I2C_ARBITRATOR_CROS_EC
+	tristate "GPIO-based I2C arbitrator used on exynos5250-snow"
+	depends on GENERIC_GPIO && OF
+	help
+	  If you say yes to this option, support will be included for an
+	  I2C multimaster arbitration scheme using GPIOs that is used in
+	  the Samsung ARM Chromebook (exynos5250-snow).
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called i2c-arbitrator-cros-ec.
+
 config I2C_MUX_GPIO
 	tristate "GPIO-based I2C multiplexer"
 	depends on GENERIC_GPIO
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 76da869..e60dcc1 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -1,6 +1,8 @@
 #
 # Makefile for multiplexer I2C chip drivers.
 
+obj-$(CONFIG_I2C_ARBITRATOR_CROS_EC)	+= i2c-arbitrator-cros-ec.o
+
 obj-$(CONFIG_I2C_MUX_GPIO)	+= i2c-mux-gpio.o
 obj-$(CONFIG_I2C_MUX_PCA9541)	+= i2c-mux-pca9541.o
 obj-$(CONFIG_I2C_MUX_PCA954x)	+= i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c b/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c
new file mode 100644
index 0000000..f95b591
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c
@@ -0,0 +1,222 @@
+/*
+ * I2C arbitrator driver for the ARM Chromebook
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/kernel.h>
+#include <linux/i2c.h>
+#include <linux/i2c-mux.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_i2c.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+
+/**
+ * struct i2c_arbitrator_data - Driver data for I2C arbitrator
+ *
+ * @parent: Parent adapter
+ * @child: Child bus
+ * @ap_gpio: GPIO we'll use to claim.
+ * @ap_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO == this
+ *   then consider it released.
+ * @ec_gpio: GPIO that the other side will use to claim.
+ * @ec_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO == this
+ *   then consider it released.
+ * @slew_delay_us: microseconds to wait for a GPIO to go high.
+ * @wait_retry_us: we'll attempt another claim after this many microseconds.
+ * @wait_free_us: we'll give up after this many microseconds.
+ */
+
+struct i2c_arbitrator_data {
+	struct i2c_adapter *parent;
+	struct i2c_adapter *child;
+
+	int		ap_gpio;
+	int		ap_gpio_release;
+	int		ec_gpio;
+	int		ec_gpio_release;
+	unsigned int	slew_delay_us;
+	unsigned int	wait_retry_us;
+	unsigned int	wait_free_us;
+};
+
+
+/**
+ * i2c_arbitrator_select - claim the I2C bus
+ *
+ * Use the GPIO-based signalling protocol; return -EBUSY if we fail.
+ */
+static int i2c_arbitrator_select(struct i2c_adapter *adap, void *data, u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+	unsigned long stop_retry, stop_time;
+
+	/* Start a round of trying to claim the bus */
+	stop_time = jiffies + usecs_to_jiffies(arb->wait_free_us) + 1;
+	do {
+		/* Indicate that we want to claim the bus */
+		gpio_set_value(arb->ap_gpio, !arb->ap_gpio_release);
+		udelay(arb->slew_delay_us);
+
+		/* Wait for the EC to release it */
+		stop_retry = jiffies + usecs_to_jiffies(arb->wait_retry_us) + 1;
+		while (time_before(jiffies, stop_retry)) {
+			int gpio_val = !!gpio_get_value(arb->ec_gpio);
+
+			if (gpio_val == arb->ec_gpio_release) {
+				/* We got it, so return */
+				return 0;
+			}
+
+			usleep_range(50, 200);
+		}
+
+		/* It didn't release, so give up, wait, and try again */
+		gpio_set_value(arb->ap_gpio, arb->ap_gpio_release);
+
+		usleep_range(arb->wait_retry_us, arb->wait_retry_us * 2);
+	} while (time_before(jiffies, stop_time));
+
+	/* Give up, release our claim */
+	gpio_set_value(arb->ap_gpio, arb->ap_gpio_release);
+	udelay(arb->slew_delay_us);
+	dev_err(&adap->dev, "Could not claim bus, timeout\n");
+	return -EBUSY;
+}
+
+/**
+ * i2c_arbitrator_deselect - release the I2C bus
+ *
+ * Release the I2C bus using the GPIO-based signalling protocol.
+ */
+static int i2c_arbitrator_deselect(struct i2c_adapter *adap, void *data,
+				   u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+
+	/* Release the bus and wait for the EC to notice */
+	gpio_set_value(arb->ap_gpio, arb->ap_gpio_release);
+	udelay(arb->slew_delay_us);
+
+	return 0;
+}
+
+static int i2c_arbitrator_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *parent_np;
+	struct i2c_arbitrator_data *arb;
+	enum of_gpio_flags gpio_flags;
+	unsigned long out_init;
+	int ret;
+
+	/* We only support probing from device tree; no platform_data */
+	if (WARN_ON(!np))
+		return -ENODEV;
+	if (WARN_ON(pdev->dev.platform_data))
+		return -EINVAL;
+
+	arb = devm_kzalloc(&pdev->dev, sizeof(*arb), GFP_KERNEL);
+	if (WARN_ON(!arb))
+		return -ENOMEM;
+	platform_set_drvdata(pdev, arb);
+
+	/* Request GPIOs */
+	ret = of_get_named_gpio_flags(np, "ap-claim-gpio", 0, &gpio_flags);
+	if (ret == -EPROBE_DEFER || WARN_ON(!gpio_is_valid(ret)))
+		return ret;
+	arb->ap_gpio = ret;
+	arb->ap_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	out_init = (gpio_flags & OF_GPIO_ACTIVE_LOW) ?
+		GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
+	ret = devm_gpio_request_one(&pdev->dev, arb->ap_gpio, out_init,
+				    "ap-claim-gpio");
+	if (ret == -EPROBE_DEFER || WARN_ON(ret))
+		return ret;
+
+	ret = of_get_named_gpio_flags(np, "ec-claim-gpio", 0, &gpio_flags);
+	if (ret == -EPROBE_DEFER || WARN_ON(!gpio_is_valid(ret)))
+		return ret;
+	arb->ec_gpio = ret;
+	arb->ec_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	ret = devm_gpio_request_one(&pdev->dev, arb->ec_gpio, GPIOF_IN,
+				    "ec-claim-gpio");
+	if (ret == -EPROBE_DEFER || WARN_ON(ret))
+		return ret;
+
+	/* Arbitration parameters */
+	if (of_property_read_u32(np, "slew-delay-us", &arb->slew_delay_us))
+		arb->slew_delay_us = 10;
+	if (of_property_read_u32(np, "wait-retry-us", &arb->wait_retry_us))
+		arb->wait_retry_us = 3000;
+	if (of_property_read_u32(np, "wait-free-us", &arb->wait_free_us))
+		arb->wait_free_us = 50000;
+
+	/* Find our parent */
+	parent_np = of_parse_phandle(np, "i2c-parent", 0);
+	if (WARN_ON(!parent_np))
+		return -EINVAL;
+	arb->parent = of_find_i2c_adapter_by_node(parent_np);
+	if (WARN_ON(!arb->parent))
+		return -EINVAL;
+
+	/* Actually add the mux adapter */
+	arb->child = i2c_add_mux_adapter(arb->parent, &pdev->dev, arb, 0, 0, 0,
+					 i2c_arbitrator_select,
+					 i2c_arbitrator_deselect);
+	if (WARN_ON(!arb->child)) {
+		ret = -ENODEV;
+		i2c_put_adapter(arb->parent);
+	}
+
+	return ret;
+}
+
+static int i2c_arbitrator_remove(struct platform_device *pdev)
+{
+	struct i2c_arbitrator_data *arb = platform_get_drvdata(pdev);
+
+	i2c_del_mux_adapter(arb->child);
+	i2c_put_adapter(arb->parent);
+
+	return 0;
+}
+
+static const struct of_device_id i2c_arbitrator_of_match[] = {
+	{ .compatible = "i2c-arbitrator-cros-ec", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, i2c_arbitrator_of_match);
+
+static struct platform_driver i2c_arbitrator_driver = {
+	.probe	= i2c_arbitrator_probe,
+	.remove	= i2c_arbitrator_remove,
+	.driver	= {
+		.owner	= THIS_MODULE,
+		.name	= "i2c-arbitrator-cros-ec",
+		.of_match_table = of_match_ptr(i2c_arbitrator_of_match),
+	},
+};
+
+module_platform_driver(i2c_arbitrator_driver);
+
+MODULE_DESCRIPTION("I2C arbitrator driver for the ARM Chromebook");
+MODULE_AUTHOR("Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:i2c-arbitrator-cros-ec");
-- 
1.8.1

[PATCH v3 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Doug Anderson]

We need to use the i2c-arbitrator to talk to any of the devices on i2c
bus 4 on exynos5250-snow so that we don't confuse the embedded
controller (EC).  Add the i2c-arbitrator to the device tree.  As we
add future devices (keyboard, sbs, tps65090) we'll add them on top of
this.

The arbitrated bus is numbered 104 simply as a convenience to make it
easier for people poking around to guess that it might have something
to do with the physical bus 4.

The addition is split between the cros5250-common and the snow device
tree file since not all cros5250-class devices use arbitration.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v3: None
Changes in v2:
- Use new device tree property names / compatible string.
- Include that the GPIOs for arbitration are active low.

 arch/arm/boot/dts/cros5250-common.dtsi |  5 ++++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 46c0980..f451375 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -58,7 +58,10 @@
 	};
 
 	i2c@12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
+		gpios = <&gpa2 0 3 3 0>,
+			<&gpa2 1 3 3 0>;
 	};
 
 	i2c@12CB0000 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 17dd951..d2d4b48 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -16,6 +16,10 @@
 	model = "Google Snow";
 	compatible = "google,snow", "samsung,exynos5250";
 
+	aliases {
+		i2c104 = &i2c_104;
+	};
+
 	gpio-keys {
 		compatible = "gpio-keys";
 
@@ -29,6 +33,27 @@
 		};
 	};
 
+	i2c-arbitrator {
+		compatible = "i2c-arbitrator-cros-ec";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		ap-claim-gpio = <&gpf0 3 1 0x10000 0>;
+		ec-claim-gpio = <&gpe0 4 0 0x10003 0>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		/* Use ID 104 as a hint that we're on physical bus 4 */
+		i2c_104: i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	/*
 	 * On Snow we've got SIP WiFi and so can keep drive strengths low to
 	 * reduce EMI.
-- 
1.8.1

[PATCH v3 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Doug Anderson]

We need to use the i2c-arbitrator to talk to any of the devices on i2c
bus 4 on exynos5250-snow so that we don't confuse the embedded
controller (EC).  Add the i2c-arbitrator to the device tree.  As we
add future devices (keyboard, sbs, tps65090) we'll add them on top of
this.

The arbitrated bus is numbered 104 simply as a convenience to make it
easier for people poking around to guess that it might have something
to do with the physical bus 4.

The addition is split between the cros5250-common and the snow device
tree file since not all cros5250-class devices use arbitration.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v3: None
Changes in v2:
- Use new device tree property names / compatible string.
- Include that the GPIOs for arbitration are active low.

 arch/arm/boot/dts/cros5250-common.dtsi |  5 ++++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 46c0980..f451375 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -58,7 +58,10 @@
 	};
 
 	i2c at 12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
+		gpios = <&gpa2 0 3 3 0>,
+			<&gpa2 1 3 3 0>;
 	};
 
 	i2c at 12CB0000 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 17dd951..d2d4b48 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -16,6 +16,10 @@
 	model = "Google Snow";
 	compatible = "google,snow", "samsung,exynos5250";
 
+	aliases {
+		i2c104 = &i2c_104;
+	};
+
 	gpio-keys {
 		compatible = "gpio-keys";
 
@@ -29,6 +33,27 @@
 		};
 	};
 
+	i2c-arbitrator {
+		compatible = "i2c-arbitrator-cros-ec";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		ap-claim-gpio = <&gpf0 3 1 0x10000 0>;
+		ec-claim-gpio = <&gpe0 4 0 0x10003 0>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		/* Use ID 104 as a hint that we're on physical bus 4 */
+		i2c_104: i2c at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	/*
 	 * On Snow we've got SIP WiFi and so can keep drive strengths low to
 	 * reduce EMI.
-- 
1.8.1

[PATCH v3 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

[Doug Anderson]

Now that we have i2c-arbitrator in place on bus 4 we can add the
sbs-battery driver.  Future devices will be added onto bus 4 once
drivers are in good shape.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index d2d4b48..2127386 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -51,6 +51,12 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			battery: sbs-battery@b {
+				compatible = "sbs,sbs-battery";
+				reg = <0xb>;
+				sbs,poll-retry-count = <1>;
+			};
 		};
 	};
 
-- 
1.8.1

[PATCH v3 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

[Doug Anderson]

Now that we have i2c-arbitrator in place on bus 4 we can add the
sbs-battery driver.  Future devices will be added onto bus 4 once
drivers are in good shape.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index d2d4b48..2127386 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -51,6 +51,12 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			battery: sbs-battery at b {
+				compatible = "sbs,sbs-battery";
+				reg = <0xb>;
+				sbs,poll-retry-count = <1>;
+			};
 		};
 	};
 
-- 
1.8.1

Re: [PATCH v3 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Stephen Warren]

On 02/15/2013 12:46 PM, Doug Anderson wrote:
> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
> that the Embedded Controller (EC) on the ARM Chromebook expects to use
> for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
> be used in other places where standard I2C bus arbitration can't be
> used and two extra GPIOs are available for arbitration.
> 
> This driver is based on code that Simon Glass added to the i2c-s3c2410
> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
> mux driver is as suggested by Grant Likely.  See
> <https://patchwork.kernel.org/patch/1877311/> for some history.

Reviewed-by: Stephen Warren <swarren@nvidia.com>

> diff --git a/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c b/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c

> +static int i2c_arbitrator_probe(struct platform_device *pdev)

> +	/* Request GPIOs */
> +	ret = of_get_named_gpio_flags(np, "ap-claim-gpio", 0, &gpio_flags);
> +	if (ret == -EPROBE_DEFER || WARN_ON(!gpio_is_valid(ret)))
> +		return ret;

I think by the time that doesn't return -EPROBE_DEFER ...

> +	arb->ap_gpio = ret;
> +	arb->ap_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
> +	out_init = (gpio_flags & OF_GPIO_ACTIVE_LOW) ?
> +		GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
> +	ret = devm_gpio_request_one(&pdev->dev, arb->ap_gpio, out_init,
> +				    "ap-claim-gpio");
> +	if (ret == -EPROBE_DEFER || WARN_ON(ret))
> +		return ret;

... that won't either, since of_get_named_gpio_flags()'s implementation
requires the relevant GPIO driver to be active already.

Still, there's no harm in the code as it stands, so no need to change.

Re: [PATCH v3 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Naveen Krishna Ch]

On 16 February 2013 04:46, Doug Anderson <dianders@chromium.org> wrote:
> We need to use the i2c-arbitrator to talk to any of the devices on i2c
> bus 4 on exynos5250-snow so that we don't confuse the embedded
> controller (EC).  Add the i2c-arbitrator to the device tree.  As we
> add future devices (keyboard, sbs, tps65090) we'll add them on top of
> this.
>
> The arbitrated bus is numbered 104 simply as a convenience to make it
> easier for people poking around to guess that it might have something
> to do with the physical bus 4.
>
> The addition is split between the cros5250-common and the snow device
> tree file since not all cros5250-class devices use arbitration.
>
> Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
The patch set [v3] is tested on snow with test case which uses i2c-4 from both
EC and AP side continuously for a more than a couple of minutes.

> ---
> Changes in v3: None
> Changes in v2:
> - Use new device tree property names / compatible string.
> - Include that the GPIOs for arbitration are active low.
>
>  arch/arm/boot/dts/cros5250-common.dtsi |  5 ++++-
>  arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
>  2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
> index 46c0980..f451375 100644
> --- a/arch/arm/boot/dts/cros5250-common.dtsi
> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
> @@ -58,7 +58,10 @@
>         };
>
>         i2c@12CA0000 {
> -               status = "disabled";
> +               samsung,i2c-sda-delay = <100>;
> +               samsung,i2c-max-bus-freq = <66000>;
> +               gpios = <&gpa2 0 3 3 0>,
> +                       <&gpa2 1 3 3 0>;
>         };
>
>         i2c@12CB0000 {
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
> index 17dd951..d2d4b48 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -16,6 +16,10 @@
>         model = "Google Snow";
>         compatible = "google,snow", "samsung,exynos5250";
>
> +       aliases {
> +               i2c104 = &i2c_104;
> +       };
> +
>         gpio-keys {
>                 compatible = "gpio-keys";
>
> @@ -29,6 +33,27 @@
>                 };
>         };
>
> +       i2c-arbitrator {
> +               compatible = "i2c-arbitrator-cros-ec";
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               i2c-parent = <&{/i2c@12CA0000}>;
> +
> +               ap-claim-gpio = <&gpf0 3 1 0x10000 0>;
> +               ec-claim-gpio = <&gpe0 4 0 0x10003 0>;
> +               slew-delay-us = <10>;
> +               wait-retry-us = <3000>;
> +               wait-free-us = <50000>;
> +
> +               /* Use ID 104 as a hint that we're on physical bus 4 */
> +               i2c_104: i2c@0 {
> +                       reg = <0>;
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +               };
> +       };
> +
>         /*
>          * On Snow we've got SIP WiFi and so can keep drive strengths low to
>          * reduce EMI.
> --
> 1.8.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



--
Shine bright,
(: Nav :)

[PATCH v3 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Naveen Krishna Ch]

On 16 February 2013 04:46, Doug Anderson <dianders@chromium.org> wrote:
> We need to use the i2c-arbitrator to talk to any of the devices on i2c
> bus 4 on exynos5250-snow so that we don't confuse the embedded
> controller (EC).  Add the i2c-arbitrator to the device tree.  As we
> add future devices (keyboard, sbs, tps65090) we'll add them on top of
> this.
>
> The arbitrated bus is numbered 104 simply as a convenience to make it
> easier for people poking around to guess that it might have something
> to do with the physical bus 4.
>
> The addition is split between the cros5250-common and the snow device
> tree file since not all cros5250-class devices use arbitration.
>
> Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
The patch set [v3] is tested on snow with test case which uses i2c-4 from both
EC and AP side continuously for a more than a couple of minutes.

> ---
> Changes in v3: None
> Changes in v2:
> - Use new device tree property names / compatible string.
> - Include that the GPIOs for arbitration are active low.
>
>  arch/arm/boot/dts/cros5250-common.dtsi |  5 ++++-
>  arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
>  2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
> index 46c0980..f451375 100644
> --- a/arch/arm/boot/dts/cros5250-common.dtsi
> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
> @@ -58,7 +58,10 @@
>         };
>
>         i2c at 12CA0000 {
> -               status = "disabled";
> +               samsung,i2c-sda-delay = <100>;
> +               samsung,i2c-max-bus-freq = <66000>;
> +               gpios = <&gpa2 0 3 3 0>,
> +                       <&gpa2 1 3 3 0>;
>         };
>
>         i2c at 12CB0000 {
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
> index 17dd951..d2d4b48 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -16,6 +16,10 @@
>         model = "Google Snow";
>         compatible = "google,snow", "samsung,exynos5250";
>
> +       aliases {
> +               i2c104 = &i2c_104;
> +       };
> +
>         gpio-keys {
>                 compatible = "gpio-keys";
>
> @@ -29,6 +33,27 @@
>                 };
>         };
>
> +       i2c-arbitrator {
> +               compatible = "i2c-arbitrator-cros-ec";
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               i2c-parent = <&{/i2c@12CA0000}>;
> +
> +               ap-claim-gpio = <&gpf0 3 1 0x10000 0>;
> +               ec-claim-gpio = <&gpe0 4 0 0x10003 0>;
> +               slew-delay-us = <10>;
> +               wait-retry-us = <3000>;
> +               wait-free-us = <50000>;
> +
> +               /* Use ID 104 as a hint that we're on physical bus 4 */
> +               i2c_104: i2c at 0 {
> +                       reg = <0>;
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +               };
> +       };
> +
>         /*
>          * On Snow we've got SIP WiFi and so can keep drive strengths low to
>          * reduce EMI.
> --
> 1.8.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



--
Shine bright,
(: Nav :)

Re: [PATCH v3 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

[Naveen Krishna Ch]

On 16 February 2013 04:46, Doug Anderson <dianders@chromium.org> wrote:
> Now that we have i2c-arbitrator in place on bus 4 we can add the
> sbs-battery driver.  Future devices will be added onto bus 4 once
> drivers are in good shape.
>
> Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
The patchset v3 is tested on snow with test case which uses i2c-4 from both
EC and AP side continuously for a more than a couple of minutes
> ---
> Changes in v3: None
> Changes in v2: None
>
>  arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
> index d2d4b48..2127386 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -51,6 +51,12 @@
>                         reg = <0>;
>                         #address-cells = <1>;
>                         #size-cells = <0>;
> +
> +                       battery: sbs-battery@b {
> +                               compatible = "sbs,sbs-battery";
> +                               reg = <0xb>;
> +                               sbs,poll-retry-count = <1>;
> +                       };
>                 };
>         };
>
> --
> 1.8.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



--
Shine bright,
(: Nav :)

[PATCH v3 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

[Naveen Krishna Ch]

On 16 February 2013 04:46, Doug Anderson <dianders@chromium.org> wrote:
> Now that we have i2c-arbitrator in place on bus 4 we can add the
> sbs-battery driver.  Future devices will be added onto bus 4 once
> drivers are in good shape.
>
> Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
The patchset v3 is tested on snow with test case which uses i2c-4 from both
EC and AP side continuously for a more than a couple of minutes
> ---
> Changes in v3: None
> Changes in v2: None
>
>  arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
> index d2d4b48..2127386 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -51,6 +51,12 @@
>                         reg = <0>;
>                         #address-cells = <1>;
>                         #size-cells = <0>;
> +
> +                       battery: sbs-battery at b {
> +                               compatible = "sbs,sbs-battery";
> +                               reg = <0xb>;
> +                               sbs,poll-retry-count = <1>;
> +                       };
>                 };
>         };
>
> --
> 1.8.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



--
Shine bright,
(: Nav :)

Re: [PATCH v3 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Doug Anderson]

Wolfram,

On Fri, Feb 15, 2013 at 11:46 AM, Doug Anderson <dianders@chromium.org> wrote:
> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
> that the Embedded Controller (EC) on the ARM Chromebook expects to use
> for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
> be used in other places where standard I2C bus arbitration can't be
> used and two extra GPIOs are available for arbitration.
>
> This driver is based on code that Simon Glass added to the i2c-s3c2410
> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
> mux driver is as suggested by Grant Likely.  See
> <https://patchwork.kernel.org/patch/1877311/> for some history.
>
> Signed-off-by: Doug Anderson <dianders@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
> ---
> Changes in v3:
> - Handle of_find_i2c_adapter_by_node() failure more properly by
>   changing init order.
> - Don't warn on -EPROBE_DEFER from calls that could return it.
> - Move to module_platform_driver().  As we pull in parts of the system
>   that rely on devices under this i2c bus we'll need to make sure they
>   can handle the fact that they'll be initted later now.
>
> Changes in v2:
> - Renamed to i2c-arbitrator-cros-ec.
> - Documented "microsecond" properties as optional; removed
>   "bus-arbitration" prefix since it was just extra wordy.
> - Split GPIOs into two properties to make it cleaner.
> - Capitalized I2C in freeform text.
> - Get 'active low' from device tree.
>
>  .../bindings/i2c/i2c-arbitrator-cros-ec.txt        |  76 +++++++
>  drivers/i2c/muxes/Kconfig                          |  11 +
>  drivers/i2c/muxes/Makefile                         |   2 +
>  drivers/i2c/muxes/i2c-arbitrator-cros-ec.c         | 222 +++++++++++++++++++++
>  4 files changed, 311 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
>  create mode 100644 drivers/i2c/muxes/i2c-arbitrator-cros-ec.c

Is there anything you'd like done before landing this patch for 3.10?
It's been reviewed by Stephen Warren (thanks Stephen!).  From what I
remember from Olof's talk at ELC it seems like the best thing would be
to merge part 1 through i2c tree and then ask Olof to merge parts 2
and 3 (the dts bits) through the arm-soc tree.

I believe you could also add a "Tested-by" from Naveen to patch #1.
He sent a tested by for parts 2 and 3 so must have also tested part 1
(the other two don't function without it).

Please let me know--I'm happy to spin with any changes needed.  :)

-Doug

Re: [PATCH v3 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Doug Anderson]

Wolfram,

On Fri, Feb 15, 2013 at 11:46 AM, Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
> that the Embedded Controller (EC) on the ARM Chromebook expects to use
> for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
> be used in other places where standard I2C bus arbitration can't be
> used and two extra GPIOs are available for arbitration.
>
> This driver is based on code that Simon Glass added to the i2c-s3c2410
> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
> mux driver is as suggested by Grant Likely.  See
> <https://patchwork.kernel.org/patch/1877311/> for some history.
>
> Signed-off-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> Changes in v3:
> - Handle of_find_i2c_adapter_by_node() failure more properly by
>   changing init order.
> - Don't warn on -EPROBE_DEFER from calls that could return it.
> - Move to module_platform_driver().  As we pull in parts of the system
>   that rely on devices under this i2c bus we'll need to make sure they
>   can handle the fact that they'll be initted later now.
>
> Changes in v2:
> - Renamed to i2c-arbitrator-cros-ec.
> - Documented "microsecond" properties as optional; removed
>   "bus-arbitration" prefix since it was just extra wordy.
> - Split GPIOs into two properties to make it cleaner.
> - Capitalized I2C in freeform text.
> - Get 'active low' from device tree.
>
>  .../bindings/i2c/i2c-arbitrator-cros-ec.txt        |  76 +++++++
>  drivers/i2c/muxes/Kconfig                          |  11 +
>  drivers/i2c/muxes/Makefile                         |   2 +
>  drivers/i2c/muxes/i2c-arbitrator-cros-ec.c         | 222 +++++++++++++++++++++
>  4 files changed, 311 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
>  create mode 100644 drivers/i2c/muxes/i2c-arbitrator-cros-ec.c

Is there anything you'd like done before landing this patch for 3.10?
It's been reviewed by Stephen Warren (thanks Stephen!).  From what I
remember from Olof's talk at ELC it seems like the best thing would be
to merge part 1 through i2c tree and then ask Olof to merge parts 2
and 3 (the dts bits) through the arm-soc tree.

I believe you could also add a "Tested-by" from Naveen to patch #1.
He sent a tested by for parts 2 and 3 so must have also tested part 1
(the other two don't function without it).

Please let me know--I'm happy to spin with any changes needed.  :)

-Doug

RE: [PATCH v3 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Kukjin Kim]

Naveen Krishna Ch wrote:
> On 16 February 2013 04:46, Doug Anderson <dianders@chromium.org> wrote:
> > We need to use the i2c-arbitrator to talk to any of the devices on i2c
> > bus 4 on exynos5250-snow so that we don't confuse the embedded
> > controller (EC).  Add the i2c-arbitrator to the device tree.  As we
> > add future devices (keyboard, sbs, tps65090) we'll add them on top of
> > this.
> >
> > The arbitrated bus is numbered 104 simply as a convenience to make it
> > easier for people poking around to guess that it might have something
> > to do with the physical bus 4.
> >
> > The addition is split between the cros5250-common and the snow device
> > tree file since not all cros5250-class devices use arbitration.
> >
> > Signed-off-by: Doug Anderson <dianders@chromium.org>
> Tested-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
> The patch set [v3] is tested on snow with test case which uses i2c-4 from both
> EC and AP side continuously for a more than a couple of minutes.
> 
Thanks for your test and looks good to me.

BTW, Doug, I think, this should be re-worked to use pinctrl. Can you?

Thanks.

- Kukjin

> > ---
> > Changes in v3: None
> > Changes in v2:
> > - Use new device tree property names / compatible string.
> > - Include that the GPIOs for arbitration are active low.
> >
> >  arch/arm/boot/dts/cros5250-common.dtsi |  5 ++++-
> >  arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
> >  2 files changed, 29 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
> b/arch/arm/boot/dts/cros5250-common.dtsi
> > index 46c0980..f451375 100644
> > --- a/arch/arm/boot/dts/cros5250-common.dtsi
> > +++ b/arch/arm/boot/dts/cros5250-common.dtsi
> > @@ -58,7 +58,10 @@
> >         };
> >
> >         i2c@12CA0000 {
> > -               status = "disabled";
> > +               samsung,i2c-sda-delay = <100>;
> > +               samsung,i2c-max-bus-freq = <66000>;
> > +               gpios = <&gpa2 0 3 3 0>,
> > +                       <&gpa2 1 3 3 0>;
> >         };
> >
> >         i2c@12CB0000 {
> > diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts
> > index 17dd951..d2d4b48 100644
> > --- a/arch/arm/boot/dts/exynos5250-snow.dts
> > +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> > @@ -16,6 +16,10 @@
> >         model = "Google Snow";
> >         compatible = "google,snow", "samsung,exynos5250";
> >
> > +       aliases {
> > +               i2c104 = &i2c_104;
> > +       };
> > +
> >         gpio-keys {
> >                 compatible = "gpio-keys";
> >
> > @@ -29,6 +33,27 @@
> >                 };
> >         };
> >
> > +       i2c-arbitrator {
> > +               compatible = "i2c-arbitrator-cros-ec";
> > +               #address-cells = <1>;
> > +               #size-cells = <0>;
> > +
> > +               i2c-parent = <&{/i2c@12CA0000}>;
> > +
> > +               ap-claim-gpio = <&gpf0 3 1 0x10000 0>;
> > +               ec-claim-gpio = <&gpe0 4 0 0x10003 0>;
> > +               slew-delay-us = <10>;
> > +               wait-retry-us = <3000>;
> > +               wait-free-us = <50000>;
> > +
> > +               /* Use ID 104 as a hint that we're on physical bus 4 */
> > +               i2c_104: i2c@0 {
> > +                       reg = <0>;
> > +                       #address-cells = <1>;
> > +                       #size-cells = <0>;
> > +               };
> > +       };
> > +
> >         /*
> >          * On Snow we've got SIP WiFi and so can keep drive strengths low to
> >          * reduce EMI.
> > --
> > 1.8.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> 
> --
> Shine bright,
> (: Nav :)

[PATCH v3 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Kukjin Kim]

Naveen Krishna Ch wrote:
> On 16 February 2013 04:46, Doug Anderson <dianders@chromium.org> wrote:
> > We need to use the i2c-arbitrator to talk to any of the devices on i2c
> > bus 4 on exynos5250-snow so that we don't confuse the embedded
> > controller (EC).  Add the i2c-arbitrator to the device tree.  As we
> > add future devices (keyboard, sbs, tps65090) we'll add them on top of
> > this.
> >
> > The arbitrated bus is numbered 104 simply as a convenience to make it
> > easier for people poking around to guess that it might have something
> > to do with the physical bus 4.
> >
> > The addition is split between the cros5250-common and the snow device
> > tree file since not all cros5250-class devices use arbitration.
> >
> > Signed-off-by: Doug Anderson <dianders@chromium.org>
> Tested-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
> The patch set [v3] is tested on snow with test case which uses i2c-4 from both
> EC and AP side continuously for a more than a couple of minutes.
> 
Thanks for your test and looks good to me.

BTW, Doug, I think, this should be re-worked to use pinctrl. Can you?

Thanks.

- Kukjin

> > ---
> > Changes in v3: None
> > Changes in v2:
> > - Use new device tree property names / compatible string.
> > - Include that the GPIOs for arbitration are active low.
> >
> >  arch/arm/boot/dts/cros5250-common.dtsi |  5 ++++-
> >  arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
> >  2 files changed, 29 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
> b/arch/arm/boot/dts/cros5250-common.dtsi
> > index 46c0980..f451375 100644
> > --- a/arch/arm/boot/dts/cros5250-common.dtsi
> > +++ b/arch/arm/boot/dts/cros5250-common.dtsi
> > @@ -58,7 +58,10 @@
> >         };
> >
> >         i2c at 12CA0000 {
> > -               status = "disabled";
> > +               samsung,i2c-sda-delay = <100>;
> > +               samsung,i2c-max-bus-freq = <66000>;
> > +               gpios = <&gpa2 0 3 3 0>,
> > +                       <&gpa2 1 3 3 0>;
> >         };
> >
> >         i2c at 12CB0000 {
> > diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts
> > index 17dd951..d2d4b48 100644
> > --- a/arch/arm/boot/dts/exynos5250-snow.dts
> > +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> > @@ -16,6 +16,10 @@
> >         model = "Google Snow";
> >         compatible = "google,snow", "samsung,exynos5250";
> >
> > +       aliases {
> > +               i2c104 = &i2c_104;
> > +       };
> > +
> >         gpio-keys {
> >                 compatible = "gpio-keys";
> >
> > @@ -29,6 +33,27 @@
> >                 };
> >         };
> >
> > +       i2c-arbitrator {
> > +               compatible = "i2c-arbitrator-cros-ec";
> > +               #address-cells = <1>;
> > +               #size-cells = <0>;
> > +
> > +               i2c-parent = <&{/i2c@12CA0000}>;
> > +
> > +               ap-claim-gpio = <&gpf0 3 1 0x10000 0>;
> > +               ec-claim-gpio = <&gpe0 4 0 0x10003 0>;
> > +               slew-delay-us = <10>;
> > +               wait-retry-us = <3000>;
> > +               wait-free-us = <50000>;
> > +
> > +               /* Use ID 104 as a hint that we're on physical bus 4 */
> > +               i2c_104: i2c at 0 {
> > +                       reg = <0>;
> > +                       #address-cells = <1>;
> > +                       #size-cells = <0>;
> > +               };
> > +       };
> > +
> >         /*
> >          * On Snow we've got SIP WiFi and so can keep drive strengths low to
> >          * reduce EMI.
> > --
> > 1.8.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> 
> --
> Shine bright,
> (: Nav :)

Re: [PATCH v3 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Doug Anderson]

Kukjin,

On Wed, Mar 13, 2013 at 12:30 AM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> BTW, Doug, I think, this should be re-worked to use pinctrl. Can you?

Yes, I've already got this locally.  I hadn't sent it up yet since I
wasn't sure whether pinctrl would land before or after this.  I'll
send it up today against my local cherry-pick of Thomas's pinctrl
stuff (since it doesn't seem to be in linux-next nor in
arm-soc/for-next).

Naveen: I'm going to keep your Tested-by on all 3 patches if that's
OK.  The only difference will be the gpio specifier in the device tree
and the change is trivial.

-Doug

[PATCH v3 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Doug Anderson]

Kukjin,

On Wed, Mar 13, 2013 at 12:30 AM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> BTW, Doug, I think, this should be re-worked to use pinctrl. Can you?

Yes, I've already got this locally.  I hadn't sent it up yet since I
wasn't sure whether pinctrl would land before or after this.  I'll
send it up today against my local cherry-pick of Thomas's pinctrl
stuff (since it doesn't seem to be in linux-next nor in
arm-soc/for-next).

Naveen: I'm going to keep your Tested-by on all 3 patches if that's
OK.  The only difference will be the gpio specifier in the device tree
and the change is trivial.

-Doug

[PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Doug Anderson]

The i2c-arbitrator-cros-ec driver implements the arbitration scheme
that the Embedded Controller (EC) on the ARM Chromebook expects to use
for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
be used in other places where standard I2C bus arbitration can't be
used and two extra GPIOs are available for arbitration.

This driver is based on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
mux driver is as suggested by Grant Likely.  See
<https://patchwork.kernel.org/patch/1877311/> for some history.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
---
Changes in v4: None
Changes in v3:
- Handle of_find_i2c_adapter_by_node() failure more properly by
  changing init order.
- Don't warn on -EPROBE_DEFER from calls that could return it.
- Move to module_platform_driver().  As we pull in parts of the system
  that rely on devices under this i2c bus we'll need to make sure they
  can handle the fact that they'll be initted later now.

Changes in v2:
- Renamed to i2c-arbitrator-cros-ec.
- Documented "microsecond" properties as optional; removed
  "bus-arbitration" prefix since it was just extra wordy.
- Split GPIOs into two properties to make it cleaner.
- Capitalized I2C in freeform text.
- Get 'active low' from device tree.

 .../bindings/i2c/i2c-arbitrator-cros-ec.txt        |  76 +++++++
 drivers/i2c/muxes/Kconfig                          |  11 +
 drivers/i2c/muxes/Makefile                         |   2 +
 drivers/i2c/muxes/i2c-arbitrator-cros-ec.c         | 222 +++++++++++++++++++++
 4 files changed, 311 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
 create mode 100644 drivers/i2c/muxes/i2c-arbitrator-cros-ec.c

diff --git a/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt b/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
new file mode 100644
index 0000000..1f893e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
@@ -0,0 +1,76 @@
+GPIO-based Arbitration used by the ARM Chromebook (exynos5250-snow)
+===================================================================
+This uses GPIO lines between the AP (Application Processor) and an attached
+EC (Embedded Controller) which both want to talk on the same I2C bus as master.
+
+The AP and EC each have a 'bus claim' line, which is an output that the
+other can see. These are both active low, with pull-ups enabled.
+
+- AP_CLAIM: output from AP, signalling to the EC that the AP wants the bus
+- EC_CLAIM: output from EC, signalling to the AP that the EC wants the bus
+
+This mechanism is used instead of standard I2C multimaster to avoid some of the
+subtle driver and silicon bugs that are often present with I2C multimaster.
+
+
+Algorithm:
+
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also. A detailed explanation is best
+done with an example.
+
+Let's say the AP wants to claim the bus. It:
+1. Asserts AP_CLAIM.
+2. Waits a little bit for the other side to notice (slew time, say 10
+   microseconds).
+3. Checks EC_CLAIM. If this is not asserted then the AP has the bus and we are
+   done.
+4. Otherwise, wait for a few milliseconds and see if EC_CLAIM is released.
+5. If not, back off, release the claim and wait for a few more milliseconds.
+6. Go back to 1 (until retry time has expired).
+
+
+Required properties:
+- compatible: i2c-arbitrator-cros-ec
+- ap-claim-gpio: The GPIO that we (the AP) use to claim the bus.
+- ec-claim-gpio: The GPIO that the other side (the EC) uses the claim the bus.
+- Standard I2C mux properties. See mux.txt in this directory.
+- Single I2C child bus node at reg 0. See mux.txt in this directory.
+
+Optional properties:
+- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
+- wait-retry-us: we'll attempt another claim after this many microseconds.
+    Default is 3000 us.
+- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
+
+
+Example:
+	i2c@12CA0000 {
+		compatible = "acme,some-i2c-device";
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+	i2c-arbitrator {
+		compatible = "i2c-arbitrator-cros-ec";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		ap-claim-gpio = <&gpf0 3 1 0x10000 0>;
+		ec-claim-gpio = <&gpe0 4 0 0x10003 0>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			i2c@52 {
+				// Normal I2C device
+			};
+		};
+	};
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 0be5b83..ca19378 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -5,6 +5,17 @@
 menu "Multiplexer I2C Chip support"
 	depends on I2C_MUX
 
+config I2C_ARBITRATOR_CROS_EC
+	tristate "GPIO-based I2C arbitrator used on exynos5250-snow"
+	depends on GENERIC_GPIO && OF
+	help
+	  If you say yes to this option, support will be included for an
+	  I2C multimaster arbitration scheme using GPIOs that is used in
+	  the Samsung ARM Chromebook (exynos5250-snow).
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called i2c-arbitrator-cros-ec.
+
 config I2C_MUX_GPIO
 	tristate "GPIO-based I2C multiplexer"
 	depends on GENERIC_GPIO
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 76da869..e60dcc1 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -1,6 +1,8 @@
 #
 # Makefile for multiplexer I2C chip drivers.
 
+obj-$(CONFIG_I2C_ARBITRATOR_CROS_EC)	+= i2c-arbitrator-cros-ec.o
+
 obj-$(CONFIG_I2C_MUX_GPIO)	+= i2c-mux-gpio.o
 obj-$(CONFIG_I2C_MUX_PCA9541)	+= i2c-mux-pca9541.o
 obj-$(CONFIG_I2C_MUX_PCA954x)	+= i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c b/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c
new file mode 100644
index 0000000..f95b591
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c
@@ -0,0 +1,222 @@
+/*
+ * I2C arbitrator driver for the ARM Chromebook
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/kernel.h>
+#include <linux/i2c.h>
+#include <linux/i2c-mux.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_i2c.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+
+/**
+ * struct i2c_arbitrator_data - Driver data for I2C arbitrator
+ *
+ * @parent: Parent adapter
+ * @child: Child bus
+ * @ap_gpio: GPIO we'll use to claim.
+ * @ap_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO == this
+ *   then consider it released.
+ * @ec_gpio: GPIO that the other side will use to claim.
+ * @ec_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO == this
+ *   then consider it released.
+ * @slew_delay_us: microseconds to wait for a GPIO to go high.
+ * @wait_retry_us: we'll attempt another claim after this many microseconds.
+ * @wait_free_us: we'll give up after this many microseconds.
+ */
+
+struct i2c_arbitrator_data {
+	struct i2c_adapter *parent;
+	struct i2c_adapter *child;
+
+	int		ap_gpio;
+	int		ap_gpio_release;
+	int		ec_gpio;
+	int		ec_gpio_release;
+	unsigned int	slew_delay_us;
+	unsigned int	wait_retry_us;
+	unsigned int	wait_free_us;
+};
+
+
+/**
+ * i2c_arbitrator_select - claim the I2C bus
+ *
+ * Use the GPIO-based signalling protocol; return -EBUSY if we fail.
+ */
+static int i2c_arbitrator_select(struct i2c_adapter *adap, void *data, u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+	unsigned long stop_retry, stop_time;
+
+	/* Start a round of trying to claim the bus */
+	stop_time = jiffies + usecs_to_jiffies(arb->wait_free_us) + 1;
+	do {
+		/* Indicate that we want to claim the bus */
+		gpio_set_value(arb->ap_gpio, !arb->ap_gpio_release);
+		udelay(arb->slew_delay_us);
+
+		/* Wait for the EC to release it */
+		stop_retry = jiffies + usecs_to_jiffies(arb->wait_retry_us) + 1;
+		while (time_before(jiffies, stop_retry)) {
+			int gpio_val = !!gpio_get_value(arb->ec_gpio);
+
+			if (gpio_val == arb->ec_gpio_release) {
+				/* We got it, so return */
+				return 0;
+			}
+
+			usleep_range(50, 200);
+		}
+
+		/* It didn't release, so give up, wait, and try again */
+		gpio_set_value(arb->ap_gpio, arb->ap_gpio_release);
+
+		usleep_range(arb->wait_retry_us, arb->wait_retry_us * 2);
+	} while (time_before(jiffies, stop_time));
+
+	/* Give up, release our claim */
+	gpio_set_value(arb->ap_gpio, arb->ap_gpio_release);
+	udelay(arb->slew_delay_us);
+	dev_err(&adap->dev, "Could not claim bus, timeout\n");
+	return -EBUSY;
+}
+
+/**
+ * i2c_arbitrator_deselect - release the I2C bus
+ *
+ * Release the I2C bus using the GPIO-based signalling protocol.
+ */
+static int i2c_arbitrator_deselect(struct i2c_adapter *adap, void *data,
+				   u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+
+	/* Release the bus and wait for the EC to notice */
+	gpio_set_value(arb->ap_gpio, arb->ap_gpio_release);
+	udelay(arb->slew_delay_us);
+
+	return 0;
+}
+
+static int i2c_arbitrator_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *parent_np;
+	struct i2c_arbitrator_data *arb;
+	enum of_gpio_flags gpio_flags;
+	unsigned long out_init;
+	int ret;
+
+	/* We only support probing from device tree; no platform_data */
+	if (WARN_ON(!np))
+		return -ENODEV;
+	if (WARN_ON(pdev->dev.platform_data))
+		return -EINVAL;
+
+	arb = devm_kzalloc(&pdev->dev, sizeof(*arb), GFP_KERNEL);
+	if (WARN_ON(!arb))
+		return -ENOMEM;
+	platform_set_drvdata(pdev, arb);
+
+	/* Request GPIOs */
+	ret = of_get_named_gpio_flags(np, "ap-claim-gpio", 0, &gpio_flags);
+	if (ret == -EPROBE_DEFER || WARN_ON(!gpio_is_valid(ret)))
+		return ret;
+	arb->ap_gpio = ret;
+	arb->ap_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	out_init = (gpio_flags & OF_GPIO_ACTIVE_LOW) ?
+		GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
+	ret = devm_gpio_request_one(&pdev->dev, arb->ap_gpio, out_init,
+				    "ap-claim-gpio");
+	if (ret == -EPROBE_DEFER || WARN_ON(ret))
+		return ret;
+
+	ret = of_get_named_gpio_flags(np, "ec-claim-gpio", 0, &gpio_flags);
+	if (ret == -EPROBE_DEFER || WARN_ON(!gpio_is_valid(ret)))
+		return ret;
+	arb->ec_gpio = ret;
+	arb->ec_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	ret = devm_gpio_request_one(&pdev->dev, arb->ec_gpio, GPIOF_IN,
+				    "ec-claim-gpio");
+	if (ret == -EPROBE_DEFER || WARN_ON(ret))
+		return ret;
+
+	/* Arbitration parameters */
+	if (of_property_read_u32(np, "slew-delay-us", &arb->slew_delay_us))
+		arb->slew_delay_us = 10;
+	if (of_property_read_u32(np, "wait-retry-us", &arb->wait_retry_us))
+		arb->wait_retry_us = 3000;
+	if (of_property_read_u32(np, "wait-free-us", &arb->wait_free_us))
+		arb->wait_free_us = 50000;
+
+	/* Find our parent */
+	parent_np = of_parse_phandle(np, "i2c-parent", 0);
+	if (WARN_ON(!parent_np))
+		return -EINVAL;
+	arb->parent = of_find_i2c_adapter_by_node(parent_np);
+	if (WARN_ON(!arb->parent))
+		return -EINVAL;
+
+	/* Actually add the mux adapter */
+	arb->child = i2c_add_mux_adapter(arb->parent, &pdev->dev, arb, 0, 0, 0,
+					 i2c_arbitrator_select,
+					 i2c_arbitrator_deselect);
+	if (WARN_ON(!arb->child)) {
+		ret = -ENODEV;
+		i2c_put_adapter(arb->parent);
+	}
+
+	return ret;
+}
+
+static int i2c_arbitrator_remove(struct platform_device *pdev)
+{
+	struct i2c_arbitrator_data *arb = platform_get_drvdata(pdev);
+
+	i2c_del_mux_adapter(arb->child);
+	i2c_put_adapter(arb->parent);
+
+	return 0;
+}
+
+static const struct of_device_id i2c_arbitrator_of_match[] = {
+	{ .compatible = "i2c-arbitrator-cros-ec", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, i2c_arbitrator_of_match);
+
+static struct platform_driver i2c_arbitrator_driver = {
+	.probe	= i2c_arbitrator_probe,
+	.remove	= i2c_arbitrator_remove,
+	.driver	= {
+		.owner	= THIS_MODULE,
+		.name	= "i2c-arbitrator-cros-ec",
+		.of_match_table = of_match_ptr(i2c_arbitrator_of_match),
+	},
+};
+
+module_platform_driver(i2c_arbitrator_driver);
+
+MODULE_DESCRIPTION("I2C arbitrator driver for the ARM Chromebook");
+MODULE_AUTHOR("Doug Anderson <dianders@chromium.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:i2c-arbitrator-cros-ec");
-- 
1.8.1.3

[PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Doug Anderson]

The i2c-arbitrator-cros-ec driver implements the arbitration scheme
that the Embedded Controller (EC) on the ARM Chromebook expects to use
for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
be used in other places where standard I2C bus arbitration can't be
used and two extra GPIOs are available for arbitration.

This driver is based on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
mux driver is as suggested by Grant Likely.  See
<https://patchwork.kernel.org/patch/1877311/> for some history.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
---
Changes in v4: None
Changes in v3:
- Handle of_find_i2c_adapter_by_node() failure more properly by
  changing init order.
- Don't warn on -EPROBE_DEFER from calls that could return it.
- Move to module_platform_driver().  As we pull in parts of the system
  that rely on devices under this i2c bus we'll need to make sure they
  can handle the fact that they'll be initted later now.

Changes in v2:
- Renamed to i2c-arbitrator-cros-ec.
- Documented "microsecond" properties as optional; removed
  "bus-arbitration" prefix since it was just extra wordy.
- Split GPIOs into two properties to make it cleaner.
- Capitalized I2C in freeform text.
- Get 'active low' from device tree.

 .../bindings/i2c/i2c-arbitrator-cros-ec.txt        |  76 +++++++
 drivers/i2c/muxes/Kconfig                          |  11 +
 drivers/i2c/muxes/Makefile                         |   2 +
 drivers/i2c/muxes/i2c-arbitrator-cros-ec.c         | 222 +++++++++++++++++++++
 4 files changed, 311 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
 create mode 100644 drivers/i2c/muxes/i2c-arbitrator-cros-ec.c

diff --git a/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt b/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
new file mode 100644
index 0000000..1f893e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
@@ -0,0 +1,76 @@
+GPIO-based Arbitration used by the ARM Chromebook (exynos5250-snow)
+===================================================================
+This uses GPIO lines between the AP (Application Processor) and an attached
+EC (Embedded Controller) which both want to talk on the same I2C bus as master.
+
+The AP and EC each have a 'bus claim' line, which is an output that the
+other can see. These are both active low, with pull-ups enabled.
+
+- AP_CLAIM: output from AP, signalling to the EC that the AP wants the bus
+- EC_CLAIM: output from EC, signalling to the AP that the EC wants the bus
+
+This mechanism is used instead of standard I2C multimaster to avoid some of the
+subtle driver and silicon bugs that are often present with I2C multimaster.
+
+
+Algorithm:
+
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also. A detailed explanation is best
+done with an example.
+
+Let's say the AP wants to claim the bus. It:
+1. Asserts AP_CLAIM.
+2. Waits a little bit for the other side to notice (slew time, say 10
+   microseconds).
+3. Checks EC_CLAIM. If this is not asserted then the AP has the bus and we are
+   done.
+4. Otherwise, wait for a few milliseconds and see if EC_CLAIM is released.
+5. If not, back off, release the claim and wait for a few more milliseconds.
+6. Go back to 1 (until retry time has expired).
+
+
+Required properties:
+- compatible: i2c-arbitrator-cros-ec
+- ap-claim-gpio: The GPIO that we (the AP) use to claim the bus.
+- ec-claim-gpio: The GPIO that the other side (the EC) uses the claim the bus.
+- Standard I2C mux properties. See mux.txt in this directory.
+- Single I2C child bus node at reg 0. See mux.txt in this directory.
+
+Optional properties:
+- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
+- wait-retry-us: we'll attempt another claim after this many microseconds.
+    Default is 3000 us.
+- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
+
+
+Example:
+	i2c@12CA0000 {
+		compatible = "acme,some-i2c-device";
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+	i2c-arbitrator {
+		compatible = "i2c-arbitrator-cros-ec";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		ap-claim-gpio = <&gpf0 3 1 0x10000 0>;
+		ec-claim-gpio = <&gpe0 4 0 0x10003 0>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			i2c@52 {
+				// Normal I2C device
+			};
+		};
+	};
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 0be5b83..ca19378 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -5,6 +5,17 @@
 menu "Multiplexer I2C Chip support"
 	depends on I2C_MUX
 
+config I2C_ARBITRATOR_CROS_EC
+	tristate "GPIO-based I2C arbitrator used on exynos5250-snow"
+	depends on GENERIC_GPIO && OF
+	help
+	  If you say yes to this option, support will be included for an
+	  I2C multimaster arbitration scheme using GPIOs that is used in
+	  the Samsung ARM Chromebook (exynos5250-snow).
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called i2c-arbitrator-cros-ec.
+
 config I2C_MUX_GPIO
 	tristate "GPIO-based I2C multiplexer"
 	depends on GENERIC_GPIO
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 76da869..e60dcc1 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -1,6 +1,8 @@
 #
 # Makefile for multiplexer I2C chip drivers.
 
+obj-$(CONFIG_I2C_ARBITRATOR_CROS_EC)	+= i2c-arbitrator-cros-ec.o
+
 obj-$(CONFIG_I2C_MUX_GPIO)	+= i2c-mux-gpio.o
 obj-$(CONFIG_I2C_MUX_PCA9541)	+= i2c-mux-pca9541.o
 obj-$(CONFIG_I2C_MUX_PCA954x)	+= i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c b/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c
new file mode 100644
index 0000000..f95b591
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-arbitrator-cros-ec.c
@@ -0,0 +1,222 @@
+/*
+ * I2C arbitrator driver for the ARM Chromebook
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/kernel.h>
+#include <linux/i2c.h>
+#include <linux/i2c-mux.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_i2c.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+
+/**
+ * struct i2c_arbitrator_data - Driver data for I2C arbitrator
+ *
+ * @parent: Parent adapter
+ * @child: Child bus
+ * @ap_gpio: GPIO we'll use to claim.
+ * @ap_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO == this
+ *   then consider it released.
+ * @ec_gpio: GPIO that the other side will use to claim.
+ * @ec_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO == this
+ *   then consider it released.
+ * @slew_delay_us: microseconds to wait for a GPIO to go high.
+ * @wait_retry_us: we'll attempt another claim after this many microseconds.
+ * @wait_free_us: we'll give up after this many microseconds.
+ */
+
+struct i2c_arbitrator_data {
+	struct i2c_adapter *parent;
+	struct i2c_adapter *child;
+
+	int		ap_gpio;
+	int		ap_gpio_release;
+	int		ec_gpio;
+	int		ec_gpio_release;
+	unsigned int	slew_delay_us;
+	unsigned int	wait_retry_us;
+	unsigned int	wait_free_us;
+};
+
+
+/**
+ * i2c_arbitrator_select - claim the I2C bus
+ *
+ * Use the GPIO-based signalling protocol; return -EBUSY if we fail.
+ */
+static int i2c_arbitrator_select(struct i2c_adapter *adap, void *data, u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+	unsigned long stop_retry, stop_time;
+
+	/* Start a round of trying to claim the bus */
+	stop_time = jiffies + usecs_to_jiffies(arb->wait_free_us) + 1;
+	do {
+		/* Indicate that we want to claim the bus */
+		gpio_set_value(arb->ap_gpio, !arb->ap_gpio_release);
+		udelay(arb->slew_delay_us);
+
+		/* Wait for the EC to release it */
+		stop_retry = jiffies + usecs_to_jiffies(arb->wait_retry_us) + 1;
+		while (time_before(jiffies, stop_retry)) {
+			int gpio_val = !!gpio_get_value(arb->ec_gpio);
+
+			if (gpio_val == arb->ec_gpio_release) {
+				/* We got it, so return */
+				return 0;
+			}
+
+			usleep_range(50, 200);
+		}
+
+		/* It didn't release, so give up, wait, and try again */
+		gpio_set_value(arb->ap_gpio, arb->ap_gpio_release);
+
+		usleep_range(arb->wait_retry_us, arb->wait_retry_us * 2);
+	} while (time_before(jiffies, stop_time));
+
+	/* Give up, release our claim */
+	gpio_set_value(arb->ap_gpio, arb->ap_gpio_release);
+	udelay(arb->slew_delay_us);
+	dev_err(&adap->dev, "Could not claim bus, timeout\n");
+	return -EBUSY;
+}
+
+/**
+ * i2c_arbitrator_deselect - release the I2C bus
+ *
+ * Release the I2C bus using the GPIO-based signalling protocol.
+ */
+static int i2c_arbitrator_deselect(struct i2c_adapter *adap, void *data,
+				   u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+
+	/* Release the bus and wait for the EC to notice */
+	gpio_set_value(arb->ap_gpio, arb->ap_gpio_release);
+	udelay(arb->slew_delay_us);
+
+	return 0;
+}
+
+static int i2c_arbitrator_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *parent_np;
+	struct i2c_arbitrator_data *arb;
+	enum of_gpio_flags gpio_flags;
+	unsigned long out_init;
+	int ret;
+
+	/* We only support probing from device tree; no platform_data */
+	if (WARN_ON(!np))
+		return -ENODEV;
+	if (WARN_ON(pdev->dev.platform_data))
+		return -EINVAL;
+
+	arb = devm_kzalloc(&pdev->dev, sizeof(*arb), GFP_KERNEL);
+	if (WARN_ON(!arb))
+		return -ENOMEM;
+	platform_set_drvdata(pdev, arb);
+
+	/* Request GPIOs */
+	ret = of_get_named_gpio_flags(np, "ap-claim-gpio", 0, &gpio_flags);
+	if (ret == -EPROBE_DEFER || WARN_ON(!gpio_is_valid(ret)))
+		return ret;
+	arb->ap_gpio = ret;
+	arb->ap_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	out_init = (gpio_flags & OF_GPIO_ACTIVE_LOW) ?
+		GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
+	ret = devm_gpio_request_one(&pdev->dev, arb->ap_gpio, out_init,
+				    "ap-claim-gpio");
+	if (ret == -EPROBE_DEFER || WARN_ON(ret))
+		return ret;
+
+	ret = of_get_named_gpio_flags(np, "ec-claim-gpio", 0, &gpio_flags);
+	if (ret == -EPROBE_DEFER || WARN_ON(!gpio_is_valid(ret)))
+		return ret;
+	arb->ec_gpio = ret;
+	arb->ec_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	ret = devm_gpio_request_one(&pdev->dev, arb->ec_gpio, GPIOF_IN,
+				    "ec-claim-gpio");
+	if (ret == -EPROBE_DEFER || WARN_ON(ret))
+		return ret;
+
+	/* Arbitration parameters */
+	if (of_property_read_u32(np, "slew-delay-us", &arb->slew_delay_us))
+		arb->slew_delay_us = 10;
+	if (of_property_read_u32(np, "wait-retry-us", &arb->wait_retry_us))
+		arb->wait_retry_us = 3000;
+	if (of_property_read_u32(np, "wait-free-us", &arb->wait_free_us))
+		arb->wait_free_us = 50000;
+
+	/* Find our parent */
+	parent_np = of_parse_phandle(np, "i2c-parent", 0);
+	if (WARN_ON(!parent_np))
+		return -EINVAL;
+	arb->parent = of_find_i2c_adapter_by_node(parent_np);
+	if (WARN_ON(!arb->parent))
+		return -EINVAL;
+
+	/* Actually add the mux adapter */
+	arb->child = i2c_add_mux_adapter(arb->parent, &pdev->dev, arb, 0, 0, 0,
+					 i2c_arbitrator_select,
+					 i2c_arbitrator_deselect);
+	if (WARN_ON(!arb->child)) {
+		ret = -ENODEV;
+		i2c_put_adapter(arb->parent);
+	}
+
+	return ret;
+}
+
+static int i2c_arbitrator_remove(struct platform_device *pdev)
+{
+	struct i2c_arbitrator_data *arb = platform_get_drvdata(pdev);
+
+	i2c_del_mux_adapter(arb->child);
+	i2c_put_adapter(arb->parent);
+
+	return 0;
+}
+
+static const struct of_device_id i2c_arbitrator_of_match[] = {
+	{ .compatible = "i2c-arbitrator-cros-ec", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, i2c_arbitrator_of_match);
+
+static struct platform_driver i2c_arbitrator_driver = {
+	.probe	= i2c_arbitrator_probe,
+	.remove	= i2c_arbitrator_remove,
+	.driver	= {
+		.owner	= THIS_MODULE,
+		.name	= "i2c-arbitrator-cros-ec",
+		.of_match_table = of_match_ptr(i2c_arbitrator_of_match),
+	},
+};
+
+module_platform_driver(i2c_arbitrator_driver);
+
+MODULE_DESCRIPTION("I2C arbitrator driver for the ARM Chromebook");
+MODULE_AUTHOR("Doug Anderson <dianders@chromium.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:i2c-arbitrator-cros-ec");
-- 
1.8.1.3

[PATCH v4 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Doug Anderson]

We need to use the i2c-arbitrator to talk to any of the devices on i2c
bus 4 on exynos5250-snow so that we don't confuse the embedded
controller (EC).  Add the i2c-arbitrator to the device tree.  As we
add future devices (keyboard, sbs, tps65090) we'll add them on top of
this.

The arbitrated bus is numbered 104 simply as a convenience to make it
easier for people poking around to guess that it might have something
to do with the physical bus 4.

The addition is split between the cros5250-common and the snow device
tree file since not all cros5250-class devices use arbitration.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
---
Changes in v4:
- Changed mux gpio syntax to work atop Thomas's "ARM: dts: add pin
  state information in client nodes for Exynos5 platforms"; avoid
  adding gpios property to i2c@12CA0000 for the same reason.

Changes in v3: None
Changes in v2:
- Use new device tree property names / compatible string.
- Include that the GPIOs for arbitration are active low.

 arch/arm/boot/dts/cros5250-common.dtsi |  3 ++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 8a5b3a6..0a61bbb 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -193,7 +193,8 @@
 	};
 
 	i2c@12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
 	};
 
 	i2c@12CB0000 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 581ffae..bf16353 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -16,6 +16,10 @@
 	model = "Google Snow";
 	compatible = "google,snow", "samsung,exynos5250";
 
+	aliases {
+		i2c104 = &i2c_104;
+	};
+
 	pinctrl@11400000 {
 		sd3_clk: sd3-clk {
 			samsung,pin-drv = <0>;
@@ -44,6 +48,27 @@
 		};
 	};
 
+	i2c-arbitrator {
+		compatible = "i2c-arbitrator-cros-ec";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		ap-claim-gpio = <&gpf0 3 1>;
+		ec-claim-gpio = <&gpe0 4 1>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		/* Use ID 104 as a hint that we're on physical bus 4 */
+		i2c_104: i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	/*
 	 * On Snow we've got SIP WiFi and so can keep drive strengths low to
 	 * reduce EMI.
-- 
1.8.1.3

[PATCH v4 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Doug Anderson]

We need to use the i2c-arbitrator to talk to any of the devices on i2c
bus 4 on exynos5250-snow so that we don't confuse the embedded
controller (EC).  Add the i2c-arbitrator to the device tree.  As we
add future devices (keyboard, sbs, tps65090) we'll add them on top of
this.

The arbitrated bus is numbered 104 simply as a convenience to make it
easier for people poking around to guess that it might have something
to do with the physical bus 4.

The addition is split between the cros5250-common and the snow device
tree file since not all cros5250-class devices use arbitration.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
---
Changes in v4:
- Changed mux gpio syntax to work atop Thomas's "ARM: dts: add pin
  state information in client nodes for Exynos5 platforms"; avoid
  adding gpios property to i2c at 12CA0000 for the same reason.

Changes in v3: None
Changes in v2:
- Use new device tree property names / compatible string.
- Include that the GPIOs for arbitration are active low.

 arch/arm/boot/dts/cros5250-common.dtsi |  3 ++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 8a5b3a6..0a61bbb 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -193,7 +193,8 @@
 	};
 
 	i2c at 12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
 	};
 
 	i2c at 12CB0000 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 581ffae..bf16353 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -16,6 +16,10 @@
 	model = "Google Snow";
 	compatible = "google,snow", "samsung,exynos5250";
 
+	aliases {
+		i2c104 = &i2c_104;
+	};
+
 	pinctrl at 11400000 {
 		sd3_clk: sd3-clk {
 			samsung,pin-drv = <0>;
@@ -44,6 +48,27 @@
 		};
 	};
 
+	i2c-arbitrator {
+		compatible = "i2c-arbitrator-cros-ec";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		ap-claim-gpio = <&gpf0 3 1>;
+		ec-claim-gpio = <&gpe0 4 1>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		/* Use ID 104 as a hint that we're on physical bus 4 */
+		i2c_104: i2c at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	/*
 	 * On Snow we've got SIP WiFi and so can keep drive strengths low to
 	 * reduce EMI.
-- 
1.8.1.3

[PATCH v4 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

[Doug Anderson]

Now that we have i2c-arbitrator in place on bus 4 we can add the
sbs-battery driver.  Future devices will be added onto bus 4 once
drivers are in good shape.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index bf16353..7aa66c8 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -66,6 +66,12 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			battery: sbs-battery@b {
+				compatible = "sbs,sbs-battery";
+				reg = <0xb>;
+				sbs,poll-retry-count = <1>;
+			};
 		};
 	};
 
-- 
1.8.1.3

[PATCH v4 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

[Doug Anderson]

Now that we have i2c-arbitrator in place on bus 4 we can add the
sbs-battery driver.  Future devices will be added onto bus 4 once
drivers are in good shape.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index bf16353..7aa66c8 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -66,6 +66,12 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			battery: sbs-battery at b {
+				compatible = "sbs,sbs-battery";
+				reg = <0xb>;
+				sbs,poll-retry-count = <1>;
+			};
 		};
 	};
 
-- 
1.8.1.3

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Stephen Warren]

On 03/13/2013 10:36 AM, Doug Anderson wrote:
> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
> that the Embedded Controller (EC) on the ARM Chromebook expects to use
> for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
> be used in other places where standard I2C bus arbitration can't be
> used and two extra GPIOs are available for arbitration.
> 
> This driver is based on code that Simon Glass added to the i2c-s3c2410
> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
> mux driver is as suggested by Grant Likely.  See
> <https://patchwork.kernel.org/patch/1877311/> for some history.
...
> Changes in v4: None

Isn't this 'PATCH V3 REPOST' then?

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Stephen Warren]

On 03/13/2013 10:36 AM, Doug Anderson wrote:
> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
> that the Embedded Controller (EC) on the ARM Chromebook expects to use
> for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
> be used in other places where standard I2C bus arbitration can't be
> used and two extra GPIOs are available for arbitration.
> 
> This driver is based on code that Simon Glass added to the i2c-s3c2410
> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
> mux driver is as suggested by Grant Likely.  See
> <https://patchwork.kernel.org/patch/1877311/> for some history.
...
> Changes in v4: None

Isn't this 'PATCH V3 REPOST' then?

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Doug Anderson]

Stephen,

On Wed, Mar 13, 2013 at 9:53 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> Changes in v4: None
>
> Isn't this 'PATCH V3 REPOST' then?

In this case part 2 in the patch series changes but not parts 1 and 3.
 I could have just reposted part 2 with a higher version, but that
makes it a little harder to piece together all of the parts of the
series so I decided to repost all 3.  I can do differently in the
future if you prefer, but my understanding was that it was a matter of
preference/judgement call.

Thanks!  :)

-Doug

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Doug Anderson]

Stephen,

On Wed, Mar 13, 2013 at 9:53 AM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
>> Changes in v4: None
>
> Isn't this 'PATCH V3 REPOST' then?

In this case part 2 in the patch series changes but not parts 1 and 3.
 I could have just reposted part 2 with a higher version, but that
makes it a little harder to piece together all of the parts of the
series so I decided to repost all 3.  I can do differently in the
future if you prefer, but my understanding was that it was a matter of
preference/judgement call.

Thanks!  :)

-Doug

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Stephen Warren]

On 03/13/2013 10:59 AM, Doug Anderson wrote:
> Stephen,
> 
> On Wed, Mar 13, 2013 at 9:53 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>> Changes in v4: None
>>
>> Isn't this 'PATCH V3 REPOST' then?
> 
> In this case part 2 in the patch series changes but not parts 1 and 3.
>  I could have just reposted part 2 with a higher version, but that
> makes it a little harder to piece together all of the parts of the
> series so I decided to repost all 3.  I can do differently in the
> future if you prefer, but my understanding was that it was a matter of
> preference/judgement call.

Oh no you're quite right. I didn't notice it was a 3-part series, since
I only got patch 1/3 filtered into my inbox; I guess I wasn't CC'd on
the rest. Sorry for the noise.

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Stephen Warren]

On 03/13/2013 10:59 AM, Doug Anderson wrote:
> Stephen,
> 
> On Wed, Mar 13, 2013 at 9:53 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>> Changes in v4: None
>>
>> Isn't this 'PATCH V3 REPOST' then?
> 
> In this case part 2 in the patch series changes but not parts 1 and 3.
>  I could have just reposted part 2 with a higher version, but that
> makes it a little harder to piece together all of the parts of the
> series so I decided to repost all 3.  I can do differently in the
> future if you prefer, but my understanding was that it was a matter of
> preference/judgement call.

Oh no you're quite right. I didn't notice it was a 3-part series, since
I only got patch 1/3 filtered into my inbox; I guess I wasn't CC'd on
the rest. Sorry for the noise.

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Doug Anderson]

Wolfram,

On Wed, Mar 13, 2013 at 9:36 AM, Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
> that the Embedded Controller (EC) on the ARM Chromebook expects to use
> for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
> be used in other places where standard I2C bus arbitration can't be
> used and two extra GPIOs are available for arbitration.
>
> This driver is based on code that Simon Glass added to the i2c-s3c2410
> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
> mux driver is as suggested by Grant Likely.  See
> <https://patchwork.kernel.org/patch/1877311/> for some history.
>
> Signed-off-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Reviewed-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Tested-by: Naveen Krishna Chatradhi <ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> Changes in v4: None
> Changes in v3:
> - Handle of_find_i2c_adapter_by_node() failure more properly by
>   changing init order.
> - Don't warn on -EPROBE_DEFER from calls that could return it.
> - Move to module_platform_driver().  As we pull in parts of the system
>   that rely on devices under this i2c bus we'll need to make sure they
>   can handle the fact that they'll be initted later now.
>
> Changes in v2:
> - Renamed to i2c-arbitrator-cros-ec.
> - Documented "microsecond" properties as optional; removed
>   "bus-arbitration" prefix since it was just extra wordy.
> - Split GPIOs into two properties to make it cleaner.
> - Capitalized I2C in freeform text.
> - Get 'active low' from device tree.
>
>  .../bindings/i2c/i2c-arbitrator-cros-ec.txt        |  76 +++++++
>  drivers/i2c/muxes/Kconfig                          |  11 +
>  drivers/i2c/muxes/Makefile                         |   2 +
>  drivers/i2c/muxes/i2c-arbitrator-cros-ec.c         | 222 +++++++++++++++++++++
>  4 files changed, 311 insertions(+)

I'm still looking for some feedback about this patch.  Should I ask
another maintainer to review / pick it up or are you planning on
reviewing / picking up once you have some time?  The lack of this
patch blocks access to quite a few important devices on the ARM
Chromebook.

Note: I'd expect that "dts" parts of this patchset would be picked up
by Kukjin once the main code lands.

Thanks!  :)

-Doug

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Doug Anderson]

Wolfram,

On Fri, Mar 29, 2013 at 4:58 AM, Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> wrote:
> I can't recall the reason standard I2C bus arbitration is not working
> and why this is needed. I need the feeling this is a solution and not a
> workaround. I mean driver bugs can be fixed and I am unsure if it is a
> good idea to open the i2c-arbitration-*.c namespace.

Thanks for the feedback!

Separately from a discussion of the technical merits, I'd say that
this patch is needed because the Embedded Controller (EC) on the ARM
Chromebook shipped expecting to communicate with this scheme.  While
it is technically possible to update the read-write copy of the
software on the EC, it would be prohibitively difficult to ship an
update that changed the communication method.  Specifically we'd still
require fallback to the old scheme in cases where we need to talk to
the read-only copy of the software on the EC.

...but we can also talk technical merits.  One person on our team
spent a bit of time thinking about this and decided that traditional
i2c arbitration can't actually be used in this case (aside from the
general experience about multimaster being buggy).  Specifically, our
bus is setup with these devices on it:

* AP (running Linux) - Master only.  Only talks when awake.
* EC (running custom code) - Acts as a master and _also_ a slave.
* Battery (smart battery) - Only a slave
* Power Management Unit (PMU - tps65090) - Only a slave

Both the AP and the EC would like to talk to the battery and PMU.  The
AP needs to be able to talk to the EC.

The problem here is that the EC is both a master and a slave.  It's my
understanding that if the AP tries to talk EC on the bus at the same
time that the EC is trying to talk to the battery of PMU that we can
get into trouble.  Specifically the EC needs to be switched to "master
mode" to talk to the battery/PMU and thus has a period of time where
it won't be listening for the AP's messages.  The arbitration lines
make it very clear that the EC has gained mastery of the bus and is
free to switch into "master mode" without worrying that the AP may
talk to it.

I will freely admit that I am not an expert on multimater I2C so if
the above is incorrect then let me know.  As I said, though, it's
still useful to get this patch in because that's simply how the
shipping EC expects to communicate.

Thanks!  :)

-Doug

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Simon Glass]

HI Wolfram,

On Wed, Apr 3, 2013 at 12:19 PM, Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> wrote:
> Doug,
>
>> Separately from a discussion of the technical merits, I'd say that
>> this patch is needed because the Embedded Controller (EC) on the ARM
>> Chromebook shipped expecting to communicate with this scheme.  While
>
> Uhrm, with all respect, "we already shipped it" is not a convincing
> argument regarding inclusion. Benefit for the kernel is.
>
>> ...but we can also talk technical merits.  One person on our team
>> spent a bit of time thinking about this and decided that traditional
>> i2c arbitration can't actually be used in this case (aside from the
>
> The details would be extremly interesting here. I am very interested in
> this and will ask a few questions further on. This is to get a better
> undestanding for the situation regarding multi-master and what is
> needed, because I expect some demand for it in the near future.
>
>> general experience about multimaster being buggy).  Specifically, our
>
> I'm also interested in these experiences.

Thanks for coming back on this. Please see my comments below.

>
>> The problem here is that the EC is both a master and a slave.  It's my
>> understanding that if the AP tries to talk EC on the bus at the same
>> time that the EC is trying to talk to the battery of PMU that we can
>> get into trouble.
>
> If I understand correctly, the I2C Specs mention this case explicitly:
>
> "If a master also incorporates a slave function and it loses arbitration
> during the addressing stage, it is possible that the winning master is
> trying to address it. The losing master must therefore switch over
> immediately to its slave mode."

This seems pretty complicated - does the EC then need to compare the
address it was sending with the remaining bits that are to be received
in that address?

Anyway yes we did consider this case at the time, and the STM32
datasheet had mention of it. But it adds quite a bit of complexity. I
think the start sequence is intended to make this all work, at least
in theory, but it seemed risky to rely on it.

The practical problem here is that in my experience the I2C
multi-master feature is lightly used in practice, and is quite tricky
to get right. That experience was shared with other engineers in the
team, and no one was willing to take the risk on getting everything
running perfectly with i2c multi-master, or doing it on a tight
timeline. I suspect this same problem has arisen many times before,
and will arise again, so from that point of view this feature is a
useful addition to the kernel.

If you are interested in specific experiences then I might be able to
collect some comments from people here. For myself I have found that
getting a reliable I2C driver at all is a sufficient challenge and
time sink with many embedded chips. My memory is a little vague now,
but I know that in 2-3 projects we had to use bit-bash due to bugs or
insufficient documentation in the chip's dedicated I2C peripheral. One
project which had multi-master used a retry scheme with sequenced
packets which seemed to work well enough (i.e. adding a layer above
the I2C layer to sort out problems). The snow project was more
challenging on the I2C  ront, due to the critical nature of I2C buses
in the device.

For snow we found that the Exynos driver did not support arbitration
loss, the STM32 driver we had did not support it, the STM32F I2C
errata indicated problems with I2C in general which reduced our
confidence, and we were unable to determine whether the slave devices
on the bus (smart battery and pmic) would definitely do the right
thing (both chips had I2C issues which we were tracking). I am not
trying to point fingers here, and certainly anything can be solved
given sufficient persistence...but keeping to common features that are
well-tested and available is prudent. As it was we spent more time on
I2C drivers than I would like, and you can get a feel for that in the
Chromium bug tracker if you wish.

Again, I don't believe this would be an unusual situation in a product
development. We need to consider the risk and cost of an approach,
rather than just whether it is technically possible.

>From the point of view of arbitration, the two critical points in the
I2C transfer are claiming the bus (detecting that the start condition
failed) and detecting loss of arbitration during a transfer. These
points need to be tested and validated on all master devices, which
can add a considerable burden. Silicon and driver bugs may make this
even more onerous and in fact for some non-compliant implementations
it simply might not work, or might not work reliably.

Please don't take this as a negative view of I2C in general, which is
an excellent bus, unmatched for what it was designed in my view.

>
>> Specifically the EC needs to be switched to "master
>> mode" to talk to the battery/PMU and thus has a period of time where
>> it won't be listening for the AP's messages.
>
> When it talks to the battery, the bus is busy and the EC will not be
> addressed by the AP?

That's right - there is only one bus and we want to avoid contention for it.

>
>> The arbitration lines make it very clear that the EC has gained
>> mastery of the bus and is free to switch into "master mode" without
>> worrying that the AP may talk to it.
>
> There is another thing I wonder: The arbitration is not I2C specific.
> You could use this scheme for various busses. So, besides the question
> if this is really needed on top of I2C arbitration, the other question
> is if this should reside inside the I2C kernel realm or should/could be
> generic.

Yes this is an interesting point! So far this feature has been added:

- in a separate 'arbitrator' driver (my original implementation, and
now suggested by you)
- in the Samsung I2C driver (suggested by Olof Johansson, my second
implementation)
- in the I2C core (suggested in code review I think and implemented by
Naveen Chatradhi)
- as an I2C mux (suggested by Grant Likely, implemented by Doug Anderson)

So yes there are clearly a number of places where it could go and we
might be going around in circles. But we should be careful to address
this question based on present need rather than theoretical value. I
believe there is clear value in having an I2C mux which can arbitrate
between masters using an out-of-band method for the reasons explained
above. Other needs and wishes should be justified on their merits when
they arise.

Having a mux, which can be is set up using the device tree, is quite
an attractive option. It allows the feature to be used by any I2C
driver, and does not touch the core I2C code.

The present patch is a nice clean implementation IMO, and I believe it
has value for the kernel.

Regards,
Simon

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Stephen Warren]

On 04/05/2013 01:37 PM, Simon Glass wrote:
> HI Wolfram,
> 
> On Wed, Apr 3, 2013 at 12:19 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>> Doug,
>>
>>> Separately from a discussion of the technical merits, I'd say that
>>> this patch is needed because the Embedded Controller (EC) on the ARM
>>> Chromebook shipped expecting to communicate with this scheme.  While
>>
>> Uhrm, with all respect, "we already shipped it" is not a convincing
>> argument regarding inclusion. Benefit for the kernel is.

I'm not quite sure why that isn't a convincing argument.

The hardware has shipped. I don't know whether the EC microcode can be
updated in the field; it seems risky to do so even if it's possible. So,
it either gets supported or not; the HW/ucode isn't going to change I
suspect.

Hence, it seems that the decision would be:

a) Disallow the implementation of the arbitration scheme in the kernel,
and hence don't support this board in the kernel. (or at least some very
core features of this board)

b) Allow the implementation of the arbitration scheme in the kernel, and
hence make possible support this board in the kernel.

>From that perspective, the benefit for the kernel question comes down
to: do we see a benefit for the kernel to support this board? I can't
see why that wouldn't be a benefit.

The only disadvantage would be having to carrying code to support that
board. That same argument can be made for any board, and I think
typically doesn't cause any issue. The code for this I2C mux seems
pretty self-contained, so even if it was absolutely terrible (which I
don't think it is), it still wouldn't cause any wide-spread issues, I think.

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Stephen Warren]

On 04/05/2013 01:37 PM, Simon Glass wrote:
> HI Wolfram,
> 
> On Wed, Apr 3, 2013 at 12:19 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>> Doug,
>>
>>> Separately from a discussion of the technical merits, I'd say that
>>> this patch is needed because the Embedded Controller (EC) on the ARM
>>> Chromebook shipped expecting to communicate with this scheme.  While
>>
>> Uhrm, with all respect, "we already shipped it" is not a convincing
>> argument regarding inclusion. Benefit for the kernel is.

I'm not quite sure why that isn't a convincing argument.

The hardware has shipped. I don't know whether the EC microcode can be
updated in the field; it seems risky to do so even if it's possible. So,
it either gets supported or not; the HW/ucode isn't going to change I
suspect.

Hence, it seems that the decision would be:

a) Disallow the implementation of the arbitration scheme in the kernel,
and hence don't support this board in the kernel. (or at least some very
core features of this board)

b) Allow the implementation of the arbitration scheme in the kernel, and
hence make possible support this board in the kernel.

>From that perspective, the benefit for the kernel question comes down
to: do we see a benefit for the kernel to support this board? I can't
see why that wouldn't be a benefit.

The only disadvantage would be having to carrying code to support that
board. That same argument can be made for any board, and I think
typically doesn't cause any issue. The code for this I2C mux seems
pretty self-contained, so even if it was absolutely terrible (which I
don't think it is), it still wouldn't cause any wide-spread issues, I think.

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Guenter Roeck]

On Fri, Apr 05, 2013 at 02:03:52PM -0600, Stephen Warren wrote:
> On 04/05/2013 01:37 PM, Simon Glass wrote:
> > HI Wolfram,
> > 
> > On Wed, Apr 3, 2013 at 12:19 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> >> Doug,
> >>
> >>> Separately from a discussion of the technical merits, I'd say that
> >>> this patch is needed because the Embedded Controller (EC) on the ARM
> >>> Chromebook shipped expecting to communicate with this scheme.  While
> >>
> >> Uhrm, with all respect, "we already shipped it" is not a convincing
> >> argument regarding inclusion. Benefit for the kernel is.
> 
> I'm not quite sure why that isn't a convincing argument.
> 
> The hardware has shipped. I don't know whether the EC microcode can be
> updated in the field; it seems risky to do so even if it's possible. So,
> it either gets supported or not; the HW/ucode isn't going to change I
> suspect.
> 
> Hence, it seems that the decision would be:
> 
> a) Disallow the implementation of the arbitration scheme in the kernel,
> and hence don't support this board in the kernel. (or at least some very
> core features of this board)
> 
> b) Allow the implementation of the arbitration scheme in the kernel, and
> hence make possible support this board in the kernel.
> 
> From that perspective, the benefit for the kernel question comes down
> to: do we see a benefit for the kernel to support this board? I can't
> see why that wouldn't be a benefit.
> 
> The only disadvantage would be having to carrying code to support that
> board. That same argument can be made for any board, and I think
> typically doesn't cause any issue. The code for this I2C mux seems
> pretty self-contained, so even if it was absolutely terrible (which I
> don't think it is), it still wouldn't cause any wide-spread issues, I think.

Very interesting discussion, especially the argument that "we already shipped"
would not be a convincing argument.

I had senior kernel maintainers tell me and the company I work for that we should
submit _all_ our platform specific kernel code and drivers for inclusion into
the upstream kernel.

This exchange suggests that "it is a shipping product" does not count for such
submissions, and that "Benefit for the kernel" would be the deciding factor
instead. Which of course is a very vague statement - if code supporting
Chromebookis is of no benefit for the kernel, support for my company's products
for sure is much less so.

Which kind of leaves me in a bind. On one side I promote that we should submit
all our kernel code, on the other side there is a very compelling case to be
made that it won't be accepted anyway. That doesn't make my life easier -
essentially since it supports those who say that we should not submit anything
in the first place. And believe me, there are many of those. 

Just to give some examples:
- I2C multiplexers. We have a bunch of those. Looking at this exchange,
  it doesn't look good to get that code included.
- Custom multi-function FPGAs and CPLDs, amongst others implementing I2C
  controllers, I2C muxes, GPIO access, Flash access, and other functions. Same
  as above.
- Devicetree support for UIO devices (mostly forwarding ASICs), including gpio
  bindings, interrupt bindings, and clock bindings. Looking at older exchanges,
  that doesn't look good either. And please dont expect me to implement hacks
  around a clean solution because any devicetree binding for UIO drivers
  "does not describe hardware but its use".

Now, I can understand that there may be technical or architectural issues
preventing one driver or another from being accepted. For example, I can
understand if a driver for an USB-I2C adapder isn't accepted because the adapter
reports itself to the USB subsystem as serial driver. But "Benefit for the
kernel" is vague enough to reject anything for no real reason other than
someone not liking it (or the submitter, or the company the submitter
works for, or the hardware architecture).

It would be nice have to get some well defined guidelines for "acceptable"
contributions. "Benefit for the kernel" sure isn't one.

Guenter

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Wolfram Sang]

Hi,

> Very interesting discussion, especially the argument that "we already shipped"
> would not be a convincing argument.
> 
> I had senior kernel maintainers tell me and the company I work for that we should
> submit _all_ our platform specific kernel code and drivers for inclusion into
> the upstream kernel.

Yes, great. Really!

> This exchange suggests that "it is a shipping product" does not count for such
> submissions, and that "Benefit for the kernel" would be the deciding factor
> instead. Which of course is a very vague statement - if code supporting
> Chromebookis is of no benefit for the kernel, support for my company's products
> for sure is much less so.

First, let me state that I did not intend to say that the arbitrator
muxer here has NO benefit for the kernel. I was aware there might be
arguments for that and I wanted some more discussion to make that
clearer to me. Simon's mail was very helpful in that regard and I will
comment on that somewhen later.

Still, I do have problems with "we already shipped it". If the driver is
bad or the underlying concept is fragile, I want the freedom to reject a
patch, product shipped or not. I will be supportive to find a proper
solution, promised. If all fails, there is still staging/ or the
possibility of out-of-tree patches.

> Which kind of leaves me in a bind. On one side I promote that we should submit
> all our kernel code, on the other side there is a very compelling case to be
> made that it won't be accepted anyway. That doesn't make my life easier -

Concentrate on argumenting why the driver is useful and it will be fine.
"we already shipped this" feels a bit like blackmailing to me. And since
most drivers do have well thought reasons for their existance, I'd
primarily like to hear about those.

> essentially since it supports those who say that we should not submit anything
> in the first place. And believe me, there are many of those. 
> 
> Just to give some examples:
> - I2C multiplexers. We have a bunch of those. Looking at this exchange,
>   it doesn't look good to get that code included.

Multiplexers should be easy going, it is the arbitration which is discussed here.
I am open to consider some generic arbitration schemes. What I am reluctant to
do is to allow every board to have its own arbitration scheme. This
would be board support hosted in the I2C directory. Meh.

> It would be nice have to get some well defined guidelines for "acceptable"
> contributions. "Benefit for the kernel" sure isn't one.

I don't think it is possible to write down concrete guidelines for this.
"According to rule 4a) of the guidelines you have to accept my patch"?
That would be a mess, I think.

Regards,

   Wolfram

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Guenter Roeck]

On Sat, Apr 06, 2013 at 10:11:32PM +0200, Wolfram Sang wrote:
> Hi,
> 
> > Very interesting discussion, especially the argument that "we already shipped"
> > would not be a convincing argument.
> > 
> > I had senior kernel maintainers tell me and the company I work for that we should
> > submit _all_ our platform specific kernel code and drivers for inclusion into
> > the upstream kernel.
> 
> Yes, great. Really!
> 
Yes, though, thinking about it, it was "submit" and didn't say anything
about potential for acceptance.

> > This exchange suggests that "it is a shipping product" does not count for such
> > submissions, and that "Benefit for the kernel" would be the deciding factor
> > instead. Which of course is a very vague statement - if code supporting
> > Chromebookis is of no benefit for the kernel, support for my company's products
> > for sure is much less so.
> 
> First, let me state that I did not intend to say that the arbitrator
> muxer here has NO benefit for the kernel. I was aware there might be
> arguments for that and I wanted some more discussion to make that
> clearer to me. Simon's mail was very helpful in that regard and I will
> comment on that somewhen later.
> 
> Still, I do have problems with "we already shipped it". If the driver is
> bad or the underlying concept is fragile, I want the freedom to reject a
> patch, product shipped or not. I will be supportive to find a proper
> solution, promised. If all fails, there is still staging/ or the
> possibility of out-of-tree patches.
> 
I think there is a difference between a bad driver or underlying hardware. To
me, "shipped" applies to hardware or firmware which can not be upgraded, not to
the software running on it.

> > Which kind of leaves me in a bind. On one side I promote that we should submit
> > all our kernel code, on the other side there is a very compelling case to be
> > made that it won't be accepted anyway. That doesn't make my life easier -
> 
> Concentrate on argumenting why the driver is useful and it will be fine.
> "we already shipped this" feels a bit like blackmailing to me. And since
> most drivers do have well thought reasons for their existance, I'd
> primarily like to hear about those.
> 
> > essentially since it supports those who say that we should not submit anything
> > in the first place. And believe me, there are many of those. 
> > 
> > Just to give some examples:
> > - I2C multiplexers. We have a bunch of those. Looking at this exchange,
> >   it doesn't look good to get that code included.
> 
> Multiplexers should be easy going, it is the arbitration which is discussed here.
> I am open to consider some generic arbitration schemes. What I am reluctant to
> do is to allow every board to have its own arbitration scheme. This
> would be board support hosted in the I2C directory. Meh.
> 
"board support hosted in the I2C directory". But that is exactly what I am
talking about, isn't it ? I have board specific multiplexers and a board
specific I2C controller, and that is just talking about the I2C code.

> > It would be nice have to get some well defined guidelines for "acceptable"
> > contributions. "Benefit for the kernel" sure isn't one.
> 
> I don't think it is possible to write down concrete guidelines for this.
> "According to rule 4a) of the guidelines you have to accept my patch"?
> That would be a mess, I think.
> 
Looking at it from a maintainer perspective, I agree.

Where it gets murky is really the hardware part. The (in my opinion)
philosophical arguments around not permitting device-tree based instantiation
of uio devices is one example. Another practical example I had to deal with
in my previous company is VGA memory space. Some hw geniuses decided to re-use
the VGA memory space in an embedded x86 device for an EEPROM. Guess what -
the x86 kernel writes into that space no matter what. A patch to address that
problem was rejected because "you should not re-use VGA memory space".
As if I had a choice.

A better example might be Kontron board support. They implement gpio, I2C mux,
and a watchdog in a PLD. They too have an access arbitration scheme where
one has to acquire a hardware mutex before accessing the pld, if I understand
correctly because some microcontroller might need to access it as well.
Leaving the actual code aside, would you reject that too if you don't like
the arbitration scheme, or because you don't want to have board support
in the i2c directory ?

Thanks,
Guenter

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Wolfram Sang]

Guenter,

> I think there is a difference between a bad driver or underlying hardware. To
> me, "shipped" applies to hardware or firmware which can not be upgraded, not to
> the software running on it.

OK. Valuable distinction.

> "board support hosted in the I2C directory". But that is exactly what I am
> talking about, isn't it ? I have board specific multiplexers and a board
> specific I2C controller, and that is just talking about the I2C code.

Yes and no. I think I can accept that some hardware has GPIOs wired to
handle I2C arbitration. I still have problems in having arbitrator
drivers per board, each one with various ideas how to do it. That would
be a maintenance horror and has nothing to do with I2C, strictly
speaking. What I would love to see is a few generic arbitrator drivers,
e.g. utilizing a timeout-based scheme (as proposed here). Or like the
old SCSI method putting IDs on the wire and the lowest wins. Stuff like
that.

> A better example might be Kontron board support. They implement gpio, I2C mux,
> and a watchdog in a PLD. They too have an access arbitration scheme where
> one has to acquire a hardware mutex before accessing the pld, if I understand
> correctly because some microcontroller might need to access it as well.
> Leaving the actual code aside, would you reject that too if you don't like
> the arbitration scheme, or because you don't want to have board support
> in the i2c directory ?

If I understood correctly, getting the mutex would be done in some
platform code and the I2C driver will simply call the necessary function
to obtain and release the mutex. Or maybe the MFD layer can help, dunno.
Both are fine with me and I don't care about the actual PLD arbitration.

Thanks,

   Wolfram

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Wolfram Sang]

Guenter,

> I think there is a difference between a bad driver or underlying hardware. To
> me, "shipped" applies to hardware or firmware which can not be upgraded, not to
> the software running on it.

OK. Valuable distinction.

> "board support hosted in the I2C directory". But that is exactly what I am
> talking about, isn't it ? I have board specific multiplexers and a board
> specific I2C controller, and that is just talking about the I2C code.

Yes and no. I think I can accept that some hardware has GPIOs wired to
handle I2C arbitration. I still have problems in having arbitrator
drivers per board, each one with various ideas how to do it. That would
be a maintenance horror and has nothing to do with I2C, strictly
speaking. What I would love to see is a few generic arbitrator drivers,
e.g. utilizing a timeout-based scheme (as proposed here). Or like the
old SCSI method putting IDs on the wire and the lowest wins. Stuff like
that.

> A better example might be Kontron board support. They implement gpio, I2C mux,
> and a watchdog in a PLD. They too have an access arbitration scheme where
> one has to acquire a hardware mutex before accessing the pld, if I understand
> correctly because some microcontroller might need to access it as well.
> Leaving the actual code aside, would you reject that too if you don't like
> the arbitration scheme, or because you don't want to have board support
> in the i2c directory ?

If I understood correctly, getting the mutex would be done in some
platform code and the I2C driver will simply call the necessary function
to obtain and release the mutex. Or maybe the MFD layer can help, dunno.
Both are fine with me and I don't care about the actual PLD arbitration.

Thanks,

   Wolfram

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Wolfram Sang]

On Wed, Mar 13, 2013 at 09:36:21AM -0700, Doug Anderson wrote:
> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
> that the Embedded Controller (EC) on the ARM Chromebook expects to use
> for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
> be used in other places where standard I2C bus arbitration can't be
> used and two extra GPIOs are available for arbitration.
> 
> This driver is based on code that Simon Glass added to the i2c-s3c2410
> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
> mux driver is as suggested by Grant Likely.  See
> <https://patchwork.kernel.org/patch/1877311/> for some history.
> 
> Signed-off-by: Doug Anderson <dianders@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
> Reviewed-by: Stephen Warren <swarren@nvidia.com>
> Tested-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>

I'd like to have the bindings more generic. They should allow for n
possible masters IMO. It doesn't need to be implemented right now, but
it should be possible to add that later.

> ---
> Changes in v4: None
> Changes in v3:
> - Handle of_find_i2c_adapter_by_node() failure more properly by
>   changing init order.
> - Don't warn on -EPROBE_DEFER from calls that could return it.
> - Move to module_platform_driver().  As we pull in parts of the system
>   that rely on devices under this i2c bus we'll need to make sure they
>   can handle the fact that they'll be initted later now.
> 
> Changes in v2:
> - Renamed to i2c-arbitrator-cros-ec.
> - Documented "microsecond" properties as optional; removed
>   "bus-arbitration" prefix since it was just extra wordy.
> - Split GPIOs into two properties to make it cleaner.
> - Capitalized I2C in freeform text.
> - Get 'active low' from device tree.
> 
>  .../bindings/i2c/i2c-arbitrator-cros-ec.txt        |  76 +++++++

I wonder about a more generic name. i2c-arb-gpio-challenge.* maybe?

>  drivers/i2c/muxes/Kconfig                          |  11 +
>  drivers/i2c/muxes/Makefile                         |   2 +
>  drivers/i2c/muxes/i2c-arbitrator-cros-ec.c         | 222 +++++++++++++++++++++
>  4 files changed, 311 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
>  create mode 100644 drivers/i2c/muxes/i2c-arbitrator-cros-ec.c
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt b/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
> new file mode 100644
> index 0000000..1f893e7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
> @@ -0,0 +1,76 @@
> +GPIO-based Arbitration used by the ARM Chromebook (exynos5250-snow)
> +===================================================================
> +This uses GPIO lines between the AP (Application Processor) and an attached
> +EC (Embedded Controller) which both want to talk on the same I2C bus as master.
> +
> +The AP and EC each have a 'bus claim' line, which is an output that the
> +other can see. These are both active low, with pull-ups enabled.
> +
> +- AP_CLAIM: output from AP, signalling to the EC that the AP wants the bus
> +- EC_CLAIM: output from EC, signalling to the AP that the EC wants the bus

I'd like to drop the specific terms of AP and EC and just talk about
multiple masters.

> +This mechanism is used instead of standard I2C multimaster to avoid some of the
> +subtle driver and silicon bugs that are often present with I2C multimaster.
> +
> +
> +Algorithm:
> +
> +The basic algorithm is to assert your line when you want the bus, then make
> +sure that the other side doesn't want it also. A detailed explanation is best
> +done with an example.
> +
> +Let's say the AP wants to claim the bus. It:
> +1. Asserts AP_CLAIM.
> +2. Waits a little bit for the other side to notice (slew time, say 10
> +   microseconds).
> +3. Checks EC_CLAIM. If this is not asserted then the AP has the bus and we are
> +   done.
> +4. Otherwise, wait for a few milliseconds and see if EC_CLAIM is released.
> +5. If not, back off, release the claim and wait for a few more milliseconds.
> +6. Go back to 1 (until retry time has expired).
> +
> +
> +Required properties:
> +- compatible: i2c-arbitrator-cros-ec
> +- ap-claim-gpio: The GPIO that we (the AP) use to claim the bus.
> +- ec-claim-gpio: The GPIO that the other side (the EC) uses the claim the bus.

An array based approach like in the i2c-mux-gpio driver would be more
generic. Just mention that the driver only supports 2 entries at the
moment.

> +- Standard I2C mux properties. See mux.txt in this directory.
> +- Single I2C child bus node at reg 0. See mux.txt in this directory.
> +
> +Optional properties:
> +- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
> +- wait-retry-us: we'll attempt another claim after this many microseconds.
> +    Default is 3000 us.
> +- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.

Grant, I assume it is okay to introduce these generic bindings?

> diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
> index 0be5b83..ca19378 100644
> --- a/drivers/i2c/muxes/Kconfig
> +++ b/drivers/i2c/muxes/Kconfig
> @@ -5,6 +5,17 @@
>  menu "Multiplexer I2C Chip support"
>  	depends on I2C_MUX
>  
> +config I2C_ARBITRATOR_CROS_EC
> +	tristate "GPIO-based I2C arbitrator used on exynos5250-snow"
> +	depends on GENERIC_GPIO && OF
> +	help
> +	  If you say yes to this option, support will be included for an
> +	  I2C multimaster arbitration scheme using GPIOs that is used in
> +	  the Samsung ARM Chromebook (exynos5250-snow).
> +
> +	  This driver can also be built as a module.  If so, the module
> +	  will be called i2c-arbitrator-cros-ec.
> +

This text could be more generic then, too.

> +static int i2c_arbitrator_probe(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct device_node *parent_np;
> +	struct i2c_arbitrator_data *arb;
> +	enum of_gpio_flags gpio_flags;
> +	unsigned long out_init;
> +	int ret;
> +
> +	/* We only support probing from device tree; no platform_data */
> +	if (WARN_ON(!np))
> +		return -ENODEV;

Too much WARN_ON for my taste.

Thanks,

   Wolfram

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Wolfram Sang]

On Wed, Mar 13, 2013 at 09:36:21AM -0700, Doug Anderson wrote:
> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
> that the Embedded Controller (EC) on the ARM Chromebook expects to use
> for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
> be used in other places where standard I2C bus arbitration can't be
> used and two extra GPIOs are available for arbitration.
> 
> This driver is based on code that Simon Glass added to the i2c-s3c2410
> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
> mux driver is as suggested by Grant Likely.  See
> <https://patchwork.kernel.org/patch/1877311/> for some history.
> 
> Signed-off-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Reviewed-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Tested-by: Naveen Krishna Chatradhi <ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

I'd like to have the bindings more generic. They should allow for n
possible masters IMO. It doesn't need to be implemented right now, but
it should be possible to add that later.

> ---
> Changes in v4: None
> Changes in v3:
> - Handle of_find_i2c_adapter_by_node() failure more properly by
>   changing init order.
> - Don't warn on -EPROBE_DEFER from calls that could return it.
> - Move to module_platform_driver().  As we pull in parts of the system
>   that rely on devices under this i2c bus we'll need to make sure they
>   can handle the fact that they'll be initted later now.
> 
> Changes in v2:
> - Renamed to i2c-arbitrator-cros-ec.
> - Documented "microsecond" properties as optional; removed
>   "bus-arbitration" prefix since it was just extra wordy.
> - Split GPIOs into two properties to make it cleaner.
> - Capitalized I2C in freeform text.
> - Get 'active low' from device tree.
> 
>  .../bindings/i2c/i2c-arbitrator-cros-ec.txt        |  76 +++++++

I wonder about a more generic name. i2c-arb-gpio-challenge.* maybe?

>  drivers/i2c/muxes/Kconfig                          |  11 +
>  drivers/i2c/muxes/Makefile                         |   2 +
>  drivers/i2c/muxes/i2c-arbitrator-cros-ec.c         | 222 +++++++++++++++++++++
>  4 files changed, 311 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
>  create mode 100644 drivers/i2c/muxes/i2c-arbitrator-cros-ec.c
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt b/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
> new file mode 100644
> index 0000000..1f893e7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-arbitrator-cros-ec.txt
> @@ -0,0 +1,76 @@
> +GPIO-based Arbitration used by the ARM Chromebook (exynos5250-snow)
> +===================================================================
> +This uses GPIO lines between the AP (Application Processor) and an attached
> +EC (Embedded Controller) which both want to talk on the same I2C bus as master.
> +
> +The AP and EC each have a 'bus claim' line, which is an output that the
> +other can see. These are both active low, with pull-ups enabled.
> +
> +- AP_CLAIM: output from AP, signalling to the EC that the AP wants the bus
> +- EC_CLAIM: output from EC, signalling to the AP that the EC wants the bus

I'd like to drop the specific terms of AP and EC and just talk about
multiple masters.

> +This mechanism is used instead of standard I2C multimaster to avoid some of the
> +subtle driver and silicon bugs that are often present with I2C multimaster.
> +
> +
> +Algorithm:
> +
> +The basic algorithm is to assert your line when you want the bus, then make
> +sure that the other side doesn't want it also. A detailed explanation is best
> +done with an example.
> +
> +Let's say the AP wants to claim the bus. It:
> +1. Asserts AP_CLAIM.
> +2. Waits a little bit for the other side to notice (slew time, say 10
> +   microseconds).
> +3. Checks EC_CLAIM. If this is not asserted then the AP has the bus and we are
> +   done.
> +4. Otherwise, wait for a few milliseconds and see if EC_CLAIM is released.
> +5. If not, back off, release the claim and wait for a few more milliseconds.
> +6. Go back to 1 (until retry time has expired).
> +
> +
> +Required properties:
> +- compatible: i2c-arbitrator-cros-ec
> +- ap-claim-gpio: The GPIO that we (the AP) use to claim the bus.
> +- ec-claim-gpio: The GPIO that the other side (the EC) uses the claim the bus.

An array based approach like in the i2c-mux-gpio driver would be more
generic. Just mention that the driver only supports 2 entries at the
moment.

> +- Standard I2C mux properties. See mux.txt in this directory.
> +- Single I2C child bus node at reg 0. See mux.txt in this directory.
> +
> +Optional properties:
> +- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
> +- wait-retry-us: we'll attempt another claim after this many microseconds.
> +    Default is 3000 us.
> +- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.

Grant, I assume it is okay to introduce these generic bindings?

> diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
> index 0be5b83..ca19378 100644
> --- a/drivers/i2c/muxes/Kconfig
> +++ b/drivers/i2c/muxes/Kconfig
> @@ -5,6 +5,17 @@
>  menu "Multiplexer I2C Chip support"
>  	depends on I2C_MUX
>  
> +config I2C_ARBITRATOR_CROS_EC
> +	tristate "GPIO-based I2C arbitrator used on exynos5250-snow"
> +	depends on GENERIC_GPIO && OF
> +	help
> +	  If you say yes to this option, support will be included for an
> +	  I2C multimaster arbitration scheme using GPIOs that is used in
> +	  the Samsung ARM Chromebook (exynos5250-snow).
> +
> +	  This driver can also be built as a module.  If so, the module
> +	  will be called i2c-arbitrator-cros-ec.
> +

This text could be more generic then, too.

> +static int i2c_arbitrator_probe(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct device_node *parent_np;
> +	struct i2c_arbitrator_data *arb;
> +	enum of_gpio_flags gpio_flags;
> +	unsigned long out_init;
> +	int ret;
> +
> +	/* We only support probing from device tree; no platform_data */
> +	if (WARN_ON(!np))
> +		return -ENODEV;

Too much WARN_ON for my taste.

Thanks,

   Wolfram

[PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Doug Anderson]

The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
where masters need to claim the bus with a GPIO before they can start
a transcation.  This should generally only be used when standard I2C
multimaster isn't appropriate for some reason (errata/bugs).

This driver is based on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
mux driver is as suggested by Grant Likely.  See
<https://patchwork.kernel.org/patch/1877311/> for some history.

Signed-off-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Changes in v5:
- Renamed as per Wolfram Sang.
- Avoid references to AP and EC.
- Bindings are now generic and could support N other masters; code
  still only supports one other master.
- Replaced all instances of WARN_ON with error messages.
- Left Stephen's Reviewed-by from v4 since changes aren't huge, but
  please yell if you want it removed or don't like something about the
  new code; removed Naveen's Tested-by for now.

Changes in v4: None
Changes in v3:
- Handle of_find_i2c_adapter_by_node() failure more properly by
  changing init order.
- Don't warn on -EPROBE_DEFER from calls that could return it.
- Move to module_platform_driver().  As we pull in parts of the system
  that rely on devices under this i2c bus we'll need to make sure they
  can handle the fact that they'll be initted later now.

Changes in v2:
- Renamed to i2c-arb-gpio-challenge.
- Documented "microsecond" properties as optional; removed
  "bus-arbitration" prefix since it was just extra wordy.
- Split GPIOs into two properties to make it cleaner.
- Capitalized I2C in freeform text.
- Get 'active low' from device tree.

 .../bindings/i2c/i2c-arb-gpio-challenge.txt        |  80 +++++++
 drivers/i2c/muxes/Kconfig                          |  11 +
 drivers/i2c/muxes/Makefile                         |   2 +
 drivers/i2c/muxes/i2c-arb-gpio-challenge.c         | 252 +++++++++++++++++++++
 4 files changed, 345 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
 create mode 100644 drivers/i2c/muxes/i2c-arb-gpio-challenge.c

diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
new file mode 100644
index 0000000..726e099
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
@@ -0,0 +1,80 @@
+GPIO-based I2C Arbitration
+==========================
+This uses GPIO lines to arbitrate who is the master of an I2C bus in a
+multimaster situation.
+
+In many cases using GPIOs to arbitrate is not needed and a design can use
+the standard I2C multi-master rules.  Using GPIOs is generally useful in
+the case where there is a device on the bus that has errata and/or bugs
+that makes standard multimaster mode not feasible.
+
+
+Algorithm:
+
+All masters on the bus have a 'bus claim' line which is an output that the
+others can see. These are all active low with pull-ups enabled.  We'll
+describe these lines as:
+
+- OUR_CLAIM: output from us signaling to other hosts that we want the bus
+- THEIR_CLAIMS: output from others signaling that they want the bus
+
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also.  A detailed explanation is best
+done with an example.
+
+Let's say we want to claim the bus.  We:
+1. Assert OUR_CLAIM.
+2. Waits a little bit for the other sides to notice (slew time, say 10
+   microseconds).
+3. Check THEIR_CLAIMS.  If none are asserted then the we have the bus and we are
+   done.
+4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
+5. If not, back off, release the claim and wait for a few more milliseconds.
+6. Go back to 1 (until retry time has expired).
+
+
+Required properties:
+- compatible: i2c-arb-gpio-challenge
+- our-claim-gpio: The GPIO that we use to claim the bus.
+- their-claim-gpios: The GPIOs that the other sides use the claim the bus.
+  Note that some implementations may only support a single other master.
+- Standard I2C mux properties. See mux.txt in this directory.
+- Single I2C child bus node at reg 0. See mux.txt in this directory.
+
+Optional properties:
+- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
+- wait-retry-us: we'll attempt another claim after this many microseconds.
+    Default is 3000 us.
+- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
+
+
+Example:
+	i2c@12CA0000 {
+		compatible = "acme,some-i2c-device";
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+	i2c-arbitrator {
+		compatible = "i2c-arb-gpio-challenge";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		our-claim-gpio = <&gpf0 3 1>;
+		their-claim-gpios = <&gpe0 4 1>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			i2c@52 {
+				// Normal I2C device
+			};
+		};
+	};
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 0be5b83..ab4dcaf 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -5,6 +5,17 @@
 menu "Multiplexer I2C Chip support"
 	depends on I2C_MUX
 
+config I2C_ARB_GPIO_CHALLENGE
+	tristate "GPIO-based I2C arbitration"
+	depends on GENERIC_GPIO && OF
+	help
+	  If you say yes to this option, support will be included for an
+	  I2C multimaster arbitration scheme using GPIOs where masters have
+	  to claim the bus by asserting a GPIO.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called i2c-arb-gpio-challenge.
+
 config I2C_MUX_GPIO
 	tristate "GPIO-based I2C multiplexer"
 	depends on GENERIC_GPIO
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 76da869..465778b 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -1,6 +1,8 @@
 #
 # Makefile for multiplexer I2C chip drivers.
 
+obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE)	+= i2c-arb-gpio-challenge.o
+
 obj-$(CONFIG_I2C_MUX_GPIO)	+= i2c-mux-gpio.o
 obj-$(CONFIG_I2C_MUX_PCA9541)	+= i2c-mux-pca9541.o
 obj-$(CONFIG_I2C_MUX_PCA954x)	+= i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
new file mode 100644
index 0000000..bda020a
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
@@ -0,0 +1,252 @@
+/*
+ * GPIO-based I2C Arbitration
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/kernel.h>
+#include <linux/i2c.h>
+#include <linux/i2c-mux.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_i2c.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+
+/**
+ * struct i2c_arbitrator_data - Driver data for I2C arbitrator
+ *
+ * @parent: Parent adapter
+ * @child: Child bus
+ * @our_gpio: GPIO we'll use to claim.
+ * @our_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO ==
+ *   this then consider it released.
+ * @their_gpio: GPIO that the other side will use to claim.
+ * @their_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO ==
+ *   this then consider it released.
+ * @slew_delay_us: microseconds to wait for a GPIO to go high.
+ * @wait_retry_us: we'll attempt another claim after this many microseconds.
+ * @wait_free_us: we'll give up after this many microseconds.
+ */
+
+struct i2c_arbitrator_data {
+	struct i2c_adapter *parent;
+	struct i2c_adapter *child;
+
+	int		our_gpio;
+	int		our_gpio_release;
+	int		their_gpio;
+	int		their_gpio_release;
+	unsigned int	slew_delay_us;
+	unsigned int	wait_retry_us;
+	unsigned int	wait_free_us;
+};
+
+
+/**
+ * i2c_arbitrator_select - claim the I2C bus
+ *
+ * Use the GPIO-based signalling protocol; return -EBUSY if we fail.
+ */
+static int i2c_arbitrator_select(struct i2c_adapter *adap, void *data, u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+	unsigned long stop_retry, stop_time;
+
+	/* Start a round of trying to claim the bus */
+	stop_time = jiffies + usecs_to_jiffies(arb->wait_free_us) + 1;
+	do {
+		/* Indicate that we want to claim the bus */
+		gpio_set_value(arb->our_gpio, !arb->our_gpio_release);
+		udelay(arb->slew_delay_us);
+
+		/* Wait for the other master to release it */
+		stop_retry = jiffies + usecs_to_jiffies(arb->wait_retry_us) + 1;
+		while (time_before(jiffies, stop_retry)) {
+			int gpio_val = !!gpio_get_value(arb->their_gpio);
+
+			if (gpio_val == arb->their_gpio_release) {
+				/* We got it, so return */
+				return 0;
+			}
+
+			usleep_range(50, 200);
+		}
+
+		/* It didn't release, so give up, wait, and try again */
+		gpio_set_value(arb->our_gpio, arb->our_gpio_release);
+
+		usleep_range(arb->wait_retry_us, arb->wait_retry_us * 2);
+	} while (time_before(jiffies, stop_time));
+
+	/* Give up, release our claim */
+	gpio_set_value(arb->our_gpio, arb->our_gpio_release);
+	udelay(arb->slew_delay_us);
+	dev_err(&adap->dev, "Could not claim bus, timeout\n");
+	return -EBUSY;
+}
+
+/**
+ * i2c_arbitrator_deselect - release the I2C bus
+ *
+ * Release the I2C bus using the GPIO-based signalling protocol.
+ */
+static int i2c_arbitrator_deselect(struct i2c_adapter *adap, void *data,
+				   u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+
+	/* Release the bus and wait for the other master to notice */
+	gpio_set_value(arb->our_gpio, arb->our_gpio_release);
+	udelay(arb->slew_delay_us);
+
+	return 0;
+}
+
+static int i2c_arbitrator_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct device_node *parent_np;
+	struct i2c_arbitrator_data *arb;
+	enum of_gpio_flags gpio_flags;
+	unsigned long out_init;
+	int ret;
+
+	/* We only support probing from device tree; no platform_data */
+	if (!np) {
+		dev_err(dev, "Cannot find device tree node\n");
+		return -ENODEV;
+	}
+	if (dev->platform_data) {
+		dev_err(dev, "Platform data is not supported\n");
+		return -EINVAL;
+	}
+
+	arb = devm_kzalloc(dev, sizeof(*arb), GFP_KERNEL);
+	if (!arb) {
+		dev_err(dev, "Cannot allocate i2c_arbitrator_data\n");
+		return -ENOMEM;
+	}
+	platform_set_drvdata(pdev, arb);
+
+	/* Request GPIOs */
+	ret = of_get_named_gpio_flags(np, "our-claim-gpio", 0, &gpio_flags);
+	if (!gpio_is_valid(ret)) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error getting our-claim-gpio\n");
+		return ret;
+	}
+	arb->our_gpio = ret;
+	arb->our_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	out_init = (gpio_flags & OF_GPIO_ACTIVE_LOW) ?
+		GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
+	ret = devm_gpio_request_one(dev, arb->our_gpio, out_init,
+				    "our-claim-gpio");
+	if (ret) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error requesting our-claim-gpio\n");
+		return ret;
+	}
+
+	ret = of_get_named_gpio_flags(np, "their-claim-gpios", 0, &gpio_flags);
+	if (!gpio_is_valid(ret)) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error getting their-claim-gpio\n");
+		return ret;
+	}
+	arb->their_gpio = ret;
+	arb->their_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	ret = devm_gpio_request_one(dev, arb->their_gpio, GPIOF_IN,
+				    "their-claim-gpio");
+	if (ret) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error requesting their-claim-gpio\n");
+		return ret;
+	}
+
+	/* At the moment we only support a single two master (us + 1 other) */
+	if (gpio_is_valid(of_get_named_gpio(np, "their-claim-gpios", 1))) {
+		dev_err(dev, "Only one other master is supported\n");
+		return -EINVAL;
+	}
+
+	/* Arbitration parameters */
+	if (of_property_read_u32(np, "slew-delay-us", &arb->slew_delay_us))
+		arb->slew_delay_us = 10;
+	if (of_property_read_u32(np, "wait-retry-us", &arb->wait_retry_us))
+		arb->wait_retry_us = 3000;
+	if (of_property_read_u32(np, "wait-free-us", &arb->wait_free_us))
+		arb->wait_free_us = 50000;
+
+	/* Find our parent */
+	parent_np = of_parse_phandle(np, "i2c-parent", 0);
+	if (!parent_np) {
+		dev_err(dev, "Cannot parse i2c-parent\n");
+		return -EINVAL;
+	}
+	arb->parent = of_find_i2c_adapter_by_node(parent_np);
+	if (!arb->parent) {
+		dev_err(dev, "Cannot find parent bus\n");
+		return -EINVAL;
+	}
+
+	/* Actually add the mux adapter */
+	arb->child = i2c_add_mux_adapter(arb->parent, dev, arb, 0, 0, 0,
+					 i2c_arbitrator_select,
+					 i2c_arbitrator_deselect);
+	if (!arb->child) {
+		dev_err(dev, "Failed to add adapter\n");
+		ret = -ENODEV;
+		i2c_put_adapter(arb->parent);
+	}
+
+	return ret;
+}
+
+static int i2c_arbitrator_remove(struct platform_device *pdev)
+{
+	struct i2c_arbitrator_data *arb = platform_get_drvdata(pdev);
+
+	i2c_del_mux_adapter(arb->child);
+	i2c_put_adapter(arb->parent);
+
+	return 0;
+}
+
+static const struct of_device_id i2c_arbitrator_of_match[] = {
+	{ .compatible = "i2c-arb-gpio-challenge", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, i2c_arbitrator_of_match);
+
+static struct platform_driver i2c_arbitrator_driver = {
+	.probe	= i2c_arbitrator_probe,
+	.remove	= i2c_arbitrator_remove,
+	.driver	= {
+		.owner	= THIS_MODULE,
+		.name	= "i2c-arb-gpio-challenge",
+		.of_match_table = of_match_ptr(i2c_arbitrator_of_match),
+	},
+};
+
+module_platform_driver(i2c_arbitrator_driver);
+
+MODULE_DESCRIPTION("GPIO-based I2C Arbitration");
+MODULE_AUTHOR("Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:i2c-arb-gpio-challenge");
-- 
1.8.1.3

[PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Doug Anderson]

We need to use the i2c-arbitrator to talk to any of the devices on i2c
bus 4 on exynos5250-snow so that we don't confuse the embedded
controller (EC).  Add the i2c-arbitrator to the device tree.  As we
add future devices (keyboard, sbs, tps65090) we'll add them on top of
this.

The arbitrated bus is numbered 104 simply as a convenience to make it
easier for people poking around to guess that it might have something
to do with the physical bus 4.

The addition is split between the cros5250-common and the snow device
tree file since not all cros5250-class devices use arbitration.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v5:
- Adjust bindings as per Wolfram Sang.

Changes in v4:
- Changed mux gpio syntax to work atop Thomas's "ARM: dts: add pin
  state information in client nodes for Exynos5 platforms"; avoid
  adding gpios property to i2c@12CA0000 for the same reason.

Changes in v3: None
Changes in v2:
- Use new device tree property names / compatible string.
- Include that the GPIOs for arbitration are active low.

 arch/arm/boot/dts/cros5250-common.dtsi |  3 ++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 8a5b3a6..0a61bbb 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -193,7 +193,8 @@
 	};
 
 	i2c@12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
 	};
 
 	i2c@12CB0000 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 581ffae..fa85f58 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -16,6 +16,10 @@
 	model = "Google Snow";
 	compatible = "google,snow", "samsung,exynos5250";
 
+	aliases {
+		i2c104 = &i2c_104;
+	};
+
 	pinctrl@11400000 {
 		sd3_clk: sd3-clk {
 			samsung,pin-drv = <0>;
@@ -44,6 +48,27 @@
 		};
 	};
 
+	i2c-arbitrator {
+		compatible = "i2c-arb-gpio-challenge";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		our-claim-gpio = <&gpf0 3 1>;
+		their-claim-gpios = <&gpe0 4 1>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		/* Use ID 104 as a hint that we're on physical bus 4 */
+		i2c_104: i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	/*
 	 * On Snow we've got SIP WiFi and so can keep drive strengths low to
 	 * reduce EMI.
-- 
1.8.1.3

[PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Doug Anderson]

We need to use the i2c-arbitrator to talk to any of the devices on i2c
bus 4 on exynos5250-snow so that we don't confuse the embedded
controller (EC).  Add the i2c-arbitrator to the device tree.  As we
add future devices (keyboard, sbs, tps65090) we'll add them on top of
this.

The arbitrated bus is numbered 104 simply as a convenience to make it
easier for people poking around to guess that it might have something
to do with the physical bus 4.

The addition is split between the cros5250-common and the snow device
tree file since not all cros5250-class devices use arbitration.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v5:
- Adjust bindings as per Wolfram Sang.

Changes in v4:
- Changed mux gpio syntax to work atop Thomas's "ARM: dts: add pin
  state information in client nodes for Exynos5 platforms"; avoid
  adding gpios property to i2c at 12CA0000 for the same reason.

Changes in v3: None
Changes in v2:
- Use new device tree property names / compatible string.
- Include that the GPIOs for arbitration are active low.

 arch/arm/boot/dts/cros5250-common.dtsi |  3 ++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 8a5b3a6..0a61bbb 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -193,7 +193,8 @@
 	};
 
 	i2c at 12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
 	};
 
 	i2c at 12CB0000 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 581ffae..fa85f58 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -16,6 +16,10 @@
 	model = "Google Snow";
 	compatible = "google,snow", "samsung,exynos5250";
 
+	aliases {
+		i2c104 = &i2c_104;
+	};
+
 	pinctrl at 11400000 {
 		sd3_clk: sd3-clk {
 			samsung,pin-drv = <0>;
@@ -44,6 +48,27 @@
 		};
 	};
 
+	i2c-arbitrator {
+		compatible = "i2c-arb-gpio-challenge";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		our-claim-gpio = <&gpf0 3 1>;
+		their-claim-gpios = <&gpe0 4 1>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		/* Use ID 104 as a hint that we're on physical bus 4 */
+		i2c_104: i2c at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	/*
 	 * On Snow we've got SIP WiFi and so can keep drive strengths low to
 	 * reduce EMI.
-- 
1.8.1.3

[PATCH v5 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

[Doug Anderson]

Now that we have i2c-arbitrator in place on bus 4 we can add the
sbs-battery driver.  Future devices will be added onto bus 4 once
drivers are in good shape.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index fa85f58..c115143 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -66,6 +66,12 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			battery: sbs-battery@b {
+				compatible = "sbs,sbs-battery";
+				reg = <0xb>;
+				sbs,poll-retry-count = <1>;
+			};
 		};
 	};
 
-- 
1.8.1.3

[PATCH v5 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

[Doug Anderson]

Now that we have i2c-arbitrator in place on bus 4 we can add the
sbs-battery driver.  Future devices will be added onto bus 4 once
drivers are in good shape.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index fa85f58..c115143 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -66,6 +66,12 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			battery: sbs-battery at b {
+				compatible = "sbs,sbs-battery";
+				reg = <0xb>;
+				sbs,poll-retry-count = <1>;
+			};
 		};
 	};
 
-- 
1.8.1.3

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Doug Anderson]

Wolfram,

Thanks for your review!

On Mon, Apr 8, 2013 at 3:26 AM, Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> wrote:

> I'd like to have the bindings more generic. They should allow for n
> possible masters IMO. It doesn't need to be implemented right now, but
> it should be possible to add that later.

Done.  Left code as only handling one other master (as you suggested)
since it has been tested that way and there are no known users with
more than one other master.  Code will give an error if it encounters
a device tree with more than one master.


> I wonder about a more generic name. i2c-arb-gpio-challenge.* maybe?

Done.


> I'd like to drop the specific terms of AP and EC and just talk about
> multiple masters.

Done.


> An array based approach like in the i2c-mux-gpio driver would be more
> generic. Just mention that the driver only supports 2 entries at the
> moment.

Done.  Mentioned that some drivers may only support one other master
(rather than describing the current state of the kernel code) since
bindings should make sense even outside of a single driver, I think.


> Grant, I assume it is okay to introduce these generic bindings?

You are thinking that Grant wouldn't like the names I chose, or that
bindings of this type might not be OK?  The scheme as it stands is
pretty close to what Grant suggested himself here
<https://patchwork.kernel.org/patch/1877311/>.

I did drop the "bus-arbitration-" prefix from the ones he wrote up
since it seemed redundant to have that prefix on all properties of a
node that's only for bus arbitration anyway.  I can add them back in
if you think it's better.  I think Grant only had that prefix in his
proposed bindings because that was the name of the properties in
Naveen's patch (where the bus arbitration was bolted on to the i2c bus
and thus needed differentiation).


>> +config I2C_ARBITRATOR_CROS_EC
>> +     tristate "GPIO-based I2C arbitrator used on exynos5250-snow"
>> +     depends on GENERIC_GPIO && OF
>> +     help
>> +       If you say yes to this option, support will be included for an
>> +       I2C multimaster arbitration scheme using GPIOs that is used in
>> +       the Samsung ARM Chromebook (exynos5250-snow).
>> +
>> +       This driver can also be built as a module.  If so, the module
>> +       will be called i2c-arbitrator-cros-ec.
>> +
>
> This text could be more generic then, too.

Done.


>> +     /* We only support probing from device tree; no platform_data */
>> +     if (WARN_ON(!np))
>> +             return -ENODEV;
>
> Too much WARN_ON for my taste.

Sure.  I've removed them all and put dev_err() messages everywhere as
other mux drivers seem to.  I'd been of the mindset that there was no
need for verbose error messages and extra complexity for uncommon
cases like this, but I can see the benefit of describing exactly what
went wrong in the kernel log.


Please let me know if there's any other fixes needed.

-Doug

[PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Doug Anderson]

The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
where masters need to claim the bus with a GPIO before they can start
a transcation.  This should generally only be used when standard I2C
multimaster isn't appropriate for some reason (errata/bugs).

This driver is based on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
mux driver is as suggested by Grant Likely.  See
<https://patchwork.kernel.org/patch/1877311/> for some history.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
---
(Sorry if you got v5 more than once--apparently the CC list has grown
 too long and my mail was rejected; resending with a shorter header)

Changes in v5:
- Renamed as per Wolfram Sang.
- Avoid references to AP and EC.
- Bindings are now generic and could support N other masters; code
  still only supports one other master.
- Replaced all instances of WARN_ON with error messages.
- Left Stephen's Reviewed-by from v4 since changes aren't huge, but
  please yell if you want it removed or don't like something about the
  new code; removed Naveen's Tested-by for now.

Changes in v4: None
Changes in v3:
- Handle of_find_i2c_adapter_by_node() failure more properly by
  changing init order.
- Don't warn on -EPROBE_DEFER from calls that could return it.
- Move to module_platform_driver().  As we pull in parts of the system
  that rely on devices under this i2c bus we'll need to make sure they
  can handle the fact that they'll be initted later now.

Changes in v2:
- Renamed to i2c-arb-gpio-challenge.
- Documented "microsecond" properties as optional; removed
  "bus-arbitration" prefix since it was just extra wordy.
- Split GPIOs into two properties to make it cleaner.
- Capitalized I2C in freeform text.
- Get 'active low' from device tree.

 .../bindings/i2c/i2c-arb-gpio-challenge.txt        |  80 +++++++
 drivers/i2c/muxes/Kconfig                          |  11 +
 drivers/i2c/muxes/Makefile                         |   2 +
 drivers/i2c/muxes/i2c-arb-gpio-challenge.c         | 252 +++++++++++++++++++++
 4 files changed, 345 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
 create mode 100644 drivers/i2c/muxes/i2c-arb-gpio-challenge.c

diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
new file mode 100644
index 0000000..726e099
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
@@ -0,0 +1,80 @@
+GPIO-based I2C Arbitration
+==========================
+This uses GPIO lines to arbitrate who is the master of an I2C bus in a
+multimaster situation.
+
+In many cases using GPIOs to arbitrate is not needed and a design can use
+the standard I2C multi-master rules.  Using GPIOs is generally useful in
+the case where there is a device on the bus that has errata and/or bugs
+that makes standard multimaster mode not feasible.
+
+
+Algorithm:
+
+All masters on the bus have a 'bus claim' line which is an output that the
+others can see. These are all active low with pull-ups enabled.  We'll
+describe these lines as:
+
+- OUR_CLAIM: output from us signaling to other hosts that we want the bus
+- THEIR_CLAIMS: output from others signaling that they want the bus
+
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also.  A detailed explanation is best
+done with an example.
+
+Let's say we want to claim the bus.  We:
+1. Assert OUR_CLAIM.
+2. Waits a little bit for the other sides to notice (slew time, say 10
+   microseconds).
+3. Check THEIR_CLAIMS.  If none are asserted then the we have the bus and we are
+   done.
+4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
+5. If not, back off, release the claim and wait for a few more milliseconds.
+6. Go back to 1 (until retry time has expired).
+
+
+Required properties:
+- compatible: i2c-arb-gpio-challenge
+- our-claim-gpio: The GPIO that we use to claim the bus.
+- their-claim-gpios: The GPIOs that the other sides use the claim the bus.
+  Note that some implementations may only support a single other master.
+- Standard I2C mux properties. See mux.txt in this directory.
+- Single I2C child bus node at reg 0. See mux.txt in this directory.
+
+Optional properties:
+- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
+- wait-retry-us: we'll attempt another claim after this many microseconds.
+    Default is 3000 us.
+- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
+
+
+Example:
+	i2c@12CA0000 {
+		compatible = "acme,some-i2c-device";
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+	i2c-arbitrator {
+		compatible = "i2c-arb-gpio-challenge";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		our-claim-gpio = <&gpf0 3 1>;
+		their-claim-gpios = <&gpe0 4 1>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			i2c@52 {
+				// Normal I2C device
+			};
+		};
+	};
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 0be5b83..ab4dcaf 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -5,6 +5,17 @@
 menu "Multiplexer I2C Chip support"
 	depends on I2C_MUX
 
+config I2C_ARB_GPIO_CHALLENGE
+	tristate "GPIO-based I2C arbitration"
+	depends on GENERIC_GPIO && OF
+	help
+	  If you say yes to this option, support will be included for an
+	  I2C multimaster arbitration scheme using GPIOs where masters have
+	  to claim the bus by asserting a GPIO.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called i2c-arb-gpio-challenge.
+
 config I2C_MUX_GPIO
 	tristate "GPIO-based I2C multiplexer"
 	depends on GENERIC_GPIO
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 76da869..465778b 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -1,6 +1,8 @@
 #
 # Makefile for multiplexer I2C chip drivers.
 
+obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE)	+= i2c-arb-gpio-challenge.o
+
 obj-$(CONFIG_I2C_MUX_GPIO)	+= i2c-mux-gpio.o
 obj-$(CONFIG_I2C_MUX_PCA9541)	+= i2c-mux-pca9541.o
 obj-$(CONFIG_I2C_MUX_PCA954x)	+= i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
new file mode 100644
index 0000000..bda020a
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
@@ -0,0 +1,252 @@
+/*
+ * GPIO-based I2C Arbitration
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/kernel.h>
+#include <linux/i2c.h>
+#include <linux/i2c-mux.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_i2c.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+
+/**
+ * struct i2c_arbitrator_data - Driver data for I2C arbitrator
+ *
+ * @parent: Parent adapter
+ * @child: Child bus
+ * @our_gpio: GPIO we'll use to claim.
+ * @our_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO ==
+ *   this then consider it released.
+ * @their_gpio: GPIO that the other side will use to claim.
+ * @their_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO ==
+ *   this then consider it released.
+ * @slew_delay_us: microseconds to wait for a GPIO to go high.
+ * @wait_retry_us: we'll attempt another claim after this many microseconds.
+ * @wait_free_us: we'll give up after this many microseconds.
+ */
+
+struct i2c_arbitrator_data {
+	struct i2c_adapter *parent;
+	struct i2c_adapter *child;
+
+	int		our_gpio;
+	int		our_gpio_release;
+	int		their_gpio;
+	int		their_gpio_release;
+	unsigned int	slew_delay_us;
+	unsigned int	wait_retry_us;
+	unsigned int	wait_free_us;
+};
+
+
+/**
+ * i2c_arbitrator_select - claim the I2C bus
+ *
+ * Use the GPIO-based signalling protocol; return -EBUSY if we fail.
+ */
+static int i2c_arbitrator_select(struct i2c_adapter *adap, void *data, u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+	unsigned long stop_retry, stop_time;
+
+	/* Start a round of trying to claim the bus */
+	stop_time = jiffies + usecs_to_jiffies(arb->wait_free_us) + 1;
+	do {
+		/* Indicate that we want to claim the bus */
+		gpio_set_value(arb->our_gpio, !arb->our_gpio_release);
+		udelay(arb->slew_delay_us);
+
+		/* Wait for the other master to release it */
+		stop_retry = jiffies + usecs_to_jiffies(arb->wait_retry_us) + 1;
+		while (time_before(jiffies, stop_retry)) {
+			int gpio_val = !!gpio_get_value(arb->their_gpio);
+
+			if (gpio_val == arb->their_gpio_release) {
+				/* We got it, so return */
+				return 0;
+			}
+
+			usleep_range(50, 200);
+		}
+
+		/* It didn't release, so give up, wait, and try again */
+		gpio_set_value(arb->our_gpio, arb->our_gpio_release);
+
+		usleep_range(arb->wait_retry_us, arb->wait_retry_us * 2);
+	} while (time_before(jiffies, stop_time));
+
+	/* Give up, release our claim */
+	gpio_set_value(arb->our_gpio, arb->our_gpio_release);
+	udelay(arb->slew_delay_us);
+	dev_err(&adap->dev, "Could not claim bus, timeout\n");
+	return -EBUSY;
+}
+
+/**
+ * i2c_arbitrator_deselect - release the I2C bus
+ *
+ * Release the I2C bus using the GPIO-based signalling protocol.
+ */
+static int i2c_arbitrator_deselect(struct i2c_adapter *adap, void *data,
+				   u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+
+	/* Release the bus and wait for the other master to notice */
+	gpio_set_value(arb->our_gpio, arb->our_gpio_release);
+	udelay(arb->slew_delay_us);
+
+	return 0;
+}
+
+static int i2c_arbitrator_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct device_node *parent_np;
+	struct i2c_arbitrator_data *arb;
+	enum of_gpio_flags gpio_flags;
+	unsigned long out_init;
+	int ret;
+
+	/* We only support probing from device tree; no platform_data */
+	if (!np) {
+		dev_err(dev, "Cannot find device tree node\n");
+		return -ENODEV;
+	}
+	if (dev->platform_data) {
+		dev_err(dev, "Platform data is not supported\n");
+		return -EINVAL;
+	}
+
+	arb = devm_kzalloc(dev, sizeof(*arb), GFP_KERNEL);
+	if (!arb) {
+		dev_err(dev, "Cannot allocate i2c_arbitrator_data\n");
+		return -ENOMEM;
+	}
+	platform_set_drvdata(pdev, arb);
+
+	/* Request GPIOs */
+	ret = of_get_named_gpio_flags(np, "our-claim-gpio", 0, &gpio_flags);
+	if (!gpio_is_valid(ret)) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error getting our-claim-gpio\n");
+		return ret;
+	}
+	arb->our_gpio = ret;
+	arb->our_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	out_init = (gpio_flags & OF_GPIO_ACTIVE_LOW) ?
+		GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
+	ret = devm_gpio_request_one(dev, arb->our_gpio, out_init,
+				    "our-claim-gpio");
+	if (ret) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error requesting our-claim-gpio\n");
+		return ret;
+	}
+
+	ret = of_get_named_gpio_flags(np, "their-claim-gpios", 0, &gpio_flags);
+	if (!gpio_is_valid(ret)) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error getting their-claim-gpio\n");
+		return ret;
+	}
+	arb->their_gpio = ret;
+	arb->their_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	ret = devm_gpio_request_one(dev, arb->their_gpio, GPIOF_IN,
+				    "their-claim-gpio");
+	if (ret) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error requesting their-claim-gpio\n");
+		return ret;
+	}
+
+	/* At the moment we only support a single two master (us + 1 other) */
+	if (gpio_is_valid(of_get_named_gpio(np, "their-claim-gpios", 1))) {
+		dev_err(dev, "Only one other master is supported\n");
+		return -EINVAL;
+	}
+
+	/* Arbitration parameters */
+	if (of_property_read_u32(np, "slew-delay-us", &arb->slew_delay_us))
+		arb->slew_delay_us = 10;
+	if (of_property_read_u32(np, "wait-retry-us", &arb->wait_retry_us))
+		arb->wait_retry_us = 3000;
+	if (of_property_read_u32(np, "wait-free-us", &arb->wait_free_us))
+		arb->wait_free_us = 50000;
+
+	/* Find our parent */
+	parent_np = of_parse_phandle(np, "i2c-parent", 0);
+	if (!parent_np) {
+		dev_err(dev, "Cannot parse i2c-parent\n");
+		return -EINVAL;
+	}
+	arb->parent = of_find_i2c_adapter_by_node(parent_np);
+	if (!arb->parent) {
+		dev_err(dev, "Cannot find parent bus\n");
+		return -EINVAL;
+	}
+
+	/* Actually add the mux adapter */
+	arb->child = i2c_add_mux_adapter(arb->parent, dev, arb, 0, 0, 0,
+					 i2c_arbitrator_select,
+					 i2c_arbitrator_deselect);
+	if (!arb->child) {
+		dev_err(dev, "Failed to add adapter\n");
+		ret = -ENODEV;
+		i2c_put_adapter(arb->parent);
+	}
+
+	return ret;
+}
+
+static int i2c_arbitrator_remove(struct platform_device *pdev)
+{
+	struct i2c_arbitrator_data *arb = platform_get_drvdata(pdev);
+
+	i2c_del_mux_adapter(arb->child);
+	i2c_put_adapter(arb->parent);
+
+	return 0;
+}
+
+static const struct of_device_id i2c_arbitrator_of_match[] = {
+	{ .compatible = "i2c-arb-gpio-challenge", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, i2c_arbitrator_of_match);
+
+static struct platform_driver i2c_arbitrator_driver = {
+	.probe	= i2c_arbitrator_probe,
+	.remove	= i2c_arbitrator_remove,
+	.driver	= {
+		.owner	= THIS_MODULE,
+		.name	= "i2c-arb-gpio-challenge",
+		.of_match_table = of_match_ptr(i2c_arbitrator_of_match),
+	},
+};
+
+module_platform_driver(i2c_arbitrator_driver);
+
+MODULE_DESCRIPTION("GPIO-based I2C Arbitration");
+MODULE_AUTHOR("Doug Anderson <dianders@chromium.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:i2c-arb-gpio-challenge");
-- 
1.8.1.3

[PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Doug Anderson]

The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
where masters need to claim the bus with a GPIO before they can start
a transcation.  This should generally only be used when standard I2C
multimaster isn't appropriate for some reason (errata/bugs).

This driver is based on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
mux driver is as suggested by Grant Likely.  See
<https://patchwork.kernel.org/patch/1877311/> for some history.

Signed-off-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
(Sorry if you got v5 more than once--apparently the CC list has grown
 too long and my mail was rejected; resending with a shorter header)

Changes in v5:
- Renamed as per Wolfram Sang.
- Avoid references to AP and EC.
- Bindings are now generic and could support N other masters; code
  still only supports one other master.
- Replaced all instances of WARN_ON with error messages.
- Left Stephen's Reviewed-by from v4 since changes aren't huge, but
  please yell if you want it removed or don't like something about the
  new code; removed Naveen's Tested-by for now.

Changes in v4: None
Changes in v3:
- Handle of_find_i2c_adapter_by_node() failure more properly by
  changing init order.
- Don't warn on -EPROBE_DEFER from calls that could return it.
- Move to module_platform_driver().  As we pull in parts of the system
  that rely on devices under this i2c bus we'll need to make sure they
  can handle the fact that they'll be initted later now.

Changes in v2:
- Renamed to i2c-arb-gpio-challenge.
- Documented "microsecond" properties as optional; removed
  "bus-arbitration" prefix since it was just extra wordy.
- Split GPIOs into two properties to make it cleaner.
- Capitalized I2C in freeform text.
- Get 'active low' from device tree.

 .../bindings/i2c/i2c-arb-gpio-challenge.txt        |  80 +++++++
 drivers/i2c/muxes/Kconfig                          |  11 +
 drivers/i2c/muxes/Makefile                         |   2 +
 drivers/i2c/muxes/i2c-arb-gpio-challenge.c         | 252 +++++++++++++++++++++
 4 files changed, 345 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
 create mode 100644 drivers/i2c/muxes/i2c-arb-gpio-challenge.c

diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
new file mode 100644
index 0000000..726e099
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
@@ -0,0 +1,80 @@
+GPIO-based I2C Arbitration
+==========================
+This uses GPIO lines to arbitrate who is the master of an I2C bus in a
+multimaster situation.
+
+In many cases using GPIOs to arbitrate is not needed and a design can use
+the standard I2C multi-master rules.  Using GPIOs is generally useful in
+the case where there is a device on the bus that has errata and/or bugs
+that makes standard multimaster mode not feasible.
+
+
+Algorithm:
+
+All masters on the bus have a 'bus claim' line which is an output that the
+others can see. These are all active low with pull-ups enabled.  We'll
+describe these lines as:
+
+- OUR_CLAIM: output from us signaling to other hosts that we want the bus
+- THEIR_CLAIMS: output from others signaling that they want the bus
+
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also.  A detailed explanation is best
+done with an example.
+
+Let's say we want to claim the bus.  We:
+1. Assert OUR_CLAIM.
+2. Waits a little bit for the other sides to notice (slew time, say 10
+   microseconds).
+3. Check THEIR_CLAIMS.  If none are asserted then the we have the bus and we are
+   done.
+4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
+5. If not, back off, release the claim and wait for a few more milliseconds.
+6. Go back to 1 (until retry time has expired).
+
+
+Required properties:
+- compatible: i2c-arb-gpio-challenge
+- our-claim-gpio: The GPIO that we use to claim the bus.
+- their-claim-gpios: The GPIOs that the other sides use the claim the bus.
+  Note that some implementations may only support a single other master.
+- Standard I2C mux properties. See mux.txt in this directory.
+- Single I2C child bus node at reg 0. See mux.txt in this directory.
+
+Optional properties:
+- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
+- wait-retry-us: we'll attempt another claim after this many microseconds.
+    Default is 3000 us.
+- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
+
+
+Example:
+	i2c@12CA0000 {
+		compatible = "acme,some-i2c-device";
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+	i2c-arbitrator {
+		compatible = "i2c-arb-gpio-challenge";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		our-claim-gpio = <&gpf0 3 1>;
+		their-claim-gpios = <&gpe0 4 1>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			i2c@52 {
+				// Normal I2C device
+			};
+		};
+	};
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 0be5b83..ab4dcaf 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -5,6 +5,17 @@
 menu "Multiplexer I2C Chip support"
 	depends on I2C_MUX
 
+config I2C_ARB_GPIO_CHALLENGE
+	tristate "GPIO-based I2C arbitration"
+	depends on GENERIC_GPIO && OF
+	help
+	  If you say yes to this option, support will be included for an
+	  I2C multimaster arbitration scheme using GPIOs where masters have
+	  to claim the bus by asserting a GPIO.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called i2c-arb-gpio-challenge.
+
 config I2C_MUX_GPIO
 	tristate "GPIO-based I2C multiplexer"
 	depends on GENERIC_GPIO
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 76da869..465778b 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -1,6 +1,8 @@
 #
 # Makefile for multiplexer I2C chip drivers.
 
+obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE)	+= i2c-arb-gpio-challenge.o
+
 obj-$(CONFIG_I2C_MUX_GPIO)	+= i2c-mux-gpio.o
 obj-$(CONFIG_I2C_MUX_PCA9541)	+= i2c-mux-pca9541.o
 obj-$(CONFIG_I2C_MUX_PCA954x)	+= i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
new file mode 100644
index 0000000..bda020a
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
@@ -0,0 +1,252 @@
+/*
+ * GPIO-based I2C Arbitration
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/kernel.h>
+#include <linux/i2c.h>
+#include <linux/i2c-mux.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_i2c.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+
+/**
+ * struct i2c_arbitrator_data - Driver data for I2C arbitrator
+ *
+ * @parent: Parent adapter
+ * @child: Child bus
+ * @our_gpio: GPIO we'll use to claim.
+ * @our_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO ==
+ *   this then consider it released.
+ * @their_gpio: GPIO that the other side will use to claim.
+ * @their_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO ==
+ *   this then consider it released.
+ * @slew_delay_us: microseconds to wait for a GPIO to go high.
+ * @wait_retry_us: we'll attempt another claim after this many microseconds.
+ * @wait_free_us: we'll give up after this many microseconds.
+ */
+
+struct i2c_arbitrator_data {
+	struct i2c_adapter *parent;
+	struct i2c_adapter *child;
+
+	int		our_gpio;
+	int		our_gpio_release;
+	int		their_gpio;
+	int		their_gpio_release;
+	unsigned int	slew_delay_us;
+	unsigned int	wait_retry_us;
+	unsigned int	wait_free_us;
+};
+
+
+/**
+ * i2c_arbitrator_select - claim the I2C bus
+ *
+ * Use the GPIO-based signalling protocol; return -EBUSY if we fail.
+ */
+static int i2c_arbitrator_select(struct i2c_adapter *adap, void *data, u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+	unsigned long stop_retry, stop_time;
+
+	/* Start a round of trying to claim the bus */
+	stop_time = jiffies + usecs_to_jiffies(arb->wait_free_us) + 1;
+	do {
+		/* Indicate that we want to claim the bus */
+		gpio_set_value(arb->our_gpio, !arb->our_gpio_release);
+		udelay(arb->slew_delay_us);
+
+		/* Wait for the other master to release it */
+		stop_retry = jiffies + usecs_to_jiffies(arb->wait_retry_us) + 1;
+		while (time_before(jiffies, stop_retry)) {
+			int gpio_val = !!gpio_get_value(arb->their_gpio);
+
+			if (gpio_val == arb->their_gpio_release) {
+				/* We got it, so return */
+				return 0;
+			}
+
+			usleep_range(50, 200);
+		}
+
+		/* It didn't release, so give up, wait, and try again */
+		gpio_set_value(arb->our_gpio, arb->our_gpio_release);
+
+		usleep_range(arb->wait_retry_us, arb->wait_retry_us * 2);
+	} while (time_before(jiffies, stop_time));
+
+	/* Give up, release our claim */
+	gpio_set_value(arb->our_gpio, arb->our_gpio_release);
+	udelay(arb->slew_delay_us);
+	dev_err(&adap->dev, "Could not claim bus, timeout\n");
+	return -EBUSY;
+}
+
+/**
+ * i2c_arbitrator_deselect - release the I2C bus
+ *
+ * Release the I2C bus using the GPIO-based signalling protocol.
+ */
+static int i2c_arbitrator_deselect(struct i2c_adapter *adap, void *data,
+				   u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+
+	/* Release the bus and wait for the other master to notice */
+	gpio_set_value(arb->our_gpio, arb->our_gpio_release);
+	udelay(arb->slew_delay_us);
+
+	return 0;
+}
+
+static int i2c_arbitrator_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct device_node *parent_np;
+	struct i2c_arbitrator_data *arb;
+	enum of_gpio_flags gpio_flags;
+	unsigned long out_init;
+	int ret;
+
+	/* We only support probing from device tree; no platform_data */
+	if (!np) {
+		dev_err(dev, "Cannot find device tree node\n");
+		return -ENODEV;
+	}
+	if (dev->platform_data) {
+		dev_err(dev, "Platform data is not supported\n");
+		return -EINVAL;
+	}
+
+	arb = devm_kzalloc(dev, sizeof(*arb), GFP_KERNEL);
+	if (!arb) {
+		dev_err(dev, "Cannot allocate i2c_arbitrator_data\n");
+		return -ENOMEM;
+	}
+	platform_set_drvdata(pdev, arb);
+
+	/* Request GPIOs */
+	ret = of_get_named_gpio_flags(np, "our-claim-gpio", 0, &gpio_flags);
+	if (!gpio_is_valid(ret)) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error getting our-claim-gpio\n");
+		return ret;
+	}
+	arb->our_gpio = ret;
+	arb->our_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	out_init = (gpio_flags & OF_GPIO_ACTIVE_LOW) ?
+		GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
+	ret = devm_gpio_request_one(dev, arb->our_gpio, out_init,
+				    "our-claim-gpio");
+	if (ret) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error requesting our-claim-gpio\n");
+		return ret;
+	}
+
+	ret = of_get_named_gpio_flags(np, "their-claim-gpios", 0, &gpio_flags);
+	if (!gpio_is_valid(ret)) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error getting their-claim-gpio\n");
+		return ret;
+	}
+	arb->their_gpio = ret;
+	arb->their_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	ret = devm_gpio_request_one(dev, arb->their_gpio, GPIOF_IN,
+				    "their-claim-gpio");
+	if (ret) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error requesting their-claim-gpio\n");
+		return ret;
+	}
+
+	/* At the moment we only support a single two master (us + 1 other) */
+	if (gpio_is_valid(of_get_named_gpio(np, "their-claim-gpios", 1))) {
+		dev_err(dev, "Only one other master is supported\n");
+		return -EINVAL;
+	}
+
+	/* Arbitration parameters */
+	if (of_property_read_u32(np, "slew-delay-us", &arb->slew_delay_us))
+		arb->slew_delay_us = 10;
+	if (of_property_read_u32(np, "wait-retry-us", &arb->wait_retry_us))
+		arb->wait_retry_us = 3000;
+	if (of_property_read_u32(np, "wait-free-us", &arb->wait_free_us))
+		arb->wait_free_us = 50000;
+
+	/* Find our parent */
+	parent_np = of_parse_phandle(np, "i2c-parent", 0);
+	if (!parent_np) {
+		dev_err(dev, "Cannot parse i2c-parent\n");
+		return -EINVAL;
+	}
+	arb->parent = of_find_i2c_adapter_by_node(parent_np);
+	if (!arb->parent) {
+		dev_err(dev, "Cannot find parent bus\n");
+		return -EINVAL;
+	}
+
+	/* Actually add the mux adapter */
+	arb->child = i2c_add_mux_adapter(arb->parent, dev, arb, 0, 0, 0,
+					 i2c_arbitrator_select,
+					 i2c_arbitrator_deselect);
+	if (!arb->child) {
+		dev_err(dev, "Failed to add adapter\n");
+		ret = -ENODEV;
+		i2c_put_adapter(arb->parent);
+	}
+
+	return ret;
+}
+
+static int i2c_arbitrator_remove(struct platform_device *pdev)
+{
+	struct i2c_arbitrator_data *arb = platform_get_drvdata(pdev);
+
+	i2c_del_mux_adapter(arb->child);
+	i2c_put_adapter(arb->parent);
+
+	return 0;
+}
+
+static const struct of_device_id i2c_arbitrator_of_match[] = {
+	{ .compatible = "i2c-arb-gpio-challenge", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, i2c_arbitrator_of_match);
+
+static struct platform_driver i2c_arbitrator_driver = {
+	.probe	= i2c_arbitrator_probe,
+	.remove	= i2c_arbitrator_remove,
+	.driver	= {
+		.owner	= THIS_MODULE,
+		.name	= "i2c-arb-gpio-challenge",
+		.of_match_table = of_match_ptr(i2c_arbitrator_of_match),
+	},
+};
+
+module_platform_driver(i2c_arbitrator_driver);
+
+MODULE_DESCRIPTION("GPIO-based I2C Arbitration");
+MODULE_AUTHOR("Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:i2c-arb-gpio-challenge");
-- 
1.8.1.3

[PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Doug Anderson]

We need to use the i2c-arbitrator to talk to any of the devices on i2c
bus 4 on exynos5250-snow so that we don't confuse the embedded
controller (EC).  Add the i2c-arbitrator to the device tree.  As we
add future devices (keyboard, sbs, tps65090) we'll add them on top of
this.

The arbitrated bus is numbered 104 simply as a convenience to make it
easier for people poking around to guess that it might have something
to do with the physical bus 4.

The addition is split between the cros5250-common and the snow device
tree file since not all cros5250-class devices use arbitration.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v5:
- Adjust bindings as per Wolfram Sang.

Changes in v4:
- Changed mux gpio syntax to work atop Thomas's "ARM: dts: add pin
  state information in client nodes for Exynos5 platforms"; avoid
  adding gpios property to i2c@12CA0000 for the same reason.

Changes in v3: None
Changes in v2:
- Use new device tree property names / compatible string.
- Include that the GPIOs for arbitration are active low.

 arch/arm/boot/dts/cros5250-common.dtsi |  3 ++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 8a5b3a6..0a61bbb 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -193,7 +193,8 @@
 	};
 
 	i2c@12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
 	};
 
 	i2c@12CB0000 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 581ffae..fa85f58 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -16,6 +16,10 @@
 	model = "Google Snow";
 	compatible = "google,snow", "samsung,exynos5250";
 
+	aliases {
+		i2c104 = &i2c_104;
+	};
+
 	pinctrl@11400000 {
 		sd3_clk: sd3-clk {
 			samsung,pin-drv = <0>;
@@ -44,6 +48,27 @@
 		};
 	};
 
+	i2c-arbitrator {
+		compatible = "i2c-arb-gpio-challenge";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		our-claim-gpio = <&gpf0 3 1>;
+		their-claim-gpios = <&gpe0 4 1>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		/* Use ID 104 as a hint that we're on physical bus 4 */
+		i2c_104: i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	/*
 	 * On Snow we've got SIP WiFi and so can keep drive strengths low to
 	 * reduce EMI.
-- 
1.8.1.3

[PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Doug Anderson]

We need to use the i2c-arbitrator to talk to any of the devices on i2c
bus 4 on exynos5250-snow so that we don't confuse the embedded
controller (EC).  Add the i2c-arbitrator to the device tree.  As we
add future devices (keyboard, sbs, tps65090) we'll add them on top of
this.

The arbitrated bus is numbered 104 simply as a convenience to make it
easier for people poking around to guess that it might have something
to do with the physical bus 4.

The addition is split between the cros5250-common and the snow device
tree file since not all cros5250-class devices use arbitration.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v5:
- Adjust bindings as per Wolfram Sang.

Changes in v4:
- Changed mux gpio syntax to work atop Thomas's "ARM: dts: add pin
  state information in client nodes for Exynos5 platforms"; avoid
  adding gpios property to i2c at 12CA0000 for the same reason.

Changes in v3: None
Changes in v2:
- Use new device tree property names / compatible string.
- Include that the GPIOs for arbitration are active low.

 arch/arm/boot/dts/cros5250-common.dtsi |  3 ++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 8a5b3a6..0a61bbb 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -193,7 +193,8 @@
 	};
 
 	i2c at 12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
 	};
 
 	i2c at 12CB0000 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 581ffae..fa85f58 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -16,6 +16,10 @@
 	model = "Google Snow";
 	compatible = "google,snow", "samsung,exynos5250";
 
+	aliases {
+		i2c104 = &i2c_104;
+	};
+
 	pinctrl at 11400000 {
 		sd3_clk: sd3-clk {
 			samsung,pin-drv = <0>;
@@ -44,6 +48,27 @@
 		};
 	};
 
+	i2c-arbitrator {
+		compatible = "i2c-arb-gpio-challenge";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		our-claim-gpio = <&gpf0 3 1>;
+		their-claim-gpios = <&gpe0 4 1>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		/* Use ID 104 as a hint that we're on physical bus 4 */
+		i2c_104: i2c at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	/*
 	 * On Snow we've got SIP WiFi and so can keep drive strengths low to
 	 * reduce EMI.
-- 
1.8.1.3

[PATCH v5 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

[Doug Anderson]

Now that we have i2c-arbitrator in place on bus 4 we can add the
sbs-battery driver.  Future devices will be added onto bus 4 once
drivers are in good shape.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index fa85f58..c115143 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -66,6 +66,12 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			battery: sbs-battery@b {
+				compatible = "sbs,sbs-battery";
+				reg = <0xb>;
+				sbs,poll-retry-count = <1>;
+			};
 		};
 	};
 
-- 
1.8.1.3

[PATCH v5 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

[Doug Anderson]

Now that we have i2c-arbitrator in place on bus 4 we can add the
sbs-battery driver.  Future devices will be added onto bus 4 once
drivers are in good shape.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index fa85f58..c115143 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -66,6 +66,12 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			battery: sbs-battery at b {
+				compatible = "sbs,sbs-battery";
+				reg = <0xb>;
+				sbs,poll-retry-count = <1>;
+			};
 		};
 	};
 
-- 
1.8.1.3

RE: [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Kukjin Kim]

Doug Anderson wrote:
> 
> We need to use the i2c-arbitrator to talk to any of the devices on i2c
> bus 4 on exynos5250-snow so that we don't confuse the embedded
> controller (EC).  Add the i2c-arbitrator to the device tree.  As we
> add future devices (keyboard, sbs, tps65090) we'll add them on top of
> this.
> 
> The arbitrated bus is numbered 104 simply as a convenience to make it
> easier for people poking around to guess that it might have something
> to do with the physical bus 4.
> 
> The addition is split between the cros5250-common and the snow device
> tree file since not all cros5250-class devices use arbitration.
> 
> Signed-off-by: Doug Anderson <dianders@chromium.org>

I'm fine on 2nd and 3rd patches. Shall I take only two patches without 1st
one in samsung tree?

- Kukjin

> ---
> Changes in v5:
> - Adjust bindings as per Wolfram Sang.
> 
> Changes in v4:
> - Changed mux gpio syntax to work atop Thomas's "ARM: dts: add pin
>   state information in client nodes for Exynos5 platforms"; avoid
>   adding gpios property to i2c@12CA0000 for the same reason.
> 
> Changes in v3: None
> Changes in v2:
> - Use new device tree property names / compatible string.
> - Include that the GPIOs for arbitration are active low.
> 
>  arch/arm/boot/dts/cros5250-common.dtsi |  3 ++-
>  arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
>  2 files changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
> b/arch/arm/boot/dts/cros5250-common.dtsi
> index 8a5b3a6..0a61bbb 100644
> --- a/arch/arm/boot/dts/cros5250-common.dtsi
> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
> @@ -193,7 +193,8 @@
>  	};
> 
>  	i2c@12CA0000 {
> -		status = "disabled";
> +		samsung,i2c-sda-delay = <100>;
> +		samsung,i2c-max-bus-freq = <66000>;
>  	};
> 
>  	i2c@12CB0000 {
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index 581ffae..fa85f58 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -16,6 +16,10 @@
>  	model = "Google Snow";
>  	compatible = "google,snow", "samsung,exynos5250";
> 
> +	aliases {
> +		i2c104 = &i2c_104;
> +	};
> +
>  	pinctrl@11400000 {
>  		sd3_clk: sd3-clk {
>  			samsung,pin-drv = <0>;
> @@ -44,6 +48,27 @@
>  		};
>  	};
> 
> +	i2c-arbitrator {
> +		compatible = "i2c-arb-gpio-challenge";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		i2c-parent = <&{/i2c@12CA0000}>;
> +
> +		our-claim-gpio = <&gpf0 3 1>;
> +		their-claim-gpios = <&gpe0 4 1>;
> +		slew-delay-us = <10>;
> +		wait-retry-us = <3000>;
> +		wait-free-us = <50000>;
> +
> +		/* Use ID 104 as a hint that we're on physical bus 4 */
> +		i2c_104: i2c@0 {
> +			reg = <0>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +	};
> +
>  	/*
>  	 * On Snow we've got SIP WiFi and so can keep drive strengths low
> to
>  	 * reduce EMI.
> --
> 1.8.1.3

[PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Kukjin Kim]

Doug Anderson wrote:
> 
> We need to use the i2c-arbitrator to talk to any of the devices on i2c
> bus 4 on exynos5250-snow so that we don't confuse the embedded
> controller (EC).  Add the i2c-arbitrator to the device tree.  As we
> add future devices (keyboard, sbs, tps65090) we'll add them on top of
> this.
> 
> The arbitrated bus is numbered 104 simply as a convenience to make it
> easier for people poking around to guess that it might have something
> to do with the physical bus 4.
> 
> The addition is split between the cros5250-common and the snow device
> tree file since not all cros5250-class devices use arbitration.
> 
> Signed-off-by: Doug Anderson <dianders@chromium.org>

I'm fine on 2nd and 3rd patches. Shall I take only two patches without 1st
one in samsung tree?

- Kukjin

> ---
> Changes in v5:
> - Adjust bindings as per Wolfram Sang.
> 
> Changes in v4:
> - Changed mux gpio syntax to work atop Thomas's "ARM: dts: add pin
>   state information in client nodes for Exynos5 platforms"; avoid
>   adding gpios property to i2c at 12CA0000 for the same reason.
> 
> Changes in v3: None
> Changes in v2:
> - Use new device tree property names / compatible string.
> - Include that the GPIOs for arbitration are active low.
> 
>  arch/arm/boot/dts/cros5250-common.dtsi |  3 ++-
>  arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
>  2 files changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
> b/arch/arm/boot/dts/cros5250-common.dtsi
> index 8a5b3a6..0a61bbb 100644
> --- a/arch/arm/boot/dts/cros5250-common.dtsi
> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
> @@ -193,7 +193,8 @@
>  	};
> 
>  	i2c at 12CA0000 {
> -		status = "disabled";
> +		samsung,i2c-sda-delay = <100>;
> +		samsung,i2c-max-bus-freq = <66000>;
>  	};
> 
>  	i2c at 12CB0000 {
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index 581ffae..fa85f58 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -16,6 +16,10 @@
>  	model = "Google Snow";
>  	compatible = "google,snow", "samsung,exynos5250";
> 
> +	aliases {
> +		i2c104 = &i2c_104;
> +	};
> +
>  	pinctrl at 11400000 {
>  		sd3_clk: sd3-clk {
>  			samsung,pin-drv = <0>;
> @@ -44,6 +48,27 @@
>  		};
>  	};
> 
> +	i2c-arbitrator {
> +		compatible = "i2c-arb-gpio-challenge";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		i2c-parent = <&{/i2c@12CA0000}>;
> +
> +		our-claim-gpio = <&gpf0 3 1>;
> +		their-claim-gpios = <&gpe0 4 1>;
> +		slew-delay-us = <10>;
> +		wait-retry-us = <3000>;
> +		wait-free-us = <50000>;
> +
> +		/* Use ID 104 as a hint that we're on physical bus 4 */
> +		i2c_104: i2c at 0 {
> +			reg = <0>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +	};
> +
>  	/*
>  	 * On Snow we've got SIP WiFi and so can keep drive strengths low
> to
>  	 * reduce EMI.
> --
> 1.8.1.3

Re: [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Wolfram Sang]

On Wed, Apr 10, 2013 at 07:59:17PM +0900, Kukjin Kim wrote:
> Doug Anderson wrote:
> > 
> > We need to use the i2c-arbitrator to talk to any of the devices on i2c
> > bus 4 on exynos5250-snow so that we don't confuse the embedded
> > controller (EC).  Add the i2c-arbitrator to the device tree.  As we
> > add future devices (keyboard, sbs, tps65090) we'll add them on top of
> > this.
> > 
> > The arbitrated bus is numbered 104 simply as a convenience to make it
> > easier for people poking around to guess that it might have something
> > to do with the physical bus 4.
> > 
> > The addition is split between the cros5250-common and the snow device
> > tree file since not all cros5250-class devices use arbitration.
> > 
> > Signed-off-by: Doug Anderson <dianders@chromium.org>
> 
> I'm fine on 2nd and 3rd patches. Shall I take only two patches without 1st
> one in samsung tree?

Please wait for my OK on patch 1. Or ack patches 2 and 3 and I will pick
them up. I am fine with both.

[PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Wolfram Sang]

On Wed, Apr 10, 2013 at 07:59:17PM +0900, Kukjin Kim wrote:
> Doug Anderson wrote:
> > 
> > We need to use the i2c-arbitrator to talk to any of the devices on i2c
> > bus 4 on exynos5250-snow so that we don't confuse the embedded
> > controller (EC).  Add the i2c-arbitrator to the device tree.  As we
> > add future devices (keyboard, sbs, tps65090) we'll add them on top of
> > this.
> > 
> > The arbitrated bus is numbered 104 simply as a convenience to make it
> > easier for people poking around to guess that it might have something
> > to do with the physical bus 4.
> > 
> > The addition is split between the cros5250-common and the snow device
> > tree file since not all cros5250-class devices use arbitration.
> > 
> > Signed-off-by: Doug Anderson <dianders@chromium.org>
> 
> I'm fine on 2nd and 3rd patches. Shall I take only two patches without 1st
> one in samsung tree?

Please wait for my OK on patch 1. Or ack patches 2 and 3 and I will pick
them up. I am fine with both.

Re: [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Kukjin Kim]

On 04/10/13 20:02, Wolfram Sang wrote:
> On Wed, Apr 10, 2013 at 07:59:17PM +0900, Kukjin Kim wrote:
>> Doug Anderson wrote:
>>>
>>> We need to use the i2c-arbitrator to talk to any of the devices on i2c
>>> bus 4 on exynos5250-snow so that we don't confuse the embedded
>>> controller (EC).  Add the i2c-arbitrator to the device tree.  As we
>>> add future devices (keyboard, sbs, tps65090) we'll add them on top of
>>> this.
>>>
>>> The arbitrated bus is numbered 104 simply as a convenience to make it
>>> easier for people poking around to guess that it might have something
>>> to do with the physical bus 4.
>>>
>>> The addition is split between the cros5250-common and the snow device
>>> tree file since not all cros5250-class devices use arbitration.
>>>
>>> Signed-off-by: Doug Anderson<dianders@chromium.org>
>>
>> I'm fine on 2nd and 3rd patches. Shall I take only two patches without 1st
>> one in samsung tree?
>
> Please wait for my OK on patch 1. Or ack patches 2 and 3 and I will pick
> them up. I am fine with both.
>
OK, I will wait for your reply on this. Because I suppose if the dt 
patches in your tree could make useless conflicts. Anyway let me know 
your opinion on that.

Thanks.

- Kukjin

[PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Kukjin Kim]

On 04/10/13 20:02, Wolfram Sang wrote:
> On Wed, Apr 10, 2013 at 07:59:17PM +0900, Kukjin Kim wrote:
>> Doug Anderson wrote:
>>>
>>> We need to use the i2c-arbitrator to talk to any of the devices on i2c
>>> bus 4 on exynos5250-snow so that we don't confuse the embedded
>>> controller (EC).  Add the i2c-arbitrator to the device tree.  As we
>>> add future devices (keyboard, sbs, tps65090) we'll add them on top of
>>> this.
>>>
>>> The arbitrated bus is numbered 104 simply as a convenience to make it
>>> easier for people poking around to guess that it might have something
>>> to do with the physical bus 4.
>>>
>>> The addition is split between the cros5250-common and the snow device
>>> tree file since not all cros5250-class devices use arbitration.
>>>
>>> Signed-off-by: Doug Anderson<dianders@chromium.org>
>>
>> I'm fine on 2nd and 3rd patches. Shall I take only two patches without 1st
>> one in samsung tree?
>
> Please wait for my OK on patch 1. Or ack patches 2 and 3 and I will pick
> them up. I am fine with both.
>
OK, I will wait for your reply on this. Because I suppose if the dt 
patches in your tree could make useless conflicts. Anyway let me know 
your opinion on that.

Thanks.

- Kukjin

Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Wolfram Sang]

Doug,

On Tue, Apr 09, 2013 at 02:34:28PM -0700, Doug Anderson wrote:
> The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
> where masters need to claim the bus with a GPIO before they can start
> a transcation.  This should generally only be used when standard I2C
> multimaster isn't appropriate for some reason (errata/bugs).
> 
> This driver is based on code that Simon Glass added to the i2c-s3c2410
> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
> mux driver is as suggested by Grant Likely.  See
> <https://patchwork.kernel.org/patch/1877311/> for some history.
> 
> Signed-off-by: Doug Anderson <dianders@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
> Reviewed-by: Stephen Warren <swarren@nvidia.com>

Mostly good, except for some documentation updates.

> diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
> new file mode 100644
> index 0000000..726e099
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
> @@ -0,0 +1,80 @@
> +GPIO-based I2C Arbitration
> +==========================
> +This uses GPIO lines to arbitrate who is the master of an I2C bus in a
> +multimaster situation.

"uses GPIO lines and a challange & response mechanism" or something like
that. There might be other GPIO based arbitrations in the future (though
I hope there won't).

> +
> +In many cases using GPIOs to arbitrate is not needed and a design can use
> +the standard I2C multi-master rules.  Using GPIOs is generally useful in
> +the case where there is a device on the bus that has errata and/or bugs
> +that makes standard multimaster mode not feasible.

I like this paragraph!

...

> +- their-claim-gpios: The GPIOs that the other sides use the claim the bus.
> +  Note that some implementations may only support a single other master.

Stronger? "Currently, only one other master is supported"?

...

> diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
> index 0be5b83..ab4dcaf 100644
> --- a/drivers/i2c/muxes/Kconfig
> +++ b/drivers/i2c/muxes/Kconfig
> @@ -5,6 +5,17 @@
>  menu "Multiplexer I2C Chip support"
>  	depends on I2C_MUX
>  
> +config I2C_ARB_GPIO_CHALLENGE
> +	tristate "GPIO-based I2C arbitration"
> +	depends on GENERIC_GPIO && OF
> +	help
> +	  If you say yes to this option, support will be included for an
> +	  I2C multimaster arbitration scheme using GPIOs where masters have
> +	  to claim the bus by asserting a GPIO.

"callenge & response"?

...

> diff --git a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
> new file mode 100644
> index 0000000..bda020a
> --- /dev/null
> +++ b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
> @@ -0,0 +1,252 @@
> +/*
> + * GPIO-based I2C Arbitration

"callenge & response"?

...

> + *
> + * Copyright (C) 2012 Google, Inc
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/gpio.h>
> +#include <linux/kernel.h>
> +#include <linux/i2c.h>
> +#include <linux/i2c-mux.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/of_i2c.h>
> +#include <linux/of_gpio.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +
> +
> +/**
> + * struct i2c_arbitrator_data - Driver data for I2C arbitrator
> + *
> + * @parent: Parent adapter
> + * @child: Child bus
> + * @our_gpio: GPIO we'll use to claim.
> + * @our_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO ==
> + *   this then consider it released.
> + * @their_gpio: GPIO that the other side will use to claim.
> + * @their_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO ==
> + *   this then consider it released.
> + * @slew_delay_us: microseconds to wait for a GPIO to go high.
> + * @wait_retry_us: we'll attempt another claim after this many microseconds.
> + * @wait_free_us: we'll give up after this many microseconds.
> + */
> +
> +struct i2c_arbitrator_data {
> +	struct i2c_adapter *parent;
> +	struct i2c_adapter *child;
> +

No empty line.

> +	int		our_gpio;
> +	int		our_gpio_release;
> +	int		their_gpio;
> +	int		their_gpio_release;
> +	unsigned int	slew_delay_us;
> +	unsigned int	wait_retry_us;
> +	unsigned int	wait_free_us;
> +};

Single space as indentaion after "int".

Other than that, looks fine to me.

Thanks!

Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Wolfram Sang]

Doug,

On Tue, Apr 09, 2013 at 02:34:28PM -0700, Doug Anderson wrote:
> The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
> where masters need to claim the bus with a GPIO before they can start
> a transcation.  This should generally only be used when standard I2C
> multimaster isn't appropriate for some reason (errata/bugs).
> 
> This driver is based on code that Simon Glass added to the i2c-s3c2410
> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
> mux driver is as suggested by Grant Likely.  See
> <https://patchwork.kernel.org/patch/1877311/> for some history.
> 
> Signed-off-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Reviewed-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

Mostly good, except for some documentation updates.

> diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
> new file mode 100644
> index 0000000..726e099
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
> @@ -0,0 +1,80 @@
> +GPIO-based I2C Arbitration
> +==========================
> +This uses GPIO lines to arbitrate who is the master of an I2C bus in a
> +multimaster situation.

"uses GPIO lines and a challange & response mechanism" or something like
that. There might be other GPIO based arbitrations in the future (though
I hope there won't).

> +
> +In many cases using GPIOs to arbitrate is not needed and a design can use
> +the standard I2C multi-master rules.  Using GPIOs is generally useful in
> +the case where there is a device on the bus that has errata and/or bugs
> +that makes standard multimaster mode not feasible.

I like this paragraph!

...

> +- their-claim-gpios: The GPIOs that the other sides use the claim the bus.
> +  Note that some implementations may only support a single other master.

Stronger? "Currently, only one other master is supported"?

...

> diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
> index 0be5b83..ab4dcaf 100644
> --- a/drivers/i2c/muxes/Kconfig
> +++ b/drivers/i2c/muxes/Kconfig
> @@ -5,6 +5,17 @@
>  menu "Multiplexer I2C Chip support"
>  	depends on I2C_MUX
>  
> +config I2C_ARB_GPIO_CHALLENGE
> +	tristate "GPIO-based I2C arbitration"
> +	depends on GENERIC_GPIO && OF
> +	help
> +	  If you say yes to this option, support will be included for an
> +	  I2C multimaster arbitration scheme using GPIOs where masters have
> +	  to claim the bus by asserting a GPIO.

"callenge & response"?

...

> diff --git a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
> new file mode 100644
> index 0000000..bda020a
> --- /dev/null
> +++ b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
> @@ -0,0 +1,252 @@
> +/*
> + * GPIO-based I2C Arbitration

"callenge & response"?

...

> + *
> + * Copyright (C) 2012 Google, Inc
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/gpio.h>
> +#include <linux/kernel.h>
> +#include <linux/i2c.h>
> +#include <linux/i2c-mux.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/of_i2c.h>
> +#include <linux/of_gpio.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +
> +
> +/**
> + * struct i2c_arbitrator_data - Driver data for I2C arbitrator
> + *
> + * @parent: Parent adapter
> + * @child: Child bus
> + * @our_gpio: GPIO we'll use to claim.
> + * @our_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO ==
> + *   this then consider it released.
> + * @their_gpio: GPIO that the other side will use to claim.
> + * @their_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO ==
> + *   this then consider it released.
> + * @slew_delay_us: microseconds to wait for a GPIO to go high.
> + * @wait_retry_us: we'll attempt another claim after this many microseconds.
> + * @wait_free_us: we'll give up after this many microseconds.
> + */
> +
> +struct i2c_arbitrator_data {
> +	struct i2c_adapter *parent;
> +	struct i2c_adapter *child;
> +

No empty line.

> +	int		our_gpio;
> +	int		our_gpio_release;
> +	int		their_gpio;
> +	int		their_gpio_release;
> +	unsigned int	slew_delay_us;
> +	unsigned int	wait_retry_us;
> +	unsigned int	wait_free_us;
> +};

Single space as indentaion after "int".

Other than that, looks fine to me.

Thanks!

Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Peter Korsgaard]

>>>>> "Wolfram" == Wolfram Sang <wsa@the-dreams.de> writes:

Hi,

 >> +- their-claim-gpios: The GPIOs that the other sides use the claim the bus.
 >> +  Note that some implementations may only support a single other master.

 Wolfram> Stronger? "Currently, only one other master is supported"?

Also there's a typo: s/use the claim/use to claim/

-- 
Bye, Peter Korsgaard

Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Peter Korsgaard]

>>>>> "Wolfram" == Wolfram Sang <wsa@the-dreams.de> writes:

Hi,

 >> +- their-claim-gpios: The GPIOs that the other sides use the claim the bus.
 >> +  Note that some implementations may only support a single other master.

 Wolfram> Stronger? "Currently, only one other master is supported"?

Also there's a typo: s/use the claim/use to claim/

-- 
Bye, Peter Korsgaard

Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Guenter Roeck]

On Tue, Apr 16, 2013 at 11:36:33AM +0200, Wolfram Sang wrote:
> Doug,
> 
[ ... ]
> 
> "callenge & response"?
> 
> ...
> 
> > diff --git a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
> > new file mode 100644
> > index 0000000..bda020a
> > --- /dev/null
> > +++ b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
> > @@ -0,0 +1,252 @@
> > +/*
> > + * GPIO-based I2C Arbitration
> 
> "callenge & response"?
> 
s/callenge/challenge/g

Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Stephen Warren]

On 04/16/2013 03:36 AM, Wolfram Sang wrote:
> Doug,
> 
> On Tue, Apr 09, 2013 at 02:34:28PM -0700, Doug Anderson wrote:
>> The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
>> where masters need to claim the bus with a GPIO before they can start
>> a transcation.  This should generally only be used when standard I2C
>> multimaster isn't appropriate for some reason (errata/bugs).
>>
>> This driver is based on code that Simon Glass added to the i2c-s3c2410
>> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
>> mux driver is as suggested by Grant Likely.  See
>> <https://patchwork.kernel.org/patch/1877311/> for some history.

>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt

>> +GPIO-based I2C Arbitration
>> +==========================
>> +This uses GPIO lines to arbitrate who is the master of an I2C bus in a
>> +multimaster situation.
> 
> "uses GPIO lines and a challange & response mechanism" or something like
> that. There might be other GPIO based arbitrations in the future (though
> I hope there won't).

The existing text appears clearer to me; this document should spell out
the exact details of the protocol in later paragraphs, so there's no
need to try and spell it out here.

>> +- their-claim-gpios: The GPIOs that the other sides use the claim the bus.
>> +  Note that some implementations may only support a single other master.
> 
> Stronger? "Currently, only one other master is supported"?

The DT binding documentation, which should be OS-/driver-agnostic,
should describe the binding, not the implementation. The limitation that
Linux imposes is OS-specific and hence should not be mentioned here as
an absolute, or perhaps even at all.

Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Stephen Warren]

On 04/16/2013 03:36 AM, Wolfram Sang wrote:
> Doug,
> 
> On Tue, Apr 09, 2013 at 02:34:28PM -0700, Doug Anderson wrote:
>> The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
>> where masters need to claim the bus with a GPIO before they can start
>> a transcation.  This should generally only be used when standard I2C
>> multimaster isn't appropriate for some reason (errata/bugs).
>>
>> This driver is based on code that Simon Glass added to the i2c-s3c2410
>> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
>> mux driver is as suggested by Grant Likely.  See
>> <https://patchwork.kernel.org/patch/1877311/> for some history.

>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt

>> +GPIO-based I2C Arbitration
>> +==========================
>> +This uses GPIO lines to arbitrate who is the master of an I2C bus in a
>> +multimaster situation.
> 
> "uses GPIO lines and a challange & response mechanism" or something like
> that. There might be other GPIO based arbitrations in the future (though
> I hope there won't).

The existing text appears clearer to me; this document should spell out
the exact details of the protocol in later paragraphs, so there's no
need to try and spell it out here.

>> +- their-claim-gpios: The GPIOs that the other sides use the claim the bus.
>> +  Note that some implementations may only support a single other master.
> 
> Stronger? "Currently, only one other master is supported"?

The DT binding documentation, which should be OS-/driver-agnostic,
should describe the binding, not the implementation. The limitation that
Linux imposes is OS-specific and hence should not be mentioned here as
an absolute, or perhaps even at all.

Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Doug Anderson]

Wolfram / Guenter / Stephen,

Thanks for your reviews.  New version on its way...

On Tue, Apr 16, 2013 at 2:36 AM, Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> wrote:
> "uses GPIO lines and a challange & response mechanism" or something like
> that. There might be other GPIO based arbitrations in the future (though
> I hope there won't).

Done (including fixing spelling of challenge).  Stephen: I think the
new paragraph is still high-level enough even with Wolfram's requested
addition.


>> +- their-claim-gpios: The GPIOs that the other sides use the claim the bus.
>> +  Note that some implementations may only support a single other master.
>
> Stronger? "Currently, only one other master is supported"?

As per Stephen Warren, I didn't touch this.  He says:

The DT binding documentation, which should be OS-/driver-agnostic,
should describe the binding, not the implementation. The limitation that
Linux imposes is OS-specific and hence should not be mentioned here as
an absolute, or perhaps even at all.

I think the current wording about "may only support a single other
master" is a compromise and would at least give some a clue that they
should check the Linux driver for details.


>> +       If you say yes to this option, support will be included for an
>> +       I2C multimaster arbitration scheme using GPIOs where masters have
>> +       to claim the bus by asserting a GPIO.
>
> "callenge & response"?

Done (including fixing spelling of challenge).


>> + * GPIO-based I2C Arbitration
>
> "callenge & response"?

Done (including fixing spelling of challenge).


>> +struct i2c_arbitrator_data {
>> +     struct i2c_adapter *parent;
>> +     struct i2c_adapter *child;
>> +
>
> No empty line.

Done.


>> +     int             our_gpio;
>> +     int             our_gpio_release;
>> +     int             their_gpio;
>> +     int             their_gpio_release;
>> +     unsigned int    slew_delay_us;
>> +     unsigned int    wait_retry_us;
>> +     unsigned int    wait_free_us;
>> +};
>
> Single space as indentaion after "int".

Done.

[PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Doug Anderson]

The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
where masters need to claim the bus with a GPIO before they can start
a transcation.  This should generally only be used when standard I2C
multimaster isn't appropriate for some reason (errata/bugs).

This driver is based on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
mux driver is as suggested by Grant Likely.  See
<https://patchwork.kernel.org/patch/1877311/> for some history.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
---
Changes in v6:
- Cleaned up documentation, spacing, and typos as per review.

Changes in v5:
- Renamed as per Wolfram Sang.
- Avoid references to AP and EC.
- Bindings are now generic and could support N other masters; code
  still only supports one other master.
- Replaced all instances of WARN_ON with error messages.
- Left Stephen's Reviewed-by from v4 since changes aren't huge, but
  please yell if you want it removed or don't like something about the
  new code; removed Naveen's Tested-by for now.

Changes in v4: None
Changes in v3:
- Handle of_find_i2c_adapter_by_node() failure more properly by
  changing init order.
- Don't warn on -EPROBE_DEFER from calls that could return it.
- Move to module_platform_driver().  As we pull in parts of the system
  that rely on devices under this i2c bus we'll need to make sure they
  can handle the fact that they'll be initted later now.

Changes in v2:
- Renamed to i2c-arb-gpio-challenge.
- Documented "microsecond" properties as optional; removed
  "bus-arbitration" prefix since it was just extra wordy.
- Split GPIOs into two properties to make it cleaner.
- Capitalized I2C in freeform text.
- Get 'active low' from device tree.

 .../bindings/i2c/i2c-arb-gpio-challenge.txt        |  80 +++++++
 drivers/i2c/muxes/Kconfig                          |  12 +
 drivers/i2c/muxes/Makefile                         |   2 +
 drivers/i2c/muxes/i2c-arb-gpio-challenge.c         | 251 +++++++++++++++++++++
 4 files changed, 345 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
 create mode 100644 drivers/i2c/muxes/i2c-arb-gpio-challenge.c

diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
new file mode 100644
index 0000000..1ac8ea8
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
@@ -0,0 +1,80 @@
+GPIO-based I2C Arbitration Using a Challenge & Response Mechanism
+=================================================================
+This uses GPIO lines and a challenge & response mechanism to arbitrate who is
+the master of an I2C bus in a multimaster situation.
+
+In many cases using GPIOs to arbitrate is not needed and a design can use
+the standard I2C multi-master rules.  Using GPIOs is generally useful in
+the case where there is a device on the bus that has errata and/or bugs
+that makes standard multimaster mode not feasible.
+
+
+Algorithm:
+
+All masters on the bus have a 'bus claim' line which is an output that the
+others can see. These are all active low with pull-ups enabled.  We'll
+describe these lines as:
+
+- OUR_CLAIM: output from us signaling to other hosts that we want the bus
+- THEIR_CLAIMS: output from others signaling that they want the bus
+
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also.  A detailed explanation is best
+done with an example.
+
+Let's say we want to claim the bus.  We:
+1. Assert OUR_CLAIM.
+2. Waits a little bit for the other sides to notice (slew time, say 10
+   microseconds).
+3. Check THEIR_CLAIMS.  If none are asserted then the we have the bus and we are
+   done.
+4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
+5. If not, back off, release the claim and wait for a few more milliseconds.
+6. Go back to 1 (until retry time has expired).
+
+
+Required properties:
+- compatible: i2c-arb-gpio-challenge
+- our-claim-gpio: The GPIO that we use to claim the bus.
+- their-claim-gpios: The GPIOs that the other sides use to claim the bus.
+  Note that some implementations may only support a single other master.
+- Standard I2C mux properties. See mux.txt in this directory.
+- Single I2C child bus node at reg 0. See mux.txt in this directory.
+
+Optional properties:
+- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
+- wait-retry-us: we'll attempt another claim after this many microseconds.
+    Default is 3000 us.
+- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
+
+
+Example:
+	i2c@12CA0000 {
+		compatible = "acme,some-i2c-device";
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+	i2c-arbitrator {
+		compatible = "i2c-arb-gpio-challenge";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		our-claim-gpio = <&gpf0 3 1>;
+		their-claim-gpios = <&gpe0 4 1>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			i2c@52 {
+				// Normal I2C device
+			};
+		};
+	};
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 0be5b83..5faf244 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -5,6 +5,18 @@
 menu "Multiplexer I2C Chip support"
 	depends on I2C_MUX
 
+config I2C_ARB_GPIO_CHALLENGE
+	tristate "GPIO-based I2C arbitration"
+	depends on GENERIC_GPIO && OF
+	help
+	  If you say yes to this option, support will be included for an
+	  I2C multimaster arbitration scheme using GPIOs and a challenge &
+	  response mechanism where masters have to claim the bus by asserting
+	  a GPIO.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called i2c-arb-gpio-challenge.
+
 config I2C_MUX_GPIO
 	tristate "GPIO-based I2C multiplexer"
 	depends on GENERIC_GPIO
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 76da869..465778b 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -1,6 +1,8 @@
 #
 # Makefile for multiplexer I2C chip drivers.
 
+obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE)	+= i2c-arb-gpio-challenge.o
+
 obj-$(CONFIG_I2C_MUX_GPIO)	+= i2c-mux-gpio.o
 obj-$(CONFIG_I2C_MUX_PCA9541)	+= i2c-mux-pca9541.o
 obj-$(CONFIG_I2C_MUX_PCA954x)	+= i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
new file mode 100644
index 0000000..210b6f7
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
@@ -0,0 +1,251 @@
+/*
+ * GPIO-based I2C Arbitration Using a Challenge & Response Mechanism
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/kernel.h>
+#include <linux/i2c.h>
+#include <linux/i2c-mux.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_i2c.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+
+/**
+ * struct i2c_arbitrator_data - Driver data for I2C arbitrator
+ *
+ * @parent: Parent adapter
+ * @child: Child bus
+ * @our_gpio: GPIO we'll use to claim.
+ * @our_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO ==
+ *   this then consider it released.
+ * @their_gpio: GPIO that the other side will use to claim.
+ * @their_gpio_release: 0 if active high; 1 if active low; AKA if the GPIO ==
+ *   this then consider it released.
+ * @slew_delay_us: microseconds to wait for a GPIO to go high.
+ * @wait_retry_us: we'll attempt another claim after this many microseconds.
+ * @wait_free_us: we'll give up after this many microseconds.
+ */
+
+struct i2c_arbitrator_data {
+	struct i2c_adapter *parent;
+	struct i2c_adapter *child;
+	int our_gpio;
+	int our_gpio_release;
+	int their_gpio;
+	int their_gpio_release;
+	unsigned int slew_delay_us;
+	unsigned int wait_retry_us;
+	unsigned int wait_free_us;
+};
+
+
+/**
+ * i2c_arbitrator_select - claim the I2C bus
+ *
+ * Use the GPIO-based signalling protocol; return -EBUSY if we fail.
+ */
+static int i2c_arbitrator_select(struct i2c_adapter *adap, void *data, u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+	unsigned long stop_retry, stop_time;
+
+	/* Start a round of trying to claim the bus */
+	stop_time = jiffies + usecs_to_jiffies(arb->wait_free_us) + 1;
+	do {
+		/* Indicate that we want to claim the bus */
+		gpio_set_value(arb->our_gpio, !arb->our_gpio_release);
+		udelay(arb->slew_delay_us);
+
+		/* Wait for the other master to release it */
+		stop_retry = jiffies + usecs_to_jiffies(arb->wait_retry_us) + 1;
+		while (time_before(jiffies, stop_retry)) {
+			int gpio_val = !!gpio_get_value(arb->their_gpio);
+
+			if (gpio_val == arb->their_gpio_release) {
+				/* We got it, so return */
+				return 0;
+			}
+
+			usleep_range(50, 200);
+		}
+
+		/* It didn't release, so give up, wait, and try again */
+		gpio_set_value(arb->our_gpio, arb->our_gpio_release);
+
+		usleep_range(arb->wait_retry_us, arb->wait_retry_us * 2);
+	} while (time_before(jiffies, stop_time));
+
+	/* Give up, release our claim */
+	gpio_set_value(arb->our_gpio, arb->our_gpio_release);
+	udelay(arb->slew_delay_us);
+	dev_err(&adap->dev, "Could not claim bus, timeout\n");
+	return -EBUSY;
+}
+
+/**
+ * i2c_arbitrator_deselect - release the I2C bus
+ *
+ * Release the I2C bus using the GPIO-based signalling protocol.
+ */
+static int i2c_arbitrator_deselect(struct i2c_adapter *adap, void *data,
+				   u32 chan)
+{
+	const struct i2c_arbitrator_data *arb = data;
+
+	/* Release the bus and wait for the other master to notice */
+	gpio_set_value(arb->our_gpio, arb->our_gpio_release);
+	udelay(arb->slew_delay_us);
+
+	return 0;
+}
+
+static int i2c_arbitrator_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct device_node *parent_np;
+	struct i2c_arbitrator_data *arb;
+	enum of_gpio_flags gpio_flags;
+	unsigned long out_init;
+	int ret;
+
+	/* We only support probing from device tree; no platform_data */
+	if (!np) {
+		dev_err(dev, "Cannot find device tree node\n");
+		return -ENODEV;
+	}
+	if (dev->platform_data) {
+		dev_err(dev, "Platform data is not supported\n");
+		return -EINVAL;
+	}
+
+	arb = devm_kzalloc(dev, sizeof(*arb), GFP_KERNEL);
+	if (!arb) {
+		dev_err(dev, "Cannot allocate i2c_arbitrator_data\n");
+		return -ENOMEM;
+	}
+	platform_set_drvdata(pdev, arb);
+
+	/* Request GPIOs */
+	ret = of_get_named_gpio_flags(np, "our-claim-gpio", 0, &gpio_flags);
+	if (!gpio_is_valid(ret)) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error getting our-claim-gpio\n");
+		return ret;
+	}
+	arb->our_gpio = ret;
+	arb->our_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	out_init = (gpio_flags & OF_GPIO_ACTIVE_LOW) ?
+		GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
+	ret = devm_gpio_request_one(dev, arb->our_gpio, out_init,
+				    "our-claim-gpio");
+	if (ret) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error requesting our-claim-gpio\n");
+		return ret;
+	}
+
+	ret = of_get_named_gpio_flags(np, "their-claim-gpios", 0, &gpio_flags);
+	if (!gpio_is_valid(ret)) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error getting their-claim-gpio\n");
+		return ret;
+	}
+	arb->their_gpio = ret;
+	arb->their_gpio_release = !!(gpio_flags & OF_GPIO_ACTIVE_LOW);
+	ret = devm_gpio_request_one(dev, arb->their_gpio, GPIOF_IN,
+				    "their-claim-gpio");
+	if (ret) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "Error requesting their-claim-gpio\n");
+		return ret;
+	}
+
+	/* At the moment we only support a single two master (us + 1 other) */
+	if (gpio_is_valid(of_get_named_gpio(np, "their-claim-gpios", 1))) {
+		dev_err(dev, "Only one other master is supported\n");
+		return -EINVAL;
+	}
+
+	/* Arbitration parameters */
+	if (of_property_read_u32(np, "slew-delay-us", &arb->slew_delay_us))
+		arb->slew_delay_us = 10;
+	if (of_property_read_u32(np, "wait-retry-us", &arb->wait_retry_us))
+		arb->wait_retry_us = 3000;
+	if (of_property_read_u32(np, "wait-free-us", &arb->wait_free_us))
+		arb->wait_free_us = 50000;
+
+	/* Find our parent */
+	parent_np = of_parse_phandle(np, "i2c-parent", 0);
+	if (!parent_np) {
+		dev_err(dev, "Cannot parse i2c-parent\n");
+		return -EINVAL;
+	}
+	arb->parent = of_find_i2c_adapter_by_node(parent_np);
+	if (!arb->parent) {
+		dev_err(dev, "Cannot find parent bus\n");
+		return -EINVAL;
+	}
+
+	/* Actually add the mux adapter */
+	arb->child = i2c_add_mux_adapter(arb->parent, dev, arb, 0, 0, 0,
+					 i2c_arbitrator_select,
+					 i2c_arbitrator_deselect);
+	if (!arb->child) {
+		dev_err(dev, "Failed to add adapter\n");
+		ret = -ENODEV;
+		i2c_put_adapter(arb->parent);
+	}
+
+	return ret;
+}
+
+static int i2c_arbitrator_remove(struct platform_device *pdev)
+{
+	struct i2c_arbitrator_data *arb = platform_get_drvdata(pdev);
+
+	i2c_del_mux_adapter(arb->child);
+	i2c_put_adapter(arb->parent);
+
+	return 0;
+}
+
+static const struct of_device_id i2c_arbitrator_of_match[] = {
+	{ .compatible = "i2c-arb-gpio-challenge", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, i2c_arbitrator_of_match);
+
+static struct platform_driver i2c_arbitrator_driver = {
+	.probe	= i2c_arbitrator_probe,
+	.remove	= i2c_arbitrator_remove,
+	.driver	= {
+		.owner	= THIS_MODULE,
+		.name	= "i2c-arb-gpio-challenge",
+		.of_match_table = of_match_ptr(i2c_arbitrator_of_match),
+	},
+};
+
+module_platform_driver(i2c_arbitrator_driver);
+
+MODULE_DESCRIPTION("GPIO-based I2C Arbitration");
+MODULE_AUTHOR("Doug Anderson <dianders@chromium.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:i2c-arb-gpio-challenge");
-- 
1.8.1.3

[PATCH v6 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Doug Anderson]

We need to use the i2c-arbitrator to talk to any of the devices on i2c
bus 4 on exynos5250-snow so that we don't confuse the embedded
controller (EC).  Add the i2c-arbitrator to the device tree.  As we
add future devices (keyboard, sbs, tps65090) we'll add them on top of
this.

The arbitrated bus is numbered 104 simply as a convenience to make it
easier for people poking around to guess that it might have something
to do with the physical bus 4.

The addition is split between the cros5250-common and the snow device
tree file since not all cros5250-class devices use arbitration.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v6: None
Changes in v5:
- Adjust bindings as per Wolfram Sang.

Changes in v4:
- Changed mux gpio syntax to work atop Thomas's "ARM: dts: add pin
  state information in client nodes for Exynos5 platforms"; avoid
  adding gpios property to i2c@12CA0000 for the same reason.

Changes in v3: None
Changes in v2:
- Use new device tree property names / compatible string.
- Include that the GPIOs for arbitration are active low.

 arch/arm/boot/dts/cros5250-common.dtsi |  3 ++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 8a5b3a6..0a61bbb 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -193,7 +193,8 @@
 	};
 
 	i2c@12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
 	};
 
 	i2c@12CB0000 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 581ffae..fa85f58 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -16,6 +16,10 @@
 	model = "Google Snow";
 	compatible = "google,snow", "samsung,exynos5250";
 
+	aliases {
+		i2c104 = &i2c_104;
+	};
+
 	pinctrl@11400000 {
 		sd3_clk: sd3-clk {
 			samsung,pin-drv = <0>;
@@ -44,6 +48,27 @@
 		};
 	};
 
+	i2c-arbitrator {
+		compatible = "i2c-arb-gpio-challenge";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		our-claim-gpio = <&gpf0 3 1>;
+		their-claim-gpios = <&gpe0 4 1>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		/* Use ID 104 as a hint that we're on physical bus 4 */
+		i2c_104: i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	/*
 	 * On Snow we've got SIP WiFi and so can keep drive strengths low to
 	 * reduce EMI.
-- 
1.8.1.3

[PATCH v6 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Doug Anderson]

We need to use the i2c-arbitrator to talk to any of the devices on i2c
bus 4 on exynos5250-snow so that we don't confuse the embedded
controller (EC).  Add the i2c-arbitrator to the device tree.  As we
add future devices (keyboard, sbs, tps65090) we'll add them on top of
this.

The arbitrated bus is numbered 104 simply as a convenience to make it
easier for people poking around to guess that it might have something
to do with the physical bus 4.

The addition is split between the cros5250-common and the snow device
tree file since not all cros5250-class devices use arbitration.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v6: None
Changes in v5:
- Adjust bindings as per Wolfram Sang.

Changes in v4:
- Changed mux gpio syntax to work atop Thomas's "ARM: dts: add pin
  state information in client nodes for Exynos5 platforms"; avoid
  adding gpios property to i2c at 12CA0000 for the same reason.

Changes in v3: None
Changes in v2:
- Use new device tree property names / compatible string.
- Include that the GPIOs for arbitration are active low.

 arch/arm/boot/dts/cros5250-common.dtsi |  3 ++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 8a5b3a6..0a61bbb 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -193,7 +193,8 @@
 	};
 
 	i2c at 12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
 	};
 
 	i2c at 12CB0000 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 581ffae..fa85f58 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -16,6 +16,10 @@
 	model = "Google Snow";
 	compatible = "google,snow", "samsung,exynos5250";
 
+	aliases {
+		i2c104 = &i2c_104;
+	};
+
 	pinctrl at 11400000 {
 		sd3_clk: sd3-clk {
 			samsung,pin-drv = <0>;
@@ -44,6 +48,27 @@
 		};
 	};
 
+	i2c-arbitrator {
+		compatible = "i2c-arb-gpio-challenge";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c@12CA0000}>;
+
+		our-claim-gpio = <&gpf0 3 1>;
+		their-claim-gpios = <&gpe0 4 1>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		/* Use ID 104 as a hint that we're on physical bus 4 */
+		i2c_104: i2c at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	/*
 	 * On Snow we've got SIP WiFi and so can keep drive strengths low to
 	 * reduce EMI.
-- 
1.8.1.3

[PATCH v6 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

Now that we have i2c-arbitrator in place on bus 4 we can add the
sbs-battery driver.  Future devices will be added onto bus 4 once
drivers are in good shape.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index fa85f58..c115143 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -66,6 +66,12 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			battery: sbs-battery@b {
+				compatible = "sbs,sbs-battery";
+				reg = <0xb>;
+				sbs,poll-retry-count = <1>;
+			};
 		};
 	};
 
-- 
1.8.1.3

[PATCH v6 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

[Doug Anderson]

Now that we have i2c-arbitrator in place on bus 4 we can add the
sbs-battery driver.  Future devices will be added onto bus 4 once
drivers are in good shape.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index fa85f58..c115143 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -66,6 +66,12 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			battery: sbs-battery at b {
+				compatible = "sbs,sbs-battery";
+				reg = <0xb>;
+				sbs,poll-retry-count = <1>;
+			};
 		};
 	};
 
-- 
1.8.1.3

Re: [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Olof Johansson]

Overdue, should have added a few iterations ago: :)

On Tue, Apr 16, 2013 at 09:29:00AM -0700, Doug Anderson wrote:
> The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
> where masters need to claim the bus with a GPIO before they can start
> a transcation.  This should generally only be used when standard I2C
> multimaster isn't appropriate for some reason (errata/bugs).
> 
> This driver is based on code that Simon Glass added to the i2c-s3c2410
> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
> mux driver is as suggested by Grant Likely.  See
> <https://patchwork.kernel.org/patch/1877311/> for some history.
> 
> Signed-off-by: Doug Anderson <dianders@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
> Reviewed-by: Stephen Warren <swarren@nvidia.com>

Acked-by: Olof Johansson <olof@lixom.net>

Re: [PATCH v6 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Olof Johansson]

On Tue, Apr 16, 2013 at 09:29:01AM -0700, Doug Anderson wrote:
> We need to use the i2c-arbitrator to talk to any of the devices on i2c
> bus 4 on exynos5250-snow so that we don't confuse the embedded
> controller (EC).  Add the i2c-arbitrator to the device tree.  As we
> add future devices (keyboard, sbs, tps65090) we'll add them on top of
> this.
> 
> The arbitrated bus is numbered 104 simply as a convenience to make it
> easier for people poking around to guess that it might have something
> to do with the physical bus 4.
> 
> The addition is split between the cros5250-common and the snow device
> tree file since not all cros5250-class devices use arbitration.
> 
> Signed-off-by: Doug Anderson <dianders@chromium.org>

Acked-by: Olof Johansson <olof@lixom.net>


-Olof

[PATCH v6 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow

[Olof Johansson]

On Tue, Apr 16, 2013 at 09:29:01AM -0700, Doug Anderson wrote:
> We need to use the i2c-arbitrator to talk to any of the devices on i2c
> bus 4 on exynos5250-snow so that we don't confuse the embedded
> controller (EC).  Add the i2c-arbitrator to the device tree.  As we
> add future devices (keyboard, sbs, tps65090) we'll add them on top of
> this.
> 
> The arbitrated bus is numbered 104 simply as a convenience to make it
> easier for people poking around to guess that it might have something
> to do with the physical bus 4.
> 
> The addition is split between the cros5250-common and the snow device
> tree file since not all cros5250-class devices use arbitration.
> 
> Signed-off-by: Doug Anderson <dianders@chromium.org>

Acked-by: Olof Johansson <olof@lixom.net>


-Olof

Re: [PATCH v6 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

[Olof Johansson]

On Tue, Apr 16, 2013 at 09:29:02AM -0700, Doug Anderson wrote:
> Now that we have i2c-arbitrator in place on bus 4 we can add the
> sbs-battery driver.  Future devices will be added onto bus 4 once
> drivers are in good shape.
> 
> Signed-off-by: Doug Anderson <dianders@chromium.org>

Acked-by: Olof Johansson <olof@lixom.net>


-Olof

[PATCH v6 3/3] ARM: dts: Add sbs-battery for exynos5250-snow

[Olof Johansson]

On Tue, Apr 16, 2013 at 09:29:02AM -0700, Doug Anderson wrote:
> Now that we have i2c-arbitrator in place on bus 4 we can add the
> sbs-battery driver.  Future devices will be added onto bus 4 once
> drivers are in good shape.
> 
> Signed-off-by: Doug Anderson <dianders@chromium.org>

Acked-by: Olof Johansson <olof@lixom.net>


-Olof

Re: [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Guenter Roeck]

On Tue, Apr 16, 2013 at 09:29:00AM -0700, Doug Anderson wrote:
> The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
> where masters need to claim the bus with a GPIO before they can start
> a transcation.  This should generally only be used when standard I2C

I am having fun with spelling today :)

s/transcation/transaction/

Re: [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Guenter Roeck]

On Tue, Apr 16, 2013 at 09:29:00AM -0700, Doug Anderson wrote:
> The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
> where masters need to claim the bus with a GPIO before they can start
> a transcation.  This should generally only be used when standard I2C

I am having fun with spelling today :)

s/transcation/transaction/

Re: [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Doug Anderson]

Guenter,

On Tue, Apr 16, 2013 at 9:45 AM, Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> wrote:
> On Tue, Apr 16, 2013 at 09:29:00AM -0700, Doug Anderson wrote:
>> The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
>> where masters need to claim the bus with a GPIO before they can start
>> a transcation.  This should generally only be used when standard I2C
>
> I am having fun with spelling today :)
>
> s/transcation/transaction/

Doh.  I'm a terrable spellar.  Thenks fur cetching.

Wolfram: I'm happy to send up a v7 to fix this if you'd like or you
can fix it on your end when applying.  Please let me know.  It's
trivial for me to send up a v7 but I'd hate to add yet more noise.

-Doug

Re: [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Wolfram Sang]

On Tue, Apr 16, 2013 at 09:29:00AM -0700, Doug Anderson wrote:
> The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
> where masters need to claim the bus with a GPIO before they can start
> a transcation.  This should generally only be used when standard I2C
> multimaster isn't appropriate for some reason (errata/bugs).
> 
> This driver is based on code that Simon Glass added to the i2c-s3c2410
> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
> mux driver is as suggested by Grant Likely.  See
> <https://patchwork.kernel.org/patch/1877311/> for some history.
> 
> Signed-off-by: Doug Anderson <dianders@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
> Reviewed-by: Stephen Warren <swarren@nvidia.com>

I fixed the typo myself. Applied to for-next, thanks everyone!

Re: [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Wolfram Sang]

On Tue, Apr 16, 2013 at 09:34:58AM -0700, Olof Johansson wrote:

> Overdue, should have added a few iterations ago: :)

Why is that? Is the current iteration too generic for your taste?

Re: [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Olof Johansson]

[-- Attachment #1.1: Type: text/plain, Size: 512 bytes --]

On Apr 17, 2013 2:35 AM, "Wolfram Sang" <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> wrote:
>
> On Tue, Apr 16, 2013 at 09:34:58AM -0700, Olof Johansson wrote:
>
> > Overdue, should have added a few iterations ago: :)
>
> Why is that? Is the current iteration too generic for your taste?

No, nothing like that.

I've been talking to Doug and others offlist (at work) about this but never
acked the patches on the list. I've been happy with them for a while and
I'm glad you've reached that point too :)

-Olof

[-- Attachment #1.2: Type: text/html, Size: 729 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Olof Johansson]

(Resend since I replied from my phone earlier and got list rejects due
to HTML email)


On Wed, Apr 17, 2013 at 2:34 AM, Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> wrote:
>
> On Tue, Apr 16, 2013 at 09:34:58AM -0700, Olof Johansson wrote:
>
> > Overdue, should have added a few iterations ago: :)
>
> Why is that? Is the current iteration too generic for your taste?


No, nothing like that.

I've been talking to Doug and others offlist (at work) about this but
never acked the patches on the list. I've been happy with them for a
while and I'm glad you've reached that point too :)


-Olof