* [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
@ 2013-03-13 16:36 ` Doug Anderson
0 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-03-13 16:36 UTC (permalink / raw)
To: Wolfram Sang, Kukjin Kim
Cc: Simon Glass, Naveen Krishna Chatradhi, Grant Likely,
Yuvaraj Kumar, Ben Dooks, u.kleine-koenig, Mark Brown,
Girish Shivananjappa, bhushan.r, sreekumar.c, Prashanth G,
Olof Johansson, Daniel Kurtz, Grant Grundler, Doug Anderson,
Rob Herring, Rob Landley, Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard,
devicetree-discuss, linux-doc
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v4 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
2013-03-13 16:36 ` Doug Anderson
@ 2013-03-13 16:36 ` Doug Anderson
-1 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-03-13 16:36 UTC (permalink / raw)
To: Wolfram Sang, Kukjin Kim
Cc: Simon Glass, Naveen Krishna Chatradhi, Grant Likely,
Yuvaraj Kumar, Ben Dooks, u.kleine-koenig, Mark Brown,
Girish Shivananjappa, bhushan.r, sreekumar.c, Prashanth G,
Olof Johansson, Daniel Kurtz, Grant Grundler, Doug Anderson,
Russell King, Thomas Abraham, Rahul Sharma, Jingoo Han,
linux-arm-kernel, linux-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v4 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
@ 2013-03-13 16:36 ` Doug Anderson
0 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-03-13 16:36 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v4 3/3] ARM: dts: Add sbs-battery for exynos5250-snow
2013-03-13 16:36 ` Doug Anderson
@ 2013-03-13 16:36 ` Doug Anderson
-1 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-03-13 16:36 UTC (permalink / raw)
To: Wolfram Sang, Kukjin Kim
Cc: Simon Glass, Naveen Krishna Chatradhi, Grant Likely,
Yuvaraj Kumar, Ben Dooks, u.kleine-koenig, Mark Brown,
Girish Shivananjappa, bhushan.r, sreekumar.c, Prashanth G,
Olof Johansson, Daniel Kurtz, Grant Grundler, Doug Anderson,
Russell King, Thomas Abraham, Jingoo Han, linux-arm-kernel,
linux-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v4 3/3] ARM: dts: Add sbs-battery for exynos5250-snow
@ 2013-03-13 16:36 ` Doug Anderson
0 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-03-13 16:36 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
[not found] ` <1363192583-26363-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
@ 2013-03-13 16:53 ` Stephen Warren
2013-04-09 20:12 ` [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge " Doug Anderson
1 sibling, 0 replies; 96+ messages in thread
From: Stephen Warren @ 2013-03-13 16:53 UTC (permalink / raw)
To: Doug Anderson
Cc: Wolfram Sang, Kukjin Kim, linux-doc, Daniel Kurtz, linux-kernel,
linux-i2c, Stephen Warren, Ben Dooks, u.kleine-koenig,
Grant Grundler, devicetree-discuss, Rob Herring, Jean Delvare,
Ben Dooks (embedded platforms),
Girish Shivananjappa, bhushan.r, Naveen Krishna Chatradhi,
sreekumar.c, Mark Brown, Peter Korsgaard, Yuvaraj Kumar,
Prashanth G
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?
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
@ 2013-03-13 16:53 ` Stephen Warren
0 siblings, 0 replies; 96+ messages in thread
From: Stephen Warren @ 2013-03-13 16:53 UTC (permalink / raw)
To: Doug Anderson
Cc: Wolfram Sang, Kukjin Kim, linux-doc-u79uwXL29TY76Z2rM5mHXA,
Daniel Kurtz, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Stephen Warren, Ben Dooks,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ, Grant Grundler,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Rob Herring,
Jean Delvare, Ben Dooks (embedded platforms),
Girish Shivananjappa, bhushan.r-Sze3O3UU22JBDgjK7y7TUQ,
Naveen Krishna Chatradhi, sreekumar.c-Sze3O3UU22JBDgjK7y7TUQ,
Mark Brown, Peter Korsgaard, Yuvaraj Kumar, Prashanth G
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?
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
@ 2013-03-13 16:59 ` Doug Anderson
0 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-03-13 16:59 UTC (permalink / raw)
To: Stephen Warren
Cc: Wolfram Sang, Kukjin Kim, linux-doc, Daniel Kurtz, linux-kernel,
linux-i2c, Stephen Warren, Ben Dooks, u.kleine-koenig,
Grant Grundler, devicetree-discuss, Rob Herring, Jean Delvare,
Ben Dooks (embedded platforms),
Girish Shivananjappa, bhushan.r, Naveen Krishna Chatradhi,
sreekumar.c, Mark Brown, Peter Korsgaard, Yuvaraj Kumar,
Prashanth G
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
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
@ 2013-03-13 16:59 ` Doug Anderson
0 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-03-13 16:59 UTC (permalink / raw)
To: Stephen Warren
Cc: Wolfram Sang, Kukjin Kim, linux-doc-u79uwXL29TY76Z2rM5mHXA,
Daniel Kurtz, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Stephen Warren, Ben Dooks,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ, Grant Grundler,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Rob Herring,
Jean Delvare, Ben Dooks (embedded platforms),
Girish Shivananjappa, bhushan.r, Naveen Krishna Chatradhi,
sreekumar.c, Mark Brown, Peter Korsgaard, Yuvaraj Kumar
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
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
2013-03-13 16:59 ` Doug Anderson
@ 2013-03-13 17:29 ` Stephen Warren
-1 siblings, 0 replies; 96+ messages in thread
From: Stephen Warren @ 2013-03-13 17:29 UTC (permalink / raw)
To: Doug Anderson
Cc: Wolfram Sang, Kukjin Kim, linux-doc, Daniel Kurtz, linux-kernel,
linux-i2c, Stephen Warren, Ben Dooks, u.kleine-koenig,
Grant Grundler, devicetree-discuss, Rob Herring, Jean Delvare,
Ben Dooks (embedded platforms),
Girish Shivananjappa, bhushan.r, Naveen Krishna Chatradhi,
sreekumar.c, Mark Brown, Peter Korsgaard, Yuvaraj Kumar,
Prashanth G
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.
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
@ 2013-03-13 17:29 ` Stephen Warren
0 siblings, 0 replies; 96+ messages in thread
From: Stephen Warren @ 2013-03-13 17:29 UTC (permalink / raw)
To: Doug Anderson
Cc: Wolfram Sang, Kukjin Kim, linux-doc, Daniel Kurtz, linux-kernel,
linux-i2c, Stephen Warren, Ben Dooks, u.kleine-koenig,
Grant Grundler, devicetree-discuss, Rob Herring, Jean Delvare,
Ben Dooks (embedded platforms),
Girish Shivananjappa, bhushan.r, Naveen Krishna Chatradhi,
sreekumar.c, Mark Brown, Peter Korsgaard, Yuvaraj Kumar
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.
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
[not found] ` <1363192583-26363-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
@ 2013-04-08 10:26 ` Wolfram Sang
2013-04-09 20:12 ` [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge " Doug Anderson
1 sibling, 0 replies; 96+ messages in thread
From: Wolfram Sang @ 2013-04-08 10:26 UTC (permalink / raw)
To: Doug Anderson
Cc: Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi, Grant Likely,
Yuvaraj Kumar, Ben Dooks, u.kleine-koenig, Mark Brown,
Girish Shivananjappa, bhushan.r, sreekumar.c, Prashanth G,
Olof Johansson, Daniel Kurtz, Grant Grundler, Rob Herring,
Rob Landley, Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard,
devicetree-discuss, linux-doc, linux-kernel, linux-i2c
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
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
@ 2013-04-08 10:26 ` Wolfram Sang
0 siblings, 0 replies; 96+ messages in thread
From: Wolfram Sang @ 2013-04-08 10:26 UTC (permalink / raw)
To: Doug Anderson
Cc: Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi, Grant Likely,
Yuvaraj Kumar, Ben Dooks, u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ,
Mark Brown, Girish Shivananjappa,
bhushan.r-Sze3O3UU22JBDgjK7y7TUQ,
sreekumar.c-Sze3O3UU22JBDgjK7y7TUQ, Prashanth G, Olof Johansson,
Daniel Kurtz, Grant Grundler, Rob Herring, Rob Landley,
Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-doc-u79uwXL29TY76Z2rM5mHXA
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
^ permalink raw reply [flat|nested] 96+ messages in thread
[parent not found: <20130408102617.GC3496-z923LK4zBo2bacvFa/9K2g@public.gmane.org>]
* Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
[not found] ` <20130408102617.GC3496-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
@ 2013-04-09 20:26 ` Doug Anderson
0 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-09 20:26 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-doc-u79uwXL29TY76Z2rM5mHXA, Daniel Kurtz,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Kukjin Kim, Stephen Warren,
Ben Dooks, u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ,
Grant Grundler, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Rob Herring, Jean Delvare, Ben Dooks (embedded platforms),
Girish Shivananjappa, bhushan.r, Naveen Krishna Chatradhi,
sreekumar.c, Mark Brown, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Peter Korsgaard, Yuvaraj Kumar, Prashanth G
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
^ permalink raw reply [flat|nested] 96+ messages in thread
[parent not found: <1363192583-26363-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>]
* Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
[not found] ` <1363192583-26363-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
@ 2013-03-26 20:23 ` Doug Anderson
[not found] ` <20130329115821.GC6359@the-dreams.de>
2013-04-09 20:12 ` [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge " Doug Anderson
1 sibling, 1 reply; 96+ messages in thread
From: Doug Anderson @ 2013-03-26 20:23 UTC (permalink / raw)
To: Wolfram Sang, Kukjin Kim
Cc: linux-doc-u79uwXL29TY76Z2rM5mHXA, Daniel Kurtz,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Stephen Warren, Ben Dooks,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ, Grant Grundler,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Rob Herring,
Jean Delvare, Ben Dooks (embedded platforms),
Girish Shivananjappa, bhushan.r, Naveen Krishna Chatradhi,
sreekumar.c, Mark Brown, Peter Korsgaard, Yuvaraj Kumar,
Prashanth G
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
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
[not found] ` <1363192583-26363-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2013-03-26 20:23 ` Doug Anderson
@ 2013-04-09 20:12 ` Doug Anderson
2013-04-09 20:12 ` Doug Anderson
2013-04-09 20:12 ` Doug Anderson
1 sibling, 2 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-09 20:12 UTC (permalink / raw)
To: Wolfram Sang, Kukjin Kim
Cc: linux-doc-u79uwXL29TY76Z2rM5mHXA, Daniel Kurtz,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Stephen Warren, Ben Dooks,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ, Guenter Roeck,
Grant Grundler, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Rob Herring, Jean Delvare, Ben Dooks (embedded platforms),
Girish Shivananjappa, bhushan.r-Sze3O3UU22JBDgjK7y7TUQ,
Naveen Krishna Chatradhi, sreekumar.c-Sze3O3UU22JBDgjK7y7TUQ,
Mark Brown, Peter Korsgaard, Yuvaraj Kumar, Prashanth G
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
2013-04-09 20:12 ` [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge " Doug Anderson
@ 2013-04-09 20:12 ` Doug Anderson
2013-04-09 20:12 ` Doug Anderson
1 sibling, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-09 20:12 UTC (permalink / raw)
To: Wolfram Sang, Kukjin Kim
Cc: Simon Glass, Naveen Krishna Chatradhi, Grant Likely,
Yuvaraj Kumar, Ben Dooks, u.kleine-koenig, Mark Brown,
Girish Shivananjappa, bhushan.r, sreekumar.c, Prashanth G,
Olof Johansson, Daniel Kurtz, Grant Grundler, Stephen Warren,
Guenter Roeck, Doug Anderson, Russell King, Thomas Abraham,
Rahul Sharma, Jingoo Han, linux-arm-kernel, linux-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
@ 2013-04-09 20:12 ` Doug Anderson
0 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-09 20:12 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v5 3/3] ARM: dts: Add sbs-battery for exynos5250-snow
2013-04-09 20:12 ` [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge " Doug Anderson
@ 2013-04-09 20:12 ` Doug Anderson
2013-04-09 20:12 ` Doug Anderson
1 sibling, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-09 20:12 UTC (permalink / raw)
To: Wolfram Sang, Kukjin Kim
Cc: Simon Glass, Naveen Krishna Chatradhi, Grant Likely,
Yuvaraj Kumar, Ben Dooks, u.kleine-koenig, Mark Brown,
Girish Shivananjappa, bhushan.r, sreekumar.c, Prashanth G,
Olof Johansson, Daniel Kurtz, Grant Grundler, Stephen Warren,
Guenter Roeck, Doug Anderson, Russell King, Thomas Abraham,
Jingoo Han, linux-arm-kernel, linux-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v5 3/3] ARM: dts: Add sbs-battery for exynos5250-snow
@ 2013-04-09 20:12 ` Doug Anderson
0 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-09 20:12 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
[not found] ` <1363192583-26363-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
@ 2013-04-09 21:34 ` Doug Anderson
2013-04-09 20:12 ` [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge " Doug Anderson
1 sibling, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-09 21:34 UTC (permalink / raw)
To: Wolfram Sang, Kukjin Kim
Cc: Simon Glass, Naveen Krishna Chatradhi, grant.likely, yuvaraj.cd,
ben.dooks, u.kleine-koenig, broonie, girish.shivananjappa,
bhushan.r, sreekumar.c, prashanth.g, olof, djkurtz, swarren,
linux, Doug Anderson, Rob Herring, Rob Landley,
Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard, Guenter Roeck,
devicetree-discuss, linux-doc, linux-kernel, linux-i2c
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
@ 2013-04-09 21:34 ` Doug Anderson
0 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-09 21:34 UTC (permalink / raw)
To: Wolfram Sang, Kukjin Kim
Cc: linux-doc-u79uwXL29TY76Z2rM5mHXA, djkurtz-F7+t8E8rja9g9hUCZPvPmw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Guenter Roeck, Stephen Warren,
ben.dooks-4yDnlxn2s6sWdaTGBSpHTA,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-0h96xk9xTtrk1uMJSBkQmQ,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Rob Herring,
Jean Delvare, Ben Dooks (embedded platforms),
girish.shivananjappa-QSEj5FYQhm4dnm+yROfE0A,
bhushan.r-Sze3O3UU22JBDgjK7y7TUQ, Naveen Krishna Chatradhi,
sreekumar.c-Sze3O3UU22JBDgjK7y7TUQ,
broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
Peter Korsgaard, yuvaraj.cd-Re5JQEeQqe8AvxtiuMwx3w,
prashanth.g-Sze3O3UU22JBDgjK7y7TUQ
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
2013-04-09 21:34 ` Doug Anderson
@ 2013-04-09 21:34 ` Doug Anderson
-1 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-09 21:34 UTC (permalink / raw)
To: Wolfram Sang, Kukjin Kim
Cc: Simon Glass, Naveen Krishna Chatradhi, grant.likely, yuvaraj.cd,
ben.dooks, u.kleine-koenig, broonie, girish.shivananjappa,
bhushan.r, sreekumar.c, prashanth.g, olof, djkurtz, swarren,
linux, Doug Anderson, Russell King, Thomas Abraham, Rahul Sharma,
Jingoo Han, linux-arm-kernel, linux-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
@ 2013-04-09 21:34 ` Doug Anderson
0 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-09 21:34 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* RE: [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
2013-04-09 21:34 ` Doug Anderson
@ 2013-04-10 10:59 ` Kukjin Kim
-1 siblings, 0 replies; 96+ messages in thread
From: Kukjin Kim @ 2013-04-10 10:59 UTC (permalink / raw)
To: 'Doug Anderson', 'Wolfram Sang'
Cc: 'Simon Glass', 'Naveen Krishna Chatradhi',
grant.likely, yuvaraj.cd, ben.dooks, u.kleine-koenig, broonie,
girish.shivananjappa, bhushan.r, sreekumar.c, prashanth.g, olof,
djkurtz, swarren, linux, 'Russell King',
'Thomas Abraham', 'Rahul Sharma',
'Jingoo Han',
linux-arm-kernel, linux-kernel
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
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
@ 2013-04-10 10:59 ` Kukjin Kim
0 siblings, 0 replies; 96+ messages in thread
From: Kukjin Kim @ 2013-04-10 10:59 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
2013-04-10 10:59 ` Kukjin Kim
@ 2013-04-10 11:02 ` Wolfram Sang
-1 siblings, 0 replies; 96+ messages in thread
From: Wolfram Sang @ 2013-04-10 11:02 UTC (permalink / raw)
To: Kukjin Kim
Cc: 'Doug Anderson', 'Simon Glass',
'Naveen Krishna Chatradhi',
grant.likely, yuvaraj.cd, ben.dooks, u.kleine-koenig, broonie,
girish.shivananjappa, bhushan.r, sreekumar.c, prashanth.g, olof,
djkurtz, swarren, linux, 'Russell King',
'Thomas Abraham', 'Rahul Sharma',
'Jingoo Han',
linux-arm-kernel, linux-kernel
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.
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
@ 2013-04-10 11:02 ` Wolfram Sang
0 siblings, 0 replies; 96+ messages in thread
From: Wolfram Sang @ 2013-04-10 11:02 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
2013-04-10 11:02 ` Wolfram Sang
@ 2013-04-10 14:12 ` Kukjin Kim
-1 siblings, 0 replies; 96+ messages in thread
From: Kukjin Kim @ 2013-04-10 14:12 UTC (permalink / raw)
To: Wolfram Sang
Cc: Kukjin Kim, djkurtz, linux-kernel, grant.likely,
'Russell King', 'Jingoo Han',
ben.dooks, 'Thomas Abraham',
u.kleine-koenig, linux, swarren, girish.shivananjappa, bhushan.r,
'Naveen Krishna Chatradhi',
linux-arm-kernel, 'Rahul Sharma',
sreekumar.c, 'Simon Glass',
broonie, 'Doug Anderson',
yuvaraj.cd, olof, prashanth.g
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
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
@ 2013-04-10 14:12 ` Kukjin Kim
0 siblings, 0 replies; 96+ messages in thread
From: Kukjin Kim @ 2013-04-10 14:12 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v5 3/3] ARM: dts: Add sbs-battery for exynos5250-snow
2013-04-09 21:34 ` Doug Anderson
@ 2013-04-09 21:34 ` Doug Anderson
-1 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-09 21:34 UTC (permalink / raw)
To: Wolfram Sang, Kukjin Kim
Cc: Simon Glass, Naveen Krishna Chatradhi, grant.likely, yuvaraj.cd,
ben.dooks, u.kleine-koenig, broonie, girish.shivananjappa,
bhushan.r, sreekumar.c, prashanth.g, olof, djkurtz, swarren,
linux, Doug Anderson, Russell King, Thomas Abraham, Jingoo Han,
linux-arm-kernel, linux-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v5 3/3] ARM: dts: Add sbs-battery for exynos5250-snow
@ 2013-04-09 21:34 ` Doug Anderson
0 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-09 21:34 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
@ 2013-04-16 9:36 ` Wolfram Sang
0 siblings, 0 replies; 96+ messages in thread
From: Wolfram Sang @ 2013-04-16 9:36 UTC (permalink / raw)
To: Doug Anderson
Cc: Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi, grant.likely,
yuvaraj.cd, ben.dooks, u.kleine-koenig, broonie,
girish.shivananjappa, bhushan.r, sreekumar.c, prashanth.g, olof,
djkurtz, swarren, linux, Rob Herring, Rob Landley,
Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard, Guenter Roeck,
devicetree-discuss, linux-doc, linux-kernel, linux-i2c
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!
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
@ 2013-04-16 9:36 ` Wolfram Sang
0 siblings, 0 replies; 96+ messages in thread
From: Wolfram Sang @ 2013-04-16 9:36 UTC (permalink / raw)
To: Doug Anderson
Cc: Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ,
yuvaraj.cd-Re5JQEeQqe8AvxtiuMwx3w,
ben.dooks-4yDnlxn2s6sWdaTGBSpHTA,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ,
broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
girish.shivananjappa-QSEj5FYQhm4dnm+yROfE0A,
bhushan.r-Sze3O3UU22JBDgjK7y7TUQ,
sreekumar.c-Sze3O3UU22JBDgjK7y7TUQ,
prashanth.g-Sze3O3UU22JBDgjK7y7TUQ, olof-nZhT3qVonbNeoWH0uzbU5w,
djkurtz-F7+t8E8rja9g9hUCZPvPmw, swarren-3lzwWm7+Weoh9ZMKESR00Q,
linux-0h96xk9xTtrk1uMJSBkQmQ, Rob Herring, Rob Landley,
Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard, Guenter Roeck,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
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!
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
2013-04-16 9:36 ` Wolfram Sang
@ 2013-04-16 9:44 ` Peter Korsgaard
-1 siblings, 0 replies; 96+ messages in thread
From: Peter Korsgaard @ 2013-04-16 9:44 UTC (permalink / raw)
To: Wolfram Sang
Cc: Doug Anderson, Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi,
grant.likely, yuvaraj.cd, ben.dooks, u.kleine-koenig, broonie,
girish.shivananjappa, bhushan.r, sreekumar.c, prashanth.g, olof,
djkurtz, swarren, linux, Rob Herring, Rob Landley,
Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard, Guenter Roeck,
devicetree-discuss, linux-doc, linux-kernel, linux-i2c
>>>>> "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
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
@ 2013-04-16 9:44 ` Peter Korsgaard
0 siblings, 0 replies; 96+ messages in thread
From: Peter Korsgaard @ 2013-04-16 9:44 UTC (permalink / raw)
To: Wolfram Sang
Cc: Doug Anderson, Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi,
grant.likely, yuvaraj.cd, ben.dooks, u.kleine-koenig, broonie,
girish.shivananjappa, bhushan.r, sreekumar.c, prashanth.g, olof,
djkurtz, swarren, linux, Rob Herring, Rob Landley,
Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard, Guenter Roeck,
devicetree-discuss, linux-doc, linux-kernel
>>>>> "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
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
2013-04-16 9:36 ` Wolfram Sang
(?)
(?)
@ 2013-04-16 13:38 ` Guenter Roeck
-1 siblings, 0 replies; 96+ messages in thread
From: Guenter Roeck @ 2013-04-16 13:38 UTC (permalink / raw)
To: Wolfram Sang
Cc: Doug Anderson, Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi,
grant.likely, yuvaraj.cd, ben.dooks, u.kleine-koenig, broonie,
girish.shivananjappa, bhushan.r, sreekumar.c, prashanth.g, olof,
djkurtz, swarren, Rob Herring, Rob Landley,
Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard, Guenter Roeck,
devicetree-discuss, linux-doc, linux-kernel, linux-i2c
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
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
[not found] ` <20130416093633.GC16978-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
@ 2013-04-16 15:42 ` Stephen Warren
0 siblings, 0 replies; 96+ messages in thread
From: Stephen Warren @ 2013-04-16 15:42 UTC (permalink / raw)
To: Wolfram Sang
Cc: Doug Anderson, Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi,
grant.likely, yuvaraj.cd, ben.dooks, u.kleine-koenig, broonie,
girish.shivananjappa, bhushan.r, sreekumar.c, prashanth.g, olof,
djkurtz, linux, Rob Herring, Rob Landley,
Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard, Guenter Roeck,
devicetree-discuss, linux-doc, linux-kernel, linux-i2c
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.
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
@ 2013-04-16 15:42 ` Stephen Warren
0 siblings, 0 replies; 96+ messages in thread
From: Stephen Warren @ 2013-04-16 15:42 UTC (permalink / raw)
To: Wolfram Sang
Cc: Doug Anderson, Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ,
yuvaraj.cd-Re5JQEeQqe8AvxtiuMwx3w,
ben.dooks-4yDnlxn2s6sWdaTGBSpHTA,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ,
broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
girish.shivananjappa-QSEj5FYQhm4dnm+yROfE0A,
bhushan.r-Sze3O3UU22JBDgjK7y7TUQ,
sreekumar.c-Sze3O3UU22JBDgjK7y7TUQ,
prashanth.g-Sze3O3UU22JBDgjK7y7TUQ, olof-nZhT3qVonbNeoWH0uzbU5w,
djkurtz-F7+t8E8rja9g9hUCZPvPmw, linux-0h96xk9xTtrk1uMJSBkQmQ,
Rob Herring, Rob Landley, Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard, Guenter Roeck,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
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.
^ permalink raw reply [flat|nested] 96+ messages in thread
[parent not found: <20130416093633.GC16978-z923LK4zBo2bacvFa/9K2g@public.gmane.org>]
* Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
[not found] ` <20130416093633.GC16978-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
@ 2013-04-16 16:25 ` Doug Anderson
0 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-16 16:25 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-doc-u79uwXL29TY76Z2rM5mHXA, Daniel Kurtz,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Guenter Roeck, Kukjin Kim,
Stephen Warren, Ben Dooks,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ, Guenter Roeck,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Rob Herring,
Jean Delvare, Ben Dooks (embedded platforms),
Girish Shivananjappa, bhushan.r, Naveen Krishna Chatradhi,
sreekumar.c, Mark Brown, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Peter Korsgaard, Yuvaraj Kumar
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.
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
2013-04-09 21:34 ` Doug Anderson
` (3 preceding siblings ...)
(?)
@ 2013-04-16 16:29 ` Doug Anderson
2013-04-16 16:29 ` Doug Anderson
` (4 more replies)
-1 siblings, 5 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-16 16:29 UTC (permalink / raw)
To: Wolfram Sang, Kukjin Kim
Cc: Simon Glass, Naveen Krishna Chatradhi, grant.likely, yuvaraj.cd,
ben.dooks, u.kleine-koenig, broonie, girish.shivananjappa,
bhushan.r, sreekumar.c, prashanth.g, olof, djkurtz, swarren,
linux, Doug Anderson, Rob Herring, Rob Landley,
Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard,
devicetree-discuss, linux-doc, linux-kernel, linux-i2c
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v6 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
2013-04-16 16:29 ` [PATCH v6 " Doug Anderson
@ 2013-04-16 16:29 ` Doug Anderson
2013-04-16 16:29 ` Doug Anderson
` (3 subsequent siblings)
4 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-16 16:29 UTC (permalink / raw)
To: Wolfram Sang, Kukjin Kim
Cc: Simon Glass, Naveen Krishna Chatradhi, grant.likely, yuvaraj.cd,
ben.dooks, u.kleine-koenig, broonie, girish.shivananjappa,
bhushan.r, sreekumar.c, prashanth.g, olof, djkurtz, swarren,
linux, Doug Anderson, Russell King, Thomas Abraham, Rahul Sharma,
Linus Walleij, Jingoo Han, linux-arm-kernel, linux-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v6 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
@ 2013-04-16 16:29 ` Doug Anderson
0 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-16 16:29 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* Re: [PATCH v6 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
2013-04-16 16:29 ` Doug Anderson
@ 2013-04-16 16:35 ` Olof Johansson
-1 siblings, 0 replies; 96+ messages in thread
From: Olof Johansson @ 2013-04-16 16:35 UTC (permalink / raw)
To: Doug Anderson
Cc: Wolfram Sang, Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi,
grant.likely, yuvaraj.cd, ben.dooks, u.kleine-koenig, broonie,
girish.shivananjappa, bhushan.r, sreekumar.c, prashanth.g,
djkurtz, swarren, linux, Russell King, Thomas Abraham,
Rahul Sharma, Linus Walleij, Jingoo Han, linux-arm-kernel,
linux-kernel
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
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v6 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
@ 2013-04-16 16:35 ` Olof Johansson
0 siblings, 0 replies; 96+ messages in thread
From: Olof Johansson @ 2013-04-16 16:35 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v6 3/3] ARM: dts: Add sbs-battery for exynos5250-snow
2013-04-16 16:29 ` [PATCH v6 " Doug Anderson
@ 2013-04-16 16:29 ` Doug Anderson
2013-04-16 16:29 ` Doug Anderson
` (3 subsequent siblings)
4 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-16 16:29 UTC (permalink / raw)
To: Wolfram Sang, Kukjin Kim
Cc: Simon Glass, Naveen Krishna Chatradhi, grant.likely, yuvaraj.cd,
ben.dooks, u.kleine-koenig, broonie, girish.shivananjappa,
bhushan.r, sreekumar.c, prashanth.g, olof, djkurtz, swarren,
linux, Doug Anderson, Russell King, Thomas Abraham,
Linus Walleij, Jingoo Han, linux-arm-kernel, linux-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v6 3/3] ARM: dts: Add sbs-battery for exynos5250-snow
@ 2013-04-16 16:29 ` Doug Anderson
0 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-16 16:29 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 96+ messages in thread
* Re: [PATCH v6 3/3] ARM: dts: Add sbs-battery for exynos5250-snow
2013-04-16 16:29 ` Doug Anderson
@ 2013-04-16 16:36 ` Olof Johansson
-1 siblings, 0 replies; 96+ messages in thread
From: Olof Johansson @ 2013-04-16 16:36 UTC (permalink / raw)
To: Doug Anderson
Cc: Wolfram Sang, Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi,
grant.likely, yuvaraj.cd, ben.dooks, u.kleine-koenig, broonie,
girish.shivananjappa, bhushan.r, sreekumar.c, prashanth.g,
djkurtz, swarren, linux, Russell King, Thomas Abraham,
Linus Walleij, Jingoo Han, linux-arm-kernel, linux-kernel
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
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v6 3/3] ARM: dts: Add sbs-battery for exynos5250-snow
@ 2013-04-16 16:36 ` Olof Johansson
0 siblings, 0 replies; 96+ messages in thread
From: Olof Johansson @ 2013-04-16 16:36 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
2013-04-16 16:29 ` [PATCH v6 " Doug Anderson
2013-04-16 16:29 ` Doug Anderson
2013-04-16 16:29 ` Doug Anderson
@ 2013-04-16 16:34 ` Olof Johansson
2013-04-17 9:34 ` Wolfram Sang
2013-04-16 16:45 ` Guenter Roeck
2013-04-17 9:32 ` Wolfram Sang
4 siblings, 1 reply; 96+ messages in thread
From: Olof Johansson @ 2013-04-16 16:34 UTC (permalink / raw)
To: Doug Anderson
Cc: Wolfram Sang, Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi,
grant.likely, yuvaraj.cd, ben.dooks, u.kleine-koenig, broonie,
girish.shivananjappa, bhushan.r, sreekumar.c, prashanth.g,
djkurtz, swarren, linux, Rob Herring, Rob Landley,
Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard,
devicetree-discuss, linux-doc, linux-kernel, linux-i2c
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>
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
2013-04-16 16:34 ` [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver Olof Johansson
@ 2013-04-17 9:34 ` Wolfram Sang
[not found] ` <20130417093424.GC4508-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
0 siblings, 1 reply; 96+ messages in thread
From: Wolfram Sang @ 2013-04-17 9:34 UTC (permalink / raw)
To: Olof Johansson
Cc: Doug Anderson, Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi,
grant.likely, yuvaraj.cd, ben.dooks, u.kleine-koenig, broonie,
girish.shivananjappa, bhushan.r, sreekumar.c, prashanth.g,
djkurtz, swarren, linux, Rob Herring, Rob Landley,
Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard,
devicetree-discuss, linux-doc, linux-kernel, linux-i2c
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?
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
@ 2013-04-16 16:45 ` Guenter Roeck
0 siblings, 0 replies; 96+ messages in thread
From: Guenter Roeck @ 2013-04-16 16:45 UTC (permalink / raw)
To: Doug Anderson
Cc: Wolfram Sang, Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi,
grant.likely, yuvaraj.cd, ben.dooks, u.kleine-koenig, broonie,
girish.shivananjappa, bhushan.r, sreekumar.c, prashanth.g, olof,
djkurtz, swarren, Rob Herring, Rob Landley,
Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard,
devicetree-discuss, linux-doc, linux-kernel, linux-i2c
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/
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
@ 2013-04-16 16:45 ` Guenter Roeck
0 siblings, 0 replies; 96+ messages in thread
From: Guenter Roeck @ 2013-04-16 16:45 UTC (permalink / raw)
To: Doug Anderson
Cc: Wolfram Sang, Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ,
yuvaraj.cd-Re5JQEeQqe8AvxtiuMwx3w,
ben.dooks-4yDnlxn2s6sWdaTGBSpHTA,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ,
broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
girish.shivananjappa-QSEj5FYQhm4dnm+yROfE0A,
bhushan.r-Sze3O3UU22JBDgjK7y7TUQ,
sreekumar.c-Sze3O3UU22JBDgjK7y7TUQ,
prashanth.g-Sze3O3UU22JBDgjK7y7TUQ, olof-nZhT3qVonbNeoWH0uzbU5w,
djkurtz-F7+t8E8rja9g9hUCZPvPmw, swarren-3lzwWm7+Weoh9ZMKESR00Q,
Rob Herring, Rob Landley, Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
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/
^ permalink raw reply [flat|nested] 96+ messages in thread
[parent not found: <20130416164512.GB27488-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>]
* Re: [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
[not found] ` <20130416164512.GB27488-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
@ 2013-04-16 16:51 ` Doug Anderson
0 siblings, 0 replies; 96+ messages in thread
From: Doug Anderson @ 2013-04-16 16:51 UTC (permalink / raw)
To: Guenter Roeck, Wolfram Sang
Cc: linux-doc-u79uwXL29TY76Z2rM5mHXA, Daniel Kurtz,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Kukjin Kim, Stephen Warren,
Ben Dooks, u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Rob Herring,
Jean Delvare, Ben Dooks (embedded platforms),
Girish Shivananjappa, bhushan.r, Naveen Krishna Chatradhi,
sreekumar.c, Mark Brown, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Peter Korsgaard, Yuvaraj Kumar, Prashanth G
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
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v6 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
2013-04-16 16:29 ` [PATCH v6 " Doug Anderson
` (3 preceding siblings ...)
2013-04-16 16:45 ` Guenter Roeck
@ 2013-04-17 9:32 ` Wolfram Sang
4 siblings, 0 replies; 96+ messages in thread
From: Wolfram Sang @ 2013-04-17 9:32 UTC (permalink / raw)
To: Doug Anderson
Cc: Kukjin Kim, Simon Glass, Naveen Krishna Chatradhi, grant.likely,
yuvaraj.cd, ben.dooks, u.kleine-koenig, broonie,
girish.shivananjappa, bhushan.r, sreekumar.c, prashanth.g, olof,
djkurtz, swarren, linux, Rob Herring, Rob Landley,
Ben Dooks (embedded platforms),
Stephen Warren, Jean Delvare, Peter Korsgaard,
devicetree-discuss, linux-doc, linux-kernel, linux-i2c
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!
^ permalink raw reply [flat|nested] 96+ messages in thread