[RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support

[RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support

[G, Manjunath Kondaiah]

This is in continuation of patch series posted at:
http://lwn.net/Articles/451917/

Patches from Kevin Hilman and others are consolidated along with this
series since it will be part of ongoing work of decoupling pdev from
omap_device.
[There is latest version posted which will be rebased later]

Apart from the above, the major feature included in this series is
dt-hwmod binding and preparing omap hwmod framework for adapting omap
drivers to support omap dt after aligning with Grant Likely 
<grant.likely@secretlab.ca>

However, current hwmod-dt binding will be replaced with notifiers in
generic board file and hwmod device pointer will be scanned and attached
in notifier call.

Used 3.0 stable kernel version for this patch series since latest mainline
was broken for beagle boot last week.

git://git.secretlab.ca/git/linux-2.6.git
Branch: devicetree/test-3.0

G, Manjunath Kondaiah (6):
  dt: omap: prepare hwmod to support dt
  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: enable dt support for i2c1 controller

Kevin Hilman (7):
  OMAP: omap_device: replace _find_by_pdev() with to_omap_device()
  OMAP: omap_device: replace debug/warning/error prints with dev_*
    macros
  OMAP3: beagle: don't touch omap_device internals
  OMAP: McBSP: use existing macros for converting between devices
  OMAP: omap_device: remove internal functions from omap_device.h
  OMAP: omap_device: when building return platform_device instead of
    omap_device
  ARM: platform_device: pdev_archdata: add omap_device pointer

Tony Lindgren (1):
  omap2+: Use Kconfig symbol in Makefile instead of obj-y

 arch/arm/boot/dts/omap3-beagle-nunchuck.dts   |   11 +--
 arch/arm/boot/dts/omap3-beagle.dts            |   18 +++-
 arch/arm/boot/dts/omap3-soc.dtsi              |   62 ++++++++++
 arch/arm/include/asm/device.h                 |    5 +
 arch/arm/mach-omap2/Kconfig                   |   11 ++
 arch/arm/mach-omap2/Makefile                  |   77 ++++++-------
 arch/arm/mach-omap2/board-omap3-dt.c          |   93 +++++++++++++++
 arch/arm/mach-omap2/board-omap3beagle.c       |   40 ++-----
 arch/arm/mach-omap2/devices.c                 |   44 ++++----
 arch/arm/mach-omap2/display.c                 |    6 +-
 arch/arm/mach-omap2/dma.c                     |   16 ++--
 arch/arm/mach-omap2/gpio.c                    |    8 +-
 arch/arm/mach-omap2/hsmmc.c                   |    8 +-
 arch/arm/mach-omap2/hwspinlock.c              |    8 +-
 arch/arm/mach-omap2/mcbsp.c                   |    8 +-
 arch/arm/mach-omap2/pm.c                      |    8 +-
 arch/arm/mach-omap2/serial.c                  |   12 +-
 arch/arm/plat-omap/i2c.c                      |    8 +-
 arch/arm/plat-omap/include/plat/omap_device.h |   17 ++-
 arch/arm/plat-omap/mcbsp.c                    |    6 +-
 arch/arm/plat-omap/omap_device.c              |  150 ++++++++++++++++---------
 drivers/i2c/busses/i2c-omap.c                 |   23 ++++-
 drivers/of/platform.c                         |   41 +++++++
 include/linux/of_platform.h                   |    5 +
 24 files changed, 469 insertions(+), 216 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
 create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c

[RFC/PATCH 01/14] OMAP: omap_device: replace _find_by_pdev() with to_omap_device()

[G, Manjunath Kondaiah]

From: Kevin Hilman <khilman@ti.com>

The omap_device layer currently has two ways of getting an omap_device
pointer from a platform_device pointer.

Replace current usage of _find_by_pdev() with to_omap_device() since
to_omap_device() is more familiar to the existing to_platform_device()
used when getting a platform_device pointer from a struct device pointer.

Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/plat-omap/omap_device.c |   15 +++++----------
 1 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 49fc0df..c8b9cd1 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -236,11 +236,6 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat)
 	return 0;
 }
 
-static inline struct omap_device *_find_by_pdev(struct platform_device *pdev)
-{
-	return container_of(pdev, struct omap_device, pdev);
-}
-
 /**
  * _add_optional_clock_clkdev - Add clkdev entry for hwmod optional clocks
  * @od: struct omap_device *od
@@ -316,7 +311,7 @@ u32 omap_device_get_context_loss_count(struct platform_device *pdev)
 	struct omap_device *od;
 	u32 ret = 0;
 
-	od = _find_by_pdev(pdev);
+	od = to_omap_device(pdev);
 
 	if (od->hwmods_cnt)
 		ret = omap_hwmod_get_context_loss_count(od->hwmods[0]);
@@ -611,7 +606,7 @@ int omap_device_enable(struct platform_device *pdev)
 	int ret;
 	struct omap_device *od;
 
-	od = _find_by_pdev(pdev);
+	od = to_omap_device(pdev);
 
 	if (od->_state == OMAP_DEVICE_STATE_ENABLED) {
 		WARN(1, "omap_device: %s.%d: %s() called from invalid state %d\n",
@@ -650,7 +645,7 @@ int omap_device_idle(struct platform_device *pdev)
 	int ret;
 	struct omap_device *od;
 
-	od = _find_by_pdev(pdev);
+	od = to_omap_device(pdev);
 
 	if (od->_state != OMAP_DEVICE_STATE_ENABLED) {
 		WARN(1, "omap_device: %s.%d: %s() called from invalid state %d\n",
@@ -681,7 +676,7 @@ int omap_device_shutdown(struct platform_device *pdev)
 	int ret, i;
 	struct omap_device *od;
 
-	od = _find_by_pdev(pdev);
+	od = to_omap_device(pdev);
 
 	if (od->_state != OMAP_DEVICE_STATE_ENABLED &&
 	    od->_state != OMAP_DEVICE_STATE_IDLE) {
@@ -722,7 +717,7 @@ int omap_device_align_pm_lat(struct platform_device *pdev,
 	int ret = -EINVAL;
 	struct omap_device *od;
 
-	od = _find_by_pdev(pdev);
+	od = to_omap_device(pdev);
 
 	if (new_wakeup_lat_limit == od->dev_wakeup_lat)
 		return 0;
-- 
1.7.1

[RFC/PATCH 02/14] OMAP: omap_device: replace debug/warning/error prints with dev_* macros

[G, Manjunath Kondaiah]

From: Kevin Hilman <khilman@ti.com>

For consistency in kernel printk output for devices, use dev_dbg(),
dev_warn(), dev_err() instead of pr_debug(), pr_warning() and
pr_err(), some of which currently use direct access of name from
platform_device and others of which use dev_name().  Using the dev_*
versions uses the standard device naming from the driver core.

Some pr_* prints were not converted with this patch since they are
used before the platform_device and struct device are created so
neither the dev_* prints or dev_name() is valid.

Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
 arch/arm/plat-omap/omap_device.c |   70 +++++++++++++++++++-------------------
 1 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index c8b9cd1..1d69596 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -114,7 +114,7 @@ static int _omap_device_activate(struct omap_device *od, u8 ignore_lat)
 {
 	struct timespec a, b, c;
 
-	pr_debug("omap_device: %s: activating\n", od->pdev.name);
+	dev_dbg(&od->pdev.dev, "omap_device: activating\n");
 
 	while (od->pm_lat_level > 0) {
 		struct omap_device_pm_latency *odpl;
@@ -138,25 +138,24 @@ static int _omap_device_activate(struct omap_device *od, u8 ignore_lat)
 		c = timespec_sub(b, a);
 		act_lat = timespec_to_ns(&c);
 
-		pr_debug("omap_device: %s: pm_lat %d: activate: elapsed time "
-			 "%llu nsec\n", od->pdev.name, od->pm_lat_level,
-			 act_lat);
+		dev_dbg(&od->pdev.dev,
+			"omap_device: pm_lat %d: activate: elapsed time "
+			"%llu nsec\n", od->pm_lat_level, act_lat);
 
 		if (act_lat > odpl->activate_lat) {
 			odpl->activate_lat_worst = act_lat;
 			if (odpl->flags & OMAP_DEVICE_LATENCY_AUTO_ADJUST) {
 				odpl->activate_lat = act_lat;
-				pr_warning("omap_device: %s.%d: new worst case "
-					   "activate latency %d: %llu\n",
-					   od->pdev.name, od->pdev.id,
-					   od->pm_lat_level, act_lat);
+				dev_warn(&od->pdev.dev,
+					 "new worst case activate latency "
+					 "%d: %llu\n",
+					 od->pm_lat_level, act_lat);
 			} else
-				pr_warning("omap_device: %s.%d: activate "
-					   "latency %d higher than exptected. "
-					   "(%llu > %d)\n",
-					   od->pdev.name, od->pdev.id,
-					   od->pm_lat_level, act_lat,
-					   odpl->activate_lat);
+				dev_warn(&od->pdev.dev,
+					 "activate latency %d "
+					 "higher than exptected. (%llu > %d)\n",
+					 od->pm_lat_level, act_lat,
+					 odpl->activate_lat);
 		}
 
 		od->dev_wakeup_lat -= odpl->activate_lat;
@@ -183,7 +182,7 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat)
 {
 	struct timespec a, b, c;
 
-	pr_debug("omap_device: %s: deactivating\n", od->pdev.name);
+	dev_dbg(&od->pdev.dev, "omap_device: deactivating\n");
 
 	while (od->pm_lat_level < od->pm_lats_cnt) {
 		struct omap_device_pm_latency *odpl;
@@ -206,28 +205,26 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat)
 		c = timespec_sub(b, a);
 		deact_lat = timespec_to_ns(&c);
 
-		pr_debug("omap_device: %s: pm_lat %d: deactivate: elapsed time "
-			 "%llu nsec\n", od->pdev.name, od->pm_lat_level,
-			 deact_lat);
+		dev_dbg(&od->pdev.dev,
+			"omap_device: pm_lat %d: deactivate: elapsed time "
+			"%llu nsec\n", od->pm_lat_level, deact_lat);
 
 		if (deact_lat > odpl->deactivate_lat) {
 			odpl->deactivate_lat_worst = deact_lat;
 			if (odpl->flags & OMAP_DEVICE_LATENCY_AUTO_ADJUST) {
 				odpl->deactivate_lat = deact_lat;
-				pr_warning("omap_device: %s.%d: new worst case "
-					   "deactivate latency %d: %llu\n",
-					   od->pdev.name, od->pdev.id,
-					   od->pm_lat_level, deact_lat);
+				dev_warn(&od->pdev.dev,
+					 "new worst case deactivate latency "
+					 "%d: %llu\n",
+					 od->pm_lat_level, deact_lat);
 			} else
-				pr_warning("omap_device: %s.%d: deactivate "
-					   "latency %d higher than exptected. "
-					   "(%llu > %d)\n",
-					   od->pdev.name, od->pdev.id,
-					   od->pm_lat_level, deact_lat,
-					   odpl->deactivate_lat);
+				dev_warn(&od->pdev.dev,
+					 "deactivate latency %d "
+					 "higher than exptected. (%llu > %d)\n",
+					 od->pm_lat_level, deact_lat,
+					 odpl->deactivate_lat);
 		}
 
-
 		od->dev_wakeup_lat += odpl->activate_lat;
 
 		od->pm_lat_level++;
@@ -609,8 +606,9 @@ int omap_device_enable(struct platform_device *pdev)
 	od = to_omap_device(pdev);
 
 	if (od->_state == OMAP_DEVICE_STATE_ENABLED) {
-		WARN(1, "omap_device: %s.%d: %s() called from invalid state %d\n",
-		     od->pdev.name, od->pdev.id, __func__, od->_state);
+		dev_warn(&pdev->dev,
+			 "omap_device: %s() called from invalid state %d\n",
+			 __func__, od->_state);
 		return -EINVAL;
 	}
 
@@ -648,8 +646,9 @@ int omap_device_idle(struct platform_device *pdev)
 	od = to_omap_device(pdev);
 
 	if (od->_state != OMAP_DEVICE_STATE_ENABLED) {
-		WARN(1, "omap_device: %s.%d: %s() called from invalid state %d\n",
-		     od->pdev.name, od->pdev.id, __func__, od->_state);
+		dev_warn(&pdev->dev,
+			 "omap_device: %s() called from invalid state %d\n",
+			 __func__, od->_state);
 		return -EINVAL;
 	}
 
@@ -680,8 +679,9 @@ int omap_device_shutdown(struct platform_device *pdev)
 
 	if (od->_state != OMAP_DEVICE_STATE_ENABLED &&
 	    od->_state != OMAP_DEVICE_STATE_IDLE) {
-		WARN(1, "omap_device: %s.%d: %s() called from invalid state %d\n",
-		     od->pdev.name, od->pdev.id, __func__, od->_state);
+		dev_warn(&pdev->dev,
+			 "omap_device: %s() called from invalid state %d\n",
+			 __func__, od->_state);
 		return -EINVAL;
 	}
 
-- 
1.7.1

[RFC/PATCH 03/14] OMAP3: beagle: don't touch omap_device internals

[G, Manjunath Kondaiah]

From: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>

Board code should not touch omap_device internals.  To get the MPU/IVA devices,
use existing APIs: omap2_get_mpu_device(), omap2_get_iva_device().

Signed-off-by: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>
---
 arch/arm/mach-omap2/board-omap3beagle.c |   27 ++++++++++++---------------
 1 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 213c4cd..7905c8d 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -529,25 +529,24 @@ static void __init beagle_opp_init(void)
 		return;
 	}
 
-	/* Custom OPP enabled for XM */
-	if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
-		struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
-		struct omap_hwmod *dh = omap_hwmod_lookup("iva");
-		struct device *dev;
+	/* Custom OPP enabled for all xM versions */
+	if (cpu_is_omap3630()) {
+		struct device *mpu_dev, *iva_dev;
+
+		mpu_dev = omap2_get_mpuss_device();
+		iva_dev = omap2_get_iva_device();
 
-		if (!mh || !dh) {
+		if (!mpu_dev || !iva_dev) {
 			pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
-				__func__, mh, dh);
+				__func__, mpu_dev, iva_dev);
 			return;
 		}
 		/* Enable MPU 1GHz and lower opps */
-		dev = &mh->od->pdev.dev;
-		r = opp_enable(dev, 800000000);
+		r = opp_enable(mpu_dev, 800000000);
 		/* TODO: MPU 1GHz needs SR and ABB */
 
 		/* Enable IVA 800MHz and lower opps */
-		dev = &dh->od->pdev.dev;
-		r |= opp_enable(dev, 660000000);
+		r |= opp_enable(iva_dev, 660000000);
 		/* TODO: DSP 800MHz needs SR and ABB */
 		if (r) {
 			pr_err("%s: failed to enable higher opp %d\n",
@@ -556,10 +555,8 @@ static void __init beagle_opp_init(void)
 			 * Cleanup - disable the higher freqs - we dont care
 			 * about the results
 			 */
-			dev = &mh->od->pdev.dev;
-			opp_disable(dev, 800000000);
-			dev = &dh->od->pdev.dev;
-			opp_disable(dev, 660000000);
+			opp_disable(mpu_dev, 800000000);
+			opp_disable(iva_dev, 660000000);
 		}
 	}
 	return;
-- 
1.7.1

[RFC/PATCH 04/14] OMAP: McBSP: use existing macros for converting between devices

[G, Manjunath Kondaiah]

From: Kevin Hilman <khilman@ti.com>

For converting from struct device to platform_device, and from
platform_device to struct device, there are existing macros.  Use
them instead of manual use of container_of().

Signed-off-by: Kevin Hilman <khilman@ti.com>
---
 arch/arm/plat-omap/mcbsp.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 5587acf..3f4a45d 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -295,9 +295,9 @@ EXPORT_SYMBOL(omap_mcbsp_dma_reg_params);
 #ifdef CONFIG_ARCH_OMAP3
 static struct omap_device *find_omap_device_by_dev(struct device *dev)
 {
-	struct platform_device *pdev = container_of(dev,
-					struct platform_device, dev);
-	return container_of(pdev, struct omap_device, pdev);
+	struct platform_device *pdev = to_platform_device(dev);
+
+	return to_omap_device(pdev);
 }
 
 static void omap_st_on(struct omap_mcbsp *mcbsp)
-- 
1.7.1

[RFC/PATCH 05/14] OMAP: omap_device: remove internal functions from omap_device.h

[G, Manjunath Kondaiah]

From: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>

The *_device_register() functions and the count/fill resources functions
are internal to omap_device and do not need to be in the header.

Signed-off-by: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>
---
 arch/arm/plat-omap/include/plat/omap_device.h |    6 ------
 arch/arm/plat-omap/omap_device.c              |   12 ++++++++----
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
index e4c349f..0a53a0a 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -83,9 +83,6 @@ int omap_device_shutdown(struct platform_device *pdev);
 
 /* Core code interface */
 
-int omap_device_count_resources(struct omap_device *od);
-int omap_device_fill_resources(struct omap_device *od, struct resource *res);
-
 struct omap_device *omap_device_build(const char *pdev_name, int pdev_id,
 				      struct omap_hwmod *oh, void *pdata,
 				      int pdata_len,
@@ -98,9 +95,6 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 					 struct omap_device_pm_latency *pm_lats,
 					 int pm_lats_cnt, int is_early_device);
 
-int omap_device_register(struct omap_device *od);
-int omap_early_device_register(struct omap_device *od);
-
 void __iomem *omap_device_get_rt_va(struct omap_device *od);
 
 /* OMAP PM interface */
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 1d69596..4737b60 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -94,6 +94,9 @@
 #define USE_WAKEUP_LAT			0
 #define IGNORE_WAKEUP_LAT		1
 
+static int omap_device_register(struct omap_device *od);
+static int omap_early_device_register(struct omap_device *od);
+
 /* Private functions */
 
 /**
@@ -325,7 +328,7 @@ u32 omap_device_get_context_loss_count(struct platform_device *pdev)
  * much memory to allocate before calling
  * omap_device_fill_resources().  Returns the count.
  */
