[RFC/PATCH v2 09/13] dt: omap4: add soc file for handling i2c controllers

[RFC/PATCH v2 09/13] dt: omap4: add soc file for handling i2c controllers

[Rajendra Nayak]

On 8/23/2011 10:33 AM, G, Manjunath Kondaiah wrote:
>
> Add omap4 soc dts file for handling omap4 soc i2c
> controllers existing on l4-core bus.
>
> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> ---
>   arch/arm/boot/dts/omap4-panda.dts |    7 +---
>   arch/arm/boot/dts/omap4.dtsi      |   68 +++++++++++++++++++++++++++++++++++++
>   2 files changed, 69 insertions(+), 6 deletions(-)
>   create mode 100644 arch/arm/boot/dts/omap4.dtsi
>
> diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
> index 58909e9..c28aa95 100644
> --- a/arch/arm/boot/dts/omap4-panda.dts
> +++ b/arch/arm/boot/dts/omap4-panda.dts
> @@ -1,9 +1,4 @@
> -/dts-v1/;
> -
> -/memreserve/ 0x9D000000 0x03000000; /* Frame buffer */
> -/memreserve/ 0xB0000000 0x10000000; /* Top 256MB is unaccessable */
> -
> -/include/ "skeleton.dtsi"
> +/include/ "omap4.dtsi"
>
>   / {
>   	model = "TI OMAP4 PandaBoard";
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> new file mode 100644
> index 0000000..cb055f5
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -0,0 +1,68 @@
> +/*
> + * Device Tree Source for OMAP4 SoC
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +
> +/memreserve/ 0x9D000000 0x03000000; /* Frame buffer */
> +/memreserve/ 0xB0000000 0x10000000; /* Top 256MB is unaccessable */
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	#address-cells =<1>;
> +	#size-cells =<1>;
> +	model = "ti,omap4";
> +
> +	aliases {
> +		i2c1 =&i2c1;
> +		i2c2 =&i2c2;
> +		i2c3 =&i2c3;
> +		i2c4 =&i2c4;
> +	};
> +
> +	l4-core {
> +		compatible = "ti,omap4-l4-core", "sonics,s3220";
> +		#address-cells =<1>;
> +		#size-cells =<1>;
> +		ranges =<0 0x48000000 0x1000000>;
> +
> +		i2c1: i2c at 70000 {
> +			#address-cells =<1>;
> +			#size-cells =<0>;

Are these really needed, given there are no child nodes defined?
Same with all other instances.

> +			compatible = "ti,omap-i2c", "ti,omap-device";
> +			reg =<0x70000 0x100>;
> +			interrupts =<  88>;
> +		};
> +
> +		i2c2: i2c at 72000 {
> +			#address-cells =<1>;
> +			#size-cells =<0>;
> +			compatible = "ti,omap-i2c", "ti,omap-device";
> +			reg =<0x72000 0x100>;
> +			interrupts =<  89>;
> +		};
> +
> +		i2c3: i2c at 60000 {
> +			#address-cells =<1>;
> +			#size-cells =<0>;
> +			compatible = "ti,omap-i2c", "ti,omap-device";
> +			reg =<0x60000 0x100>;
> +			interrupts =<  93>;
> +		};
> +
> +		i2c4: i2c at 350000 {
> +			#address-cells =<1>;
> +			#size-cells =<0>;
> +			compatible = "ti,omap-i2c", "ti,omap-device";
> +			reg =<0x350000 0x100>;
> +			interrupts =<  94>;
> +		};
> +	};
> +};

[RFC/PATCH v2 09/13] dt: omap4: add soc file for handling i2c controllers

[G, Manjunath Kondaiah]

