devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "G, Manjunath Kondaiah" <manjugk@ti.com>
To: "Cousson, Benoit" <b-cousson@ti.com>
Cc: "devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"grant.likely@secretlab.ca" <grant.likely@secretlab.ca>
Subject: Re: [RFC/PATCH 14/14] dt: omap3: enable dt support for i2c1 controller
Date: Wed, 17 Aug 2011 00:14:26 +0530	[thread overview]
Message-ID: <20110816184426.GA23980@manju-desktop> (raw)
In-Reply-To: <4E428031.8070600@ti.com>

On Wed, Aug 10, 2011 at 02:57:21PM +0200, Cousson, Benoit wrote:
> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> >
> >Adapt dt for omap i2c1 controller and remove legacy i2c
> >initilization in omap3 generic board file.
> >
> >Tested on omap3 beagle board for dt and non-dt builds.
> >
> >Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> >---
> >  arch/arm/boot/dts/omap3-soc.dtsi     |    6 ++--
> >  arch/arm/mach-omap2/board-omap3-dt.c |   14 +++++-----
> >  drivers/i2c/busses/i2c-omap.c        |   23 ++++++++++++++++--
> >  drivers/of/platform.c                |   41 +++++++++++++++++++++++++++++++++-
> 
> It looks like this patch is doing a lot of things. You should
> probably hack the DT core first and then update the driver and the
> DTS.
> 
> >  4 files changed, 70 insertions(+), 14 deletions(-)
> >
> >diff --git a/arch/arm/boot/dts/omap3-soc.dtsi b/arch/arm/boot/dts/omap3-soc.dtsi
> >index 85de92f..bcff63b 100644
> >--- a/arch/arm/boot/dts/omap3-soc.dtsi
> >+++ b/arch/arm/boot/dts/omap3-soc.dtsi
> >@@ -31,7 +31,7 @@
> >  		i2c1: i2c@70000 {
> >  			#address-cells =<1>;
> >  			#size-cells =<0>;
> >-			compatible = "ti,omap3-i2c";
> >+			compatible = "ti,omap3-i2c", "ti,omap3-device";
> 
> In that case the compatible is just a tagto identify an OMAP type of
> devices. You should use a more generic "ti,omap-device" entry.
> This is similar to the "arm,primecell" used to tag the primecell IPs.
> 
> >  			reg =<0x70000 0x100>;
> >  			interrupts =<  88>;
> >  		};
> >@@ -39,7 +39,7 @@
> >  		i2c2: i2c@72000 {
> >  			#address-cells =<1>;
> >  			#size-cells =<0>;
> >-			compatible = "ti,omap3-i2c";
> >+			compatible = "ti,omap3-i2c", "ti,omap3-device";
> >  			reg =<0x72000 0x100>;
> >  			interrupts =<  89>;
> >  		};
> >@@ -47,7 +47,7 @@
> >  		i2c3: i2c@60000 {
> >  			#address-cells =<1>;
> >  			#size-cells =<0>;
> >-			compatible = "ti,omap3-i2c";
> >+			compatible = "ti,omap3-i2c", "ti,omap3-device";
> >  			reg =<0x60000 0x100>;
> >  			interrupts =<  93>;
> >  		};
> >diff --git a/arch/arm/mach-omap2/board-omap3-dt.c b/arch/arm/mach-omap2/board-omap3-dt.c
> >index 4b76e19..16cf283 100644
> >--- a/arch/arm/mach-omap2/board-omap3-dt.c
> >+++ b/arch/arm/mach-omap2/board-omap3-dt.c
> >@@ -36,11 +36,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,omap3-i2c", 0x48070000, "i2c1", 1,\
> >+				&beagle_twldata, sizeof(beagle_twldata)),
> >+	{}
> >+};
> >
> >  static void __init omap3_init_early(void)
> >  {
> >@@ -70,11 +70,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 ae1545b..5167737 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,omap3-i2c", },.
> 
> This is a generic OMAP driver, so a "ti,omap-i2c" is probably much
> more appropriate. We should always avoid adding OMAP version
> information into a generic driver. Only the IP version should matter
> for a driver.
> 
> >+	{},
> >+}
> >+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
> >  	}
> >
> >  	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,
> >  	},
> >  };
> >
> >diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> >index 4b27286..4d8a2fa 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;
> >  }
> >
> >+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);
> 
> This is not enough to handle multiple hwmod entries. Moreover you
> will force the device to be named like the hwmod. This is not
> necessarily bad, but we should be able to have a distinct name if
> needed.

I agree it supports only single hwmod entries. As of now, only mcbsp uses
multiple hwmod entries. With dt enabled, most of the drivers can use single
hwmod entry for omap device creation and we can upgrade this api for handling
mutiple hwmod entries.

