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

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

[Doug Anderson]

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

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

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

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

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

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

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

[Doug Anderson]

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

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v1: 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 69a87a0..b651958 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -50,6 +50,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

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

[Stephen Warren]

On 02/13/2013 11:02 AM, 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.

> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi

>  	i2c at 12CA0000 {
> -		status = "disabled";
> +		samsung,i2c-sda-delay = <100>;
> +		samsung,i2c-max-bus-freq = <66000>;

Shouldn't that use the standard clock-frequency property?

> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts

> +	i2c-arbitrator {
> +		compatible = "i2c-arbitrator";
> +		#address-cells = <1>;
> +		#size-cells = <0>;

> +		/* Use ID 104 as a hint that we're on physical bus 4 */
> +		i2c_104: i2c at 0 {

Does something use that hint? It sounds a little odd.

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

[Doug Anderson]

Stephen,


On Wed, Feb 13, 2013 at 1:04 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 02/13/2013 11:02 AM, 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.
>
>> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
>
>>       i2c at 12CA0000 {
>> -             status = "disabled";
>> +             samsung,i2c-sda-delay = <100>;
>> +             samsung,i2c-max-bus-freq = <66000>;
>
> Shouldn't that use the standard clock-frequency property?

At the moment this is the way that you specify it for the i2c
controller we're using...


>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
>
>> +     i2c-arbitrator {
>> +             compatible = "i2c-arbitrator";
>> +             #address-cells = <1>;
>> +             #size-cells = <0>;
>
>> +             /* Use ID 104 as a hint that we're on physical bus 4 */
>> +             i2c_104: i2c at 0 {
>
> Does something use that hint? It sounds a little odd.

The i2c bus numbering patches will end up creating "/dev/i2c-104".
...so the hint is really for developers who are poking around.  It's
definitely a strange number and that's part of the point.  Right now
there's nothing preventing someone from using 'i2cdetect' or 'i2cget'
on bus 4 and bypassing arbitration.  My hope was that having something
crazy like "104" would help someone realize that it's a bad idea.

...besides, if I don't come up with _some_ number then this will get
assigned the first unused ID which could be extra confusing.

-Doug

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

[Stephen Warren]

On 02/13/2013 05:38 PM, Doug Anderson wrote:
> Stephen,
> 
> 
> On Wed, Feb 13, 2013 at 1:04 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 02/13/2013 11:02 AM, 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.

>>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
>>
>>> +     i2c-arbitrator {
>>> +             compatible = "i2c-arbitrator";
>>> +             #address-cells = <1>;
>>> +             #size-cells = <0>;
>>
>>> +             /* Use ID 104 as a hint that we're on physical bus 4 */
>>> +             i2c_104: i2c at 0 {
>>
>> Does something use that hint? It sounds a little odd.
> 
> The i2c bus numbering patches will end up creating "/dev/i2c-104".

Oh sorry, I see this is just the alias doing it's job. I'd misread that
as the reg value being 104 and driving the bus ID.