-int omap_device_count_resources(struct omap_device *od)
+static int omap_device_count_resources(struct omap_device *od)
 {
 	int c = 0;
 	int i;
@@ -356,7 +359,8 @@ int omap_device_count_resources(struct omap_device *od)
  * functions to get device resources.  Hacking around the existing
  * platform_device code wastes memory.  Returns 0.
  */
-int omap_device_fill_resources(struct omap_device *od, struct resource *res)
+static int omap_device_fill_resources(struct omap_device *od,
+				      struct resource *res)
 {
 	int c = 0;
 	int i, r;
@@ -520,7 +524,7 @@ odbs_exit1:
  * platform_early_add_device() on the underlying platform_device.
  * Returns 0 by default.
  */
-int omap_early_device_register(struct omap_device *od)
+static int omap_early_device_register(struct omap_device *od)
 {
 	struct platform_device *devices[1];
 
@@ -573,7 +577,7 @@ static struct dev_power_domain omap_device_power_domain = {
  * platform_device_register() on the underlying platform_device.
  * Returns the return value of platform_device_register().
  */
-int omap_device_register(struct omap_device *od)
+static int omap_device_register(struct omap_device *od)
 {
 	pr_debug("omap_device: %s: registering\n", od->pdev.name);
 
-- 
1.7.1

[RFC/PATCH 06/14] OMAP: omap_device: when building return platform_device instead of omap_device

[G, Manjunath Kondaiah]

From: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>

All of the device init and device driver interaction with omap_device
is done using platform_device pointers.  To make this more explicit,
have omap_device return a platform_device pointer instead of an
omap_device pointer.

All current users of the omap_device pointer were only using it to get
at the platform_device pointer or struct device pointer, so fixing all
of the users was trivial.

This also makes it more difficult for device init code to directly
access members of struct omap_device, and allows for easier changing
of omap_device internals.

Cc: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>
---
 arch/arm/mach-omap2/devices.c                 |   44 ++++++++++++------------
 arch/arm/mach-omap2/display.c                 |    6 ++--
 arch/arm/mach-omap2/dma.c                     |   16 ++++----
 arch/arm/mach-omap2/gpio.c                    |    8 ++--
 arch/arm/mach-omap2/hsmmc.c                   |    8 ++--
 arch/arm/mach-omap2/hwspinlock.c              |    8 ++--
 arch/arm/mach-omap2/mcbsp.c                   |    8 ++--
 arch/arm/mach-omap2/pm.c                      |    8 ++--
 arch/arm/mach-omap2/serial.c                  |   12 +++---
 arch/arm/plat-omap/i2c.c                      |    8 ++--
 arch/arm/plat-omap/include/plat/omap_device.h |    4 +-
 arch/arm/plat-omap/omap_device.c              |    6 ++--
 12 files changed, 68 insertions(+), 68 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5b8ca68..458f7be 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -44,7 +44,7 @@ static int __init omap3_l3_init(void)
 {
 	int l;
 	struct omap_hwmod *oh;
-	struct omap_device *od;
+	struct platform_device *pdev;
 	char oh_name[L3_MODULES_MAX_LEN];
 
 	/*
@@ -61,12 +61,12 @@ static int __init omap3_l3_init(void)
 	if (!oh)
 		pr_err("could not look up %s\n", oh_name);
 
-	od = omap_device_build("omap_l3_smx", 0, oh, NULL, 0,
+	pdev = omap_device_build("omap_l3_smx", 0, oh, NULL, 0,
 							   NULL, 0, 0);
 
-	WARN(IS_ERR(od), "could not build omap_device for %s\n", oh_name);
+	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
 
-	return IS_ERR(od) ? PTR_ERR(od) : 0;
+	return IS_ERR(pdev) ? PTR_ERR(pdev) : 0;
 }
 postcore_initcall(omap3_l3_init);
 
@@ -74,7 +74,7 @@ static int __init omap4_l3_init(void)
 {
 	int l, i;
 	struct omap_hwmod *oh[3];
-	struct omap_device *od;
+	struct platform_device *pdev;
 	char oh_name[L3_MODULES_MAX_LEN];
 
 	/*
@@ -92,12 +92,12 @@ static int __init omap4_l3_init(void)
 			pr_err("could not look up %s\n", oh_name);
 	}
 
-	od = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
+	pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
 						     0, NULL, 0, 0);
 
-	WARN(IS_ERR(od), "could not build omap_device for %s\n", oh_name);
+	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
 
-	return IS_ERR(od) ? PTR_ERR(od) : 0;
+	return IS_ERR(pdev) ? PTR_ERR(pdev) : 0;
 }
 postcore_initcall(omap4_l3_init);
 
@@ -232,7 +232,7 @@ struct omap_device_pm_latency omap_keyboard_latency[] = {
 int __init omap4_keyboard_init(struct omap4_keypad_platform_data
 						*sdp4430_keypad_data)
 {
-	struct omap_device *od;
+	struct platform_device *pdev;
 	struct omap_hwmod *oh;
 	struct omap4_keypad_platform_data *keypad_data;
 	unsigned int id = -1;
@@ -247,15 +247,15 @@ int __init omap4_keyboard_init(struct omap4_keypad_platform_data
 
 	keypad_data = sdp4430_keypad_data;
 
-	od = omap_device_build(name, id, oh, keypad_data,
+	pdev = omap_device_build(name, id, oh, keypad_data,
 			sizeof(struct omap4_keypad_platform_data),
 			omap_keyboard_latency,
 			ARRAY_SIZE(omap_keyboard_latency), 0);
 
-	if (IS_ERR(od)) {
+	if (IS_ERR(pdev)) {
 		WARN(1, "Can't build omap_device for %s:%s.\n",
 						name, oh->name);
-		return PTR_ERR(od);
+		return PTR_ERR(pdev);
 	}
 
 	return 0;
@@ -273,7 +273,7 @@ static struct omap_device_pm_latency mbox_latencies[] = {
 static inline void omap_init_mbox(void)
 {
 	struct omap_hwmod *oh;
-	struct omap_device *od;
+	struct platform_device *pdev;
 
 	oh = omap_hwmod_lookup("mailbox");
 	if (!oh) {
@@ -281,10 +281,10 @@ static inline void omap_init_mbox(void)
 		return;
 	}
 
-	od = omap_device_build("omap-mailbox", -1, oh, NULL, 0,
+	pdev = omap_device_build("omap-mailbox", -1, oh, NULL, 0,
 				mbox_latencies, ARRAY_SIZE(mbox_latencies), 0);
-	WARN(IS_ERR(od), "%s: could not build device, err %ld\n",
-						__func__, PTR_ERR(od));
+	WARN(IS_ERR(pdev), "%s: could not build device, err %ld\n",
+						__func__, PTR_ERR(pdev));
 }
 #else
 static inline void omap_init_mbox(void) { }
@@ -343,7 +343,7 @@ struct omap_device_pm_latency omap_mcspi_latency[] = {
 
 static int omap_mcspi_init(struct omap_hwmod *oh, void *unused)
 {
-	struct omap_device *od;
+	struct platform_device *pdev;
 	char *name = "omap2_mcspi";
 	struct omap2_mcspi_platform_config *pdata;
 	static int spi_num;
@@ -370,10 +370,10 @@ static int omap_mcspi_init(struct omap_hwmod *oh, void *unused)
 	}
 
 	spi_num++;
-	od = omap_device_build(name, spi_num, oh, pdata,
+	pdev = omap_device_build(name, spi_num, oh, pdata,
 				sizeof(*pdata),	omap_mcspi_latency,
 				ARRAY_SIZE(omap_mcspi_latency), 0);
-	WARN(IS_ERR(od), "Can't build omap_device for %s:%s\n",
+	WARN(IS_ERR(pdev), "Can't build omap_device for %s:%s\n",
 				name, oh->name);
 	kfree(pdata);
 	return 0;
@@ -708,7 +708,7 @@ static struct omap_device_pm_latency omap_wdt_latency[] = {
 static int __init omap_init_wdt(void)
 {
 	int id = -1;
-	struct omap_device *od;
+	struct platform_device *pdev;
 	struct omap_hwmod *oh;
 	char *oh_name = "wd_timer2";
 	char *dev_name = "omap_wdt";
@@ -722,10 +722,10 @@ static int __init omap_init_wdt(void)
 		return -EINVAL;
 	}
 
-	od = omap_device_build(dev_name, id, oh, NULL, 0,
+	pdev = omap_device_build(dev_name, id, oh, NULL, 0,
 				omap_wdt_latency,
 				ARRAY_SIZE(omap_wdt_latency), 0);
-	WARN(IS_ERR(od), "Can't build omap_device for %s:%s.\n",
+	WARN(IS_ERR(pdev), "Can't build omap_device for %s:%s.\n",
 				dev_name, oh->name);
 	return 0;
 }
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 543fcb8..225347d 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -91,7 +91,7 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
 {
 	int r = 0;
 	struct omap_hwmod *oh;
-	struct omap_device *od;
+	struct platform_device *pdev;
 	int i, oh_count;
 	struct omap_display_platform_data pdata;
 	const struct omap_dss_hwmod_data *curr_dss_hwmod;
@@ -128,13 +128,13 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
 			return -ENODEV;
 		}
 
-		od = omap_device_build(curr_dss_hwmod[i].dev_name,
+		pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
 				curr_dss_hwmod[i].id, oh, &pdata,
 				sizeof(struct omap_display_platform_data),
 				omap_dss_latency,
 				ARRAY_SIZE(omap_dss_latency), 0);
 
-		if (WARN((IS_ERR(od)), "Could not build omap_device for %s\n",
+		if (WARN((IS_ERR(pdev)), "Could not build omap_device for %s\n",
 				curr_dss_hwmod[i].oh_name))
 			return -ENODEV;
 	}
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index c9ff0e7..ae8cb3f 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -228,7 +228,7 @@ static u32 configure_dma_errata(void)
 /* One time initializations */
 static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void *unused)
 {
-	struct omap_device			*od;
+	struct platform_device			*pdev;
 	struct omap_system_dma_plat_info	*p;
 	struct resource				*mem;
 	char					*name = "omap_dma_system";
@@ -258,23 +258,23 @@ static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void *unused)
 
 	p->errata		= configure_dma_errata();
 
-	od = omap_device_build(name, 0, oh, p, sizeof(*p),
+	pdev = omap_device_build(name, 0, oh, p, sizeof(*p),
 			omap2_dma_latency, ARRAY_SIZE(omap2_dma_latency), 0);
 	kfree(p);
-	if (IS_ERR(od)) {
+	if (IS_ERR(pdev)) {
 		pr_err("%s: Can't build omap_device for %s:%s.\n",
 			__func__, name, oh->name);
-		return PTR_ERR(od);
+		return PTR_ERR(pdev);
 	}
 
-	mem = platform_get_resource(&od->pdev, IORESOURCE_MEM, 0);
+	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (!mem) {
-		dev_err(&od->pdev.dev, "%s: no mem resource\n", __func__);
+		dev_err(&pdev->dev, "%s: no mem resource\n", __func__);
 		return -EINVAL;
 	}
 	dma_base = ioremap(mem->start, resource_size(mem));
 	if (!dma_base) {
-		dev_err(&od->pdev.dev, "%s: ioremap fail\n", __func__);
+		dev_err(&pdev->dev, "%s: ioremap fail\n", __func__);
 		return -ENOMEM;
 	}
 
@@ -283,7 +283,7 @@ static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void *unused)
 					(d->lch_count), GFP_KERNEL);
 
 	if (!d->chan) {
-		dev_err(&od->pdev.dev, "%s: kzalloc fail\n", __func__);
+		dev_err(&pdev->dev, "%s: kzalloc fail\n", __func__);
 		return -ENOMEM;
 	}
 	return 0;
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 9529842..b3aaafb 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -34,7 +34,7 @@ static struct omap_device_pm_latency omap_gpio_latency[] = {
 
 static int omap2_gpio_dev_init(struct omap_hwmod *oh, void *unused)
 {
-	struct omap_device *od;
+	struct platform_device *pdev;
 	struct omap_gpio_platform_data *pdata;
 	struct omap_gpio_dev_attr *dev_attr;
 	char *name = "omap_gpio";
@@ -75,16 +75,16 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void *unused)
 		return -EINVAL;
 	}
 
-	od = omap_device_build(name, id - 1, oh, pdata,
+	pdev = omap_device_build(name, id - 1, oh, pdata,
 				sizeof(*pdata),	omap_gpio_latency,
 				ARRAY_SIZE(omap_gpio_latency),
 				false);
 	kfree(pdata);
 
-	if (IS_ERR(od)) {
+	if (IS_ERR(pdev)) {
 		WARN(1, "Can't build omap_device for %s:%s.\n",
 					name, oh->name);
-		return PTR_ERR(od);
+		return PTR_ERR(pdev);
 	}
 
 	gpio_bank_count++;
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 66868c5..a7305cf 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -431,7 +431,7 @@ static struct omap_device_pm_latency omap_hsmmc_latency[] = {
 void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
 {
 	struct omap_hwmod *oh;
-	struct omap_device *od;
+	struct platform_device *pdev;
 	struct omap_device_pm_latency *ohl;
 	char oh_name[MAX_OMAP_MMC_HWMOD_NAME_LEN];
 	struct omap_mmc_platform_data *mmc_data;
@@ -472,9 +472,9 @@ void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
 		mmc_data->controller_flags = mmc_dev_attr->flags;
 	}
 
-	od = omap_device_build(name, ctrl_nr - 1, oh, mmc_data,
+	pdev = omap_device_build(name, ctrl_nr - 1, oh, mmc_data,
 		sizeof(struct omap_mmc_platform_data), ohl, ohl_cnt, false);
-	if (IS_ERR(od)) {
+	if (IS_ERR(pdev)) {
 		WARN(1, "Can't build omap_device for %s:%s.\n", name, oh->name);
 		kfree(mmc_data->slots[0].name);
 		goto done;
@@ -483,7 +483,7 @@ void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
 	 * return device handle to board setup code
 	 * required to populate for regulator framework structure
 	 */
-	hsmmcinfo->dev = &od->pdev.dev;
+	hsmmcinfo->dev = &pdev->dev;
 
 done:
 	kfree(mmc_data);
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
index 06d4a80..0b3ae9d 100644
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ b/arch/arm/mach-omap2/hwspinlock.c
@@ -35,7 +35,7 @@ int __init hwspinlocks_init(void)
 {
 	int retval = 0;
 	struct omap_hwmod *oh;
-	struct omap_device *od;
+	struct platform_device *pdev;
 	const char *oh_name = "spinlock";
 	const char *dev_name = "omap_hwspinlock";
 
@@ -48,13 +48,13 @@ int __init hwspinlocks_init(void)
 	if (oh == NULL)
 		return -EINVAL;
 
-	od = omap_device_build(dev_name, 0, oh, NULL, 0,
+	pdev = omap_device_build(dev_name, 0, oh, NULL, 0,
 				omap_spinlock_latency,
 				ARRAY_SIZE(omap_spinlock_latency), false);
-	if (IS_ERR(od)) {
+	if (IS_ERR(pdev)) {
 		pr_err("Can't build omap_device for %s:%s\n", dev_name,
 								oh_name);
-		retval = PTR_ERR(od);
+		retval = PTR_ERR(pdev);
 	}
 
 	return retval;
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 4a6ef6a..7a42f32 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -116,7 +116,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
 	char *name = "omap-mcbsp";
 	struct omap_hwmod *oh_device[2];
 	struct omap_mcbsp_platform_data *pdata = NULL;
-	struct omap_device *od;
+	struct platform_device *pdev;
 
 	sscanf(oh->name, "mcbsp%d", &id);
 
@@ -144,14 +144,14 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
 		(struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
 		count++;
 	}
-	od = omap_device_build_ss(name, id, oh_device, count, pdata,
+	pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
 				sizeof(*pdata), omap2_mcbsp_latency,
 				ARRAY_SIZE(omap2_mcbsp_latency), false);
 	kfree(pdata);
-	if (IS_ERR(od))  {
+	if (IS_ERR(pdev))  {
 		pr_err("%s: Can't build omap_device for %s:%s.\n", __func__,
 					name, oh->name);
-		return PTR_ERR(od);
+		return PTR_ERR(pdev);
 	}
 	omap_mcbsp_count++;
 	return 0;
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 49486f5..a6f0f0e 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -60,19 +60,19 @@ EXPORT_SYMBOL(omap4_get_dsp_device);
 static int _init_omap_device(char *name, struct device **new_dev)
 {
 	struct omap_hwmod *oh;
-	struct omap_device *od;
+	struct platform_device *pdev;
 
 	oh = omap_hwmod_lookup(name);
 	if (WARN(!oh, "%s: could not find omap_hwmod for %s\n",
 		 __func__, name))
 		return -ENODEV;
 
-	od = omap_device_build(oh->name, 0, oh, NULL, 0, pm_lats, 0, false);
-	if (WARN(IS_ERR(od), "%s: could not build omap_device for %s\n",
+	pdev = omap_device_build(oh->name, 0, oh, NULL, 0, pm_lats, 0, false);
+	if (WARN(IS_ERR(pdev), "%s: could not build omap_device for %s\n",
 		 __func__, name))
 		return -ENODEV;
 
-	*new_dev = &od->pdev.dev;
+	*new_dev = &pdev->dev;
 
 	return 0;
 }
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 1ac361b..3781bcb 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -711,7 +711,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)
 {
 	struct omap_uart_state *uart;
 	struct omap_hwmod *oh;
-	struct omap_device *od;
+	struct platform_device *pdev;
 	void *pdata = NULL;
 	u32 pdata_size = 0;
 	char *name;
@@ -799,10 +799,10 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)
 	if (WARN_ON(!oh))
 		return;
 
-	od = omap_device_build(name, uart->num, oh, pdata, pdata_size,
+	pdev = omap_device_build(name, uart->num, oh, pdata, pdata_size,
 			       omap_uart_latency,
 			       ARRAY_SIZE(omap_uart_latency), false);
-	WARN(IS_ERR(od), "Could not build omap_device for %s: %s.\n",
+	WARN(IS_ERR(pdev), "Could not build omap_device for %s: %s.\n",
 	     name, oh->name);
 
 	oh->mux = omap_hwmod_mux_init(bdata->pads, bdata->pads_cnt);
@@ -811,7 +811,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)
 	uart->regshift = 2;
 	uart->mapbase = oh->slaves[0]->addr->pa_start;
 	uart->membase = omap_hwmod_get_mpu_rt_va(oh);
-	uart->pdev = &od->pdev;
+	uart->pdev = pdev;
 
 	oh->dev_attr = uart;
 
@@ -845,8 +845,8 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)
 
 	if ((cpu_is_omap34xx() && uart->padconf) ||
 	    (uart->wk_en && uart->wk_mask)) {
-		device_init_wakeup(&od->pdev.dev, true);
-		DEV_CREATE_FILE(&od->pdev.dev, &dev_attr_sleep_timeout);
+		device_init_wakeup(&pdev->dev, true);
+		DEV_CREATE_FILE(&pdev->dev, &dev_attr_sleep_timeout);
 	}
 
 	/* Enable the MDR1 errata for OMAP3 */
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 3341ca4..0c7caf2 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -135,7 +135,7 @@ static inline int omap2_i2c_add_bus(int bus_id)
 {
 	int l;
 	struct omap_hwmod *oh;
-	struct omap_device *od;
+	struct platform_device *pdev;
 	char oh_name[MAX_OMAP_I2C_HWMOD_NAME_LEN];
 	struct omap_i2c_bus_platform_data *pdata;
 
@@ -160,12 +160,12 @@ static inline int omap2_i2c_add_bus(int bus_id)
 	 */
 	if (cpu_is_omap34xx())
 		pdata->set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
-	od = omap_device_build(name, bus_id, oh, pdata,
+	pdev = omap_device_build(name, bus_id, oh, pdata,
 			sizeof(struct omap_i2c_bus_platform_data),
 			omap_i2c_latency, ARRAY_SIZE(omap_i2c_latency), 0);
-	WARN(IS_ERR(od), "Could not build omap_device for %s\n", name);
+	WARN(IS_ERR(pdev), "Could not build omap_device for %s\n", name);
 
-	return PTR_ERR(od);
+	return PTR_ERR(pdev);
 }
 #else
 static inline int omap2_i2c_add_bus(int bus_id)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
index 0a53a0a..7a3ec4f 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -83,13 +83,13 @@ int omap_device_shutdown(struct platform_device *pdev);
 
 /* Core code interface */
 
-struct omap_device *omap_device_build(const char *pdev_name, int pdev_id,
+struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
 				      struct omap_hwmod *oh, void *pdata,
 				      int pdata_len,
 				      struct omap_device_pm_latency *pm_lats,
 				      int pm_lats_cnt, int is_early_device);
 
-struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
+struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 					 struct omap_hwmod **oh, int oh_cnt,
 					 void *pdata, int pdata_len,
 					 struct omap_device_pm_latency *pm_lats,
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 4737b60..7d5e76b 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -391,7 +391,7 @@ static int omap_device_fill_resources(struct omap_device *od,
  * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
  * passes along the return value of omap_device_build_ss().
  */
-struct omap_device *omap_device_build(const char *pdev_name, int pdev_id,
+struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
 				      struct omap_hwmod *oh, void *pdata,
 				      int pdata_len,
 				      struct omap_device_pm_latency *pm_lats,
@@ -424,7 +424,7 @@ struct omap_device *omap_device_build(const char *pdev_name, int pdev_id,
  * platform_device record.  Returns an ERR_PTR() on error, or passes
  * along the return value of omap_device_register().
  */
-struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
+struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 					 struct omap_hwmod **ohs, int oh_cnt,
 					 void *pdata, int pdata_len,
 					 struct omap_device_pm_latency *pm_lats,
@@ -499,7 +499,7 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 	if (ret)
 		goto odbs_exit4;
 
-	return od;
+	return &od->pdev;
 
 odbs_exit4:
 	kfree(res);
-- 
1.7.1

[RFC/PATCH 07/14] ARM: platform_device: pdev_archdata: add omap_device pointer

[G, Manjunath Kondaiah]

From: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>

Add omap_device pointer to the ARM-specific arch data in the
platform_device.  This will be used to attach OMAP-specific
device-data to the platform device with device lifetime.

Suggested-by: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Signed-off-by: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>
---
 arch/arm/include/asm/device.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index 9f390ce..b5c9f5b 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -12,7 +12,12 @@ struct dev_archdata {
 #endif
 };
 
+struct omap_device;
+
 struct pdev_archdata {
+#ifdef CONFIG_ARCH_OMAP
+	struct omap_device *od;
+#endif
 };
 
 #endif
-- 
1.7.1

[RFC/PATCH 08/14] omap2+: Use Kconfig symbol in Makefile instead of obj-y

[G, Manjunath Kondaiah]

From: Tony Lindgren <tony@atomide.com>

As noted by Grant Likely <grant.likely@secretlab.ca>, omap2+ Makefile unnecessarily
repeats entries for common device init code instead of using Kconfig symbol.

Remove references to hsmmc.o and board-flash.o. Also omap_phy_internal.o
references can be removed once it has some Kconfig symbol to use.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/Makefile |   76 +++++++++++++++++------------------------
 1 files changed, 32 insertions(+), 44 deletions(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b148077..39e3f61 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -175,78 +175,66 @@ endif
 # Specific board support
 obj-$(CONFIG_MACH_OMAP_GENERIC)		+= board-generic.o
 obj-$(CONFIG_MACH_OMAP_H4)		+= board-h4.o
-obj-$(CONFIG_MACH_OMAP_2430SDP)		+= board-2430sdp.o \
-					   hsmmc.o
+obj-$(CONFIG_MACH_OMAP_2430SDP)		+= board-2430sdp.o
 obj-$(CONFIG_MACH_OMAP_APOLLON)		+= board-apollon.o
-obj-$(CONFIG_MACH_OMAP3_BEAGLE)		+= board-omap3beagle.o \
-					   hsmmc.o
-obj-$(CONFIG_MACH_DEVKIT8000)     	+= board-devkit8000.o \
-                                           hsmmc.o
-obj-$(CONFIG_MACH_OMAP_LDP)		+= board-ldp.o \
-					   board-flash.o \
-					   hsmmc.o
-obj-$(CONFIG_MACH_OMAP3530_LV_SOM)      += board-omap3logic.o \
-					   hsmmc.o
-obj-$(CONFIG_MACH_OMAP3_TORPEDO)        += board-omap3logic.o \
-					   hsmmc.o
-obj-$(CONFIG_MACH_OVERO)		+= board-overo.o \
-					   hsmmc.o
-obj-$(CONFIG_MACH_OMAP3EVM)		+= board-omap3evm.o \
-					   hsmmc.o
-obj-$(CONFIG_MACH_OMAP3_PANDORA)	+= board-omap3pandora.o \
-					   hsmmc.o
-obj-$(CONFIG_MACH_OMAP_3430SDP)		+= board-3430sdp.o \
-					   hsmmc.o \
-					   board-flash.o
+obj-$(CONFIG_MACH_OMAP3_BEAGLE)		+= board-omap3beagle.o
+obj-$(CONFIG_MACH_DEVKIT8000)     	+= board-devkit8000.o
+obj-$(CONFIG_MACH_OMAP_LDP)		+= board-ldp.o
+obj-$(CONFIG_MACH_OMAP3530_LV_SOM)      += board-omap3logic.o
+obj-$(CONFIG_MACH_OMAP3_TORPEDO)        += board-omap3logic.o
+obj-$(CONFIG_MACH_ENCORE)		+= board-omap3encore.o
+obj-$(CONFIG_MACH_OVERO)		+= board-overo.o
+obj-$(CONFIG_MACH_OMAP3EVM)		+= board-omap3evm.o
+obj-$(CONFIG_MACH_OMAP3_PANDORA)	+= board-omap3pandora.o
+obj-$(CONFIG_MACH_OMAP_3430SDP)		+= board-3430sdp.o
 obj-$(CONFIG_MACH_NOKIA_N8X0)		+= board-n8x0.o
 obj-$(CONFIG_MACH_NOKIA_RM680)		+= board-rm680.o \
-					   sdram-nokia.o \
-					   hsmmc.o
+					   sdram-nokia.o
 obj-$(CONFIG_MACH_NOKIA_RX51)		+= board-rx51.o \
 					   sdram-nokia.o \
 					   board-rx51-peripherals.o \
-					   board-rx51-video.o \
-					   hsmmc.o
+					   board-rx51-video.o
 obj-$(CONFIG_MACH_OMAP_ZOOM2)		+= board-zoom.o \
 					   board-zoom-peripherals.o \
 					   board-zoom-display.o \
-					   board-flash.o \
-					   hsmmc.o \
 					   board-zoom-debugboard.o
 obj-$(CONFIG_MACH_OMAP_ZOOM3)		+= board-zoom.o \
 					   board-zoom-peripherals.o \
 					   board-zoom-display.o \
-					   board-flash.o \
-					   hsmmc.o \
 					   board-zoom-debugboard.o
 obj-$(CONFIG_MACH_OMAP_3630SDP)		+= board-3630sdp.o \
 					   board-zoom-peripherals.o \
-					   board-zoom-display.o \
-					   board-flash.o \
-					   hsmmc.o
-obj-$(CONFIG_MACH_CM_T35)		+= board-cm-t35.o \
-					   hsmmc.o
+					   board-zoom-display.o
+obj-$(CONFIG_MACH_CM_T35)		+= board-cm-t35.o
 obj-$(CONFIG_MACH_CM_T3517)		+= board-cm-t3517.o
-obj-$(CONFIG_MACH_IGEP0020)		+= board-igep0020.o \
-					   hsmmc.o
-obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK)	+= board-omap3touchbook.o \
-					   hsmmc.o
+obj-$(CONFIG_MACH_IGEP0020)		+= board-igep0020.o
+obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK)	+= board-omap3touchbook.o
 obj-$(CONFIG_MACH_OMAP_4430SDP)		+= board-4430sdp.o \
-					   hsmmc.o \
 					   omap_phy_internal.o
 obj-$(CONFIG_MACH_OMAP4_PANDA)		+= board-omap4panda.o \
-					   hsmmc.o \
+					   omap_phy_internal.o
+
+obj-$(CONFIG_MACH_PCM049)		+= board-omap4pcm049.o \
 					   omap_phy_internal.o
 
 obj-$(CONFIG_MACH_OMAP3517EVM)		+= board-am3517evm.o \
-					   omap_phy_internal.o \
+					   omap_phy_internal.o
 
 obj-$(CONFIG_MACH_CRANEBOARD)		+= board-am3517crane.o
 
-obj-$(CONFIG_MACH_SBC3530)		+= board-omap3stalker.o \
-					   hsmmc.o
+obj-$(CONFIG_MACH_SBC3530)		+= board-omap3stalker.o
 obj-$(CONFIG_MACH_TI8168EVM)		+= board-ti8168evm.o
+
 # Platform specific device init code
+
+omap-flash-$(CONFIG_MTD_NAND_OMAP2)	:= board-flash.o
+omap-flash-$(CONFIG_MTD_ONENAND_OMAP2)	:= board-flash.o
+obj-y					+= $(omap-flash-y) $(omap-flash-m)
+
+omap-hsmmc-$(CONFIG_MMC_OMAP_HS)	:= hsmmc.o
+obj-y					+= $(omap-hsmmc-m) $(omap-hsmmc-y)
+
+
 usbfs-$(CONFIG_ARCH_OMAP_OTG)		:= usb-fs.o
 obj-y					+= $(usbfs-m) $(usbfs-y)
 obj-y					+= usb-musb.o
-- 
1.7.1

[RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt

[G, Manjunath Kondaiah]

The omap dt requires new omap hwmod api to be added for in order
to support omap dt.

The new api is added and new parameter "np" is added for existing
api. The users of hwmod api is changed accrodingly.

Build and boot tested on omap3 beagle for both dt and not dt build.

Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
---
 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              |   53 ++++++++++++++++++++++---
 4 files changed, 59 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 458f7be..d7ff1ae 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)
 			pr_err("could not look up %s\n", oh_name);
 	}
 
-	pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
+	pdev = omap_device_build_ss(NULL, "omap_l3_noc", 0, oh, 3, NULL,
 						     0, NULL, 0, 0);
 
 	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 7a42f32..98eb95d 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
 		(struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
 		count++;
 	}
-	pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
+	pdev = omap_device_build_ss(NULL, name, id, oh_device, count, pdata,
 				sizeof(*pdata), omap2_mcbsp_latency,
 				ARRAY_SIZE(omap2_mcbsp_latency), false);
 	kfree(pdata);
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
index 7a3ec4f..5e2424b 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -33,6 +33,7 @@
 
 #include <linux/kernel.h>
 #include <linux/platform_device.h>
+#include <linux/of.h>
 
 #include <plat/omap_hwmod.h>
 
@@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
 				      struct omap_device_pm_latency *pm_lats,
 				      int pm_lats_cnt, int is_early_device);
 
-struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
+struct platform_device *omap_device_build_ss(struct device_node *np,
+					 const char *pdev_name, int pdev_id,
 					 struct omap_hwmod **oh, int oh_cnt,
 					 void *pdata, int pdata_len,
 					 struct omap_device_pm_latency *pm_lats,
 					 int pm_lats_cnt, int is_early_device);
 
+struct platform_device *omap_device_build_dt(struct device_node *np,
+				      const char *pdev_name, int pdev_id,
+				      struct omap_hwmod *oh, void *pdata,
+				      int pdata_len,
+				      struct omap_device_pm_latency *pm_lats,
+				      int pm_lats_cnt, int is_early_device);
+
 void __iomem *omap_device_get_rt_va(struct omap_device *od);
 
 /* OMAP PM interface */
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 7d5e76b..fa49168 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -85,6 +85,7 @@
 #include <linux/clk.h>
 #include <linux/clkdev.h>
 #include <linux/pm_runtime.h>
+#include <linux/of_device.h>
 
 #include <plat/omap_device.h>
 #include <plat/omap_hwmod.h>
@@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device *od,
 /**
  * omap_device_build - build and register an omap_device with one omap_hwmod
  * @pdev_name: name of the platform_device driver to use
+ * @np: device node pointer for attaching it to of_node pointer
  * @pdev_id: this platform_device's connection ID
  * @oh: ptr to the single omap_hwmod that backs this omap_device
  * @pdata: platform_data ptr to associate with the platform_device
@@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device *od,
  * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
  * passes along the return value of omap_device_build_ss().
  */
-struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
+struct platform_device *omap_device_build_dt(struct device_node *np,
+				      const char *pdev_name, int pdev_id,
 				      struct omap_hwmod *oh, void *pdata,
 				      int pdata_len,
 				      struct omap_device_pm_latency *pm_lats,
@@ -402,12 +405,44 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
 	if (!oh)
 		return ERR_PTR(-EINVAL);
 
-	return omap_device_build_ss(pdev_name, pdev_id, ohs, 1, pdata,
+	return omap_device_build_ss(np, pdev_name, pdev_id, ohs, 1, pdata,
 				    pdata_len, pm_lats, pm_lats_cnt,
 				    is_early_device);
 }
 
 /**
+ * omap_device_build - build and register an omap_device with one omap_hwmod
+ * @pdev_name: name of the platform_device driver to use
+ * @pdev_id: this platform_device's connection ID
+ * @oh: ptr to the single omap_hwmod that backs this omap_device
+ * @pdata: platform_data ptr to associate with the platform_device
+ * @pdata_len: amount of memory pointed to by @pdata
+ * @pm_lats: pointer to a omap_device_pm_latency array for this device
+ * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
+ * @is_early_device: should the device be registered as an early device or not
+ *
+ * Convenience function for building and registering a single
+ * omap_device record, which in turn builds and registers a
+ * platform_device record.  See omap_device_build_ss() for more
+ * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
+ * passes along the return value of omap_device_build_ss().
+ */
+struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
+				      struct omap_hwmod *oh, void *pdata,
+				      int pdata_len,
+				      struct omap_device_pm_latency *pm_lats,
+				      int pm_lats_cnt, int is_early_device)
+{
+	struct omap_hwmod *ohs[] = { oh };
+
+	if (!oh)
+		return ERR_PTR(-EINVAL);
+
+	return omap_device_build_ss(NULL, pdev_name, pdev_id, ohs, 1, pdata,
+			pdata_len, pm_lats, pm_lats_cnt, is_early_device);
+}
+
+/**
  * omap_device_build_ss - build and register an omap_device with multiple hwmods
  * @pdev_name: name of the platform_device driver to use
  * @pdev_id: this platform_device's connection ID
@@ -424,7 +459,8 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
  * platform_device record.  Returns an ERR_PTR() on error, or passes
  * along the return value of omap_device_register().
  */
-struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
+struct platform_device *omap_device_build_ss(struct device_node *np,
+					 const char *pdev_name, int pdev_id,
 					 struct omap_hwmod **ohs, int oh_cnt,
 					 void *pdata, int pdata_len,
 					 struct omap_device_pm_latency *pm_lats,
@@ -436,6 +472,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 	struct resource *res = NULL;
 	int i, res_count;
 	struct omap_hwmod **hwmods;
+	struct platform_device *pdev;
 
 	if (!ohs || oh_cnt == 0 || !pdev_name)
 		return ERR_PTR(-EINVAL);
@@ -450,6 +487,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 	if (!od)
 		return ERR_PTR(-ENOMEM);
 
+	pdev = &od->pdev;
 	od->hwmods_cnt = oh_cnt;
 
 	hwmods = kzalloc(sizeof(struct omap_hwmod *) * oh_cnt,
@@ -465,8 +503,11 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 		goto odbs_exit2;
 	strcpy(pdev_name2, pdev_name);
 
-	od->pdev.name = pdev_name2;
-	od->pdev.id = pdev_id;
+#ifdef CONFIG_OF_DEVICE
+	pdev->dev.of_node = of_node_get(np);
+#endif
+	pdev->name = pdev_name2;
+	pdev->id = pdev_id;
 
 	res_count = omap_device_count_resources(od);
 	if (res_count > 0) {
@@ -499,7 +540,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 	if (ret)
 		goto odbs_exit4;
 
-	return &od->pdev;
+	return pdev;
 
 odbs_exit4:
 	kfree(res);
-- 
1.7.1

[RFC/PATCH 10/14] dt: Add pd_size to AUXDATA structure

[G, Manjunath Kondaiah]

Add pd_size in the AUXDATA structure so that device drivers which require
platform_data size can pass along with AUXDATA.

Signed-off-by: G, Manjunath Kondaiah <manjugk-l0cyMroinI0@public.gmane.org>
---
 drivers/of/platform.c       |    2 ++
 include/linux/of_platform.h |    5 +++++
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index ebbbf42..4b27286 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -565,6 +565,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 id = -1;
 	int rc = 0;
 
@@ -588,6 +589,7 @@ static int of_platform_bus_create(struct device_node *bus,
 		bus_id = auxdata->name;
 		id = auxdata->id;
 		platform_data = auxdata->platform_data;
+		pd_size = auxdata->pd_size;
 	}
 
 	if (of_device_is_compatible(bus, "arm,primecell")) {
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 252246c..a3be980 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -47,6 +47,7 @@ struct of_dev_auxdata {
 	char *name;
 	int id;
 	void *platform_data;
+	int pd_size;
 };
 
 /* Macro to simplify populating a lookup table */
@@ -58,6 +59,10 @@ struct of_dev_auxdata {
 	{ .compatible = _compat, .phys_addr = _phys, .name = _name, \
 	  .id = _id, .platform_data = _pdata }
 
+#define OF_DEV_AUXDATA_ID_PDSIZE(_compat,_phys,_name,_id,_pdata,_pd_size) \
+	{ .compatible = _compat, .phys_addr = _phys, .name = _name, \
+	  .id = _id, .platform_data = _pdata, .pd_size = _pd_size }
+
 /**
  * of_platform_driver - Legacy of-aware driver for platform devices.
  *
-- 
1.7.1

[RFC/PATCH 11/14] dt: omap3: add soc file for handling i2c controllers

[G, Manjunath Kondaiah]

Add omap3 soc file for handling omap3 soc i2c controllers existing
on l4-core bus.

Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
---
 arch/arm/boot/dts/omap3-soc.dtsi |   62 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 62 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi

diff --git a/arch/arm/boot/dts/omap3-soc.dtsi b/arch/arm/boot/dts/omap3-soc.dtsi
new file mode 100644
index 0000000..85de92f
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-soc.dtsi
@@ -0,0 +1,62 @@
+/*
+ * Device Tree Source for OMAP3 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/;
+/include/ "skeleton.dtsi"
+
+/ {
+	#address-cells = <1>;
+	#size-cells = <1>;
+	model = "ti,omap3";
+
+	aliases {
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+	};
+
+	l4-core {
+		compatible = "ti,omap3-l4-core";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0x48000000 0x1000000>;
+
+		i2c1: i2c@70000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "ti,omap3-i2c";
+			reg = <0x70000 0x100>;
+			interrupts = < 88 >;
+		};
+
+		i2c2: i2c@72000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "ti,omap3-i2c";
+			reg = <0x72000 0x100>;
+			interrupts = < 89 >;
+		};
+
+		i2c3: i2c@60000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "ti,omap3-i2c";
+			reg = <0x60000 0x100>;
+			interrupts = < 93 >;
+		};
+	};
+
+	l4-per {
+		compatible = "ti,l4-per";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0x49000000 0x100000>;
+	};
+};
-- 
1.7.1

[RFC/PATCH 12/14] dt: omap3: beagle board: set clock freq for i2c devices

[G, Manjunath Kondaiah]

Update omap3 beagle dts file with required clock frequencies for the i2c
client devices existing on beagle board.

Beagle custom board dts file is cleaned up so that it can coexist with omap3
soc dts file.

Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
---
 arch/arm/boot/dts/omap3-beagle-nunchuck.dts |   11 +----------
 arch/arm/boot/dts/omap3-beagle.dts          |   18 +++++++++++++++---
 2 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
index 2607be5..324ff86 100644
--- a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
+++ b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
@@ -1,16 +1,7 @@
 /include/ "omap3-beagle.dts"
 
 / {
-	i2c@48072000 {
-		compatible = "ti,omap3-i2c";
-		reg = <0x48072000 0x80>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		eeprom@50 {
-			compatible = "at,at24c01";
-			reg = < 0x50 >;
-		};
+	i2c@2 {
 		joystick@52 {
 			compatible = "sparkfun,wiichuck";
 			reg = < 0x52 >;
diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index 4439466..49a5ac7 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -1,7 +1,19 @@
-/dts-v1/;
-/include/ "skeleton.dtsi"
+/include/ "omap3-soc.dtsi"
 
 / {
 	model = "TI OMAP3 BeagleBoard";
-	compatible = "ti,omap3-beagle";
+	compatible = "ti,omap3-beagle", "ti,omap3";
+
+
+	i2c1 {
+		clock-frequency = <2600000>;
+	};
+
+	i2c2 {
+		clock-frequency = <400000>;
+	};
+
+	i2c3 {
+		clock-frequency = <400000>;
+	};
 };
-- 
1.7.1

[RFC/PATCH 13/14] dt: omap3: add generic board file for dt support

[G, Manjunath Kondaiah]

The generic board file is created and derived from beagle board file.
The beagle board file is migrated to boot from flattened device tree and
the cleanup of board specific file will happen in different stages.

The changes here focus on minimal configuration to boot beagle board with
dt enabled which provides basic platform for converting device drivers for
using dt.

Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
---
 arch/arm/mach-omap2/Kconfig             |   11 ++++
 arch/arm/mach-omap2/Makefile            |    1 +
 arch/arm/mach-omap2/board-omap3-dt.c    |   93 +++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/board-omap3beagle.c |   13 ----
 4 files changed, 105 insertions(+), 13 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 19d5891..6e1fe7c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -302,6 +302,17 @@ config MACH_OMAP_3630SDP
 	default y
 	select OMAP_PACKAGE_CBP
 
+config MACH_OMAP3_DT
+	bool "Generic OMAP3 board(FDT support)"
+	depends on ARCH_OMAP3
+	select OMAP_PACKAGE_CBB
+	select USE_OF
+
+	help
+	  Support for generic TI OMAP3 boards using Flattened Device Tree.
+	  Say Y here to enable OMAP3 device tree support
+	  More information at Documentation/devicetree
+
 config MACH_TI8168EVM
 	bool "TI8168 Evaluation Module"
 	depends on SOC_OMAPTI816X
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 39e3f61..0e363f2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -187,6 +187,7 @@ obj-$(CONFIG_MACH_OVERO)		+= board-overo.o
 obj-$(CONFIG_MACH_OMAP3EVM)		+= board-omap3evm.o
 obj-$(CONFIG_MACH_OMAP3_PANDORA)	+= board-omap3pandora.o
 obj-$(CONFIG_MACH_OMAP_3430SDP)		+= board-3430sdp.o
+obj-$(CONFIG_MACH_OMAP3_DT)		+= board-omap3-dt.o
 obj-$(CONFIG_MACH_NOKIA_N8X0)		+= board-n8x0.o
 obj-$(CONFIG_MACH_NOKIA_RM680)		+= board-rm680.o \
 					   sdram-nokia.o
diff --git a/arch/arm/mach-omap2/board-omap3-dt.c b/arch/arm/mach-omap2/board-omap3-dt.c
new file mode 100644
index 0000000..4b76e19
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3-dt.c
@@ -0,0 +1,93 @@
+/*
+ * TI OMAP3 device tree board support
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/platform_device.h>
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+
+#include <linux/regulator/machine.h>
+#include <linux/i2c/twl.h>
+
+#include <asm/mach/arch.h>
+
+#include <plat/common.h>
+#include <plat/omap_device.h>
+
+#include "mux.h"
+#include "timer-gp.h"
+#include "common-board-devices.h"
+#include "hsmmc.h"
+
+#include "sdram-micron-mt46h32m32lf-6.h"
+
+static struct twl4030_platform_data beagle_twldata = {
+	.irq_base	= TWL4030_IRQ_BASE,
+	.irq_end	= TWL4030_IRQ_END,
+
+	/* platform_data for children goes here */
+};
+
+static int __init omap3_beagle_i2c_init(void)
+{
+	omap3_pmic_init("twl4030", &beagle_twldata);
+	return 0;
+}
+
+static void __init omap3_init_early(void)
+{
+	omap2_init_common_infrastructure();
+	omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
+				  mt46h32m32lf6_sdrc_params);
+}
+
+static void __init omap3_init_irq(void)
+{
+	omap_init_irq();
+#ifdef CONFIG_OMAP_32K_TIMER
+	omap2_gp_clockevent_set_gptimer(12);
+#endif
+}
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+	{ .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#endif
+
+static struct of_device_id omap_dt_match_table[] __initdata = {
+	{ .compatible = "ti,omap3-l4-core", },
+	{}
+};
+
+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);
+}
+
+static const char *omap3_dt_match[] __initdata = {
+	"ti,omap3",
+	NULL
+};
+
+DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
+	.reserve	= omap_reserve,
+	.map_io		= omap3_map_io,
+	.init_early	= omap3_init_early,
+	.init_irq	= omap3_init_irq,
+	.init_machine	= omap3_init,
+	.timer		= &omap_timer,
+	.dt_compat	= omap3_dt_match,
+MACHINE_END
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 7905c8d..9ecb65d 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -19,7 +19,6 @@
 #include <linux/err.h>
 #include <linux/clk.h>
 #include <linux/io.h>
-#include <linux/of_platform.h>
 #include <linux/leds.h>
 #include <linux/gpio.h>
 #include <linux/input.h>
@@ -422,9 +421,7 @@ static int __init omap3_beagle_i2c_init(void)
 	/* Bus 3 is attached to the DVI port where devices like the pico DLP
 	 * projector don't work reliably with 400kHz */
 	omap_register_i2c_bus(3, 100, beagle_i2c_eeprom, ARRAY_SIZE(beagle_i2c_eeprom));
-#ifdef CONFIG_OF
 	omap_register_i2c_bus(2, 100, NULL, 0);
-#endif /* CONFIG_OF */
 	return 0;
 }
 
@@ -564,10 +561,6 @@ static void __init beagle_opp_init(void)
 
 static void __init omap3_beagle_init(void)
 {
-#ifdef CONFIG_OF
-	of_platform_prepare(NULL, NULL);
-#endif /* CONFIG_OF */
-
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 	omap3_beagle_init_rev();
 	omap3_beagle_i2c_init();
@@ -596,11 +589,6 @@ static void __init omap3_beagle_init(void)
 	beagle_opp_init();
 }
 
-static const char *omap3_beagle_dt_match[] __initdata = {
-	"ti,omap3-beagle",
-	NULL
-};
-
 MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
 	/* Maintainer: Syed Mohammed Khasim - http://beagleboard.org */
 	.boot_params	= 0x80000100,
@@ -610,5 +598,4 @@ MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
 	.init_irq	= omap3_beagle_init_irq,
 	.init_machine	= omap3_beagle_init,
 	.timer		= &omap_timer,
-	.dt_compat	= omap3_beagle_dt_match,
 MACHINE_END
-- 
1.7.1

[RFC/PATCH 14/14] dt: omap3: enable dt support for i2c1 controller

[G, Manjunath Kondaiah]

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-l0cyMroinI0@public.gmane.org>
---
 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 +++++++++++++++++++++++++++++++++-
 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";
 			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", },
+	{},
+}
+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);
+	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);
+}
+
 /**
  * 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,omap3-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.1

Re: [RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support

[Rajendra Nayak]

On 8/9/2011 7:40 PM, G, Manjunath Kondaiah wrote:
>
> This is in continuation of patch series posted at:
> http://lwn.net/Articles/451917/
>
> Patches from Kevin Hilman and others are consolidated along with this
> series since it will be part of ongoing work of decoupling pdev from
> omap_device.
> [There is latest version posted which will be rebased later]
>
> Apart from the above, the major feature included in this series is
> dt-hwmod binding and preparing omap hwmod framework for adapting omap
> drivers to support omap dt after aligning with Grant Likely
> <grant.likely@secretlab.ca>
>
> However, current hwmod-dt binding will be replaced with notifiers in
> generic board file and hwmod device pointer will be scanned and attached
> in notifier call.
>
> Used 3.0 stable kernel version for this patch series since latest mainline
> was broken for beagle boot last week.
>
> git://git.secretlab.ca/git/linux-2.6.git
> Branch: devicetree/test-3.0

Is there a reason why these are based on devicetree/test-3.0 and
not devicetree/test?

>
> G, Manjunath Kondaiah (6):
>    dt: omap: prepare hwmod to support dt
>    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: enable dt support for i2c1 controller
>
> Kevin Hilman (7):
>    OMAP: omap_device: replace _find_by_pdev() with to_omap_device()
>    OMAP: omap_device: replace debug/warning/error prints with dev_*
>      macros
>    OMAP3: beagle: don't touch omap_device internals
>    OMAP: McBSP: use existing macros for converting between devices
>    OMAP: omap_device: remove internal functions from omap_device.h
>    OMAP: omap_device: when building return platform_device instead of
>      omap_device
>    ARM: platform_device: pdev_archdata: add omap_device pointer
>
> Tony Lindgren (1):
>    omap2+: Use Kconfig symbol in Makefile instead of obj-y
>
>   arch/arm/boot/dts/omap3-beagle-nunchuck.dts   |   11 +--
>   arch/arm/boot/dts/omap3-beagle.dts            |   18 +++-
>   arch/arm/boot/dts/omap3-soc.dtsi              |   62 ++++++++++
>   arch/arm/include/asm/device.h                 |    5 +
>   arch/arm/mach-omap2/Kconfig                   |   11 ++
>   arch/arm/mach-omap2/Makefile                  |   77 ++++++-------
>   arch/arm/mach-omap2/board-omap3-dt.c          |   93 +++++++++++++++
>   arch/arm/mach-omap2/board-omap3beagle.c       |   40 ++-----
>   arch/arm/mach-omap2/devices.c                 |   44 ++++----
>   arch/arm/mach-omap2/display.c                 |    6 +-
>   arch/arm/mach-omap2/dma.c                     |   16 ++--
>   arch/arm/mach-omap2/gpio.c                    |    8 +-
>   arch/arm/mach-omap2/hsmmc.c                   |    8 +-
>   arch/arm/mach-omap2/hwspinlock.c              |    8 +-
>   arch/arm/mach-omap2/mcbsp.c                   |    8 +-
>   arch/arm/mach-omap2/pm.c                      |    8 +-
>   arch/arm/mach-omap2/serial.c                  |   12 +-
>   arch/arm/plat-omap/i2c.c                      |    8 +-
>   arch/arm/plat-omap/include/plat/omap_device.h |   17 ++-
>   arch/arm/plat-omap/mcbsp.c                    |    6 +-
>   arch/arm/plat-omap/omap_device.c              |  150 ++++++++++++++++---------
>   drivers/i2c/busses/i2c-omap.c                 |   23 ++++-
>   drivers/of/platform.c                         |   41 +++++++
>   include/linux/of_platform.h                   |    5 +
>   24 files changed, 469 insertions(+), 216 deletions(-)
>   create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
>   create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

[RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support

[Rajendra Nayak]

On 8/9/2011 7:40 PM, G, Manjunath Kondaiah wrote:
>
> This is in continuation of patch series posted at:
> http://lwn.net/Articles/451917/
>
> Patches from Kevin Hilman and others are consolidated along with this
> series since it will be part of ongoing work of decoupling pdev from
> omap_device.
> [There is latest version posted which will be rebased later]
>
> Apart from the above, the major feature included in this series is
> dt-hwmod binding and preparing omap hwmod framework for adapting omap
> drivers to support omap dt after aligning with Grant Likely
> <grant.likely@secretlab.ca>
>
> However, current hwmod-dt binding will be replaced with notifiers in
> generic board file and hwmod device pointer will be scanned and attached
> in notifier call.
>
> Used 3.0 stable kernel version for this patch series since latest mainline
> was broken for beagle boot last week.
>
> git://git.secretlab.ca/git/linux-2.6.git
> Branch: devicetree/test-3.0

Is there a reason why these are based on devicetree/test-3.0 and
not devicetree/test?

>
> G, Manjunath Kondaiah (6):
>    dt: omap: prepare hwmod to support dt
>    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: enable dt support for i2c1 controller
>
> Kevin Hilman (7):
>    OMAP: omap_device: replace _find_by_pdev() with to_omap_device()
>    OMAP: omap_device: replace debug/warning/error prints with dev_*
>      macros
>    OMAP3: beagle: don't touch omap_device internals
>    OMAP: McBSP: use existing macros for converting between devices
>    OMAP: omap_device: remove internal functions from omap_device.h
>    OMAP: omap_device: when building return platform_device instead of
>      omap_device
>    ARM: platform_device: pdev_archdata: add omap_device pointer
>
> Tony Lindgren (1):
>    omap2+: Use Kconfig symbol in Makefile instead of obj-y
>
>   arch/arm/boot/dts/omap3-beagle-nunchuck.dts   |   11 +--
>   arch/arm/boot/dts/omap3-beagle.dts            |   18 +++-
>   arch/arm/boot/dts/omap3-soc.dtsi              |   62 ++++++++++
>   arch/arm/include/asm/device.h                 |    5 +
>   arch/arm/mach-omap2/Kconfig                   |   11 ++
>   arch/arm/mach-omap2/Makefile                  |   77 ++++++-------
>   arch/arm/mach-omap2/board-omap3-dt.c          |   93 +++++++++++++++
>   arch/arm/mach-omap2/board-omap3beagle.c       |   40 ++-----
>   arch/arm/mach-omap2/devices.c                 |   44 ++++----
>   arch/arm/mach-omap2/display.c                 |    6 +-
>   arch/arm/mach-omap2/dma.c                     |   16 ++--
>   arch/arm/mach-omap2/gpio.c                    |    8 +-
>   arch/arm/mach-omap2/hsmmc.c                   |    8 +-
>   arch/arm/mach-omap2/hwspinlock.c              |    8 +-
>   arch/arm/mach-omap2/mcbsp.c                   |    8 +-
>   arch/arm/mach-omap2/pm.c                      |    8 +-
>   arch/arm/mach-omap2/serial.c                  |   12 +-
>   arch/arm/plat-omap/i2c.c                      |    8 +-
>   arch/arm/plat-omap/include/plat/omap_device.h |   17 ++-
>   arch/arm/plat-omap/mcbsp.c                    |    6 +-
>   arch/arm/plat-omap/omap_device.c              |  150 ++++++++++++++++---------
>   drivers/i2c/busses/i2c-omap.c                 |   23 ++++-
>   drivers/of/platform.c                         |   41 +++++++
>   include/linux/of_platform.h                   |    5 +
>   24 files changed, 469 insertions(+), 216 deletions(-)
>   create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
>   create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 10:56 AM, Rajendra Nayak <rnayak@ti.com> wrote:
> On 8/9/2011 7:40 PM, G, Manjunath Kondaiah wrote:
>>
>> This is in continuation of patch series posted at:
>> http://lwn.net/Articles/451917/
>>
>> Patches from Kevin Hilman and others are consolidated along with this
>> series since it will be part of ongoing work of decoupling pdev from
>> omap_device.
>> [There is latest version posted which will be rebased later]
>>
>> Apart from the above, the major feature included in this series is
>> dt-hwmod binding and preparing omap hwmod framework for adapting omap
>> drivers to support omap dt after aligning with Grant Likely
>> <grant.likely@secretlab.ca>
>>
>> However, current hwmod-dt binding will be replaced with notifiers in
>> generic board file and hwmod device pointer will be scanned and attached
>> in notifier call.
>>
>> Used 3.0 stable kernel version for this patch series since latest mainline
>> was broken for beagle boot last week.
>>
>> git://git.secretlab.ca/git/linux-2.6.git
>> Branch: devicetree/test-3.0
>
> Is there a reason why these are based on devicetree/test-3.0 and
> not devicetree/test?

devicetree/test was broken last week since grant has pulled latest
mainline changes hence selected stable version.

-M

[...]

[RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 10:56 AM, Rajendra Nayak <rnayak@ti.com> wrote:
> On 8/9/2011 7:40 PM, G, Manjunath Kondaiah wrote:
>>
>> This is in continuation of patch series posted at:
>> http://lwn.net/Articles/451917/
>>
>> Patches from Kevin Hilman and others are consolidated along with this
>> series since it will be part of ongoing work of decoupling pdev from
>> omap_device.
>> [There is latest version posted which will be rebased later]
>>
>> Apart from the above, the major feature included in this series is
>> dt-hwmod binding and preparing omap hwmod framework for adapting omap
>> drivers to support omap dt after aligning with Grant Likely
>> <grant.likely@secretlab.ca>
>>
>> However, current hwmod-dt binding will be replaced with notifiers in
>> generic board file and hwmod device pointer will be scanned and attached
>> in notifier call.
>>
>> Used 3.0 stable kernel version for this patch series since latest mainline
>> was broken for beagle boot last week.
>>
>> git://git.secretlab.ca/git/linux-2.6.git
>> Branch: devicetree/test-3.0
>
> Is there a reason why these are based on devicetree/test-3.0 and
> not devicetree/test?

devicetree/test was broken last week since grant has pulled latest
mainline changes hence selected stable version.

-M

[...]

Re: [RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support

[Rajendra Nayak]

On 8/10/2011 11:00 AM, G, Manjunath Kondaiah wrote:
> On Wed, Aug 10, 2011 at 10:56 AM, Rajendra Nayak<rnayak@ti.com>  wrote:
>> On 8/9/2011 7:40 PM, G, Manjunath Kondaiah wrote:
>>>
>>> This is in continuation of patch series posted at:
>>> http://lwn.net/Articles/451917/
>>>
>>> Patches from Kevin Hilman and others are consolidated along with this
>>> series since it will be part of ongoing work of decoupling pdev from
>>> omap_device.
>>> [There is latest version posted which will be rebased later]
>>>
>>> Apart from the above, the major feature included in this series is
>>> dt-hwmod binding and preparing omap hwmod framework for adapting omap
>>> drivers to support omap dt after aligning with Grant Likely
>>> <grant.likely@secretlab.ca>
>>>
>>> However, current hwmod-dt binding will be replaced with notifiers in
>>> generic board file and hwmod device pointer will be scanned and attached
>>> in notifier call.
>>>
>>> Used 3.0 stable kernel version for this patch series since latest mainline
>>> was broken for beagle boot last week.
>>>
>>> git://git.secretlab.ca/git/linux-2.6.git
>>> Branch: devicetree/test-3.0
>>
>> Is there a reason why these are based on devicetree/test-3.0 and
>> not devicetree/test?
>
> devicetree/test was broken last week since grant has pulled latest
> mainline changes hence selected stable version.

Ok, atleast mainline is fixed now.

>
> -M
>
> [...]

[RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support

[Rajendra Nayak]

On 8/10/2011 11:00 AM, G, Manjunath Kondaiah wrote:
> On Wed, Aug 10, 2011 at 10:56 AM, Rajendra Nayak<rnayak@ti.com>  wrote:
>> On 8/9/2011 7:40 PM, G, Manjunath Kondaiah wrote:
>>>
>>> This is in continuation of patch series posted at:
>>> http://lwn.net/Articles/451917/
>>>
>>> Patches from Kevin Hilman and others are consolidated along with this
>>> series since it will be part of ongoing work of decoupling pdev from
>>> omap_device.
>>> [There is latest version posted which will be rebased later]
>>>
>>> Apart from the above, the major feature included in this series is
>>> dt-hwmod binding and preparing omap hwmod framework for adapting omap
>>> drivers to support omap dt after aligning with Grant Likely
>>> <grant.likely@secretlab.ca>
>>>
>>> However, current hwmod-dt binding will be replaced with notifiers in
>>> generic board file and hwmod device pointer will be scanned and attached
>>> in notifier call.
>>>
>>> Used 3.0 stable kernel version for this patch series since latest mainline
>>> was broken for beagle boot last week.
>>>
>>> git://git.secretlab.ca/git/linux-2.6.git
>>> Branch: devicetree/test-3.0
>>
>> Is there a reason why these are based on devicetree/test-3.0 and
>> not devicetree/test?
>
> devicetree/test was broken last week since grant has pulled latest
> mainline changes hence selected stable version.

Ok, atleast mainline is fixed now.

>
> -M
>
> [...]

Re: [RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 11:09 AM, Rajendra Nayak <rnayak@ti.com> wrote:
> On 8/10/2011 11:00 AM, G, Manjunath Kondaiah wrote:
>>
>> On Wed, Aug 10, 2011 at 10:56 AM, Rajendra Nayak<rnayak@ti.com>  wrote:
>>>
>>> On 8/9/2011 7:40 PM, G, Manjunath Kondaiah wrote:
>>>>
>>>> This is in continuation of patch series posted at:
>>>> http://lwn.net/Articles/451917/
>>>>
>>>> Patches from Kevin Hilman and others are consolidated along with this
>>>> series since it will be part of ongoing work of decoupling pdev from
>>>> omap_device.
>>>> [There is latest version posted which will be rebased later]
>>>>
>>>> Apart from the above, the major feature included in this series is
>>>> dt-hwmod binding and preparing omap hwmod framework for adapting omap
>>>> drivers to support omap dt after aligning with Grant Likely
>>>> <grant.likely@secretlab.ca>
>>>>
>>>> However, current hwmod-dt binding will be replaced with notifiers in
>>>> generic board file and hwmod device pointer will be scanned and attached
>>>> in notifier call.
>>>>
>>>> Used 3.0 stable kernel version for this patch series since latest
>>>> mainline
>>>> was broken for beagle boot last week.
>>>>
>>>> git://git.secretlab.ca/git/linux-2.6.git
>>>> Branch: devicetree/test-3.0
>>>
>>> Is there a reason why these are based on devicetree/test-3.0 and
>>> not devicetree/test?
>>
>> devicetree/test was broken last week since grant has pulled latest
>> mainline changes hence selected stable version.
>
> Ok, atleast mainline is fixed now.

These changes are for v3.2 merge window and it will be rebased later
after the review.

-M
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 11:09 AM, Rajendra Nayak <rnayak@ti.com> wrote:
> On 8/10/2011 11:00 AM, G, Manjunath Kondaiah wrote:
>>
>> On Wed, Aug 10, 2011 at 10:56 AM, Rajendra Nayak<rnayak@ti.com> ?wrote:
>>>
>>> On 8/9/2011 7:40 PM, G, Manjunath Kondaiah wrote:
>>>>
>>>> This is in continuation of patch series posted at:
>>>> http://lwn.net/Articles/451917/
>>>>
>>>> Patches from Kevin Hilman and others are consolidated along with this
>>>> series since it will be part of ongoing work of decoupling pdev from
>>>> omap_device.
>>>> [There is latest version posted which will be rebased later]
>>>>
>>>> Apart from the above, the major feature included in this series is
>>>> dt-hwmod binding and preparing omap hwmod framework for adapting omap
>>>> drivers to support omap dt after aligning with Grant Likely
>>>> <grant.likely@secretlab.ca>
>>>>
>>>> However, current hwmod-dt binding will be replaced with notifiers in
>>>> generic board file and hwmod device pointer will be scanned and attached
>>>> in notifier call.
>>>>
>>>> Used 3.0 stable kernel version for this patch series since latest
>>>> mainline
>>>> was broken for beagle boot last week.
>>>>
>>>> git://git.secretlab.ca/git/linux-2.6.git
>>>> Branch: devicetree/test-3.0
>>>
>>> Is there a reason why these are based on devicetree/test-3.0 and
>>> not devicetree/test?
>>
>> devicetree/test was broken last week since grant has pulled latest
>> mainline changes hence selected stable version.
>
> Ok, atleast mainline is fixed now.

These changes are for v3.2 merge window and it will be rebased later
after the review.

-M

Re: [RFC/PATCH 04/14] OMAP: McBSP: use existing macros for converting between devices

[Jarkko Nikula]

Hi

On Tue, 09 Aug 2011 19:10:22 +0500
"G, Manjunath Kondaiah" <manjugk@ti.com> wrote:

> From: Kevin Hilman <khilman@ti.com>
> 
> For converting from struct device to platform_device, and from
> platform_device to struct device, there are existing macros.  Use
> them instead of manual use of container_of().
> 
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
>  arch/arm/plat-omap/mcbsp.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
Kevin dropped this patch and used mine that does more cleanups:

http://marc.info/?l=linux-omap&m=131255627918065&w=2

Worth to check also other patches since Kevin's updated set seems to
have other differences too:

http://marc.info/?l=linux-omap&m=131258997416300&w=2

-- 
Jarkko

[RFC/PATCH 04/14] OMAP: McBSP: use existing macros for converting between devices

[Jarkko Nikula]

Hi

On Tue, 09 Aug 2011 19:10:22 +0500
"G, Manjunath Kondaiah" <manjugk@ti.com> wrote:

> From: Kevin Hilman <khilman@ti.com>
> 
> For converting from struct device to platform_device, and from
> platform_device to struct device, there are existing macros.  Use
> them instead of manual use of container_of().
> 
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
>  arch/arm/plat-omap/mcbsp.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
Kevin dropped this patch and used mine that does more cleanups:

http://marc.info/?l=linux-omap&m=131255627918065&w=2

Worth to check also other patches since Kevin's updated set seems to
have other differences too:

http://marc.info/?l=linux-omap&m=131258997416300&w=2

-- 
Jarkko

Re: [RFC/PATCH 04/14] OMAP: McBSP: use existing macros for converting between devices

[Cousson, Benoit]

Manju,

On 8/10/2011 9:07 AM, Jarkko Nikula wrote:
> Hi
>
> On Tue, 09 Aug 2011 19:10:22 +0500
> "G, Manjunath Kondaiah"<manjugk@ti.com>  wrote:
>
>> From: Kevin Hilman<khilman@ti.com>
>>
>> For converting from struct device to platform_device, and from
>> platform_device to struct device, there are existing macros.  Use
>> them instead of manual use of container_of().
>>
>> Signed-off-by: Kevin Hilman<khilman@ti.com>
>> ---
>>   arch/arm/plat-omap/mcbsp.c |    6 +++---
>>   1 files changed, 3 insertions(+), 3 deletions(-)
>>
> Kevin dropped this patch and used mine that does more cleanups:
>
> http://marc.info/?l=linux-omap&m=131255627918065&w=2
>
> Worth to check also other patches since Kevin's updated set seems to
> have other differences too:
>
> http://marc.info/?l=linux-omap&m=131258997416300&w=2

In fact, you'd better point to the lastest Kevin's tree and not included 
the patches in this series.

Benoit

[RFC/PATCH 04/14] OMAP: McBSP: use existing macros for converting between devices

[Cousson, Benoit]

Manju,

On 8/10/2011 9:07 AM, Jarkko Nikula wrote:
> Hi
>
> On Tue, 09 Aug 2011 19:10:22 +0500
> "G, Manjunath Kondaiah"<manjugk@ti.com>  wrote:
>
>> From: Kevin Hilman<khilman@ti.com>
>>
>> For converting from struct device to platform_device, and from
>> platform_device to struct device, there are existing macros.  Use
>> them instead of manual use of container_of().
>>
>> Signed-off-by: Kevin Hilman<khilman@ti.com>
>> ---
>>   arch/arm/plat-omap/mcbsp.c |    6 +++---
>>   1 files changed, 3 insertions(+), 3 deletions(-)
>>
> Kevin dropped this patch and used mine that does more cleanups:
>
> http://marc.info/?l=linux-omap&m=131255627918065&w=2
>
> Worth to check also other patches since Kevin's updated set seems to
> have other differences too:
>
> http://marc.info/?l=linux-omap&m=131258997416300&w=2

In fact, you'd better point to the lastest Kevin's tree and not included 
the patches in this series.

Benoit

Re: [RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt

[Cousson, Benoit]

Hi Manju,

On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>
> The omap dt requires new omap hwmod api to be added for in order
> to support omap dt.

Both the subject and the changelog are misleading. You are not doing any 
hwmod stuff in it.
You are just passing an "of_node" pointer during omap_device_build_ss.

The subject should start with OMAP: omap_device: because it does not 
belong to the DT subsystem.
The same comment apply to most patches in that series.

> The new api is added and new parameter "np" is added for existing
> api.

I don't think np is not a super meaningful name. Some more explanation 
are needed as well.

> The users of hwmod api is changed accrodingly.

omap_device API + typo.

> Build and boot tested on omap3 beagle for both dt and not dt build.
>
> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> ---
>   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              |   53 ++++++++++++++++++++++---
>   4 files changed, 59 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 458f7be..d7ff1ae 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)
>   			pr_err("could not look up %s\n", oh_name);
>   	}
>
> -	pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
> +	pdev = omap_device_build_ss(NULL, "omap_l3_noc", 0, oh, 3, NULL,
>   						     0, NULL, 0, 0);

OK, maybe that is just me, but in order to extend an API, I'd rather add 
the new parameter at the end.

>   	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
> diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
> index 7a42f32..98eb95d 100644
> --- a/arch/arm/mach-omap2/mcbsp.c
> +++ b/arch/arm/mach-omap2/mcbsp.c
> @@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
>   		(struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
>   		count++;
>   	}
> -	pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
> +	pdev = omap_device_build_ss(NULL, name, id, oh_device, count, pdata,
>   				sizeof(*pdata), omap2_mcbsp_latency,
>   				ARRAY_SIZE(omap2_mcbsp_latency), false);
>   	kfree(pdata);
> diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
> index 7a3ec4f..5e2424b 100644
> --- a/arch/arm/plat-omap/include/plat/omap_device.h
> +++ b/arch/arm/plat-omap/include/plat/omap_device.h
> @@ -33,6 +33,7 @@
>
>   #include<linux/kernel.h>
>   #include<linux/platform_device.h>
> +#include<linux/of.h>
>
>   #include<plat/omap_hwmod.h>
>
> @@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>   				      struct omap_device_pm_latency *pm_lats,
>   				      int pm_lats_cnt, int is_early_device);
>
> -struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> +struct platform_device *omap_device_build_ss(struct device_node *np,
> +					 const char *pdev_name, int pdev_id,
>   					 struct omap_hwmod **oh, int oh_cnt,
>   					 void *pdata, int pdata_len,
>   					 struct omap_device_pm_latency *pm_lats,
>   					 int pm_lats_cnt, int is_early_device);
>
> +struct platform_device *omap_device_build_dt(struct device_node *np,
> +				      const char *pdev_name, int pdev_id,
> +				      struct omap_hwmod *oh, void *pdata,
> +				      int pdata_len,
> +				      struct omap_device_pm_latency *pm_lats,
> +				      int pm_lats_cnt, int is_early_device);
> +
>   void __iomem *omap_device_get_rt_va(struct omap_device *od);
>
>   /* OMAP PM interface */
> diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
> index 7d5e76b..fa49168 100644
> --- a/arch/arm/plat-omap/omap_device.c
> +++ b/arch/arm/plat-omap/omap_device.c
> @@ -85,6 +85,7 @@
>   #include<linux/clk.h>
>   #include<linux/clkdev.h>
>   #include<linux/pm_runtime.h>
> +#include<linux/of_device.h>
>
>   #include<plat/omap_device.h>
>   #include<plat/omap_hwmod.h>
> @@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device *od,
>   /**
>    * omap_device_build - build and register an omap_device with one omap_hwmod

Need to update the kerneldoc.

>    * @pdev_name: name of the platform_device driver to use
> + * @np: device node pointer for attaching it to of_node pointer
>    * @pdev_id: this platform_device's connection ID
>    * @oh: ptr to the single omap_hwmod that backs this omap_device
>    * @pdata: platform_data ptr to associate with the platform_device
> @@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device *od,
>    * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
>    * passes along the return value of omap_device_build_ss().
>    */
> -struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> +struct platform_device *omap_device_build_dt(struct device_node *np,
> +				      const char *pdev_name, int pdev_id,
>   				      struct omap_hwmod *oh, void *pdata,
>   				      int pdata_len,
>   				      struct omap_device_pm_latency *pm_lats,

That function should not be needed. You have to export 
omap_device_build_ss, otherwise you will not build any device with 
multiple hwmods.

> @@ -402,12 +405,44 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>   	if (!oh)
>   		return ERR_PTR(-EINVAL);
>
> -	return omap_device_build_ss(pdev_name, pdev_id, ohs, 1, pdata,
> +	return omap_device_build_ss(np, pdev_name, pdev_id, ohs, 1, pdata,
>   				    pdata_len, pm_lats, pm_lats_cnt,
>   				    is_early_device);
>   }
>
>   /**
> + * omap_device_build - build and register an omap_device with one omap_hwmod
> + * @pdev_name: name of the platform_device driver to use
> + * @pdev_id: this platform_device's connection ID
> + * @oh: ptr to the single omap_hwmod that backs this omap_device
> + * @pdata: platform_data ptr to associate with the platform_device
> + * @pdata_len: amount of memory pointed to by @pdata
> + * @pm_lats: pointer to a omap_device_pm_latency array for this device
> + * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
> + * @is_early_device: should the device be registered as an early device or not
> + *
> + * Convenience function for building and registering a single
> + * omap_device record, which in turn builds and registers a
> + * platform_device record.  See omap_device_build_ss() for more
> + * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
> + * passes along the return value of omap_device_build_ss().
> + */
> +struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> +				      struct omap_hwmod *oh, void *pdata,
> +				      int pdata_len,
> +				      struct omap_device_pm_latency *pm_lats,
> +				      int pm_lats_cnt, int is_early_device)
> +{
> +	struct omap_hwmod *ohs[] = { oh };
> +
> +	if (!oh)
> +		return ERR_PTR(-EINVAL);
> +
> +	return omap_device_build_ss(NULL, pdev_name, pdev_id, ohs, 1, pdata,
> +			pdata_len, pm_lats, pm_lats_cnt, is_early_device);
> +}
> +
> +/**
>    * omap_device_build_ss - build and register an omap_device with multiple hwmods
>    * @pdev_name: name of the platform_device driver to use
>    * @pdev_id: this platform_device's connection ID
> @@ -424,7 +459,8 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>    * platform_device record.  Returns an ERR_PTR() on error, or passes
>    * along the return value of omap_device_register().
>    */
> -struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> +struct platform_device *omap_device_build_ss(struct device_node *np,
> +					 const char *pdev_name, int pdev_id,
>   					 struct omap_hwmod **ohs, int oh_cnt,
>   					 void *pdata, int pdata_len,
>   					 struct omap_device_pm_latency *pm_lats,
> @@ -436,6 +472,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>   	struct resource *res = NULL;
>   	int i, res_count;
>   	struct omap_hwmod **hwmods;
> +	struct platform_device *pdev;
>
>   	if (!ohs || oh_cnt == 0 || !pdev_name)
>   		return ERR_PTR(-EINVAL);
> @@ -450,6 +487,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>   	if (!od)
>   		return ERR_PTR(-ENOMEM);
>
> +	pdev =&od->pdev;

Why do you need that? You are just adding one more user of the pdev.

>   	od->hwmods_cnt = oh_cnt;
>
>   	hwmods = kzalloc(sizeof(struct omap_hwmod *) * oh_cnt,
> @@ -465,8 +503,11 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>   		goto odbs_exit2;
>   	strcpy(pdev_name2, pdev_name);
>
> -	od->pdev.name = pdev_name2;
> -	od->pdev.id = pdev_id;
> +#ifdef CONFIG_OF_DEVICE
> +	pdev->dev.of_node = of_node_get(np);
> +#endif
> +	pdev->name = pdev_name2;
> +	pdev->id = pdev_id;
>
>   	res_count = omap_device_count_resources(od);
>   	if (res_count>  0) {
> @@ -499,7 +540,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>   	if (ret)
>   		goto odbs_exit4;
>
> -	return&od->pdev;
> +	return pdev;
>
>   odbs_exit4:
>   	kfree(res);

Regards,
Benoit

[RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt

[Cousson, Benoit]

Hi Manju,

On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>
> The omap dt requires new omap hwmod api to be added for in order
> to support omap dt.

Both the subject and the changelog are misleading. You are not doing any 
hwmod stuff in it.
You are just passing an "of_node" pointer during omap_device_build_ss.

The subject should start with OMAP: omap_device: because it does not 
belong to the DT subsystem.
The same comment apply to most patches in that series.

> The new api is added and new parameter "np" is added for existing
> api.

I don't think np is not a super meaningful name. Some more explanation 
are needed as well.

> The users of hwmod api is changed accrodingly.

omap_device API + typo.

> Build and boot tested on omap3 beagle for both dt and not dt build.
>
> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> ---
>   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              |   53 ++++++++++++++++++++++---
>   4 files changed, 59 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 458f7be..d7ff1ae 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)
>   			pr_err("could not look up %s\n", oh_name);
>   	}
>
> -	pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
> +	pdev = omap_device_build_ss(NULL, "omap_l3_noc", 0, oh, 3, NULL,
>   						     0, NULL, 0, 0);

OK, maybe that is just me, but in order to extend an API, I'd rather add 
the new parameter at the end.

>   	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
> diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
> index 7a42f32..98eb95d 100644
> --- a/arch/arm/mach-omap2/mcbsp.c
> +++ b/arch/arm/mach-omap2/mcbsp.c
> @@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
>   		(struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
>   		count++;
>   	}
> -	pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
> +	pdev = omap_device_build_ss(NULL, name, id, oh_device, count, pdata,
>   				sizeof(*pdata), omap2_mcbsp_latency,
>   				ARRAY_SIZE(omap2_mcbsp_latency), false);
>   	kfree(pdata);
> diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
> index 7a3ec4f..5e2424b 100644
> --- a/arch/arm/plat-omap/include/plat/omap_device.h
> +++ b/arch/arm/plat-omap/include/plat/omap_device.h
> @@ -33,6 +33,7 @@
>
>   #include<linux/kernel.h>
>   #include<linux/platform_device.h>
> +#include<linux/of.h>
>
>   #include<plat/omap_hwmod.h>
>
> @@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>   				      struct omap_device_pm_latency *pm_lats,
>   				      int pm_lats_cnt, int is_early_device);
>
> -struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> +struct platform_device *omap_device_build_ss(struct device_node *np,
> +					 const char *pdev_name, int pdev_id,
>   					 struct omap_hwmod **oh, int oh_cnt,
>   					 void *pdata, int pdata_len,
>   					 struct omap_device_pm_latency *pm_lats,
>   					 int pm_lats_cnt, int is_early_device);
>
> +struct platform_device *omap_device_build_dt(struct device_node *np,
> +				      const char *pdev_name, int pdev_id,
> +				      struct omap_hwmod *oh, void *pdata,
> +				      int pdata_len,
> +				      struct omap_device_pm_latency *pm_lats,
> +				      int pm_lats_cnt, int is_early_device);
> +
>   void __iomem *omap_device_get_rt_va(struct omap_device *od);
>
>   /* OMAP PM interface */
> diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
> index 7d5e76b..fa49168 100644
> --- a/arch/arm/plat-omap/omap_device.c
> +++ b/arch/arm/plat-omap/omap_device.c
> @@ -85,6 +85,7 @@
>   #include<linux/clk.h>
>   #include<linux/clkdev.h>
>   #include<linux/pm_runtime.h>
> +#include<linux/of_device.h>
>
>   #include<plat/omap_device.h>
>   #include<plat/omap_hwmod.h>
> @@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device *od,
>   /**
>    * omap_device_build - build and register an omap_device with one omap_hwmod

Need to update the kerneldoc.

>    * @pdev_name: name of the platform_device driver to use
> + * @np: device node pointer for attaching it to of_node pointer
>    * @pdev_id: this platform_device's connection ID
>    * @oh: ptr to the single omap_hwmod that backs this omap_device
>    * @pdata: platform_data ptr to associate with the platform_device
> @@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device *od,
>    * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
>    * passes along the return value of omap_device_build_ss().
>    */
> -struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> +struct platform_device *omap_device_build_dt(struct device_node *np,
> +				      const char *pdev_name, int pdev_id,
>   				      struct omap_hwmod *oh, void *pdata,
>   				      int pdata_len,
>   				      struct omap_device_pm_latency *pm_lats,

That function should not be needed. You have to export 
omap_device_build_ss, otherwise you will not build any device with 
multiple hwmods.

> @@ -402,12 +405,44 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>   	if (!oh)
>   		return ERR_PTR(-EINVAL);
>
> -	return omap_device_build_ss(pdev_name, pdev_id, ohs, 1, pdata,
> +	return omap_device_build_ss(np, pdev_name, pdev_id, ohs, 1, pdata,
>   				    pdata_len, pm_lats, pm_lats_cnt,
>   				    is_early_device);
>   }
>
>   /**
> + * omap_device_build - build and register an omap_device with one omap_hwmod
> + * @pdev_name: name of the platform_device driver to use
> + * @pdev_id: this platform_device's connection ID
> + * @oh: ptr to the single omap_hwmod that backs this omap_device
> + * @pdata: platform_data ptr to associate with the platform_device
> + * @pdata_len: amount of memory pointed to by @pdata
> + * @pm_lats: pointer to a omap_device_pm_latency array for this device
> + * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
> + * @is_early_device: should the device be registered as an early device or not
> + *
> + * Convenience function for building and registering a single
> + * omap_device record, which in turn builds and registers a
> + * platform_device record.  See omap_device_build_ss() for more
> + * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
> + * passes along the return value of omap_device_build_ss().
> + */
> +struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> +				      struct omap_hwmod *oh, void *pdata,
> +				      int pdata_len,
> +				      struct omap_device_pm_latency *pm_lats,
> +				      int pm_lats_cnt, int is_early_device)
> +{
> +	struct omap_hwmod *ohs[] = { oh };
> +
> +	if (!oh)
> +		return ERR_PTR(-EINVAL);
> +
> +	return omap_device_build_ss(NULL, pdev_name, pdev_id, ohs, 1, pdata,
> +			pdata_len, pm_lats, pm_lats_cnt, is_early_device);
> +}
> +
> +/**
>    * omap_device_build_ss - build and register an omap_device with multiple hwmods
>    * @pdev_name: name of the platform_device driver to use
>    * @pdev_id: this platform_device's connection ID
> @@ -424,7 +459,8 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>    * platform_device record.  Returns an ERR_PTR() on error, or passes
>    * along the return value of omap_device_register().
>    */
> -struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> +struct platform_device *omap_device_build_ss(struct device_node *np,
> +					 const char *pdev_name, int pdev_id,
>   					 struct omap_hwmod **ohs, int oh_cnt,
>   					 void *pdata, int pdata_len,
>   					 struct omap_device_pm_latency *pm_lats,
> @@ -436,6 +472,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>   	struct resource *res = NULL;
>   	int i, res_count;
>   	struct omap_hwmod **hwmods;
> +	struct platform_device *pdev;
>
>   	if (!ohs || oh_cnt == 0 || !pdev_name)
>   		return ERR_PTR(-EINVAL);
> @@ -450,6 +487,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>   	if (!od)
>   		return ERR_PTR(-ENOMEM);
>
> +	pdev =&od->pdev;

Why do you need that? You are just adding one more user of the pdev.

>   	od->hwmods_cnt = oh_cnt;
>
>   	hwmods = kzalloc(sizeof(struct omap_hwmod *) * oh_cnt,
> @@ -465,8 +503,11 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>   		goto odbs_exit2;
>   	strcpy(pdev_name2, pdev_name);
>
> -	od->pdev.name = pdev_name2;
> -	od->pdev.id = pdev_id;
> +#ifdef CONFIG_OF_DEVICE
> +	pdev->dev.of_node = of_node_get(np);
> +#endif
> +	pdev->name = pdev_name2;
> +	pdev->id = pdev_id;
>
>   	res_count = omap_device_count_resources(od);
>   	if (res_count>  0) {
> @@ -499,7 +540,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>   	if (ret)
>   		goto odbs_exit4;
>
> -	return&od->pdev;
> +	return pdev;
>
>   odbs_exit4:
>   	kfree(res);

Regards,
Benoit

Re: [RFC/PATCH 10/14] dt: Add pd_size to AUXDATA structure

[Cousson, Benoit]

On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>
> Add pd_size in the AUXDATA structure so that device drivers which require
> platform_data size can pass along with AUXDATA.

It is really needed by device driver? Or is it because omap_device_build 
is using platform_device_add_data that is doing a copy of the pdata and 
thus require the size?

> Signed-off-by: G, Manjunath Kondaiah<manjugk-l0cyMroinI0@public.gmane.org>
> ---
>   drivers/of/platform.c       |    2 ++
>   include/linux/of_platform.h |    5 +++++
>   2 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index ebbbf42..4b27286 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -565,6 +565,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;

Maybe platform_data_size will be a little bit more consistent?

Regards,
Benoit

>   	int id = -1;
>   	int rc = 0;
>
> @@ -588,6 +589,7 @@ static int of_platform_bus_create(struct device_node *bus,
>   		bus_id = auxdata->name;
>   		id = auxdata->id;
>   		platform_data = auxdata->platform_data;
> +		pd_size = auxdata->pd_size;
>   	}
>
>   	if (of_device_is_compatible(bus, "arm,primecell")) {
> diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
> index 252246c..a3be980 100644
> --- a/include/linux/of_platform.h
> +++ b/include/linux/of_platform.h
> @@ -47,6 +47,7 @@ struct of_dev_auxdata {
>   	char *name;
>   	int id;
>   	void *platform_data;
> +	int pd_size;
>   };
>
>   /* Macro to simplify populating a lookup table */
> @@ -58,6 +59,10 @@ struct of_dev_auxdata {
>   	{ .compatible = _compat, .phys_addr = _phys, .name = _name, \
>   	  .id = _id, .platform_data = _pdata }
>
> +#define OF_DEV_AUXDATA_ID_PDSIZE(_compat,_phys,_name,_id,_pdata,_pd_size) \
> +	{ .compatible = _compat, .phys_addr = _phys, .name = _name, \
> +	  .id = _id, .platform_data = _pdata, .pd_size = _pd_size }
> +
>   /**
>    * of_platform_driver - Legacy of-aware driver for platform devices.
>    *

[RFC/PATCH 10/14] dt: Add pd_size to AUXDATA structure

[Cousson, Benoit]

On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>
> Add pd_size in the AUXDATA structure so that device drivers which require
> platform_data size can pass along with AUXDATA.

It is really needed by device driver? Or is it because omap_device_build 
is using platform_device_add_data that is doing a copy of the pdata and 
thus require the size?

> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> ---
>   drivers/of/platform.c       |    2 ++
>   include/linux/of_platform.h |    5 +++++
>   2 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index ebbbf42..4b27286 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -565,6 +565,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;

Maybe platform_data_size will be a little bit more consistent?

Regards,
Benoit

>   	int id = -1;
>   	int rc = 0;
>
> @@ -588,6 +589,7 @@ static int of_platform_bus_create(struct device_node *bus,
>   		bus_id = auxdata->name;
>   		id = auxdata->id;
>   		platform_data = auxdata->platform_data;
> +		pd_size = auxdata->pd_size;
>   	}
>
>   	if (of_device_is_compatible(bus, "arm,primecell")) {
> diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
> index 252246c..a3be980 100644
> --- a/include/linux/of_platform.h
> +++ b/include/linux/of_platform.h
> @@ -47,6 +47,7 @@ struct of_dev_auxdata {
>   	char *name;
>   	int id;
>   	void *platform_data;
> +	int pd_size;
>   };
>
>   /* Macro to simplify populating a lookup table */
> @@ -58,6 +59,10 @@ struct of_dev_auxdata {
>   	{ .compatible = _compat, .phys_addr = _phys, .name = _name, \
>   	  .id = _id, .platform_data = _pdata }
>
> +#define OF_DEV_AUXDATA_ID_PDSIZE(_compat,_phys,_name,_id,_pdata,_pd_size) \
> +	{ .compatible = _compat, .phys_addr = _phys, .name = _name, \
> +	  .id = _id, .platform_data = _pdata, .pd_size = _pd_size }
> +
>   /**
>    * of_platform_driver - Legacy of-aware driver for platform devices.
>    *

Re: [RFC/PATCH 11/14] dt: omap3: add soc file for handling i2c controllers

[Cousson, Benoit]

On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>
> Add omap3 soc file for handling omap3 soc i2c controllers existing
> on l4-core bus.
>
> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> ---
>   arch/arm/boot/dts/omap3-soc.dtsi |   62 ++++++++++++++++++++++++++++++++++++++
>   1 files changed, 62 insertions(+), 0 deletions(-)
>   create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
>
> diff --git a/arch/arm/boot/dts/omap3-soc.dtsi b/arch/arm/boot/dts/omap3-soc.dtsi
> new file mode 100644
> index 0000000..85de92f
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-soc.dtsi
> @@ -0,0 +1,62 @@
> +/*
> + * Device Tree Source for OMAP3 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/;
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	#address-cells =<1>;
> +	#size-cells =<1>;
> +	model = "ti,omap3";
> +
> +	aliases {
> +		i2c1 =&i2c1;
> +		i2c2 =&i2c2;
> +		i2c3 =&i2c3;
> +	};
> +
> +	l4-core {

That comment is probably subject to discussion, but even if this 
interconnect is there physically, I'm not sure of the added value to add it.
It will add an extra level of indentation and that all. Moreover, it 
will mess up the physical address that are expressed using absolute 
value in the TRM with a less readable offset value.
In fact, most DTS files in the ARM directory are using a purely flat 
representation of the interconnect.

> +		compatible = "ti,omap3-l4-core";

Assuming we will keep that, you should probably add a more generic 
compatible name after that one. Like "ti,s3220" or even "sonics,s3220", 
assuming that this IP is generic enough for other SoC.

> +		#address-cells =<1>;
> +		#size-cells =<1>;
> +		ranges =<0 0x48000000 0x1000000>;
> +
> +		i2c1: i2c@70000 {
> +			#address-cells =<1>;
> +			#size-cells =<0>;
> +			compatible = "ti,omap3-i2c";

The I2C IP and thus the driver is generic across OMAP generations and is 
even potentially used by other non-OMAP TI chips like DSP or Davinci. So 
having an extra compatible entry with "ti,i2c" or "ti, omap-i2c" seems 
mandatory.

Regards,
Benoit

[RFC/PATCH 11/14] dt: omap3: add soc file for handling i2c controllers

[Cousson, Benoit]

On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>
> Add omap3 soc file for handling omap3 soc i2c controllers existing
> on l4-core bus.
>
> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> ---
>   arch/arm/boot/dts/omap3-soc.dtsi |   62 ++++++++++++++++++++++++++++++++++++++
>   1 files changed, 62 insertions(+), 0 deletions(-)
>   create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
>
> diff --git a/arch/arm/boot/dts/omap3-soc.dtsi b/arch/arm/boot/dts/omap3-soc.dtsi
> new file mode 100644
> index 0000000..85de92f
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-soc.dtsi
> @@ -0,0 +1,62 @@
> +/*
> + * Device Tree Source for OMAP3 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/;
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	#address-cells =<1>;
> +	#size-cells =<1>;
> +	model = "ti,omap3";
> +
> +	aliases {
> +		i2c1 =&i2c1;
> +		i2c2 =&i2c2;
> +		i2c3 =&i2c3;
> +	};
> +
> +	l4-core {

That comment is probably subject to discussion, but even if this 
interconnect is there physically, I'm not sure of the added value to add it.
It will add an extra level of indentation and that all. Moreover, it 
will mess up the physical address that are expressed using absolute 
value in the TRM with a less readable offset value.
In fact, most DTS files in the ARM directory are using a purely flat 
representation of the interconnect.

> +		compatible = "ti,omap3-l4-core";

Assuming we will keep that, you should probably add a more generic 
compatible name after that one. Like "ti,s3220" or even "sonics,s3220", 
assuming that this IP is generic enough for other SoC.

> +		#address-cells =<1>;
> +		#size-cells =<1>;
> +		ranges =<0 0x48000000 0x1000000>;
> +
> +		i2c1: i2c at 70000 {
> +			#address-cells =<1>;
> +			#size-cells =<0>;
> +			compatible = "ti,omap3-i2c";

The I2C IP and thus the driver is generic across OMAP generations and is 
even potentially used by other non-OMAP TI chips like DSP or Davinci. So 
having an extra compatible entry with "ti,i2c" or "ti, omap-i2c" seems 
mandatory.

Regards,
Benoit

Re: [RFC/PATCH 12/14] dt: omap3: beagle board: set clock freq for i2c devices

[Cousson, Benoit]

On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>
> Update omap3 beagle dts file with required clock frequencies for the i2c
> client devices existing on beagle board.
>
> Beagle custom board dts file is cleaned up so that it can coexist with omap3
> soc dts file.
>
> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> ---
>   arch/arm/boot/dts/omap3-beagle-nunchuck.dts |   11 +----------
>   arch/arm/boot/dts/omap3-beagle.dts          |   18 +++++++++++++++---
>   2 files changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> index 2607be5..324ff86 100644
> --- a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> @@ -1,16 +1,7 @@
>   /include/ "omap3-beagle.dts"
>
>   / {
> -	i2c@48072000 {
> -		compatible = "ti,omap3-i2c";
> -		reg =<0x48072000 0x80>;
> -		#address-cells =<1>;
> -		#size-cells =<0>;
> -
> -		eeprom@50 {
> -			compatible = "at,at24c01";
> -			reg =<  0x50>;
> -		};

This change should probably not be there.

> +	i2c@2 {
>   		joystick@52 {
>   			compatible = "sparkfun,wiichuck";

It looks like someone is having fun with a beagle connected to a Wii 
nunchuck:-)

>   			reg =<  0x52>;
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
> index 4439466..49a5ac7 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -1,7 +1,19 @@
> -/dts-v1/;
> -/include/ "skeleton.dtsi"
> +/include/ "omap3-soc.dtsi"

There is no need for the "-soc" postfix, otherwise all the other SoCs 
inside DTS directory should have it.

Benoit

[RFC/PATCH 12/14] dt: omap3: beagle board: set clock freq for i2c devices

[Cousson, Benoit]

On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>
> Update omap3 beagle dts file with required clock frequencies for the i2c
> client devices existing on beagle board.
>
> Beagle custom board dts file is cleaned up so that it can coexist with omap3
> soc dts file.
>
> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> ---
>   arch/arm/boot/dts/omap3-beagle-nunchuck.dts |   11 +----------
>   arch/arm/boot/dts/omap3-beagle.dts          |   18 +++++++++++++++---
>   2 files changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> index 2607be5..324ff86 100644
> --- a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> @@ -1,16 +1,7 @@
>   /include/ "omap3-beagle.dts"
>
>   / {
> -	i2c at 48072000 {
> -		compatible = "ti,omap3-i2c";
> -		reg =<0x48072000 0x80>;
> -		#address-cells =<1>;
> -		#size-cells =<0>;
> -
> -		eeprom at 50 {
> -			compatible = "at,at24c01";
> -			reg =<  0x50>;
> -		};

This change should probably not be there.

> +	i2c at 2 {
>   		joystick at 52 {
>   			compatible = "sparkfun,wiichuck";

It looks like someone is having fun with a beagle connected to a Wii 
nunchuck:-)

>   			reg =<  0x52>;
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
> index 4439466..49a5ac7 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -1,7 +1,19 @@
> -/dts-v1/;
> -/include/ "skeleton.dtsi"
> +/include/ "omap3-soc.dtsi"

There is no need for the "-soc" postfix, otherwise all the other SoCs 
inside DTS directory should have it.

Benoit

Re: [RFC/PATCH 14/14] dt: omap3: enable dt support for i2c1 controller

[Cousson, Benoit]

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.

Benoit

[RFC/PATCH 14/14] dt: omap3: enable dt support for i2c1 controller

[Cousson, Benoit]

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 at 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 at 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 at 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.

Benoit

Re: [RFC/PATCH 10/14] dt: Add pd_size to AUXDATA structure

[Grant Likely]

On Wed, Aug 10, 2011 at 5:57 AM, Cousson, Benoit <b-cousson@ti.com> wrote:
> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>>
>> Add pd_size in the AUXDATA structure so that device drivers which require
>> platform_data size can pass along with AUXDATA.
>
> It is really needed by device driver? Or is it because omap_device_build is
> using platform_device_add_data that is doing a copy of the pdata and thus
> require the size?

Yes, I have the same question.  What is the reason for needing the
platform data size?

g.

>
>> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
>> ---
>>  drivers/of/platform.c       |    2 ++
>>  include/linux/of_platform.h |    5 +++++
>>  2 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index ebbbf42..4b27286 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -565,6 +565,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;
>
> Maybe platform_data_size will be a little bit more consistent?
>
> Regards,
> Benoit
>
>>        int id = -1;
>>        int rc = 0;
>>
>> @@ -588,6 +589,7 @@ static int of_platform_bus_create(struct device_node
>> *bus,
>>                bus_id = auxdata->name;
>>                id = auxdata->id;
>>                platform_data = auxdata->platform_data;
>> +               pd_size = auxdata->pd_size;
>>        }
>>
>>        if (of_device_is_compatible(bus, "arm,primecell")) {
>> diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
>> index 252246c..a3be980 100644
>> --- a/include/linux/of_platform.h
>> +++ b/include/linux/of_platform.h
>> @@ -47,6 +47,7 @@ struct of_dev_auxdata {
>>        char *name;
>>        int id;
>>        void *platform_data;
>> +       int pd_size;
>>  };
>>
>>  /* Macro to simplify populating a lookup table */
>> @@ -58,6 +59,10 @@ struct of_dev_auxdata {
>>        { .compatible = _compat, .phys_addr = _phys, .name = _name, \
>>          .id = _id, .platform_data = _pdata }
>>
>> +#define OF_DEV_AUXDATA_ID_PDSIZE(_compat,_phys,_name,_id,_pdata,_pd_size)
>> \
>> +       { .compatible = _compat, .phys_addr = _phys, .name = _name, \
>> +         .id = _id, .platform_data = _pdata, .pd_size = _pd_size }
>> +
>>  /**
>>   * of_platform_driver - Legacy of-aware driver for platform devices.
>>   *
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC/PATCH 10/14] dt: Add pd_size to AUXDATA structure

[Grant Likely]

On Wed, Aug 10, 2011 at 5:57 AM, Cousson, Benoit <b-cousson@ti.com> wrote:
> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>>
>> Add pd_size in the AUXDATA structure so that device drivers which require
>> platform_data size can pass along with AUXDATA.
>
> It is really needed by device driver? Or is it because omap_device_build is
> using platform_device_add_data that is doing a copy of the pdata and thus
> require the size?

Yes, I have the same question.  What is the reason for needing the
platform data size?

g.

>
>> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
>> ---
>> ?drivers/of/platform.c ? ? ? | ? ?2 ++
>> ?include/linux/of_platform.h | ? ?5 +++++
>> ?2 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index ebbbf42..4b27286 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -565,6 +565,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;
>
> Maybe platform_data_size will be a little bit more consistent?
>
> Regards,
> Benoit
>
>> ? ? ? ?int id = -1;
>> ? ? ? ?int rc = 0;
>>
>> @@ -588,6 +589,7 @@ static int of_platform_bus_create(struct device_node
>> *bus,
>> ? ? ? ? ? ? ? ?bus_id = auxdata->name;
>> ? ? ? ? ? ? ? ?id = auxdata->id;
>> ? ? ? ? ? ? ? ?platform_data = auxdata->platform_data;
>> + ? ? ? ? ? ? ? pd_size = auxdata->pd_size;
>> ? ? ? ?}
>>
>> ? ? ? ?if (of_device_is_compatible(bus, "arm,primecell")) {
>> diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
>> index 252246c..a3be980 100644
>> --- a/include/linux/of_platform.h
>> +++ b/include/linux/of_platform.h
>> @@ -47,6 +47,7 @@ struct of_dev_auxdata {
>> ? ? ? ?char *name;
>> ? ? ? ?int id;
>> ? ? ? ?void *platform_data;
>> + ? ? ? int pd_size;
>> ?};
>>
>> ?/* Macro to simplify populating a lookup table */
>> @@ -58,6 +59,10 @@ struct of_dev_auxdata {
>> ? ? ? ?{ .compatible = _compat, .phys_addr = _phys, .name = _name, \
>> ? ? ? ? ?.id = _id, .platform_data = _pdata }
>>
>> +#define OF_DEV_AUXDATA_ID_PDSIZE(_compat,_phys,_name,_id,_pdata,_pd_size)
>> \
>> + ? ? ? { .compatible = _compat, .phys_addr = _phys, .name = _name, \
>> + ? ? ? ? .id = _id, .platform_data = _pdata, .pd_size = _pd_size }
>> +
>> ?/**
>> ? * of_platform_driver - Legacy of-aware driver for platform devices.
>> ? *
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC/PATCH 10/14] dt: Add pd_size to AUXDATA structure

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 07:16:30AM -0600, Grant Likely wrote:
> On Wed, Aug 10, 2011 at 5:57 AM, Cousson, Benoit <b-cousson@ti.com> wrote:
> > On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> >>
> >> Add pd_size in the AUXDATA structure so that device drivers which require
> >> platform_data size can pass along with AUXDATA.
> >
> > It is really needed by device driver? Or is it because omap_device_build is
> > using platform_device_add_data that is doing a copy of the pdata and thus
> > require the size?
> 
> Yes, I have the same question.  What is the reason for needing the
> platform data size?

Yes. It is required by "omap_device_build" which in turn calls 
"platform_device_add_data" and copies using "kmemdup" and original
pdata pointer memory will get freed.

It is required by hwmod and not device driver. I can change description.

> 
> g.
> 
> >
> >> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> >> ---
> >>  drivers/of/platform.c       |    2 ++
> >>  include/linux/of_platform.h |    5 +++++
> >>  2 files changed, 7 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> >> index ebbbf42..4b27286 100644
> >> --- a/drivers/of/platform.c
> >> +++ b/drivers/of/platform.c
> >> @@ -565,6 +565,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;
> >
> > Maybe platform_data_size will be a little bit more consistent?

Thought shorter name is better and still it should be readable.

-M
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC/PATCH 10/14] dt: Add pd_size to AUXDATA structure

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 07:16:30AM -0600, Grant Likely wrote:
> On Wed, Aug 10, 2011 at 5:57 AM, Cousson, Benoit <b-cousson@ti.com> wrote:
> > On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> >>
> >> Add pd_size in the AUXDATA structure so that device drivers which require
> >> platform_data size can pass along with AUXDATA.
> >
> > It is really needed by device driver? Or is it because omap_device_build is
> > using platform_device_add_data that is doing a copy of the pdata and thus
> > require the size?
> 
> Yes, I have the same question.  What is the reason for needing the
> platform data size?

Yes. It is required by "omap_device_build" which in turn calls 
"platform_device_add_data" and copies using "kmemdup" and original
pdata pointer memory will get freed.

It is required by hwmod and not device driver. I can change description.

> 
> g.
> 
> >
> >> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> >> ---
> >> ?drivers/of/platform.c ? ? ? | ? ?2 ++
> >> ?include/linux/of_platform.h | ? ?5 +++++
> >> ?2 files changed, 7 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> >> index ebbbf42..4b27286 100644
> >> --- a/drivers/of/platform.c
> >> +++ b/drivers/of/platform.c
> >> @@ -565,6 +565,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;
> >
> > Maybe platform_data_size will be a little bit more consistent?

Thought shorter name is better and still it should be readable.

-M

Re: [RFC/PATCH 04/14] OMAP: McBSP: use existing macros for converting between devices

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 12:15:50PM +0200, Cousson, Benoit wrote:
> Manju,
> 
> On 8/10/2011 9:07 AM, Jarkko Nikula wrote:
> >Hi
> >
> >On Tue, 09 Aug 2011 19:10:22 +0500
> >"G, Manjunath Kondaiah"<manjugk@ti.com>  wrote:
> >
> >>From: Kevin Hilman<khilman@ti.com>
> >>
> >>For converting from struct device to platform_device, and from
> >>platform_device to struct device, there are existing macros.  Use
> >>them instead of manual use of container_of().
> >>
> >>Signed-off-by: Kevin Hilman<khilman@ti.com>
> >>---
> >>  arch/arm/plat-omap/mcbsp.c |    6 +++---
> >>  1 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >Kevin dropped this patch and used mine that does more cleanups:
> >
> >http://marc.info/?l=linux-omap&m=131255627918065&w=2
> >
> >Worth to check also other patches since Kevin's updated set seems to
> >have other differences too:
> >
> >http://marc.info/?l=linux-omap&m=131258997416300&w=2
> 
> In fact, you'd better point to the lastest Kevin's tree and not
> included the patches in this series.

Yes. I have already mentioned this in PATCH 00/14 and it will be rebased
during rework for review comments.

Main focus here is on dt-hwmod binding and omap-i2c dt adaptation.

-M

[RFC/PATCH 04/14] OMAP: McBSP: use existing macros for converting between devices

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 12:15:50PM +0200, Cousson, Benoit wrote:
> Manju,
> 
> On 8/10/2011 9:07 AM, Jarkko Nikula wrote:
> >Hi
> >
> >On Tue, 09 Aug 2011 19:10:22 +0500
> >"G, Manjunath Kondaiah"<manjugk@ti.com>  wrote:
> >
> >>From: Kevin Hilman<khilman@ti.com>
> >>
> >>For converting from struct device to platform_device, and from
> >>platform_device to struct device, there are existing macros.  Use
> >>them instead of manual use of container_of().
> >>
> >>Signed-off-by: Kevin Hilman<khilman@ti.com>
> >>---
> >>  arch/arm/plat-omap/mcbsp.c |    6 +++---
> >>  1 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >Kevin dropped this patch and used mine that does more cleanups:
> >
> >http://marc.info/?l=linux-omap&m=131255627918065&w=2
> >
> >Worth to check also other patches since Kevin's updated set seems to
> >have other differences too:
> >
> >http://marc.info/?l=linux-omap&m=131258997416300&w=2
> 
> In fact, you'd better point to the lastest Kevin's tree and not
> included the patches in this series.

Yes. I have already mentioned this in PATCH 00/14 and it will be rebased
during rework for review comments.

Main focus here is on dt-hwmod binding and omap-i2c dt adaptation.

-M

Re: [RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
> Hi Manju,
> 
> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> >
> >The omap dt requires new omap hwmod api to be added for in order
> >to support omap dt.
> 
> Both the subject and the changelog are misleading. You are not doing
> any hwmod stuff in it.
> You are just passing an "of_node" pointer during omap_device_build_ss.
> 
> The subject should start with OMAP: omap_device: because it does not
> belong to the DT subsystem.
> The same comment apply to most patches in that series.

The goal of this patch is to make omap-hwmod ready for dt adaptation hence
I used the title "dt: omap: prepare hwmod to support dt" and "of_node" pointer
is passed from dt and it is required for dt build.

And as you mentioned, patch does not do anything related to omap_device.

> 
> >The new api is added and new parameter "np" is added for existing
> >api.
> 
> I don't think np is not a super meaningful name. Some more
> explanation are needed as well.

ok. I can expand it.

> 
> >The users of hwmod api is changed accrodingly.
> 
> omap_device API + typo.
> 
> >Build and boot tested on omap3 beagle for both dt and not dt build.
> >
> >Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> >---
> >  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              |   53 ++++++++++++++++++++++---
> >  4 files changed, 59 insertions(+), 9 deletions(-)
> >
> >diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> >index 458f7be..d7ff1ae 100644
> >--- a/arch/arm/mach-omap2/devices.c
> >+++ b/arch/arm/mach-omap2/devices.c
> >@@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)
> >  			pr_err("could not look up %s\n", oh_name);
> >  	}
> >
> >-	pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
> >+	pdev = omap_device_build_ss(NULL, "omap_l3_noc", 0, oh, 3, NULL,
> >  						     0, NULL, 0, 0);
> 
> OK, maybe that is just me, but in order to extend an API, I'd rather
> add the new parameter at the end.

I feel it's fine since node pointer is first parameter is all dt api's.

> 
> >  	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
> >diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
> >index 7a42f32..98eb95d 100644
> >--- a/arch/arm/mach-omap2/mcbsp.c
> >+++ b/arch/arm/mach-omap2/mcbsp.c
> >@@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
> >  		(struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
> >  		count++;
> >  	}
> >-	pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
> >+	pdev = omap_device_build_ss(NULL, name, id, oh_device, count, pdata,
> >  				sizeof(*pdata), omap2_mcbsp_latency,
> >  				ARRAY_SIZE(omap2_mcbsp_latency), false);
> >  	kfree(pdata);
> >diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
> >index 7a3ec4f..5e2424b 100644
> >--- a/arch/arm/plat-omap/include/plat/omap_device.h
> >+++ b/arch/arm/plat-omap/include/plat/omap_device.h
> >@@ -33,6 +33,7 @@
> >
> >  #include<linux/kernel.h>
> >  #include<linux/platform_device.h>
> >+#include<linux/of.h>
> >
> >  #include<plat/omap_hwmod.h>
> >
> >@@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> >  				      struct omap_device_pm_latency *pm_lats,
> >  				      int pm_lats_cnt, int is_early_device);
> >
> >-struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> >+struct platform_device *omap_device_build_ss(struct device_node *np,
> >+					 const char *pdev_name, int pdev_id,
> >  					 struct omap_hwmod **oh, int oh_cnt,
> >  					 void *pdata, int pdata_len,
> >  					 struct omap_device_pm_latency *pm_lats,
> >  					 int pm_lats_cnt, int is_early_device);
> >
> >+struct platform_device *omap_device_build_dt(struct device_node *np,
> >+				      const char *pdev_name, int pdev_id,
> >+				      struct omap_hwmod *oh, void *pdata,
> >+				      int pdata_len,
> >+				      struct omap_device_pm_latency *pm_lats,
> >+				      int pm_lats_cnt, int is_early_device);
> >+
> >  void __iomem *omap_device_get_rt_va(struct omap_device *od);
> >
> >  /* OMAP PM interface */
> >diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
> >index 7d5e76b..fa49168 100644
> >--- a/arch/arm/plat-omap/omap_device.c
> >+++ b/arch/arm/plat-omap/omap_device.c
> >@@ -85,6 +85,7 @@
> >  #include<linux/clk.h>
> >  #include<linux/clkdev.h>
> >  #include<linux/pm_runtime.h>
> >+#include<linux/of_device.h>
> >
> >  #include<plat/omap_device.h>
> >  #include<plat/omap_hwmod.h>
> >@@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device *od,
> >  /**
> >   * omap_device_build - build and register an omap_device with one omap_hwmod
> 
> Need to update the kerneldoc.
ok.
> 
> >   * @pdev_name: name of the platform_device driver to use
> >+ * @np: device node pointer for attaching it to of_node pointer
> >   * @pdev_id: this platform_device's connection ID
> >   * @oh: ptr to the single omap_hwmod that backs this omap_device
> >   * @pdata: platform_data ptr to associate with the platform_device
> >@@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device *od,
> >   * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
> >   * passes along the return value of omap_device_build_ss().
> >   */
> >-struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> >+struct platform_device *omap_device_build_dt(struct device_node *np,
> >+				      const char *pdev_name, int pdev_id,
> >  				      struct omap_hwmod *oh, void *pdata,
> >  				      int pdata_len,
> >  				      struct omap_device_pm_latency *pm_lats,
> 
> That function should not be needed. You have to export
> omap_device_build_ss, otherwise you will not build any device with
> multiple hwmods.
ok.
> 
> >@@ -402,12 +405,44 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> >  	if (!oh)
> >  		return ERR_PTR(-EINVAL);
> >
> >-	return omap_device_build_ss(pdev_name, pdev_id, ohs, 1, pdata,
> >+	return omap_device_build_ss(np, pdev_name, pdev_id, ohs, 1, pdata,
> >  				    pdata_len, pm_lats, pm_lats_cnt,
> >  				    is_early_device);
> >  }
> >
> >  /**
> >+ * omap_device_build - build and register an omap_device with one omap_hwmod
> >+ * @pdev_name: name of the platform_device driver to use
> >+ * @pdev_id: this platform_device's connection ID
> >+ * @oh: ptr to the single omap_hwmod that backs this omap_device
> >+ * @pdata: platform_data ptr to associate with the platform_device
> >+ * @pdata_len: amount of memory pointed to by @pdata
> >+ * @pm_lats: pointer to a omap_device_pm_latency array for this device
> >+ * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
> >+ * @is_early_device: should the device be registered as an early device or not
> >+ *
> >+ * Convenience function for building and registering a single
> >+ * omap_device record, which in turn builds and registers a
> >+ * platform_device record.  See omap_device_build_ss() for more
> >+ * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
> >+ * passes along the return value of omap_device_build_ss().
> >+ */
> >+struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> >+				      struct omap_hwmod *oh, void *pdata,
> >+				      int pdata_len,
> >+				      struct omap_device_pm_latency *pm_lats,
> >+				      int pm_lats_cnt, int is_early_device)
> >+{
> >+	struct omap_hwmod *ohs[] = { oh };
> >+
> >+	if (!oh)
> >+		return ERR_PTR(-EINVAL);
> >+
> >+	return omap_device_build_ss(NULL, pdev_name, pdev_id, ohs, 1, pdata,
> >+			pdata_len, pm_lats, pm_lats_cnt, is_early_device);
> >+}
> >+
> >+/**
> >   * omap_device_build_ss - build and register an omap_device with multiple hwmods
> >   * @pdev_name: name of the platform_device driver to use
> >   * @pdev_id: this platform_device's connection ID
> >@@ -424,7 +459,8 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> >   * platform_device record.  Returns an ERR_PTR() on error, or passes
> >   * along the return value of omap_device_register().
> >   */
> >-struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> >+struct platform_device *omap_device_build_ss(struct device_node *np,
> >+					 const char *pdev_name, int pdev_id,
> >  					 struct omap_hwmod **ohs, int oh_cnt,
> >  					 void *pdata, int pdata_len,
> >  					 struct omap_device_pm_latency *pm_lats,
> >@@ -436,6 +472,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> >  	struct resource *res = NULL;
> >  	int i, res_count;
> >  	struct omap_hwmod **hwmods;
> >+	struct platform_device *pdev;
> >
> >  	if (!ohs || oh_cnt == 0 || !pdev_name)
> >  		return ERR_PTR(-EINVAL);
> >@@ -450,6 +487,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> >  	if (!od)
> >  		return ERR_PTR(-ENOMEM);
> >
> >+	pdev =&od->pdev;
> 
> Why do you need that? You are just adding one more user of the pdev.

just improve readability otherwise we need to have &od->pdev at multiple places
below.

> 
> >  	od->hwmods_cnt = oh_cnt;
> >
> >  	hwmods = kzalloc(sizeof(struct omap_hwmod *) * oh_cnt,
> >@@ -465,8 +503,11 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> >  		goto odbs_exit2;
> >  	strcpy(pdev_name2, pdev_name);
> >
> >-	od->pdev.name = pdev_name2;
> >-	od->pdev.id = pdev_id;
> >+#ifdef CONFIG_OF_DEVICE
> >+	pdev->dev.of_node = of_node_get(np);
> >+#endif
> >+	pdev->name = pdev_name2;
> >+	pdev->id = pdev_id;
> >
> >  	res_count = omap_device_count_resources(od);
> >  	if (res_count>  0) {
> >@@ -499,7 +540,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> >  	if (ret)
> >  		goto odbs_exit4;
> >
> >-	return&od->pdev;
> >+	return pdev;
> >
> >  odbs_exit4:
> >  	kfree(res);
> 
> Regards,
> Benoit
> 
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

[RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
> Hi Manju,
> 
> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> >
> >The omap dt requires new omap hwmod api to be added for in order
> >to support omap dt.
> 
> Both the subject and the changelog are misleading. You are not doing
> any hwmod stuff in it.
> You are just passing an "of_node" pointer during omap_device_build_ss.
> 
> The subject should start with OMAP: omap_device: because it does not
> belong to the DT subsystem.
> The same comment apply to most patches in that series.

The goal of this patch is to make omap-hwmod ready for dt adaptation hence
I used the title "dt: omap: prepare hwmod to support dt" and "of_node" pointer
is passed from dt and it is required for dt build.

And as you mentioned, patch does not do anything related to omap_device.

> 
> >The new api is added and new parameter "np" is added for existing
> >api.
> 
> I don't think np is not a super meaningful name. Some more
> explanation are needed as well.

ok. I can expand it.

> 
> >The users of hwmod api is changed accrodingly.
> 
> omap_device API + typo.
> 
> >Build and boot tested on omap3 beagle for both dt and not dt build.
> >
> >Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> >---
> >  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              |   53 ++++++++++++++++++++++---
> >  4 files changed, 59 insertions(+), 9 deletions(-)
> >
> >diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> >index 458f7be..d7ff1ae 100644
> >--- a/arch/arm/mach-omap2/devices.c
> >+++ b/arch/arm/mach-omap2/devices.c
> >@@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)
> >  			pr_err("could not look up %s\n", oh_name);
> >  	}
> >
> >-	pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
> >+	pdev = omap_device_build_ss(NULL, "omap_l3_noc", 0, oh, 3, NULL,
> >  						     0, NULL, 0, 0);
> 
> OK, maybe that is just me, but in order to extend an API, I'd rather
> add the new parameter at the end.

I feel it's fine since node pointer is first parameter is all dt api's.

> 
> >  	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
> >diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
> >index 7a42f32..98eb95d 100644
> >--- a/arch/arm/mach-omap2/mcbsp.c
> >+++ b/arch/arm/mach-omap2/mcbsp.c
> >@@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
> >  		(struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
> >  		count++;
> >  	}
> >-	pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
> >+	pdev = omap_device_build_ss(NULL, name, id, oh_device, count, pdata,
> >  				sizeof(*pdata), omap2_mcbsp_latency,
> >  				ARRAY_SIZE(omap2_mcbsp_latency), false);
> >  	kfree(pdata);
> >diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
> >index 7a3ec4f..5e2424b 100644
> >--- a/arch/arm/plat-omap/include/plat/omap_device.h
> >+++ b/arch/arm/plat-omap/include/plat/omap_device.h
> >@@ -33,6 +33,7 @@
> >
> >  #include<linux/kernel.h>
> >  #include<linux/platform_device.h>
> >+#include<linux/of.h>
> >
> >  #include<plat/omap_hwmod.h>
> >
> >@@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> >  				      struct omap_device_pm_latency *pm_lats,
> >  				      int pm_lats_cnt, int is_early_device);
> >
> >-struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> >+struct platform_device *omap_device_build_ss(struct device_node *np,
> >+					 const char *pdev_name, int pdev_id,
> >  					 struct omap_hwmod **oh, int oh_cnt,
> >  					 void *pdata, int pdata_len,
> >  					 struct omap_device_pm_latency *pm_lats,
> >  					 int pm_lats_cnt, int is_early_device);
> >
> >+struct platform_device *omap_device_build_dt(struct device_node *np,
> >+				      const char *pdev_name, int pdev_id,
> >+				      struct omap_hwmod *oh, void *pdata,
> >+				      int pdata_len,
> >+				      struct omap_device_pm_latency *pm_lats,
> >+				      int pm_lats_cnt, int is_early_device);
> >+
> >  void __iomem *omap_device_get_rt_va(struct omap_device *od);
> >
> >  /* OMAP PM interface */
> >diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
> >index 7d5e76b..fa49168 100644
> >--- a/arch/arm/plat-omap/omap_device.c
> >+++ b/arch/arm/plat-omap/omap_device.c
> >@@ -85,6 +85,7 @@
> >  #include<linux/clk.h>
> >  #include<linux/clkdev.h>
> >  #include<linux/pm_runtime.h>
> >+#include<linux/of_device.h>
> >
> >  #include<plat/omap_device.h>
> >  #include<plat/omap_hwmod.h>
> >@@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device *od,
> >  /**
> >   * omap_device_build - build and register an omap_device with one omap_hwmod
> 
> Need to update the kerneldoc.
ok.
> 
> >   * @pdev_name: name of the platform_device driver to use
> >+ * @np: device node pointer for attaching it to of_node pointer
> >   * @pdev_id: this platform_device's connection ID
> >   * @oh: ptr to the single omap_hwmod that backs this omap_device
> >   * @pdata: platform_data ptr to associate with the platform_device
> >@@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device *od,
> >   * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
> >   * passes along the return value of omap_device_build_ss().
> >   */
> >-struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> >+struct platform_device *omap_device_build_dt(struct device_node *np,
> >+				      const char *pdev_name, int pdev_id,
> >  				      struct omap_hwmod *oh, void *pdata,
> >  				      int pdata_len,
> >  				      struct omap_device_pm_latency *pm_lats,
> 
> That function should not be needed. You have to export
> omap_device_build_ss, otherwise you will not build any device with
> multiple hwmods.
ok.
> 
> >@@ -402,12 +405,44 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> >  	if (!oh)
> >  		return ERR_PTR(-EINVAL);
> >
> >-	return omap_device_build_ss(pdev_name, pdev_id, ohs, 1, pdata,
> >+	return omap_device_build_ss(np, pdev_name, pdev_id, ohs, 1, pdata,
> >  				    pdata_len, pm_lats, pm_lats_cnt,
> >  				    is_early_device);
> >  }
> >
> >  /**
> >+ * omap_device_build - build and register an omap_device with one omap_hwmod
> >+ * @pdev_name: name of the platform_device driver to use
> >+ * @pdev_id: this platform_device's connection ID
> >+ * @oh: ptr to the single omap_hwmod that backs this omap_device
> >+ * @pdata: platform_data ptr to associate with the platform_device
> >+ * @pdata_len: amount of memory pointed to by @pdata
> >+ * @pm_lats: pointer to a omap_device_pm_latency array for this device
> >+ * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
> >+ * @is_early_device: should the device be registered as an early device or not
> >+ *
> >+ * Convenience function for building and registering a single
> >+ * omap_device record, which in turn builds and registers a
> >+ * platform_device record.  See omap_device_build_ss() for more
> >+ * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
> >+ * passes along the return value of omap_device_build_ss().
> >+ */
> >+struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> >+				      struct omap_hwmod *oh, void *pdata,
> >+				      int pdata_len,
> >+				      struct omap_device_pm_latency *pm_lats,
> >+				      int pm_lats_cnt, int is_early_device)
> >+{
> >+	struct omap_hwmod *ohs[] = { oh };
> >+
> >+	if (!oh)
> >+		return ERR_PTR(-EINVAL);
> >+
> >+	return omap_device_build_ss(NULL, pdev_name, pdev_id, ohs, 1, pdata,
> >+			pdata_len, pm_lats, pm_lats_cnt, is_early_device);
> >+}
> >+
> >+/**
> >   * omap_device_build_ss - build and register an omap_device with multiple hwmods
> >   * @pdev_name: name of the platform_device driver to use
> >   * @pdev_id: this platform_device's connection ID
> >@@ -424,7 +459,8 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> >   * platform_device record.  Returns an ERR_PTR() on error, or passes
> >   * along the return value of omap_device_register().
> >   */
> >-struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> >+struct platform_device *omap_device_build_ss(struct device_node *np,
> >+					 const char *pdev_name, int pdev_id,
> >  					 struct omap_hwmod **ohs, int oh_cnt,
> >  					 void *pdata, int pdata_len,
> >  					 struct omap_device_pm_latency *pm_lats,
> >@@ -436,6 +472,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> >  	struct resource *res = NULL;
> >  	int i, res_count;
> >  	struct omap_hwmod **hwmods;
> >+	struct platform_device *pdev;
> >
> >  	if (!ohs || oh_cnt == 0 || !pdev_name)
> >  		return ERR_PTR(-EINVAL);
> >@@ -450,6 +487,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> >  	if (!od)
> >  		return ERR_PTR(-ENOMEM);
> >
> >+	pdev =&od->pdev;
> 
> Why do you need that? You are just adding one more user of the pdev.

just improve readability otherwise we need to have &od->pdev at multiple places
below.

> 
> >  	od->hwmods_cnt = oh_cnt;
> >
> >  	hwmods = kzalloc(sizeof(struct omap_hwmod *) * oh_cnt,
> >@@ -465,8 +503,11 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> >  		goto odbs_exit2;
> >  	strcpy(pdev_name2, pdev_name);
> >
> >-	od->pdev.name = pdev_name2;
> >-	od->pdev.id = pdev_id;
> >+#ifdef CONFIG_OF_DEVICE
> >+	pdev->dev.of_node = of_node_get(np);
> >+#endif
> >+	pdev->name = pdev_name2;
> >+	pdev->id = pdev_id;
> >
> >  	res_count = omap_device_count_resources(od);
> >  	if (res_count>  0) {
> >@@ -499,7 +540,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> >  	if (ret)
> >  		goto odbs_exit4;
> >
> >-	return&od->pdev;
> >+	return pdev;
> >
> >  odbs_exit4:
> >  	kfree(res);
> 
> Regards,
> Benoit
> 
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [RFC/PATCH 12/14] dt: omap3: beagle board: set clock freq for i2c devices

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 02:42:56PM +0200, Cousson, Benoit wrote:
> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> >
> >Update omap3 beagle dts file with required clock frequencies for the i2c
> >client devices existing on beagle board.
> >
> >Beagle custom board dts file is cleaned up so that it can coexist with omap3
> >soc dts file.
> >
> >Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> >---
> >  arch/arm/boot/dts/omap3-beagle-nunchuck.dts |   11 +----------
> >  arch/arm/boot/dts/omap3-beagle.dts          |   18 +++++++++++++++---
> >  2 files changed, 16 insertions(+), 13 deletions(-)
> >
> >diff --git a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> >index 2607be5..324ff86 100644
> >--- a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> >+++ b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> >@@ -1,16 +1,7 @@
> >  /include/ "omap3-beagle.dts"
> >
> >  / {
> >-	i2c@48072000 {
> >-		compatible = "ti,omap3-i2c";
> >-		reg =<0x48072000 0x80>;
> >-		#address-cells =<1>;
> >-		#size-cells =<0>;
> >-
> >-		eeprom@50 {
> >-			compatible = "at,at24c01";
> >-			reg =<  0x50>;
> >-		};
> 
> This change should probably not be there.
> 
> >+	i2c@2 {
> >  		joystick@52 {
> >  			compatible = "sparkfun,wiichuck";
> 
> It looks like someone is having fun with a beagle connected to a Wii
> nunchuck:-)
It's custom beagle belong to grant :)

> 
> >  			reg =<  0x52>;
> >diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
> >index 4439466..49a5ac7 100644
> >--- a/arch/arm/boot/dts/omap3-beagle.dts
> >+++ b/arch/arm/boot/dts/omap3-beagle.dts
> >@@ -1,7 +1,19 @@
> >-/dts-v1/;
> >-/include/ "skeleton.dtsi"
> >+/include/ "omap3-soc.dtsi"
> 
> There is no need for the "-soc" postfix, otherwise all the other
> SoCs inside DTS directory should have it.
ok.

-M

[RFC/PATCH 12/14] dt: omap3: beagle board: set clock freq for i2c devices

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 02:42:56PM +0200, Cousson, Benoit wrote:
> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> >
> >Update omap3 beagle dts file with required clock frequencies for the i2c
> >client devices existing on beagle board.
> >
> >Beagle custom board dts file is cleaned up so that it can coexist with omap3
> >soc dts file.
> >
> >Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> >---
> >  arch/arm/boot/dts/omap3-beagle-nunchuck.dts |   11 +----------
> >  arch/arm/boot/dts/omap3-beagle.dts          |   18 +++++++++++++++---
> >  2 files changed, 16 insertions(+), 13 deletions(-)
> >
> >diff --git a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> >index 2607be5..324ff86 100644
> >--- a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> >+++ b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> >@@ -1,16 +1,7 @@
> >  /include/ "omap3-beagle.dts"
> >
> >  / {
> >-	i2c at 48072000 {
> >-		compatible = "ti,omap3-i2c";
> >-		reg =<0x48072000 0x80>;
> >-		#address-cells =<1>;
> >-		#size-cells =<0>;
> >-
> >-		eeprom at 50 {
> >-			compatible = "at,at24c01";
> >-			reg =<  0x50>;
> >-		};
> 
> This change should probably not be there.
> 
> >+	i2c at 2 {
> >  		joystick at 52 {
> >  			compatible = "sparkfun,wiichuck";
> 
> It looks like someone is having fun with a beagle connected to a Wii
> nunchuck:-)
It's custom beagle belong to grant :)

> 
> >  			reg =<  0x52>;
> >diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
> >index 4439466..49a5ac7 100644
> >--- a/arch/arm/boot/dts/omap3-beagle.dts
> >+++ b/arch/arm/boot/dts/omap3-beagle.dts
> >@@ -1,7 +1,19 @@
> >-/dts-v1/;
> >-/include/ "skeleton.dtsi"
> >+/include/ "omap3-soc.dtsi"
> 
> There is no need for the "-soc" postfix, otherwise all the other
> SoCs inside DTS directory should have it.
ok.

-M

Re: [RFC/PATCH 11/14] dt: omap3: add soc file for handling i2c controllers

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 02:36:50PM +0200, Cousson, Benoit wrote:
> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> >
> >Add omap3 soc file for handling omap3 soc i2c controllers existing
> >on l4-core bus.
> >
> >Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> >---
> >  arch/arm/boot/dts/omap3-soc.dtsi |   62 ++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 62 insertions(+), 0 deletions(-)
> >  create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
> >
> >diff --git a/arch/arm/boot/dts/omap3-soc.dtsi b/arch/arm/boot/dts/omap3-soc.dtsi
> >new file mode 100644
> >index 0000000..85de92f
> >--- /dev/null
> >+++ b/arch/arm/boot/dts/omap3-soc.dtsi
> >@@ -0,0 +1,62 @@
> >+/*
> >+ * Device Tree Source for OMAP3 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/;
> >+/include/ "skeleton.dtsi"
> >+
> >+/ {
> >+	#address-cells =<1>;
> >+	#size-cells =<1>;
> >+	model = "ti,omap3";
> >+
> >+	aliases {
> >+		i2c1 =&i2c1;
> >+		i2c2 =&i2c2;
> >+		i2c3 =&i2c3;
> >+	};
> >+
> >+	l4-core {
> 
> That comment is probably subject to discussion, but even if this
> interconnect is there physically, I'm not sure of the added value to
> add it.
> It will add an extra level of indentation and that all. Moreover, it
> will mess up the physical address that are expressed using absolute
> value in the TRM with a less readable offset value.
> In fact, most DTS files in the ARM directory are using a purely flat
> representation of the interconnect.
This is as per alignment with Tony and Grant:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/60391

> 
> >+		compatible = "ti,omap3-l4-core";
> 
> Assuming we will keep that, you should probably add a more generic
> compatible name after that one. Like "ti,s3220" or even
> "sonics,s3220", assuming that this IP is generic enough for other
> SoC.
will check this. I don't remember any generic names.
> 
> >+		#address-cells =<1>;
> >+		#size-cells =<1>;
> >+		ranges =<0 0x48000000 0x1000000>;
> >+
> >+		i2c1: i2c@70000 {
> >+			#address-cells =<1>;
> >+			#size-cells =<0>;
> >+			compatible = "ti,omap3-i2c";
> 
> The I2C IP and thus the driver is generic across OMAP generations
> and is even potentially used by other non-OMAP TI chips like DSP or
> Davinci. So having an extra compatible entry with "ti,i2c" or "ti,
> omap-i2c" seems mandatory.
This can be updated as and when new soc/board adaptations are done. 
As of now, it is omap3 and when we have omap4 it will be appended with
"ti,omap4-i2c" etc

-M

[RFC/PATCH 11/14] dt: omap3: add soc file for handling i2c controllers

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 02:36:50PM +0200, Cousson, Benoit wrote:
> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> >
> >Add omap3 soc file for handling omap3 soc i2c controllers existing
> >on l4-core bus.
> >
> >Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> >---
> >  arch/arm/boot/dts/omap3-soc.dtsi |   62 ++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 62 insertions(+), 0 deletions(-)
> >  create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
> >
> >diff --git a/arch/arm/boot/dts/omap3-soc.dtsi b/arch/arm/boot/dts/omap3-soc.dtsi
> >new file mode 100644
> >index 0000000..85de92f
> >--- /dev/null
> >+++ b/arch/arm/boot/dts/omap3-soc.dtsi
> >@@ -0,0 +1,62 @@
> >+/*
> >+ * Device Tree Source for OMAP3 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/;
> >+/include/ "skeleton.dtsi"
> >+
> >+/ {
> >+	#address-cells =<1>;
> >+	#size-cells =<1>;
> >+	model = "ti,omap3";
> >+
> >+	aliases {
> >+		i2c1 =&i2c1;
> >+		i2c2 =&i2c2;
> >+		i2c3 =&i2c3;
> >+	};
> >+
> >+	l4-core {
> 
> That comment is probably subject to discussion, but even if this
> interconnect is there physically, I'm not sure of the added value to
> add it.
> It will add an extra level of indentation and that all. Moreover, it
> will mess up the physical address that are expressed using absolute
> value in the TRM with a less readable offset value.
> In fact, most DTS files in the ARM directory are using a purely flat
> representation of the interconnect.
This is as per alignment with Tony and Grant:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/60391

> 
> >+		compatible = "ti,omap3-l4-core";
> 
> Assuming we will keep that, you should probably add a more generic
> compatible name after that one. Like "ti,s3220" or even
> "sonics,s3220", assuming that this IP is generic enough for other
> SoC.
will check this. I don't remember any generic names.
> 
> >+		#address-cells =<1>;
> >+		#size-cells =<1>;
> >+		ranges =<0 0x48000000 0x1000000>;
> >+
> >+		i2c1: i2c at 70000 {
> >+			#address-cells =<1>;
> >+			#size-cells =<0>;
> >+			compatible = "ti,omap3-i2c";
> 
> The I2C IP and thus the driver is generic across OMAP generations
> and is even potentially used by other non-OMAP TI chips like DSP or
> Davinci. So having an extra compatible entry with "ti,i2c" or "ti,
> omap-i2c" seems mandatory.
This can be updated as and when new soc/board adaptations are done. 
As of now, it is omap3 and when we have omap4 it will be appended with
"ti,omap4-i2c" etc

-M

Re: [RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt

[Cousson, Benoit]

On 8/10/2011 6:28 PM, G, Manjunath Kondaiah wrote:
> On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
>> Hi Manju,
>>
>> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>>>
>>> The omap dt requires new omap hwmod api to be added for in order
>>> to support omap dt.
>>
>> Both the subject and the changelog are misleading. You are not doing
>> any hwmod stuff in it.
>> You are just passing an "of_node" pointer during omap_device_build_ss.
>>
>> The subject should start with OMAP: omap_device: because it does not
>> belong to the DT subsystem.
>> The same comment apply to most patches in that series.
>
> The goal of this patch is to make omap-hwmod ready for dt adaptation hence
> I used the title "dt: omap: prepare hwmod to support dt" and "of_node" pointer
> is passed from dt and it is required for dt build.

I think that the goal of this patch is to update the 
omap_device_build_ss API in order to provide a device tree node pointer 
to pdev. For the moment there is nothing related to hwmod.

> And as you mentioned, patch does not do anything related to omap_device.

You meant omap_hwmod?

Benoit

>>> The new api is added and new parameter "np" is added for existing
>>> api.
>>
>> I don't think np is not a super meaningful name. Some more
>> explanation are needed as well.
>
> ok. I can expand it.
>
>>
>>> The users of hwmod api is changed accrodingly.
>>
>> omap_device API + typo.
>>
>>> Build and boot tested on omap3 beagle for both dt and not dt build.
>>>
>>> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
>>> ---
>>>   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              |   53 ++++++++++++++++++++++---
>>>   4 files changed, 59 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
>>> index 458f7be..d7ff1ae 100644
>>> --- a/arch/arm/mach-omap2/devices.c
>>> +++ b/arch/arm/mach-omap2/devices.c
>>> @@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)
>>>   			pr_err("could not look up %s\n", oh_name);
>>>   	}
>>>
>>> -	pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
>>> +	pdev = omap_device_build_ss(NULL, "omap_l3_noc", 0, oh, 3, NULL,
>>>   						     0, NULL, 0, 0);
>>
>> OK, maybe that is just me, but in order to extend an API, I'd rather
>> add the new parameter at the end.
>
> I feel it's fine since node pointer is first parameter is all dt api's.
>
>>
>>>   	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
>>> diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
>>> index 7a42f32..98eb95d 100644
>>> --- a/arch/arm/mach-omap2/mcbsp.c
>>> +++ b/arch/arm/mach-omap2/mcbsp.c
>>> @@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
>>>   		(struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
>>>   		count++;
>>>   	}
>>> -	pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
>>> +	pdev = omap_device_build_ss(NULL, name, id, oh_device, count, pdata,
>>>   				sizeof(*pdata), omap2_mcbsp_latency,
>>>   				ARRAY_SIZE(omap2_mcbsp_latency), false);
>>>   	kfree(pdata);
>>> diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
>>> index 7a3ec4f..5e2424b 100644
>>> --- a/arch/arm/plat-omap/include/plat/omap_device.h
>>> +++ b/arch/arm/plat-omap/include/plat/omap_device.h
>>> @@ -33,6 +33,7 @@
>>>
>>>   #include<linux/kernel.h>
>>>   #include<linux/platform_device.h>
>>> +#include<linux/of.h>
>>>
>>>   #include<plat/omap_hwmod.h>
>>>
>>> @@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>>>   				      struct omap_device_pm_latency *pm_lats,
>>>   				      int pm_lats_cnt, int is_early_device);
>>>
>>> -struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>>> +struct platform_device *omap_device_build_ss(struct device_node *np,
>>> +					 const char *pdev_name, int pdev_id,
>>>   					 struct omap_hwmod **oh, int oh_cnt,
>>>   					 void *pdata, int pdata_len,
>>>   					 struct omap_device_pm_latency *pm_lats,
>>>   					 int pm_lats_cnt, int is_early_device);
>>>
>>> +struct platform_device *omap_device_build_dt(struct device_node *np,
>>> +				      const char *pdev_name, int pdev_id,
>>> +				      struct omap_hwmod *oh, void *pdata,
>>> +				      int pdata_len,
>>> +				      struct omap_device_pm_latency *pm_lats,
>>> +				      int pm_lats_cnt, int is_early_device);
>>> +
>>>   void __iomem *omap_device_get_rt_va(struct omap_device *od);
>>>
>>>   /* OMAP PM interface */
>>> diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
>>> index 7d5e76b..fa49168 100644
>>> --- a/arch/arm/plat-omap/omap_device.c
>>> +++ b/arch/arm/plat-omap/omap_device.c
>>> @@ -85,6 +85,7 @@
>>>   #include<linux/clk.h>
>>>   #include<linux/clkdev.h>
>>>   #include<linux/pm_runtime.h>
>>> +#include<linux/of_device.h>
>>>
>>>   #include<plat/omap_device.h>
>>>   #include<plat/omap_hwmod.h>
>>> @@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device *od,
>>>   /**
>>>    * omap_device_build - build and register an omap_device with one omap_hwmod
>>
>> Need to update the kerneldoc.
> ok.
>>
>>>    * @pdev_name: name of the platform_device driver to use
>>> + * @np: device node pointer for attaching it to of_node pointer
>>>    * @pdev_id: this platform_device's connection ID
>>>    * @oh: ptr to the single omap_hwmod that backs this omap_device
>>>    * @pdata: platform_data ptr to associate with the platform_device
>>> @@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device *od,
>>>    * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
>>>    * passes along the return value of omap_device_build_ss().
>>>    */
>>> -struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>>> +struct platform_device *omap_device_build_dt(struct device_node *np,
>>> +				      const char *pdev_name, int pdev_id,
>>>   				      struct omap_hwmod *oh, void *pdata,
>>>   				      int pdata_len,
>>>   				      struct omap_device_pm_latency *pm_lats,
>>
>> That function should not be needed. You have to export
>> omap_device_build_ss, otherwise you will not build any device with
>> multiple hwmods.
> ok.
>>
>>> @@ -402,12 +405,44 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>>>   	if (!oh)
>>>   		return ERR_PTR(-EINVAL);
>>>
>>> -	return omap_device_build_ss(pdev_name, pdev_id, ohs, 1, pdata,
>>> +	return omap_device_build_ss(np, pdev_name, pdev_id, ohs, 1, pdata,
>>>   				    pdata_len, pm_lats, pm_lats_cnt,
>>>   				    is_early_device);
>>>   }
>>>
>>>   /**
>>> + * omap_device_build - build and register an omap_device with one omap_hwmod
>>> + * @pdev_name: name of the platform_device driver to use
>>> + * @pdev_id: this platform_device's connection ID
>>> + * @oh: ptr to the single omap_hwmod that backs this omap_device
>>> + * @pdata: platform_data ptr to associate with the platform_device
>>> + * @pdata_len: amount of memory pointed to by @pdata
>>> + * @pm_lats: pointer to a omap_device_pm_latency array for this device
>>> + * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
>>> + * @is_early_device: should the device be registered as an early device or not
>>> + *
>>> + * Convenience function for building and registering a single
>>> + * omap_device record, which in turn builds and registers a
>>> + * platform_device record.  See omap_device_build_ss() for more
>>> + * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
>>> + * passes along the return value of omap_device_build_ss().
>>> + */
>>> +struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>>> +				      struct omap_hwmod *oh, void *pdata,
>>> +				      int pdata_len,
>>> +				      struct omap_device_pm_latency *pm_lats,
>>> +				      int pm_lats_cnt, int is_early_device)
>>> +{
>>> +	struct omap_hwmod *ohs[] = { oh };
>>> +
>>> +	if (!oh)
>>> +		return ERR_PTR(-EINVAL);
>>> +
>>> +	return omap_device_build_ss(NULL, pdev_name, pdev_id, ohs, 1, pdata,
>>> +			pdata_len, pm_lats, pm_lats_cnt, is_early_device);
>>> +}
>>> +
>>> +/**
>>>    * omap_device_build_ss - build and register an omap_device with multiple hwmods
>>>    * @pdev_name: name of the platform_device driver to use
>>>    * @pdev_id: this platform_device's connection ID
>>> @@ -424,7 +459,8 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>>>    * platform_device record.  Returns an ERR_PTR() on error, or passes
>>>    * along the return value of omap_device_register().
>>>    */
>>> -struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>>> +struct platform_device *omap_device_build_ss(struct device_node *np,
>>> +					 const char *pdev_name, int pdev_id,
>>>   					 struct omap_hwmod **ohs, int oh_cnt,
>>>   					 void *pdata, int pdata_len,
>>>   					 struct omap_device_pm_latency *pm_lats,
>>> @@ -436,6 +472,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>>>   	struct resource *res = NULL;
>>>   	int i, res_count;
>>>   	struct omap_hwmod **hwmods;
>>> +	struct platform_device *pdev;
>>>
>>>   	if (!ohs || oh_cnt == 0 || !pdev_name)
>>>   		return ERR_PTR(-EINVAL);
>>> @@ -450,6 +487,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>>>   	if (!od)
>>>   		return ERR_PTR(-ENOMEM);
>>>
>>> +	pdev =&od->pdev;
>>
>> Why do you need that? You are just adding one more user of the pdev.
>
> just improve readability otherwise we need to have&od->pdev at multiple places
> below.
>
>>
>>>   	od->hwmods_cnt = oh_cnt;
>>>
>>>   	hwmods = kzalloc(sizeof(struct omap_hwmod *) * oh_cnt,
>>> @@ -465,8 +503,11 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>>>   		goto odbs_exit2;
>>>   	strcpy(pdev_name2, pdev_name);
>>>
>>> -	od->pdev.name = pdev_name2;
>>> -	od->pdev.id = pdev_id;
>>> +#ifdef CONFIG_OF_DEVICE
>>> +	pdev->dev.of_node = of_node_get(np);
>>> +#endif
>>> +	pdev->name = pdev_name2;
>>> +	pdev->id = pdev_id;
>>>
>>>   	res_count = omap_device_count_resources(od);
>>>   	if (res_count>   0) {
>>> @@ -499,7 +540,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>>>   	if (ret)
>>>   		goto odbs_exit4;
>>>
>>> -	return&od->pdev;
>>> +	return pdev;
>>>
>>>   odbs_exit4:
>>>   	kfree(res);
>>
>> Regards,
>> Benoit
>>
>>
>> _______________________________________________
>> devicetree-discuss mailing list
>> devicetree-discuss@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/devicetree-discuss

[RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt

[Cousson, Benoit]

On 8/10/2011 6:28 PM, G, Manjunath Kondaiah wrote:
> On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
>> Hi Manju,
>>
>> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>>>
>>> The omap dt requires new omap hwmod api to be added for in order
>>> to support omap dt.
>>
>> Both the subject and the changelog are misleading. You are not doing
>> any hwmod stuff in it.
>> You are just passing an "of_node" pointer during omap_device_build_ss.
>>
>> The subject should start with OMAP: omap_device: because it does not
>> belong to the DT subsystem.
>> The same comment apply to most patches in that series.
>
> The goal of this patch is to make omap-hwmod ready for dt adaptation hence
> I used the title "dt: omap: prepare hwmod to support dt" and "of_node" pointer
> is passed from dt and it is required for dt build.

I think that the goal of this patch is to update the 
omap_device_build_ss API in order to provide a device tree node pointer 
to pdev. For the moment there is nothing related to hwmod.

> And as you mentioned, patch does not do anything related to omap_device.

You meant omap_hwmod?

Benoit

>>> The new api is added and new parameter "np" is added for existing
>>> api.
>>
>> I don't think np is not a super meaningful name. Some more
>> explanation are needed as well.
>
> ok. I can expand it.
>
>>
>>> The users of hwmod api is changed accrodingly.
>>
>> omap_device API + typo.
>>
>>> Build and boot tested on omap3 beagle for both dt and not dt build.
>>>
>>> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
>>> ---
>>>   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              |   53 ++++++++++++++++++++++---
>>>   4 files changed, 59 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
>>> index 458f7be..d7ff1ae 100644
>>> --- a/arch/arm/mach-omap2/devices.c
>>> +++ b/arch/arm/mach-omap2/devices.c
>>> @@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)
>>>   			pr_err("could not look up %s\n", oh_name);
>>>   	}
>>>
>>> -	pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
>>> +	pdev = omap_device_build_ss(NULL, "omap_l3_noc", 0, oh, 3, NULL,
>>>   						     0, NULL, 0, 0);
>>
>> OK, maybe that is just me, but in order to extend an API, I'd rather
>> add the new parameter at the end.
>
> I feel it's fine since node pointer is first parameter is all dt api's.
>
>>
>>>   	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
>>> diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
>>> index 7a42f32..98eb95d 100644
>>> --- a/arch/arm/mach-omap2/mcbsp.c
>>> +++ b/arch/arm/mach-omap2/mcbsp.c
>>> @@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
>>>   		(struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
>>>   		count++;
>>>   	}
>>> -	pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
>>> +	pdev = omap_device_build_ss(NULL, name, id, oh_device, count, pdata,
>>>   				sizeof(*pdata), omap2_mcbsp_latency,
>>>   				ARRAY_SIZE(omap2_mcbsp_latency), false);
>>>   	kfree(pdata);
>>> diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
>>> index 7a3ec4f..5e2424b 100644
>>> --- a/arch/arm/plat-omap/include/plat/omap_device.h
>>> +++ b/arch/arm/plat-omap/include/plat/omap_device.h
>>> @@ -33,6 +33,7 @@
>>>
>>>   #include<linux/kernel.h>
>>>   #include<linux/platform_device.h>
>>> +#include<linux/of.h>
>>>
>>>   #include<plat/omap_hwmod.h>
>>>
>>> @@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>>>   				      struct omap_device_pm_latency *pm_lats,
>>>   				      int pm_lats_cnt, int is_early_device);
>>>
>>> -struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>>> +struct platform_device *omap_device_build_ss(struct device_node *np,
>>> +					 const char *pdev_name, int pdev_id,
>>>   					 struct omap_hwmod **oh, int oh_cnt,
>>>   					 void *pdata, int pdata_len,
>>>   					 struct omap_device_pm_latency *pm_lats,
>>>   					 int pm_lats_cnt, int is_early_device);
>>>
>>> +struct platform_device *omap_device_build_dt(struct device_node *np,
>>> +				      const char *pdev_name, int pdev_id,
>>> +				      struct omap_hwmod *oh, void *pdata,
>>> +				      int pdata_len,
>>> +				      struct omap_device_pm_latency *pm_lats,
>>> +				      int pm_lats_cnt, int is_early_device);
>>> +
>>>   void __iomem *omap_device_get_rt_va(struct omap_device *od);
>>>
>>>   /* OMAP PM interface */
>>> diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
>>> index 7d5e76b..fa49168 100644
>>> --- a/arch/arm/plat-omap/omap_device.c
>>> +++ b/arch/arm/plat-omap/omap_device.c
>>> @@ -85,6 +85,7 @@
>>>   #include<linux/clk.h>
>>>   #include<linux/clkdev.h>
>>>   #include<linux/pm_runtime.h>
>>> +#include<linux/of_device.h>
>>>
>>>   #include<plat/omap_device.h>
>>>   #include<plat/omap_hwmod.h>
>>> @@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device *od,
>>>   /**
>>>    * omap_device_build - build and register an omap_device with one omap_hwmod
>>
>> Need to update the kerneldoc.
> ok.
>>
>>>    * @pdev_name: name of the platform_device driver to use
>>> + * @np: device node pointer for attaching it to of_node pointer
>>>    * @pdev_id: this platform_device's connection ID
>>>    * @oh: ptr to the single omap_hwmod that backs this omap_device
>>>    * @pdata: platform_data ptr to associate with the platform_device
>>> @@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device *od,
>>>    * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
>>>    * passes along the return value of omap_device_build_ss().
>>>    */
>>> -struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>>> +struct platform_device *omap_device_build_dt(struct device_node *np,
>>> +				      const char *pdev_name, int pdev_id,
>>>   				      struct omap_hwmod *oh, void *pdata,
>>>   				      int pdata_len,
>>>   				      struct omap_device_pm_latency *pm_lats,
>>
>> That function should not be needed. You have to export
>> omap_device_build_ss, otherwise you will not build any device with
>> multiple hwmods.
> ok.
>>
>>> @@ -402,12 +405,44 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>>>   	if (!oh)
>>>   		return ERR_PTR(-EINVAL);
>>>
>>> -	return omap_device_build_ss(pdev_name, pdev_id, ohs, 1, pdata,
>>> +	return omap_device_build_ss(np, pdev_name, pdev_id, ohs, 1, pdata,
>>>   				    pdata_len, pm_lats, pm_lats_cnt,
>>>   				    is_early_device);
>>>   }
>>>
>>>   /**
>>> + * omap_device_build - build and register an omap_device with one omap_hwmod
>>> + * @pdev_name: name of the platform_device driver to use
>>> + * @pdev_id: this platform_device's connection ID
>>> + * @oh: ptr to the single omap_hwmod that backs this omap_device
>>> + * @pdata: platform_data ptr to associate with the platform_device
>>> + * @pdata_len: amount of memory pointed to by @pdata
>>> + * @pm_lats: pointer to a omap_device_pm_latency array for this device
>>> + * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
>>> + * @is_early_device: should the device be registered as an early device or not
>>> + *
>>> + * Convenience function for building and registering a single
>>> + * omap_device record, which in turn builds and registers a
>>> + * platform_device record.  See omap_device_build_ss() for more
>>> + * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
>>> + * passes along the return value of omap_device_build_ss().
>>> + */
>>> +struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>>> +				      struct omap_hwmod *oh, void *pdata,
>>> +				      int pdata_len,
>>> +				      struct omap_device_pm_latency *pm_lats,
>>> +				      int pm_lats_cnt, int is_early_device)
>>> +{
>>> +	struct omap_hwmod *ohs[] = { oh };
>>> +
>>> +	if (!oh)
>>> +		return ERR_PTR(-EINVAL);
>>> +
>>> +	return omap_device_build_ss(NULL, pdev_name, pdev_id, ohs, 1, pdata,
>>> +			pdata_len, pm_lats, pm_lats_cnt, is_early_device);
>>> +}
>>> +
>>> +/**
>>>    * omap_device_build_ss - build and register an omap_device with multiple hwmods
>>>    * @pdev_name: name of the platform_device driver to use
>>>    * @pdev_id: this platform_device's connection ID
>>> @@ -424,7 +459,8 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
>>>    * platform_device record.  Returns an ERR_PTR() on error, or passes
>>>    * along the return value of omap_device_register().
>>>    */
>>> -struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>>> +struct platform_device *omap_device_build_ss(struct device_node *np,
>>> +					 const char *pdev_name, int pdev_id,
>>>   					 struct omap_hwmod **ohs, int oh_cnt,
>>>   					 void *pdata, int pdata_len,
>>>   					 struct omap_device_pm_latency *pm_lats,
>>> @@ -436,6 +472,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>>>   	struct resource *res = NULL;
>>>   	int i, res_count;
>>>   	struct omap_hwmod **hwmods;
>>> +	struct platform_device *pdev;
>>>
>>>   	if (!ohs || oh_cnt == 0 || !pdev_name)
>>>   		return ERR_PTR(-EINVAL);
>>> @@ -450,6 +487,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>>>   	if (!od)
>>>   		return ERR_PTR(-ENOMEM);
>>>
>>> +	pdev =&od->pdev;
>>
>> Why do you need that? You are just adding one more user of the pdev.
>
> just improve readability otherwise we need to have&od->pdev at multiple places
> below.
>
>>
>>>   	od->hwmods_cnt = oh_cnt;
>>>
>>>   	hwmods = kzalloc(sizeof(struct omap_hwmod *) * oh_cnt,
>>> @@ -465,8 +503,11 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>>>   		goto odbs_exit2;
>>>   	strcpy(pdev_name2, pdev_name);
>>>
>>> -	od->pdev.name = pdev_name2;
>>> -	od->pdev.id = pdev_id;
>>> +#ifdef CONFIG_OF_DEVICE
>>> +	pdev->dev.of_node = of_node_get(np);
>>> +#endif
>>> +	pdev->name = pdev_name2;
>>> +	pdev->id = pdev_id;
>>>
>>>   	res_count = omap_device_count_resources(od);
>>>   	if (res_count>   0) {
>>> @@ -499,7 +540,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
>>>   	if (ret)
>>>   		goto odbs_exit4;
>>>
>>> -	return&od->pdev;
>>> +	return pdev;
>>>
>>>   odbs_exit4:
>>>   	kfree(res);
>>
>> Regards,
>> Benoit
>>
>>
>> _______________________________________________
>> devicetree-discuss mailing list
>> devicetree-discuss at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [RFC/PATCH 11/14] dt: omap3: add soc file for handling i2c controllers

[Cousson, Benoit]

+ Tony

On 8/10/2011 6:57 PM, G, Manjunath Kondaiah wrote:
> On Wed, Aug 10, 2011 at 02:36:50PM +0200, Cousson, Benoit wrote:
>> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>>>
>>> Add omap3 soc file for handling omap3 soc i2c controllers existing
>>> on l4-core bus.
>>>
>>> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
>>> ---
>>>   arch/arm/boot/dts/omap3-soc.dtsi |   62 ++++++++++++++++++++++++++++++++++++++
>>>   1 files changed, 62 insertions(+), 0 deletions(-)
>>>   create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
>>>
>>> diff --git a/arch/arm/boot/dts/omap3-soc.dtsi b/arch/arm/boot/dts/omap3-soc.dtsi
>>> new file mode 100644
>>> index 0000000..85de92f
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/omap3-soc.dtsi
>>> @@ -0,0 +1,62 @@
>>> +/*
>>> + * Device Tree Source for OMAP3 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/;
>>> +/include/ "skeleton.dtsi"
>>> +
>>> +/ {
>>> +	#address-cells =<1>;
>>> +	#size-cells =<1>;
>>> +	model = "ti,omap3";
>>> +
>>> +	aliases {
>>> +		i2c1 =&i2c1;
>>> +		i2c2 =&i2c2;
>>> +		i2c3 =&i2c3;
>>> +	};
>>> +
>>> +	l4-core {
>>
>> That comment is probably subject to discussion, but even if this
>> interconnect is there physically, I'm not sure of the added value to
>> add it.
>> It will add an extra level of indentation and that all. Moreover, it
>> will mess up the physical address that are expressed using absolute
>> value in the TRM with a less readable offset value.
>> In fact, most DTS files in the ARM directory are using a purely flat
>> representation of the interconnect.
> This is as per alignment with Tony and Grant:
> http://permalink.gmane.org/gmane.linux.ports.arm.omap/60391

So I'm asking the same question to Grant and Tony then:-)

>>> +		compatible = "ti,omap3-l4-core";
>>
>> Assuming we will keep that, you should probably add a more generic
>> compatible name after that one. Like "ti,s3220" or even
>> "sonics,s3220", assuming that this IP is generic enough for other
>> SoC.
> will check this. I don't remember any generic names.
>>
>>> +		#address-cells =<1>;
>>> +		#size-cells =<1>;
>>> +		ranges =<0 0x48000000 0x1000000>;
>>> +
>>> +		i2c1: i2c@70000 {
>>> +			#address-cells =<1>;
>>> +			#size-cells =<0>;
>>> +			compatible = "ti,omap3-i2c";
>>
>> The I2C IP and thus the driver is generic across OMAP generations
>> and is even potentially used by other non-OMAP TI chips like DSP or
>> Davinci. So having an extra compatible entry with "ti,i2c" or "ti,
>> omap-i2c" seems mandatory.
> This can be updated as and when new soc/board adaptations are done.
> As of now, it is omap3 and when we have omap4 it will be appended with
> "ti,omap4-i2c" etc

To infinity and beyond?

There is no need, and we should absolutely not update the driver each 
time we introduce a new SoC version/revision.
The driver should match with the generic device name in that case. Until 
we change the IP and potentially introduce a new driver.

BTW, even omap3 should not be in the name in theory. It should be 
potentially "ti,i2c-v3" or whatever HW version the IP is using.
But for some reason, most devices are using such convention in existing 
DTS:-(
This is probably due to the lack of well identified IP version in most 
SoC... including OMAP:-)


Benoit

[RFC/PATCH 11/14] dt: omap3: add soc file for handling i2c controllers

[Cousson, Benoit]

+ Tony

On 8/10/2011 6:57 PM, G, Manjunath Kondaiah wrote:
> On Wed, Aug 10, 2011 at 02:36:50PM +0200, Cousson, Benoit wrote:
>> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>>>
>>> Add omap3 soc file for handling omap3 soc i2c controllers existing
>>> on l4-core bus.
>>>
>>> Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
>>> ---
>>>   arch/arm/boot/dts/omap3-soc.dtsi |   62 ++++++++++++++++++++++++++++++++++++++
>>>   1 files changed, 62 insertions(+), 0 deletions(-)
>>>   create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
>>>
>>> diff --git a/arch/arm/boot/dts/omap3-soc.dtsi b/arch/arm/boot/dts/omap3-soc.dtsi
>>> new file mode 100644
>>> index 0000000..85de92f
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/omap3-soc.dtsi
>>> @@ -0,0 +1,62 @@
>>> +/*
>>> + * Device Tree Source for OMAP3 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/;
>>> +/include/ "skeleton.dtsi"
>>> +
>>> +/ {
>>> +	#address-cells =<1>;
>>> +	#size-cells =<1>;
>>> +	model = "ti,omap3";
>>> +
>>> +	aliases {
>>> +		i2c1 =&i2c1;
>>> +		i2c2 =&i2c2;
>>> +		i2c3 =&i2c3;
>>> +	};
>>> +
>>> +	l4-core {
>>
>> That comment is probably subject to discussion, but even if this
>> interconnect is there physically, I'm not sure of the added value to
>> add it.
>> It will add an extra level of indentation and that all. Moreover, it
>> will mess up the physical address that are expressed using absolute
>> value in the TRM with a less readable offset value.
>> In fact, most DTS files in the ARM directory are using a purely flat
>> representation of the interconnect.
> This is as per alignment with Tony and Grant:
> http://permalink.gmane.org/gmane.linux.ports.arm.omap/60391

So I'm asking the same question to Grant and Tony then:-)

>>> +		compatible = "ti,omap3-l4-core";
>>
>> Assuming we will keep that, you should probably add a more generic
>> compatible name after that one. Like "ti,s3220" or even
>> "sonics,s3220", assuming that this IP is generic enough for other
>> SoC.
> will check this. I don't remember any generic names.
>>
>>> +		#address-cells =<1>;
>>> +		#size-cells =<1>;
>>> +		ranges =<0 0x48000000 0x1000000>;
>>> +
>>> +		i2c1: i2c at 70000 {
>>> +			#address-cells =<1>;
>>> +			#size-cells =<0>;
>>> +			compatible = "ti,omap3-i2c";
>>
>> The I2C IP and thus the driver is generic across OMAP generations
>> and is even potentially used by other non-OMAP TI chips like DSP or
>> Davinci. So having an extra compatible entry with "ti,i2c" or "ti,
>> omap-i2c" seems mandatory.
> This can be updated as and when new soc/board adaptations are done.
> As of now, it is omap3 and when we have omap4 it will be appended with
> "ti,omap4-i2c" etc

To infinity and beyond?

There is no need, and we should absolutely not update the driver each 
time we introduce a new SoC version/revision.
The driver should match with the generic device name in that case. Until 
we change the IP and potentially introduce a new driver.

BTW, even omap3 should not be in the name in theory. It should be 
potentially "ti,i2c-v3" or whatever HW version the IP is using.
But for some reason, most devices are using such convention in existing 
DTS:-(
This is probably due to the lack of well identified IP version in most 
SoC... including OMAP:-)


Benoit

Re: [RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 10:41 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> On 8/10/2011 6:28 PM, G, Manjunath Kondaiah wrote:
>>
>> On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
>>>
>>> Hi Manju,
>>>
>>> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>>>>
>>>> The omap dt requires new omap hwmod api to be added for in order
>>>> to support omap dt.
>>>
>>> Both the subject and the changelog are misleading. You are not doing
>>> any hwmod stuff in it.
>>> You are just passing an "of_node" pointer during omap_device_build_ss.
>>>
>>> The subject should start with OMAP: omap_device: because it does not
>>> belong to the DT subsystem.
>>> The same comment apply to most patches in that series.
>>
>> The goal of this patch is to make omap-hwmod ready for dt adaptation hence
>> I used the title "dt: omap: prepare hwmod to support dt" and "of_node"
>> pointer
>> is passed from dt and it is required for dt build.
>
> I think that the goal of this patch is to update the omap_device_build_ss
> API in order to provide a device tree node pointer to pdev. For the moment
> there is nothing related to hwmod.
yes. it is to update  *_ss api with device node pointer and introduce new
api exported for dt builds.  I can update with this description.
>
>> And as you mentioned, patch does not do anything related to omap_device.
>
> You meant omap_hwmod?

Yes. It should be "omap: omap_hwmod: add device node pointer"

-M

[RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 10:41 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> On 8/10/2011 6:28 PM, G, Manjunath Kondaiah wrote:
>>
>> On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
>>>
>>> Hi Manju,
>>>
>>> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>>>>
>>>> The omap dt requires new omap hwmod api to be added for in order
>>>> to support omap dt.
>>>
>>> Both the subject and the changelog are misleading. You are not doing
>>> any hwmod stuff in it.
>>> You are just passing an "of_node" pointer during omap_device_build_ss.
>>>
>>> The subject should start with OMAP: omap_device: because it does not
>>> belong to the DT subsystem.
>>> The same comment apply to most patches in that series.
>>
>> The goal of this patch is to make omap-hwmod ready for dt adaptation hence
>> I used the title "dt: omap: prepare hwmod to support dt" and "of_node"
>> pointer
>> is passed from dt and it is required for dt build.
>
> I think that the goal of this patch is to update the omap_device_build_ss
> API in order to provide a device tree node pointer to pdev. For the moment
> there is nothing related to hwmod.
yes. it is to update  *_ss api with device node pointer and introduce new
api exported for dt builds.  I can update with this description.
>
>> And as you mentioned, patch does not do anything related to omap_device.
>
> You meant omap_hwmod?

Yes. It should be "omap: omap_hwmod: add device node pointer"

-M

Re: [RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt

[Cousson, Benoit]

On 8/10/2011 8:03 PM, G, Manjunath Kondaiah wrote:
> On Wed, Aug 10, 2011 at 10:41 PM, Cousson, Benoit<b-cousson-l0cyMroinI0@public.gmane.org>  wrote:
>> On 8/10/2011 6:28 PM, G, Manjunath Kondaiah wrote:
>>>
>>> On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
>>>>
>>>> Hi Manju,
>>>>
>>>> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>>>>>
>>>>> The omap dt requires new omap hwmod api to be added for in order
>>>>> to support omap dt.
>>>>
>>>> Both the subject and the changelog are misleading. You are not doing
>>>> any hwmod stuff in it.
>>>> You are just passing an "of_node" pointer during omap_device_build_ss.
>>>>
>>>> The subject should start with OMAP: omap_device: because it does not
>>>> belong to the DT subsystem.
>>>> The same comment apply to most patches in that series.
>>>
>>> The goal of this patch is to make omap-hwmod ready for dt adaptation hence
>>> I used the title "dt: omap: prepare hwmod to support dt" and "of_node"
>>> pointer
>>> is passed from dt and it is required for dt build.
>>
>> I think that the goal of this patch is to update the omap_device_build_ss
>> API in order to provide a device tree node pointer to pdev. For the moment
>> there is nothing related to hwmod.
> yes. it is to update  *_ss api with device node pointer and introduce new
> api exported for dt builds.  I can update with this description.
>>
>>> And as you mentioned, patch does not do anything related to omap_device.
>>
>> You meant omap_hwmod?
>
> Yes. It should be "omap: omap_hwmod: add device node pointer"

... "OMAP: omap_device: Add device tree node pointer"

[RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt

[Cousson, Benoit]

On 8/10/2011 8:03 PM, G, Manjunath Kondaiah wrote:
> On Wed, Aug 10, 2011 at 10:41 PM, Cousson, Benoit<b-cousson@ti.com>  wrote:
>> On 8/10/2011 6:28 PM, G, Manjunath Kondaiah wrote:
>>>
>>> On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
>>>>
>>>> Hi Manju,
>>>>
>>>> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>>>>>
>>>>> The omap dt requires new omap hwmod api to be added for in order
>>>>> to support omap dt.
>>>>
>>>> Both the subject and the changelog are misleading. You are not doing
>>>> any hwmod stuff in it.
>>>> You are just passing an "of_node" pointer during omap_device_build_ss.
>>>>
>>>> The subject should start with OMAP: omap_device: because it does not
>>>> belong to the DT subsystem.
>>>> The same comment apply to most patches in that series.
>>>
>>> The goal of this patch is to make omap-hwmod ready for dt adaptation hence
>>> I used the title "dt: omap: prepare hwmod to support dt" and "of_node"
>>> pointer
>>> is passed from dt and it is required for dt build.
>>
>> I think that the goal of this patch is to update the omap_device_build_ss
>> API in order to provide a device tree node pointer to pdev. For the moment
>> there is nothing related to hwmod.
> yes. it is to update  *_ss api with device node pointer and introduce new
> api exported for dt builds.  I can update with this description.
>>
>>> And as you mentioned, patch does not do anything related to omap_device.
>>
>> You meant omap_hwmod?
>
> Yes. It should be "omap: omap_hwmod: add device node pointer"

... "OMAP: omap_device: Add device tree node pointer"

Re: [RFC/PATCH 11/14] dt: omap3: add soc file for handling i2c controllers

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 07:45:42PM +0200, Cousson, Benoit wrote:
> + Tony
> 
> On 8/10/2011 6:57 PM, G, Manjunath Kondaiah wrote:
> >On Wed, Aug 10, 2011 at 02:36:50PM +0200, Cousson, Benoit wrote:
> >>On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> >>>
> >>>Add omap3 soc file for handling omap3 soc i2c controllers existing
> >>>on l4-core bus.
> >>>
> >>>Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> >>>---
> >>>  arch/arm/boot/dts/omap3-soc.dtsi |   62 ++++++++++++++++++++++++++++++++++++++
> >>>  1 files changed, 62 insertions(+), 0 deletions(-)
> >>>  create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
> >>>
> >>>diff --git a/arch/arm/boot/dts/omap3-soc.dtsi b/arch/arm/boot/dts/omap3-soc.dtsi
> >>>new file mode 100644
> >>>index 0000000..85de92f
> >>>--- /dev/null
> >>>+++ b/arch/arm/boot/dts/omap3-soc.dtsi
> >>>@@ -0,0 +1,62 @@
> >>>+/*
> >>>+ * Device Tree Source for OMAP3 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/;
> >>>+/include/ "skeleton.dtsi"
> >>>+
> >>>+/ {
> >>>+	#address-cells =<1>;
> >>>+	#size-cells =<1>;
> >>>+	model = "ti,omap3";
> >>>+
> >>>+	aliases {
> >>>+		i2c1 =&i2c1;
> >>>+		i2c2 =&i2c2;
> >>>+		i2c3 =&i2c3;
> >>>+	};
> >>>+
> >>>+	l4-core {
> >>
> >>That comment is probably subject to discussion, but even if this
> >>interconnect is there physically, I'm not sure of the added value to
> >>add it.
> >>It will add an extra level of indentation and that all. Moreover, it
> >>will mess up the physical address that are expressed using absolute
> >>value in the TRM with a less readable offset value.
> >>In fact, most DTS files in the ARM directory are using a purely flat
> >>representation of the interconnect.
> >This is as per alignment with Tony and Grant:
> >http://permalink.gmane.org/gmane.linux.ports.arm.omap/60391
> 
> So I'm asking the same question to Grant and Tony then:-)

What is the conclusion here? I will go ahead with current approach since
tony and grant has voted for it.

-M

> 
> >>>+		compatible = "ti,omap3-l4-core";
> >>
> >>Assuming we will keep that, you should probably add a more generic
> >>compatible name after that one. Like "ti,s3220" or even
> >>"sonics,s3220", assuming that this IP is generic enough for other
> >>SoC.
> >will check this. I don't remember any generic names.
> >>
> >>>+		#address-cells =<1>;
> >>>+		#size-cells =<1>;
> >>>+		ranges =<0 0x48000000 0x1000000>;
> >>>+
> >>>+		i2c1: i2c@70000 {
> >>>+			#address-cells =<1>;
> >>>+			#size-cells =<0>;
> >>>+			compatible = "ti,omap3-i2c";
> >>
> >>The I2C IP and thus the driver is generic across OMAP generations
> >>and is even potentially used by other non-OMAP TI chips like DSP or
> >>Davinci. So having an extra compatible entry with "ti,i2c" or "ti,
> >>omap-i2c" seems mandatory.
> >This can be updated as and when new soc/board adaptations are done.
> >As of now, it is omap3 and when we have omap4 it will be appended with
> >"ti,omap4-i2c" etc
> 
> To infinity and beyond?
> 
> There is no need, and we should absolutely not update the driver
> each time we introduce a new SoC version/revision.
> The driver should match with the generic device name in that case.
> Until we change the IP and potentially introduce a new driver.
> 
> BTW, even omap3 should not be in the name in theory. It should be
> potentially "ti,i2c-v3" or whatever HW version the IP is using.
> But for some reason, most devices are using such convention in
> existing DTS:-(
> This is probably due to the lack of well identified IP version in
> most SoC... including OMAP:-)
> 
> 
> Benoit

[RFC/PATCH 11/14] dt: omap3: add soc file for handling i2c controllers

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 07:45:42PM +0200, Cousson, Benoit wrote:
> + Tony
> 
> On 8/10/2011 6:57 PM, G, Manjunath Kondaiah wrote:
> >On Wed, Aug 10, 2011 at 02:36:50PM +0200, Cousson, Benoit wrote:
> >>On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> >>>
> >>>Add omap3 soc file for handling omap3 soc i2c controllers existing
> >>>on l4-core bus.
> >>>
> >>>Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> >>>---
> >>>  arch/arm/boot/dts/omap3-soc.dtsi |   62 ++++++++++++++++++++++++++++++++++++++
> >>>  1 files changed, 62 insertions(+), 0 deletions(-)
> >>>  create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
> >>>
> >>>diff --git a/arch/arm/boot/dts/omap3-soc.dtsi b/arch/arm/boot/dts/omap3-soc.dtsi
> >>>new file mode 100644
> >>>index 0000000..85de92f
> >>>--- /dev/null
> >>>+++ b/arch/arm/boot/dts/omap3-soc.dtsi
> >>>@@ -0,0 +1,62 @@
> >>>+/*
> >>>+ * Device Tree Source for OMAP3 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/;
> >>>+/include/ "skeleton.dtsi"
> >>>+
> >>>+/ {
> >>>+	#address-cells =<1>;
> >>>+	#size-cells =<1>;
> >>>+	model = "ti,omap3";
> >>>+
> >>>+	aliases {
> >>>+		i2c1 =&i2c1;
> >>>+		i2c2 =&i2c2;
> >>>+		i2c3 =&i2c3;
> >>>+	};
> >>>+
> >>>+	l4-core {
> >>
> >>That comment is probably subject to discussion, but even if this
> >>interconnect is there physically, I'm not sure of the added value to
> >>add it.
> >>It will add an extra level of indentation and that all. Moreover, it
> >>will mess up the physical address that are expressed using absolute
> >>value in the TRM with a less readable offset value.
> >>In fact, most DTS files in the ARM directory are using a purely flat
> >>representation of the interconnect.
> >This is as per alignment with Tony and Grant:
> >http://permalink.gmane.org/gmane.linux.ports.arm.omap/60391
> 
> So I'm asking the same question to Grant and Tony then:-)

What is the conclusion here? I will go ahead with current approach since
tony and grant has voted for it.

-M

> 
> >>>+		compatible = "ti,omap3-l4-core";
> >>
> >>Assuming we will keep that, you should probably add a more generic
> >>compatible name after that one. Like "ti,s3220" or even
> >>"sonics,s3220", assuming that this IP is generic enough for other
> >>SoC.
> >will check this. I don't remember any generic names.
> >>
> >>>+		#address-cells =<1>;
> >>>+		#size-cells =<1>;
> >>>+		ranges =<0 0x48000000 0x1000000>;
> >>>+
> >>>+		i2c1: i2c at 70000 {
> >>>+			#address-cells =<1>;
> >>>+			#size-cells =<0>;
> >>>+			compatible = "ti,omap3-i2c";
> >>
> >>The I2C IP and thus the driver is generic across OMAP generations
> >>and is even potentially used by other non-OMAP TI chips like DSP or
> >>Davinci. So having an extra compatible entry with "ti,i2c" or "ti,
> >>omap-i2c" seems mandatory.
> >This can be updated as and when new soc/board adaptations are done.
> >As of now, it is omap3 and when we have omap4 it will be appended with
> >"ti,omap4-i2c" etc
> 
> To infinity and beyond?
> 
> There is no need, and we should absolutely not update the driver
> each time we introduce a new SoC version/revision.
> The driver should match with the generic device name in that case.
> Until we change the IP and potentially introduce a new driver.
> 
> BTW, even omap3 should not be in the name in theory. It should be
> potentially "ti,i2c-v3" or whatever HW version the IP is using.
> But for some reason, most devices are using such convention in
> existing DTS:-(
> This is probably due to the lack of well identified IP version in
> most SoC... including OMAP:-)
> 
> 
> Benoit

Re: [RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 09:58:46PM +0530, G, Manjunath Kondaiah wrote:
> On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
> > Hi Manju,
> > 
> > On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> > >
> > >The omap dt requires new omap hwmod api to be added for in order
> > >to support omap dt.
> > 
> > Both the subject and the changelog are misleading. You are not doing
> > any hwmod stuff in it.
> > You are just passing an "of_node" pointer during omap_device_build_ss.
> > 
> > The subject should start with OMAP: omap_device: because it does not
> > belong to the DT subsystem.
> > The same comment apply to most patches in that series.
> 
> The goal of this patch is to make omap-hwmod ready for dt adaptation hence
> I used the title "dt: omap: prepare hwmod to support dt" and "of_node" pointer
> is passed from dt and it is required for dt build.
> 
> And as you mentioned, patch does not do anything related to omap_device.
> 
> > 
> > >The new api is added and new parameter "np" is added for existing
> > >api.
> > 
> > I don't think np is not a super meaningful name. Some more
> > explanation are needed as well.
> 
> ok. I can expand it.
> 
> > 
> > >The users of hwmod api is changed accrodingly.
> > 
> > omap_device API + typo.
> > 
> > >Build and boot tested on omap3 beagle for both dt and not dt build.
> > >
> > >Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> > >---
> > >  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              |   53 ++++++++++++++++++++++---
> > >  4 files changed, 59 insertions(+), 9 deletions(-)
> > >
> > >diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > >index 458f7be..d7ff1ae 100644
> > >--- a/arch/arm/mach-omap2/devices.c
> > >+++ b/arch/arm/mach-omap2/devices.c
> > >@@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)
> > >  			pr_err("could not look up %s\n", oh_name);
> > >  	}
> > >
> > >-	pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
> > >+	pdev = omap_device_build_ss(NULL, "omap_l3_noc", 0, oh, 3, NULL,
> > >  						     0, NULL, 0, 0);
> > 
> > OK, maybe that is just me, but in order to extend an API, I'd rather
> > add the new parameter at the end.
> 
> I feel it's fine since node pointer is first parameter is all dt api's.
> 
> > 
> > >  	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
> > >diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
> > >index 7a42f32..98eb95d 100644
> > >--- a/arch/arm/mach-omap2/mcbsp.c
> > >+++ b/arch/arm/mach-omap2/mcbsp.c
> > >@@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
> > >  		(struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
> > >  		count++;
> > >  	}
> > >-	pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
> > >+	pdev = omap_device_build_ss(NULL, name, id, oh_device, count, pdata,
> > >  				sizeof(*pdata), omap2_mcbsp_latency,
> > >  				ARRAY_SIZE(omap2_mcbsp_latency), false);
> > >  	kfree(pdata);
> > >diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
> > >index 7a3ec4f..5e2424b 100644
> > >--- a/arch/arm/plat-omap/include/plat/omap_device.h
> > >+++ b/arch/arm/plat-omap/include/plat/omap_device.h
> > >@@ -33,6 +33,7 @@
> > >
> > >  #include<linux/kernel.h>
> > >  #include<linux/platform_device.h>
> > >+#include<linux/of.h>
> > >
> > >  #include<plat/omap_hwmod.h>
> > >
> > >@@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> > >  				      struct omap_device_pm_latency *pm_lats,
> > >  				      int pm_lats_cnt, int is_early_device);
> > >
> > >-struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> > >+struct platform_device *omap_device_build_ss(struct device_node *np,
> > >+					 const char *pdev_name, int pdev_id,
> > >  					 struct omap_hwmod **oh, int oh_cnt,
> > >  					 void *pdata, int pdata_len,
> > >  					 struct omap_device_pm_latency *pm_lats,
> > >  					 int pm_lats_cnt, int is_early_device);
> > >
> > >+struct platform_device *omap_device_build_dt(struct device_node *np,
> > >+				      const char *pdev_name, int pdev_id,
> > >+				      struct omap_hwmod *oh, void *pdata,
> > >+				      int pdata_len,
> > >+				      struct omap_device_pm_latency *pm_lats,
> > >+				      int pm_lats_cnt, int is_early_device);
> > >+
> > >  void __iomem *omap_device_get_rt_va(struct omap_device *od);
> > >
> > >  /* OMAP PM interface */
> > >diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
> > >index 7d5e76b..fa49168 100644
> > >--- a/arch/arm/plat-omap/omap_device.c
> > >+++ b/arch/arm/plat-omap/omap_device.c
> > >@@ -85,6 +85,7 @@
> > >  #include<linux/clk.h>
> > >  #include<linux/clkdev.h>
> > >  #include<linux/pm_runtime.h>
> > >+#include<linux/of_device.h>
> > >
> > >  #include<plat/omap_device.h>
> > >  #include<plat/omap_hwmod.h>
> > >@@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device *od,
> > >  /**
> > >   * omap_device_build - build and register an omap_device with one omap_hwmod
> > 
> > Need to update the kerneldoc.
> ok.

As these API's are interim API's and we might have alternate setup to handle
hwmod in the coming days, the documentation part will be taken care along with
final solution for hwmod issue.

> > 
> > >   * @pdev_name: name of the platform_device driver to use
> > >+ * @np: device node pointer for attaching it to of_node pointer
> > >   * @pdev_id: this platform_device's connection ID
> > >   * @oh: ptr to the single omap_hwmod that backs this omap_device
> > >   * @pdata: platform_data ptr to associate with the platform_device
> > >@@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device *od,
> > >   * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
> > >   * passes along the return value of omap_device_build_ss().
> > >   */
> > >-struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> > >+struct platform_device *omap_device_build_dt(struct device_node *np,
> > >+				      const char *pdev_name, int pdev_id,
> > >  				      struct omap_hwmod *oh, void *pdata,
> > >  				      int pdata_len,
> > >  				      struct omap_device_pm_latency *pm_lats,
> > 
> > That function should not be needed. You have to export
> > omap_device_build_ss, otherwise you will not build any device with
> > multiple hwmods.
> ok.

confused here. All the three API's *_dt/*_ss/*_dt are exported and can be
accessed for single or multiple hwmods. Am I missing anything?

-M

[RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt

[G, Manjunath Kondaiah]

On Wed, Aug 10, 2011 at 09:58:46PM +0530, G, Manjunath Kondaiah wrote:
> On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
> > Hi Manju,
> > 
> > On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> > >
> > >The omap dt requires new omap hwmod api to be added for in order
> > >to support omap dt.
> > 
> > Both the subject and the changelog are misleading. You are not doing
> > any hwmod stuff in it.
> > You are just passing an "of_node" pointer during omap_device_build_ss.
> > 
> > The subject should start with OMAP: omap_device: because it does not
> > belong to the DT subsystem.
> > The same comment apply to most patches in that series.
> 
> The goal of this patch is to make omap-hwmod ready for dt adaptation hence
> I used the title "dt: omap: prepare hwmod to support dt" and "of_node" pointer
> is passed from dt and it is required for dt build.
> 
> And as you mentioned, patch does not do anything related to omap_device.
> 
> > 
> > >The new api is added and new parameter "np" is added for existing
> > >api.
> > 
> > I don't think np is not a super meaningful name. Some more
> > explanation are needed as well.
> 
> ok. I can expand it.
> 
> > 
> > >The users of hwmod api is changed accrodingly.
> > 
> > omap_device API + typo.
> > 
> > >Build and boot tested on omap3 beagle for both dt and not dt build.
> > >
> > >Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> > >---
> > >  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              |   53 ++++++++++++++++++++++---
> > >  4 files changed, 59 insertions(+), 9 deletions(-)
> > >
> > >diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > >index 458f7be..d7ff1ae 100644
> > >--- a/arch/arm/mach-omap2/devices.c
> > >+++ b/arch/arm/mach-omap2/devices.c
> > >@@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)
> > >  			pr_err("could not look up %s\n", oh_name);
> > >  	}
> > >
> > >-	pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
> > >+	pdev = omap_device_build_ss(NULL, "omap_l3_noc", 0, oh, 3, NULL,
> > >  						     0, NULL, 0, 0);
> > 
> > OK, maybe that is just me, but in order to extend an API, I'd rather
> > add the new parameter at the end.
> 
> I feel it's fine since node pointer is first parameter is all dt api's.
> 
> > 
> > >  	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
> > >diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
> > >index 7a42f32..98eb95d 100644
> > >--- a/arch/arm/mach-omap2/mcbsp.c
> > >+++ b/arch/arm/mach-omap2/mcbsp.c
> > >@@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
> > >  		(struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
> > >  		count++;
> > >  	}
> > >-	pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
> > >+	pdev = omap_device_build_ss(NULL, name, id, oh_device, count, pdata,
> > >  				sizeof(*pdata), omap2_mcbsp_latency,
> > >  				ARRAY_SIZE(omap2_mcbsp_latency), false);
> > >  	kfree(pdata);
> > >diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
> > >index 7a3ec4f..5e2424b 100644
> > >--- a/arch/arm/plat-omap/include/plat/omap_device.h
> > >+++ b/arch/arm/plat-omap/include/plat/omap_device.h
> > >@@ -33,6 +33,7 @@
> > >
> > >  #include<linux/kernel.h>
> > >  #include<linux/platform_device.h>
> > >+#include<linux/of.h>
> > >
> > >  #include<plat/omap_hwmod.h>
> > >
> > >@@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> > >  				      struct omap_device_pm_latency *pm_lats,
> > >  				      int pm_lats_cnt, int is_early_device);
> > >
> > >-struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> > >+struct platform_device *omap_device_build_ss(struct device_node *np,
> > >+					 const char *pdev_name, int pdev_id,
> > >  					 struct omap_hwmod **oh, int oh_cnt,
> > >  					 void *pdata, int pdata_len,
> > >  					 struct omap_device_pm_latency *pm_lats,
> > >  					 int pm_lats_cnt, int is_early_device);
> > >
> > >+struct platform_device *omap_device_build_dt(struct device_node *np,
> > >+				      const char *pdev_name, int pdev_id,
> > >+				      struct omap_hwmod *oh, void *pdata,
> > >+				      int pdata_len,
> > >+				      struct omap_device_pm_latency *pm_lats,
> > >+				      int pm_lats_cnt, int is_early_device);
> > >+
> > >  void __iomem *omap_device_get_rt_va(struct omap_device *od);
> > >
> > >  /* OMAP PM interface */
> > >diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
> > >index 7d5e76b..fa49168 100644
> > >--- a/arch/arm/plat-omap/omap_device.c
> > >+++ b/arch/arm/plat-omap/omap_device.c
> > >@@ -85,6 +85,7 @@
> > >  #include<linux/clk.h>
> > >  #include<linux/clkdev.h>
> > >  #include<linux/pm_runtime.h>
> > >+#include<linux/of_device.h>
> > >
> > >  #include<plat/omap_device.h>
> > >  #include<plat/omap_hwmod.h>
> > >@@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device *od,
> > >  /**
> > >   * omap_device_build - build and register an omap_device with one omap_hwmod
> > 
> > Need to update the kerneldoc.
> ok.

As these API's are interim API's and we might have alternate setup to handle
hwmod in the coming days, the documentation part will be taken care along with
final solution for hwmod issue.

> > 
> > >   * @pdev_name: name of the platform_device driver to use
> > >+ * @np: device node pointer for attaching it to of_node pointer
> > >   * @pdev_id: this platform_device's connection ID
> > >   * @oh: ptr to the single omap_hwmod that backs this omap_device
> > >   * @pdata: platform_data ptr to associate with the platform_device
> > >@@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device *od,
> > >   * information.  Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
> > >   * passes along the return value of omap_device_build_ss().
> > >   */
> > >-struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> > >+struct platform_device *omap_device_build_dt(struct device_node *np,
> > >+				      const char *pdev_name, int pdev_id,
> > >  				      struct omap_hwmod *oh, void *pdata,
> > >  				      int pdata_len,
> > >  				      struct omap_device_pm_latency *pm_lats,
> > 
> > That function should not be needed. You have to export
> > omap_device_build_ss, otherwise you will not build any device with
> > multiple hwmods.
> ok.

confused here. All the three API's *_dt/*_ss/*_dt are exported and can be
accessed for single or multiple hwmods. Am I missing anything?

-M

Re: [RFC/PATCH 14/14] dt: omap3: enable dt support for i2c1 controller

[G, Manjunath Kondaiah]

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

[RFC/PATCH 14/14] dt: omap3: enable dt support for i2c1 controller

[G, Manjunath Kondaiah]

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 at 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 at 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 at 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