#>git grep omap_device_build_ss
arch/arm/mach-omap2/devices.c:  pdev = omap_device_build_ss(NULL, "omap_l3_noc",
0, oh, 3, NULL,
arch/arm/mach-omap2/mcbsp.c:    pdev = omap_device_build_ss(NULL, name, id,
oh_device, count, pdata,
arch/arm/plat-omap/include/plat/omap_device.h:struct platform_device
*omap_device_build_ss(struct device_node *np,
arch/arm/plat-omap/omap_device.c: * The function is called from inside
omap_device_build_ss(), after
arch/arm/plat-omap/omap_device.c: * omap_device @od.  Used by
omap_device_build_ss() to determine how
arch/arm/plat-omap/omap_device.c: * omap_device_build_ss() after calling
omap_device_count_resources().
arch/arm/plat-omap/omap_device.c: * platform_device record.  See
omap_device_build_ss() for more
arch/arm/plat-omap/omap_device.c: * passes along the return value of
omap_device_build_ss().
arch/arm/plat-omap/omap_device.c:       return omap_device_build_ss(np,
pdev_name, pdev_id, ohs, 1, pdata,
arch/arm/plat-omap/omap_device.c: * platform_device record.  See
omap_device_build_ss() for more
arch/arm/plat-omap/omap_device.c: * passes along the return value of
omap_device_build_ss().
arch/arm/plat-omap/omap_device.c:       return omap_device_build_ss(NULL,
pdev_name, pdev_id, ohs, 1, pdata,
arch/arm/plat-omap/omap_device.c: * omap_device_build_ss - build and register an
omap_device with multiple hwmods
arch/arm/plat-omap/omap_device.c:struct platform_device
*omap_device_build_ss(struct device_node *np,
#>

-M

  reply	other threads:[~2011-08-16 18:44 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-09 14:10 [RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 01/14] OMAP: omap_device: replace _find_by_pdev() with to_omap_device() G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 02/14] OMAP: omap_device: replace debug/warning/error prints with dev_* macros G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 03/14] OMAP3: beagle: don't touch omap_device internals G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 04/14] OMAP: McBSP: use existing macros for converting between devices G, Manjunath Kondaiah
2011-08-10  7:07   ` Jarkko Nikula
2011-08-10 10:15     ` Cousson, Benoit
2011-08-10 16:05       ` G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 05/14] OMAP: omap_device: remove internal functions from omap_device.h G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 06/14] OMAP: omap_device: when building return platform_device instead of omap_device G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 07/14] ARM: platform_device: pdev_archdata: add omap_device pointer G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 08/14] omap2+: Use Kconfig symbol in Makefile instead of obj-y G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt G, Manjunath Kondaiah
2011-08-10 11:51   ` Cousson, Benoit
2011-08-10 16:28     ` G, Manjunath Kondaiah
2011-08-10 17:11       ` Cousson, Benoit
2011-08-10 18:03         ` G, Manjunath Kondaiah
     [not found]           ` <CAC63_iSX0cjauOj=CcTABqgSWAgYRE_G7Qio5y2BrpeRnkhEWQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-08-10 18:06             ` Cousson, Benoit
2011-08-16 15:02       ` G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 10/14] dt: Add pd_size to AUXDATA structure G, Manjunath Kondaiah
     [not found]   ` <1312897232-4792-11-git-send-email-manjugk-l0cyMroinI0@public.gmane.org>
2011-08-10 11:57     ` Cousson, Benoit
2011-08-10 13:16       ` Grant Likely
2011-08-10 16:02         ` G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 11/14] dt: omap3: add soc file for handling i2c controllers G, Manjunath Kondaiah
2011-08-10 12:36   ` Cousson, Benoit
2011-08-10 16:57     ` G, Manjunath Kondaiah
2011-08-10 17:45       ` Cousson, Benoit
2011-08-16  6:32         ` G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 12/14] dt: omap3: beagle board: set clock freq for i2c devices G, Manjunath Kondaiah
2011-08-10 12:42   ` Cousson, Benoit
2011-08-10 16:45     ` G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 13/14] dt: omap3: add generic board file for dt support G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 14/14] dt: omap3: enable dt support for i2c1 controller G, Manjunath Kondaiah
2011-08-10 12:57   ` Cousson, Benoit
2011-08-16 18:44     ` G, Manjunath Kondaiah [this message]
2011-08-10  5:26 ` [RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support Rajendra Nayak
2011-08-10  5:30   ` G, Manjunath Kondaiah
2011-08-10  5:39     ` Rajendra Nayak
2011-08-10  6:28       ` G, Manjunath Kondaiah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110816184426.GA23980@manju-desktop \
    --to=manjugk@ti.com \
    --cc=b-cousson@ti.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).