On Tue, Aug 23, 2011 at 01:53:54PM +0530, Rajendra Nayak wrote:
> On 8/23/2011 10:33 AM, G, Manjunath Kondaiah wrote:
> >
> >Add omap4 soc dts file for handling omap4 soc i2c
> >controllers existing on l4-core bus.
> >
> >Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> >---
> >  arch/arm/boot/dts/omap4-panda.dts |    7 +---
> >  arch/arm/boot/dts/omap4.dtsi      |   68 +++++++++++++++++++++++++++++++++++++
> >  2 files changed, 69 insertions(+), 6 deletions(-)
> >  create mode 100644 arch/arm/boot/dts/omap4.dtsi
> >
> >diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
> >index 58909e9..c28aa95 100644
> >--- a/arch/arm/boot/dts/omap4-panda.dts
> >+++ b/arch/arm/boot/dts/omap4-panda.dts
> >@@ -1,9 +1,4 @@
> >-/dts-v1/;
> >-
> >-/memreserve/ 0x9D000000 0x03000000; /* Frame buffer */
> >-/memreserve/ 0xB0000000 0x10000000; /* Top 256MB is unaccessable */
> >-
> >-/include/ "skeleton.dtsi"
> >+/include/ "omap4.dtsi"
> >
> >  / {
> >  	model = "TI OMAP4 PandaBoard";
> >diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> >new file mode 100644
> >index 0000000..cb055f5
> >--- /dev/null
> >+++ b/arch/arm/boot/dts/omap4.dtsi
> >@@ -0,0 +1,68 @@
> >+/*
> >+ * Device Tree Source for OMAP4 SoC
> >+ *
> >+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> >+ *
> >+ * This file is licensed under the terms of the GNU General Public License
> >+ * version 2.  This program is licensed "as is" without any warranty of any
> >+ * kind, whether express or implied.
> >+ */
> >+
> >+/dts-v1/;
> >+
> >+/memreserve/ 0x9D000000 0x03000000; /* Frame buffer */
> >+/memreserve/ 0xB0000000 0x10000000; /* Top 256MB is unaccessable */
> >+
> >+/include/ "skeleton.dtsi"
> >+
> >+/ {
> >+	#address-cells =<1>;
> >+	#size-cells =<1>;
> >+	model = "ti,omap4";
> >+
> >+	aliases {
> >+		i2c1 =&i2c1;
> >+		i2c2 =&i2c2;
> >+		i2c3 =&i2c3;
> >+		i2c4 =&i2c4;
> >+	};
> >+
> >+	l4-core {
> >+		compatible = "ti,omap4-l4-core", "sonics,s3220";
> >+		#address-cells =<1>;
> >+		#size-cells =<1>;
> >+		ranges =<0 0x48000000 0x1000000>;
> >+
> >+		i2c1: i2c at 70000 {
> >+			#address-cells =<1>;
> >+			#size-cells =<0>;
> 
> Are these really needed, given there are no child nodes defined?
> Same with all other instances.
This will define all the available resources for a given soc and it
can be disabled by using "status=disabled" in property field.

This is ongoing debate whether to have status field or not. 

Grant,
What is the final alignment on using status field?

-M

> 
> >+			compatible = "ti,omap-i2c", "ti,omap-device";
> >+			reg =<0x70000 0x100>;
> >+			interrupts =<  88>;
> >+		};
> >+
> >+		i2c2: i2c at 72000 {
> >+			#address-cells =<1>;
> >+			#size-cells =<0>;
> >+			compatible = "ti,omap-i2c", "ti,omap-device";
> >+			reg =<0x72000 0x100>;
> >+			interrupts =<  89>;
> >+		};
> >+
> >+		i2c3: i2c at 60000 {
> >+			#address-cells =<1>;
> >+			#size-cells =<0>;
> >+			compatible = "ti,omap-i2c", "ti,omap-device";
> >+			reg =<0x60000 0x100>;
> >+			interrupts =<  93>;
> >+		};
> >+
> >+		i2c4: i2c at 350000 {
> >+			#address-cells =<1>;
> >+			#size-cells =<0>;
> >+			compatible = "ti,omap-i2c", "ti,omap-device";
> >+			reg =<0x350000 0x100>;
> >+			interrupts =<  94>;
> >+		};
> >+	};
> >+};
> 

Fwd: [RFC/PATCH v2 09/13] dt: omap4: add soc file for handling i2c controllers

[Cousson, Benoit]

From: G, Manjunath Kondaiah<manjugk@ti.com>
> To: devicetree-discuss at lists.ozlabs.org
> CC: linux-omap at vger.kernel.org, linux-arm-kernel at lists.infradead.org
>
>
> Add omap4 soc dts file for handling omap4 soc i2c
> controllers existing on l4-core bus.

The subject and changelog is not accurate. You are doing at least 3 things:
Moving the OMAP4 SoC data from panda board file to a SoC specific 
omap4.dtsi file.
Including the omap4.dtsi into panda.
Adding some i2c nodes.

You should use at least two or three separated patches to avoid 
in-accurate subject.

Benoit


>
> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> ---
>    arch/arm/boot/dts/omap4-panda.dts |    7 +---
>    arch/arm/boot/dts/omap4.dtsi      |   68
> +++++++++++++++++++++++++++++++++++++
>    2 files changed, 69 insertions(+), 6 deletions(-)
>    create mode 100644 arch/arm/boot/dts/omap4.dtsi
>
> diff --git a/arch/arm/boot/dts/omap4-panda.dts
> b/arch/arm/boot/dts/omap4-panda.dts
> index 58909e9..c28aa95 100644
> --- a/arch/arm/boot/dts/omap4-panda.dts
> +++ b/arch/arm/boot/dts/omap4-panda.dts
> @@ -1,9 +1,4 @@
> -/dts-v1/;
> -
> -/memreserve/ 0x9D000000 0x03000000; /* Frame buffer */
> -/memreserve/ 0xB0000000 0x10000000; /* Top 256MB is unaccessable */
> -
> -/include/ "skeleton.dtsi"
> +/include/ "omap4.dtsi"
>
>    / {
>    	model = "TI OMAP4 PandaBoard";
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> new file mode 100644
> index 0000000..cb055f5
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -0,0 +1,68 @@
> +/*
> + * Device Tree Source for OMAP4 SoC
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +
> +/memreserve/ 0x9D000000 0x03000000; /* Frame buffer */
> +/memreserve/ 0xB0000000 0x10000000; /* Top 256MB is unaccessable */

That information was already there previously but where does it come from?
48 MB is clearly not for the FB, and the top 256 MB should be accessible 
with highmem.

Benoit

> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	#address-cells =<1>;
> +	#size-cells =<1>;
> +	model = "ti,omap4";
> +
> +	aliases {
> +		i2c1 =&i2c1;
> +		i2c2 =&i2c2;
> +		i2c3 =&i2c3;
> +		i2c4 =&i2c4;
> +	};
> +
> +	l4-core {
> +		compatible = "ti,omap4-l4-core", "sonics,s3220";
> +		#address-cells =<1>;
> +		#size-cells =<1>;
> +		ranges =<0 0x48000000 0x1000000>;
> +
> +		i2c1: i2c at 70000 {
> +			#address-cells =<1>;
> +			#size-cells =<0>;
> +			compatible = "ti,omap-i2c", "ti,omap-device";
> +			reg =<0x70000 0x100>;
> +			interrupts =<  88>;
> +		};
> +
> +		i2c2: i2c at 72000 {
> +			#address-cells =<1>;
> +			#size-cells =<0>;
> +			compatible = "ti,omap-i2c", "ti,omap-device";
> +			reg =<0x72000 0x100>;
> +			interrupts =<  89>;
> +		};
> +
> +		i2c3: i2c at 60000 {
> +			#address-cells =<1>;
> +			#size-cells =<0>;
> +			compatible = "ti,omap-i2c", "ti,omap-device";
> +			reg =<0x60000 0x100>;
> +			interrupts =<  93>;
> +		};
> +
> +		i2c4: i2c at 350000 {
> +			#address-cells =<1>;
> +			#size-cells =<0>;
> +			compatible = "ti,omap-i2c", "ti,omap-device";
> +			reg =<0x350000 0x100>;
> +			interrupts =<  94>;
> +		};
> +	};
> +};

Fwd: [RFC/PATCH v2 09/13] dt: omap4: add soc file for handling i2c controllers

[G, Manjunath Kondaiah]

On Tue, Aug 23, 2011 at 03:48:15PM +0200, Cousson, Benoit wrote:
> From: G, Manjunath Kondaiah<manjugk@ti.com>
> >To: devicetree-discuss at lists.ozlabs.org
> >CC: linux-omap at vger.kernel.org, linux-arm-kernel at lists.infradead.org
> >
> >
> >Add omap4 soc dts file for handling omap4 soc i2c
> >controllers existing on l4-core bus.
> 
> The subject and changelog is not accurate. You are doing at least 3 things:
> Moving the OMAP4 SoC data from panda board file to a SoC specific
> omap4.dtsi file.
> Including the omap4.dtsi into panda.
> Adding some i2c nodes.
> 
> You should use at least two or three separated patches to avoid
> in-accurate subject.

As these changes are straight forward, I can update patch description with
the required information instead of create too many patches.

If you are too specific on splitting the patches, I am ok with that too.

> 
> Benoit
> 
> 
> >
> >Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> >---
> >   arch/arm/boot/dts/omap4-panda.dts |    7 +---
> >   arch/arm/boot/dts/omap4.dtsi      |   68
> >+++++++++++++++++++++++++++++++++++++
> >   2 files changed, 69 insertions(+), 6 deletions(-)
> >   create mode 100644 arch/arm/boot/dts/omap4.dtsi
> >
> >diff --git a/arch/arm/boot/dts/omap4-panda.dts
> >b/arch/arm/boot/dts/omap4-panda.dts
> >index 58909e9..c28aa95 100644
> >--- a/arch/arm/boot/dts/omap4-panda.dts
> >+++ b/arch/arm/boot/dts/omap4-panda.dts
> >@@ -1,9 +1,4 @@
> >-/dts-v1/;
> >-
> >-/memreserve/ 0x9D000000 0x03000000; /* Frame buffer */
> >-/memreserve/ 0xB0000000 0x10000000; /* Top 256MB is unaccessable */
> >-
> >-/include/ "skeleton.dtsi"
> >+/include/ "omap4.dtsi"
> >
> >   / {
> >   	model = "TI OMAP4 PandaBoard";
> >diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> >new file mode 100644
> >index 0000000..cb055f5
> >--- /dev/null
> >+++ b/arch/arm/boot/dts/omap4.dtsi
> >@@ -0,0 +1,68 @@
> >+/*
> >+ * Device Tree Source for OMAP4 SoC
> >+ *
> >+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> >+ *
> >+ * This file is licensed under the terms of the GNU General Public License
> >+ * version 2.  This program is licensed "as is" without any warranty of any
> >+ * kind, whether express or implied.
> >+ */
> >+
> >+/dts-v1/;
> >+
> >+/memreserve/ 0x9D000000 0x03000000; /* Frame buffer */
> >+/memreserve/ 0xB0000000 0x10000000; /* Top 256MB is unaccessable */
> 
> That information was already there previously but where does it come from?
> 48 MB is clearly not for the FB, and the top 256 MB should be
> accessible with highmem.
This was originally introduced by Grant and he can provide more info on this
change.

39881c4e (Grant Likely 2011-07-05 23:42:31 -0600  4)

-M

> 
> Benoit
> 
> >+
> >+/include/ "skeleton.dtsi"
> >+
> >+/ {
> >+	#address-cells =<1>;
> >+	#size-cells =<1>;
> >+	model = "ti,omap4";
> >+
> >+	aliases {
> >+		i2c1 =&i2c1;
> >+		i2c2 =&i2c2;
> >+		i2c3 =&i2c3;
> >+		i2c4 =&i2c4;
> >+	};
> >+
> >+	l4-core {
> >+		compatible = "ti,omap4-l4-core", "sonics,s3220";
> >+		#address-cells =<1>;
> >+		#size-cells =<1>;
> >+		ranges =<0 0x48000000 0x1000000>;
> >+
> >+		i2c1: i2c at 70000 {
> >+			#address-cells =<1>;
> >+			#size-cells =<0>;
> >+			compatible = "ti,omap-i2c", "ti,omap-device";
> >+			reg =<0x70000 0x100>;
> >+			interrupts =<  88>;
> >+		};
> >+
> >+		i2c2: i2c at 72000 {
> >+			#address-cells =<1>;
> >+			#size-cells =<0>;
> >+			compatible = "ti,omap-i2c", "ti,omap-device";
> >+			reg =<0x72000 0x100>;
> >+			interrupts =<  89>;
> >+		};
> >+
> >+		i2c3: i2c at 60000 {
> >+			#address-cells =<1>;
> >+			#size-cells =<0>;
> >+			compatible = "ti,omap-i2c", "ti,omap-device";
> >+			reg =<0x60000 0x100>;
> >+			interrupts =<  93>;
> >+		};
> >+
> >+		i2c4: i2c at 350000 {
> >+			#address-cells =<1>;
> >+			#size-cells =<0>;
> >+			compatible = "ti,omap-i2c", "ti,omap-device";
> >+			reg =<0x350000 0x100>;
> >+			interrupts =<  94>;
> >+		};
> >+	};
> >+};
> 

Fwd: [RFC/PATCH v2 09/13] dt: omap4: add soc file for handling i2c controllers

[Cousson, Benoit]

On 8/23/2011 5:18 PM, G, Manjunath Kondaiah wrote:
> On Tue, Aug 23, 2011 at 03:48:15PM +0200, Cousson, Benoit wrote:
>> From: G, Manjunath Kondaiah<manjugk@ti.com>
>>> To: devicetree-discuss at lists.ozlabs.org
>>> CC: linux-omap at vger.kernel.org, linux-arm-kernel at lists.infradead.org
>>>
>>>
>>> Add omap4 soc dts file for handling omap4 soc i2c
>>> controllers existing on l4-core bus.
>>
>> The subject and changelog is not accurate. You are doing at least 3 things:
>> Moving the OMAP4 SoC data from panda board file to a SoC specific
>> omap4.dtsi file.
>> Including the omap4.dtsi into panda.
>> Adding some i2c nodes.
>>
>> You should use at least two or three separated patches to avoid
>> in-accurate subject.
>
> As these changes are straight forward, I can update patch description with
> the required information instead of create too many patches.
>
> If you are too specific on splitting the patches, I am ok with that too.

I already fixed partially the OMAP4 patches as part of my upcoming OMAP4 
early devices DT migration. So I'll rebase your series on top of it.

I'll send you that tomorrow.

Benoit

[RFC/PATCH v2 07/13] dt: omap: create platform bus for omap devices

[Jamie Iles]

Hi,

This creates a build failure for non-omap platforms as they don't know 
about struct omap_device_pm_latency, struct omap_hwmod etc.

An empty of_omap_device_create() as inline should do the trick.

Jamie

On Tue, Aug 23, 2011 at 10:03:35AM +0500, G, Manjunath Kondaiah wrote:
> 
> The omap devices will use HWMOD for fetching device information
> hence it needs to be handled seperately during platform bus
> creation during dt build.
> 
> Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
> ---
>  drivers/of/platform.c |   41 ++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 40 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index e50ffcb..bd2c089 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -24,6 +24,10 @@
>  #include <linux/of_platform.h>
>  #include <linux/platform_device.h>
>  
> +#ifdef CONFIG_ARCH_OMAP2PLUS
> +#include <plat/omap_device.h>
> +#endif
> +
>  const struct of_device_id of_default_bus_match_table[] = {
>  	{ .compatible = "simple-bus", },
>  #ifdef CONFIG_ARM_AMBA
> @@ -544,6 +548,36 @@ static const struct of_dev_auxdata *of_dev_lookup(const struct of_dev_auxdata *l
>  	return NULL;
>  }

#ifdef ARCH_OMAP

> +static struct omap_device_pm_latency omap_device_latency[] = {
> +	[0] = {
> +		.deactivate_func	= omap_device_idle_hwmods,
> +		.activate_func		= omap_device_enable_hwmods,
> +		.flags			= OMAP_DEVICE_LATENCY_AUTO_ADJUST,
> +	},
> +};
> +
> +int of_omap_device_create(struct device_node *np, const char *name, int id,
> +							void *platform_data,
> +							int pd_size)
> +{
> +	struct omap_hwmod *oh;
> +	struct platform_device *pdev;
> +
> +	oh = omap_hwmod_lookup(name);
> +	if (!oh) {
> +		pr_err("Could not look up %s\n", name);
> +		return -EEXIST;
> +	}
> +
> +	pdev = omap_device_build_dt(np, name, id, oh, platform_data,
> +				sizeof(platform_data), omap_device_latency,
> +				ARRAY_SIZE(omap_device_latency), 0);
> +	WARN(IS_ERR(pdev), "Could not build omap_device for %s\n", name);
> +
> +	pr_info("DT: omap_device build for %s is successful\n", name);
> +	return PTR_ERR(pdev);
> +}

#else /* ARCH_OMAP */
static inline int of_omap_device_create(struct device_node *np,
					const char *name, int id,
					void *platform_data, int pd_size)
{
	return -ENODEV;
}
#endif /* ARCH_OMAP */

> +
>  /**
>   * of_platform_bus_create() - Create a device for a node and its children.
>   * @bus: device node of the bus to instantiate
> @@ -565,7 +599,7 @@ static int of_platform_bus_create(struct device_node *bus,
>  	struct platform_device *dev;
>  	const char *bus_id = NULL;
>  	void *platform_data = NULL;
> -	int pd_size;
> +	int pd_size = 0;
>  	int id = -1;
>  	int rc = 0;
>  
> @@ -597,6 +631,11 @@ static int of_platform_bus_create(struct device_node *bus,
>  		return 0;
>  	}
>  
> +	if (of_device_is_compatible(bus, "ti,omap-device")) {
> +		of_omap_device_create(bus, bus_id, id, platform_data, pd_size);
> +		return 0;
> +	}
> +
>  	dev = of_platform_device_create_pdata(bus, bus_id, platform_data, parent);
>  
>  	/* override the id if auxdata gives an id */
> -- 
> 1.7.4.1
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

[RFC/PATCH v2 07/13] dt: omap: create platform bus for omap devices

[G, Manjunath Kondaiah]

On Tue, Aug 23, 2011 at 10:07:05AM +0100, Jamie Iles wrote:
> Hi,
> 
> This creates a build failure for non-omap platforms as they don't know 
> about struct omap_device_pm_latency, struct omap_hwmod etc.
> 
> An empty of_omap_device_create() as inline should do the trick.
Thanks. I will introduce this.

-M
> 
> Jamie
> 
> On Tue, Aug 23, 2011 at 10:03:35AM +0500, G, Manjunath Kondaiah wrote:
> > 
> > The omap devices will use HWMOD for fetching device information
> > hence it needs to be handled seperately during platform bus
> > creation during dt build.
> > 
> > Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
> > ---
> >  drivers/of/platform.c |   41 ++++++++++++++++++++++++++++++++++++++++-
> >  1 files changed, 40 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> > index e50ffcb..bd2c089 100644
> > --- a/drivers/of/platform.c
> > +++ b/drivers/of/platform.c
> > @@ -24,6 +24,10 @@
> >  #include <linux/of_platform.h>
> >  #include <linux/platform_device.h>
> >  
> > +#ifdef CONFIG_ARCH_OMAP2PLUS
> > +#include <plat/omap_device.h>
> > +#endif
> > +
> >  const struct of_device_id of_default_bus_match_table[] = {
> >  	{ .compatible = "simple-bus", },
> >  #ifdef CONFIG_ARM_AMBA
> > @@ -544,6 +548,36 @@ static const struct of_dev_auxdata *of_dev_lookup(const struct of_dev_auxdata *l
> >  	return NULL;
> >  }
> 
> #ifdef ARCH_OMAP
> 
> > +static struct omap_device_pm_latency omap_device_latency[] = {
> > +	[0] = {
> > +		.deactivate_func	= omap_device_idle_hwmods,
> > +		.activate_func		= omap_device_enable_hwmods,
> > +		.flags			= OMAP_DEVICE_LATENCY_AUTO_ADJUST,
> > +	},
> > +};
> > +
> > +int of_omap_device_create(struct device_node *np, const char *name, int id,
> > +							void *platform_data,
> > +							int pd_size)
> > +{
> > +	struct omap_hwmod *oh;
> > +	struct platform_device *pdev;
> > +
> > +	oh = omap_hwmod_lookup(name);
> > +	if (!oh) {
> > +		pr_err("Could not look up %s\n", name);
> > +		return -EEXIST;
> > +	}
> > +
> > +	pdev = omap_device_build_dt(np, name, id, oh, platform_data,
> > +				sizeof(platform_data), omap_device_latency,
> > +				ARRAY_SIZE(omap_device_latency), 0);
> > +	WARN(IS_ERR(pdev), "Could not build omap_device for %s\n", name);
> > +
> > +	pr_info("DT: omap_device build for %s is successful\n", name);
> > +	return PTR_ERR(pdev);
> > +}
> 
> #else /* ARCH_OMAP */
> static inline int of_omap_device_create(struct device_node *np,
> 					const char *name, int id,
> 					void *platform_data, int pd_size)
> {
> 	return -ENODEV;
> }
> #endif /* ARCH_OMAP */
> 
> > +
> >  /**
> >   * of_platform_bus_create() - Create a device for a node and its children.
> >   * @bus: device node of the bus to instantiate
> > @@ -565,7 +599,7 @@ static int of_platform_bus_create(struct device_node *bus,
> >  	struct platform_device *dev;
> >  	const char *bus_id = NULL;
> >  	void *platform_data = NULL;
> > -	int pd_size;
> > +	int pd_size = 0;
> >  	int id = -1;
> >  	int rc = 0;
> >  
> > @@ -597,6 +631,11 @@ static int of_platform_bus_create(struct device_node *bus,
> >  		return 0;
> >  	}
> >  
> > +	if (of_device_is_compatible(bus, "ti,omap-device")) {
> > +		of_omap_device_create(bus, bus_id, id, platform_data, pd_size);
> > +		return 0;
> > +	}
> > +
> >  	dev = of_platform_device_create_pdata(bus, bus_id, platform_data, parent);
> >  
> >  	/* override the id if auxdata gives an id */
> > -- 
> > 1.7.4.1
> > 
> > _______________________________________________
> > devicetree-discuss mailing list
> > devicetree-discuss at lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/devicetree-discuss

[RFC/PATCH v2 00/13] dt: omap: dt binding with omap_device and support for i2c1

[Cousson, Benoit]

Hi Manju,

Few "minor" comments about your subjects in this series.

> Patch series reworked from:
> http://permalink.gmane.org/gmane.linux.ports.arm.omap/61674
> Also added support for i2c1 controller on omap4 based panda
> board.
>
> Baseline:
> =========
> git://git.secretlab.ca/git/linux-2.6.git
> Branch: devicetree/test
> The above branch is rebased with v3.1-rc2 mainline.
> +
> pdev decoupling patches from kevin hilman
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg53534.html
>
> The patch series is also available at:
> https://gitorious.org/devicetree/dt_omap/commits/devicetree/dt_rfcv2

Please provide the git URL + branch and not the link to the web page.
It will allow to copy paste directly the line and do a git fetch <repo> 
<branch>.

> Testing:
> ========
> Build : dt and not dt build for omap2plus_defconfig
> Boot: OMAP3530 Beagle Board and OMAP4430 Panda board
>
> Limitation:
> ===========
> The current implementation of omap-device build through
> device tree supports only single instance of hwmod and
> multiple instances are not supported.
>
> G, Manjunath Kondaiah (13):
>     OMAP: omap_device: Add device tree node pointer
>     dt: Add pd_size to AUXDATA structure
>     dt: omap3: add soc file for handling i2c controllers
>     dt: omap3: beagle board: set clock freq for i2c devices
>     dt: omap3: add generic board file for dt support
>     dt: omap3: add omap-device compatible property
>     dt: omap: create platform bus for omap devices
>     dt: omap: i2c: add dt support for i2c1 controller
>     dt: omap4: add soc file for handling i2c controllers
>     dt: omap4: panda board: set clock freq for i2c devices
>     dt: omap4: add generic board file for dt support
>     dt: omap4: enable dt support for i2c1 controller
>     dt: omap: i2c: dt usage model documentation

You should adapt the prefix depending of the subsystem your patch is 
changing. Most patches are changing files inside mach-omap2 and thus in 
that case should not be prefix with dt: but rather OMAP2+:
The dts files modification should then be prefixed with arm/dt or arm/dts.


Regards,
Benoit

[RFC/PATCH v2 00/13] dt: omap: dt binding with omap_device and support for i2c1

[G, Manjunath Kondaiah]

On Tue, Aug 23, 2011 at 10:03:28AM +0500, G, Manjunath Kondaiah wrote:
> 
> Patch series reworked from:
> http://permalink.gmane.org/gmane.linux.ports.arm.omap/61674
> Also added support for i2c1 controller on omap4 based panda
> board.
> 
> Baseline:
> =========
> git://git.secretlab.ca/git/linux-2.6.git
> Branch: devicetree/test
> The above branch is rebased with v3.1-rc2 mainline.
> +
> pdev decoupling patches from kevin hilman
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg53534.html
> 
> The patch series is also available at:
> https://gitorious.org/devicetree/dt_omap/commits/devicetree/dt_rfcv2
> 
> Testing:
> ========
> Build : dt and not dt build for omap2plus_defconfig
> Boot: OMAP3530 Beagle Board and OMAP4430 Panda board

Correction: This series will support only i2c1 controller and it will not
handle i2c1 child devices such as twlxxxx pmic. Due to which, twl read/write's
might fail during boot.

I am facing issues in getting platform_data in i2c child device probe function.
The issue is reported to grant in patch 08/13 of this series.

-M

> 
> Limitation:
> ===========
> The current implementation of omap-device build through
> device tree supports only single instance of hwmod and 
> multiple instances are not supported.
> 
> G, Manjunath Kondaiah (13):
>   OMAP: omap_device: Add device tree node pointer
>   dt: Add pd_size to AUXDATA structure
>   dt: omap3: add soc file for handling i2c controllers
>   dt: omap3: beagle board: set clock freq for i2c devices
>   dt: omap3: add generic board file for dt support
>   dt: omap3: add omap-device compatible property
>   dt: omap: create platform bus for omap devices
>   dt: omap: i2c: add dt support for i2c1 controller
>   dt: omap4: add soc file for handling i2c controllers
>   dt: omap4: panda board: set clock freq for i2c devices
>   dt: omap4: add generic board file for dt support
>   dt: omap4: enable dt support for i2c1 controller
>   dt: omap: i2c: dt usage model documentation
> 
>  Documentation/devicetree/bindings/i2c/omap-i2c.txt |   57 +++++++++++++
>  arch/arm/boot/dts/omap3-beagle-nunchuck.dts        |   13 +---
>  arch/arm/boot/dts/omap3-beagle.dts                 |   18 ++++-
>  arch/arm/boot/dts/omap3.dtsi                       |   62 ++++++++++++++
>  arch/arm/boot/dts/omap4-panda.dts                  |   25 ++++--
>  arch/arm/boot/dts/omap4.dtsi                       |   68 ++++++++++++++++
>  arch/arm/mach-omap2/Kconfig                        |   22 +++++
>  arch/arm/mach-omap2/Makefile                       |    2 +
>  arch/arm/mach-omap2/board-omap3-dt.c               |   84 ++++++++++++++++++++
>  arch/arm/mach-omap2/board-omap3beagle.c            |   13 ---
>  arch/arm/mach-omap2/board-omap4-dt.c               |   75 +++++++++++++++++
>  arch/arm/mach-omap2/board-omap4panda.c             |    6 --
>  arch/arm/mach-omap2/devices.c                      |    2 +-
>  arch/arm/mach-omap2/mcbsp.c                        |    2 +-
>  arch/arm/plat-omap/include/plat/omap_device.h      |   11 +++-
>  arch/arm/plat-omap/omap_device.c                   |   46 ++++++++++-
>  drivers/i2c/busses/i2c-omap.c                      |   23 +++++-
>  drivers/of/platform.c                              |   41 ++++++++++
>  include/linux/of_platform.h                        |    5 +
>  19 files changed, 526 insertions(+), 49 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt
>  create mode 100644 arch/arm/boot/dts/omap3.dtsi
>  create mode 100644 arch/arm/boot/dts/omap4.dtsi
>  create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c
>  create mode 100644 arch/arm/mach-omap2/board-omap4-dt.c
> 
> -- 
> 1.7.4.1
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

[RFC/PATCH v2 00/13] dt: omap: dt binding with omap_device and support for i2c1

[Cousson, Benoit]

Hi Manju

On 8/23/2011 5:41 PM, G, Manjunath Kondaiah wrote:
> On Tue, Aug 23, 2011 at 10:03:28AM +0500, G, Manjunath Kondaiah wrote:
>>
>> Patch series reworked from:
>> http://permalink.gmane.org/gmane.linux.ports.arm.omap/61674
>> Also added support for i2c1 controller on omap4 based panda
>> board.
>>
>> Baseline:
>> =========
>> git://git.secretlab.ca/git/linux-2.6.git
>> Branch: devicetree/test
>> The above branch is rebased with v3.1-rc2 mainline.
>> +
>> pdev decoupling patches from kevin hilman
>> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg53534.html
>>
>> The patch series is also available at:
>> https://gitorious.org/devicetree/dt_omap/commits/devicetree/dt_rfcv2
>>
>> Testing:
>> ========
>> Build : dt and not dt build for omap2plus_defconfig
>> Boot: OMAP3530 Beagle Board and OMAP4430 Panda board
> 
> Correction: This series will support only i2c1 controller and it will not
> handle i2c1 child devices such as twlxxxx pmic. Due to which, twl read/write's
> might fail during boot.

You mean will fail :-) At least on OMAP4.

[    2.680480] [<c025d438>] (twl_i2c_read+0x34/0x128) from [<c0024368>] (twl6030_uv_to_vsel+0x28/0x84)
[    2.690032] [<c0024368>] (twl6030_uv_to_vsel+0x28/0x84) from [<c0028274>] (_pre_volt_scale+0xac/0x174)
[    2.699829] [<c0028274>] (_pre_volt_scale+0xac/0x174) from [<c0028354>] (vp_forceupdate_scale_voltage+0x18/0x2b0)
[    2.710601] [<c0028354>] (vp_forceupdate_scale_voltage+0x18/0x2b0) from [<c00280a0>] (omap_voltage_scale_vdd+0x54/0x64)
[    2.721954] [<c00280a0>] (omap_voltage_scale_vdd+0x54/0x64) from [<c056ac94>] (omap2_set_init_voltage+0xf0/0x130)
[    2.732757] [<c056ac94>] (omap2_set_init_voltage+0xf0/0x130) from [<c056ad34>] (omap2_common_pm_late_init+0x60/0xb0)
[    2.743835] [<c056ad34>] (omap2_common_pm_late_init+0x60/0xb0) from [<c0008900>] (do_one_initcall+0x94/0x168)
[    2.754272] [<c0008900>] (do_one_initcall+0x94/0x168) from [<c0562828>] (kernel_init+0x80/0x12c)
[    2.763549] [<c0562828>] (kernel_init+0x80/0x12c) from [<c001338c>] (kernel_thread_exit+0x0/0x8)
[    2.772796] Code: 8a000008 e59f70ec e1a09080 e59731ac (e7d32080)

That being said, it looks like the voltage layer should be a little bit more robust and should check the i2c status before using it blindly.

Adding Kevin, Paul and Nishanth in Cc since the voltage layer is currently being cleaned.

> I am facing issues in getting platform_data in i2c child device probe function.
> The issue is reported to grant in patch 08/13 of this series.
> 
> -M
> 
>>
>> Limitation:
>> ===========
>> The current implementation of omap-device build through
>> device tree supports only single instance of hwmod and
>> multiple instances are not supported.
>>
>> G, Manjunath Kondaiah (13):
>>    OMAP: omap_device: Add device tree node pointer
>>    dt: Add pd_size to AUXDATA structure
>>    dt: omap3: add soc file for handling i2c controllers
>>    dt: omap3: beagle board: set clock freq for i2c devices
>>    dt: omap3: add generic board file for dt support
>>    dt: omap3: add omap-device compatible property
>>    dt: omap: create platform bus for omap devices
>>    dt: omap: i2c: add dt support for i2c1 controller
>>    dt: omap4: add soc file for handling i2c controllers
>>    dt: omap4: panda board: set clock freq for i2c devices
>>    dt: omap4: add generic board file for dt support
>>    dt: omap4: enable dt support for i2c1 controller
>>    dt: omap: i2c: dt usage model documentation

Because of the broken i2c support, you should probably re-organize your series to provide at least the basic DT support for people who want to start hacking DT. The i2c support for both OMAP3 & 4 should be added at the very last time with a big disclaimer.
Ideally, you should maybe fix it first:-)

Regards,
Benoit 

[RFC/PATCH v2 08/13] dt: omap: i2c: add dt support for i2c1 controller

[G, Manjunath Kondaiah]

Hi Grant,

On Tue, Aug 23, 2011 at 10:03:36AM +0500, G, Manjunath Kondaiah wrote:
> 
> The device tree support has been added to i2c1 controller and
> corresponding i2c initilization in generic board file is cleaned
> up so that platfom device is registered through dt and omap device
> and not through board i2c initilization.
> 
> These changes will not affect non dt builds and existing functionality
> is retained.
> 
> Tested with dt and non dt builds and boot tested on beagle board.
> 
> Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
> ---
>  arch/arm/mach-omap2/board-omap3-dt.c |   14 +++++++-------
>  drivers/i2c/busses/i2c-omap.c        |   23 ++++++++++++++++++++---
>  2 files changed, 27 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-omap3-dt.c b/arch/arm/mach-omap2/board-omap3-dt.c
> index 72c59a4..cd11224 100644
> --- a/arch/arm/mach-omap2/board-omap3-dt.c
> +++ b/arch/arm/mach-omap2/board-omap3-dt.c
> @@ -35,11 +35,11 @@ static struct twl4030_platform_data beagle_twldata = {
>  	/* platform_data for children goes here */
>  };
>  
> -static int __init omap3_beagle_i2c_init(void)
> -{
> -	omap3_pmic_init("twl4030", &beagle_twldata);
> -	return 0;
> -}
> +struct of_dev_auxdata omap3_auxdata_lookup[] __initdata = {
> +	OF_DEV_AUXDATA_ID_PDSIZE("ti,omap-i2c", 0x48070000, "i2c1", 1,\
> +				&beagle_twldata, sizeof(beagle_twldata)),
> +	{}
> +};
>  
>  static void __init omap3_init_early(void)
>  {
> @@ -61,11 +61,11 @@ static struct of_device_id omap_dt_match_table[] __initdata = {
>  
>  static void __init omap3_init(void)
>  {
> -	omap3_beagle_i2c_init();
>  	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
>  	omap_serial_init();
>  
> -	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> +	of_platform_populate(NULL, omap_dt_match_table, omap3_auxdata_lookup,
> +									 NULL);
>  }
>  
>  static const char *omap3_dt_match[] __initdata = {
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 2a072ff..9e98014 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -38,6 +38,7 @@
>  #include <linux/clk.h>
>  #include <linux/io.h>
>  #include <linux/of_i2c.h>
> +#include <linux/of_device.h>
>  #include <linux/slab.h>
>  #include <linux/i2c-omap.h>
>  #include <linux/pm_runtime.h>
> @@ -972,6 +973,16 @@ static const struct i2c_algorithm omap_i2c_algo = {
>  	.functionality	= omap_i2c_func,
>  };
>  
> +#if defined(CONFIG_OF)
> +static const struct of_device_id omap_i2c_of_match[] = {
> +	{.compatible = "ti,omap-i2c", },
> +	{},
> +}
> +MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
> +#else
> +#define omap_i2c_of_match NULL
> +#endif
> +
>  static int __devinit
>  omap_i2c_probe(struct platform_device *pdev)
>  {
> @@ -1008,12 +1019,17 @@ omap_i2c_probe(struct platform_device *pdev)
>  		goto err_release_region;
>  	}
>  
> +	speed = 100;	/* Default speed */
>  	if (pdata != NULL) {
>  		speed = pdata->clkrate;
>  		dev->set_mpu_wkup_lat = pdata->set_mpu_wkup_lat;
> -	} else {
> -		speed = 100;	/* Default speed */
> -		dev->set_mpu_wkup_lat = NULL;
> +#if defined(CONFIG_OF)
> +	} else if (pdev->dev.of_node) {
> +		u32 prop;
> +		if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
> +									&prop))
> +			speed = prop/100;
> +#endif

This function calls of_i2c_register_devices which attaches all the required
parameters reg, irq, archdata etc into i2c adapter. But it will not attach 
platform_data which results empty pdata pointer in i2c child devices.

Is this done purposefully? If so, how do we get pdata pointer in i2c child 
device.

-M

>  	}
>  
>  	dev->speed = speed;
> @@ -1178,6 +1194,7 @@ static struct platform_driver omap_i2c_driver = {
>  		.name	= "omap_i2c",
>  		.owner	= THIS_MODULE,
>  		.pm	= OMAP_I2C_PM_OPS,
> +		.of_match_table = omap_i2c_of_match,
>  	},
>  };
>  
> -- 
> 1.7.4.1
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

[RFC/PATCH v2 08/13] dt: omap: i2c: add dt support for i2c1 controller

[Cousson, Benoit]

Hi Manju,

On 8/23/2011 5:46 PM, G, Manjunath Kondaiah wrote:
> Hi Grant,

[...]

> This function calls of_i2c_register_devices which attaches all the required
> parameters reg, irq, archdata etc into i2c adapter. But it will not attach
> platform_data which results empty pdata pointer in i2c child devices.
>
> Is this done purposefully?

I think so, but anyway, we'd rather spend some time on doing a proper DT 
implementation than hacking more the AUXDATA temporary solution.

I've just sent a reworked version of that series with a pure 
dt-no-auxdata-hack approach.

Regards,
Benoit

[RFC/PATCH v2 08/13] dt: omap: i2c: add dt support for i2c1 controller

[G, Manjunath Kondaiah]

Hi Benoit,

On Thu, Sep 01, 2011 at 07:34:11PM +0200, Cousson, Benoit wrote:
> Hi Manju,
> 
> On 8/23/2011 5:46 PM, G, Manjunath Kondaiah wrote:
> >Hi Grant,
> 
> [...]
> 
> >This function calls of_i2c_register_devices which attaches all the required
> >parameters reg, irq, archdata etc into i2c adapter. But it will not attach
> >platform_data which results empty pdata pointer in i2c child devices.
> >
> >Is this done purposefully?
> 
> I think so, but anyway, we'd rather spend some time on doing a
> proper DT implementation than hacking more the AUXDATA temporary
> solution.
> 
> I've just sent a reworked version of that series with a pure
> dt-no-auxdata-hack approach.

Thanks for initiating aux data cleanup series. Let us syncup on further changes
and follow up so that we can have this feature with v3.2 merge window.

Grant, Can you have a look and provide feedback on all the patches which are
done for omap dt work.

-M

Fwd: [RFC/PATCH v2 08/13] dt: omap: i2c: add dt support for i2c1 controller

[Cousson, Benoit]

> The device tree support has been added to i2c1 controller and
> corresponding i2c initilization in generic board file is cleaned
> up so that platfom device is registered through dt and omap device
> and not through board i2c initilization.

A couple of typos in the changelog.

That patch should be in two parts: the driver DT update and the beagle 
board update.

> These changes will not affect non dt builds and existing functionality
> is retained.
>
> Tested with dt and non dt builds and boot tested on beagle board.

Is it crashing at boot time like for panda? In that case a big 
disclaimer should be in the broken patch changelog as well.

> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> ---
>    arch/arm/mach-omap2/board-omap3-dt.c |   14 +++++++-------
>    drivers/i2c/busses/i2c-omap.c        |   23 ++++++++++++++++++++---
>    2 files changed, 27 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3-dt.c
> b/arch/arm/mach-omap2/board-omap3-dt.c
> index 72c59a4..cd11224 100644
> --- a/arch/arm/mach-omap2/board-omap3-dt.c
> +++ b/arch/arm/mach-omap2/board-omap3-dt.c
> @@ -35,11 +35,11 @@ static struct twl4030_platform_data beagle_twldata = {
>    	/* platform_data for children goes here */
>    };
>
> -static int __init omap3_beagle_i2c_init(void)
> -{
> -	omap3_pmic_init("twl4030",&beagle_twldata);
> -	return 0;
> -}
> +struct of_dev_auxdata omap3_auxdata_lookup[] __initdata = {
> +	OF_DEV_AUXDATA_ID_PDSIZE("ti,omap-i2c", 0x48070000, "i2c1", 1,\
> +				&beagle_twldata, sizeof(beagle_twldata)),
> +	{}
> +};
>
>    static void __init omap3_init_early(void)
>    {
> @@ -61,11 +61,11 @@ static struct of_device_id omap_dt_match_table[]
> __initdata = {
>
>    static void __init omap3_init(void)
>    {
> -	omap3_beagle_i2c_init();
>    	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
>    	omap_serial_init();
>
> -	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> +	of_platform_populate(NULL, omap_dt_match_table, omap3_auxdata_lookup,
> +									 NULL);
>    }
>
>    static const char *omap3_dt_match[] __initdata = {
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 2a072ff..9e98014 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -38,6 +38,7 @@
>    #include<linux/clk.h>
>    #include<linux/io.h>
>    #include<linux/of_i2c.h>
> +#include<linux/of_device.h>
>    #include<linux/slab.h>
>    #include<linux/i2c-omap.h>
>    #include<linux/pm_runtime.h>
> @@ -972,6 +973,16 @@ static const struct i2c_algorithm omap_i2c_algo = {
>    	.functionality	= omap_i2c_func,
>    };
>
> +#if defined(CONFIG_OF)
> +static const struct of_device_id omap_i2c_of_match[] = {
> +	{.compatible = "ti,omap-i2c", },
> +	{},
> +}
> +MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
> +#else
> +#define omap_i2c_of_match NULL
> +#endif
> +
>    static int __devinit
>    omap_i2c_probe(struct platform_device *pdev)
>    {
> @@ -1008,12 +1019,17 @@ omap_i2c_probe(struct platform_device *pdev)
>    		goto err_release_region;
>    	}
>
> +	speed = 100;	/* Default speed */
>    	if (pdata != NULL) {
>    		speed = pdata->clkrate;
>    		dev->set_mpu_wkup_lat = pdata->set_mpu_wkup_lat;
> -	} else {
> -		speed = 100;	/* Default speed */
> -		dev->set_mpu_wkup_lat = NULL;
> +#if defined(CONFIG_OF)
> +	} else if (pdev->dev.of_node) {
> +		u32 prop;
> +		if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
> +									&prop))
> +			speed = prop/100;

Did you check the frequency? It should be prop/1000 to get Hz -> kHz 
conversion. Otherwise the driver will set the i2c speed at 4 MHz.

Benoit

> +#endif
>    	}
>
>    	dev->speed = speed;
> @@ -1178,6 +1194,7 @@ static struct platform_driver omap_i2c_driver = {
>    		.name	= "omap_i2c",
>    		.owner	= THIS_MODULE,
>    		.pm	= OMAP_I2C_PM_OPS,
> +		.of_match_table = omap_i2c_of_match,
>    	},
>    };
>