[PATCH 00/13] OMAP: CM, hwmod, omap_device fixes and updates

[PATCH 00/13] OMAP: CM, hwmod, omap_device fixes and updates

[Kevin Hilman]

This is a series of fixes & updates mostly to hwmod and omap_device
that are required for the on-going hwmod conversions and runtime PM
conversion of drivers.

While some of these are fixes, they are not urgent for 2.6.35 and can
wait until the next merge window.

This series applies on top of the runtime PM series just posted and is
also available as the pm-wip/hwmods branch of my linux-omap-pm git
tree:

  git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git

This has been tested with various hwmod & runtime PM conversions
(UART, MMC, dmtimer) on OMAP2, OMAP3 and OMAP4.

Kevin


Benoit Cousson (2):
  OMAP: hwmod: Fix the missing braces
  OMAP2&3: hwmod: Remove _hwmod prefix in name string

Kevin Hilman (10):
  OMAP24xx: CM: fix mask used for checking IDLEST status
  OMAP: hwmod: allow idle after HWMOD_INIT_NO_IDLE
  OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST
  OMAP: hwmod: add non-locking versions of enable and idle functions
  OMAP: hwmod: don't auto-disable hwmod when !CONFIG_PM_RUNTIME
  OMAP: omap_device: ensure hwmod tracks attached omap_device pointer
  OMAP: omap_device: add flag to disable automatic bus-level
    suspend/resume
  OMAP: create omap_devices for MPU, DSP, L3
  OMAP: hwmod data: add class for DSP hwmods
  OMAP3: hwmod data: add data for OMAP3 IVA2

Rajendra Nayak (1):
  OMAP4: hwmod: Enable omap_device build for OMAP4

 arch/arm/mach-omap2/cm.c                      |    6 +-
 arch/arm/mach-omap2/devices.c                 |    2 +
 arch/arm/mach-omap2/io.c                      |   55 ++++++++++++++++++++++-
 arch/arm/mach-omap2/omap_hwmod.c              |   60 +++++++++++++++++++++---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c    |   15 ++++---
 arch/arm/mach-omap2/omap_hwmod_2430_data.c    |   15 ++++---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c    |   51 ++++++++++++++++++---
 arch/arm/mach-omap2/omap_hwmod_common_data.c  |    3 +
 arch/arm/mach-omap2/omap_hwmod_common_data.h  |    1 +
 arch/arm/plat-omap/Makefile                   |    1 +
 arch/arm/plat-omap/include/plat/common.h      |    4 ++
 arch/arm/plat-omap/include/plat/omap_device.h |    5 ++
 arch/arm/plat-omap/include/plat/omap_hwmod.h  |    2 +
 arch/arm/plat-omap/omap_device.c              |    8 +++-
 14 files changed, 194 insertions(+), 34 deletions(-)

[PATCH 01/13] OMAP24xx: CM: fix mask used for checking IDLEST status

[Kevin Hilman]

On OMAP24xx, the polarity for the IDLEST bits is opposite of OMAP3.
The mask used to check this was using the bit position instead of the
bit mask.

This patch fixes the problem by using the bit mask instead of the bit
field.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/cm.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/cm.c b/arch/arm/mach-omap2/cm.c
index 2d83565..721c3b6 100644
--- a/arch/arm/mach-omap2/cm.c
+++ b/arch/arm/mach-omap2/cm.c
@@ -50,15 +50,15 @@ int omap2_cm_wait_module_ready(s16 prcm_mod, u8 idlest_id, u8 idlest_shift)
 
 	cm_idlest_reg = cm_idlest_offs[idlest_id - 1];
 
+	mask = 1 << idlest_shift;
+
 	if (cpu_is_omap24xx())
-		ena = idlest_shift;
+		ena = mask;
 	else if (cpu_is_omap34xx())
 		ena = 0;
 	else
 		BUG();
 
-	mask = 1 << idlest_shift;
-
 	/* XXX should be OMAP2 CM */
 	omap_test_timeout(((cm_read_mod_reg(prcm_mod, cm_idlest_reg) & mask) == ena),
 			  MAX_MODULE_READY_TIME, i);
-- 
1.7.0.2

[PATCH 02/13] OMAP: hwmod: allow idle after HWMOD_INIT_NO_IDLE

[Kevin Hilman]

If an omap_hwmod is setup using HWMOD_INIT_NO_IDLE flag, there is
currently way to idle it since omap_hwmod_idle() requires the hwmod to
be in the enabled state.

This patch adds a check to omap_hwmod_idle() so if the hwmod was has
the INIT_NO_IDLE flag, calling omap_hwmod_idle() will still succeed.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 95c9a5f..ac75407 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -938,7 +938,13 @@ static int _enable(struct omap_hwmod *oh)
  */
 static int _idle(struct omap_hwmod *oh)
 {
-	if (oh->_state != _HWMOD_STATE_ENABLED) {
+	/*
+	 * To idle, hwmod must be enabled, EXCEPT if hwmod was
+	 * initialized using the INIT_NO_IDLE flag.  In this case it
+	 * will not yet be enabled so we have to allow it to be idled.
+	 */
+	if ((oh->_state != _HWMOD_STATE_ENABLED) &&
+	    !(oh->flags & HWMOD_INIT_NO_IDLE)) {
 		WARN(1, "omap_hwmod: %s: idle state can only be entered from "
 		     "enabled state\n", oh->name);
 		return -EINVAL;
@@ -953,6 +959,9 @@ static int _idle(struct omap_hwmod *oh)
 
 	oh->_state = _HWMOD_STATE_IDLE;
 
+	/* Clear init flag which should only affect first call to idle */
+	oh->flags &= ~HWMOD_INIT_NO_IDLE;
+
 	return 0;
 }
 
-- 
1.7.0.2

Re: [PATCH 02/13] OMAP: hwmod: allow idle after HWMOD_INIT_NO_IDLE

[Paul Walmsley]

Hi Kevin,

something doesn't make sense in this patch...

On Wed, 23 Jun 2010, Kevin Hilman wrote:

> If an omap_hwmod is setup using HWMOD_INIT_NO_IDLE flag, there is
> currently way to idle it since omap_hwmod_idle() requires the hwmod to
> be in the enabled state.

The only thing that HWMOD_INIT_NO_IDLE does is prevent the hwmod from 
being idled at the end of _setup().  By that time, the hwmod has already 
been enabled, and its state has been set to _HWMOD_STATE_ENABLED.  So 
there shouldn't be anything preventing the hwmod from being idled at that 
point?

Maybe the problem is that some hwmods were failing _wait_target_ready() 
and so were never entering the ENABLED state?  If so, that looks like it's 
fixed appropriately by your patch 3.

> This patch adds a check to omap_hwmod_idle() so if the hwmod was has
> the INIT_NO_IDLE flag, calling omap_hwmod_idle() will still succeed.
> 
> Cc: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod.c |   11 ++++++++++-
>  1 files changed, 10 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 95c9a5f..ac75407 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -938,7 +938,13 @@ static int _enable(struct omap_hwmod *oh)
>   */
>  static int _idle(struct omap_hwmod *oh)
>  {
> -	if (oh->_state != _HWMOD_STATE_ENABLED) {
> +	/*
> +	 * To idle, hwmod must be enabled, EXCEPT if hwmod was
> +	 * initialized using the INIT_NO_IDLE flag.  In this case it
> +	 * will not yet be enabled so we have to allow it to be idled.
> +	 */
> +	if ((oh->_state != _HWMOD_STATE_ENABLED) &&
> +	    !(oh->flags & HWMOD_INIT_NO_IDLE)) {
>  		WARN(1, "omap_hwmod: %s: idle state can only be entered from "
>  		     "enabled state\n", oh->name);
>  		return -EINVAL;
> @@ -953,6 +959,9 @@ static int _idle(struct omap_hwmod *oh)
>  
>  	oh->_state = _HWMOD_STATE_IDLE;
>  
> +	/* Clear init flag which should only affect first call to idle */
> +	oh->flags &= ~HWMOD_INIT_NO_IDLE;


- Paul

Re: [PATCH 02/13] OMAP: hwmod: allow idle after HWMOD_INIT_NO_IDLE

[Kevin Hilman]

Paul Walmsley <paul@pwsan.com> writes:

> Hi Kevin,
>
> something doesn't make sense in this patch...
>
> On Wed, 23 Jun 2010, Kevin Hilman wrote:
>
>> If an omap_hwmod is setup using HWMOD_INIT_NO_IDLE flag, there is
>> currently way to idle it since omap_hwmod_idle() requires the hwmod to
>> be in the enabled state.
>
> The only thing that HWMOD_INIT_NO_IDLE does is prevent the hwmod from 
> being idled at the end of _setup().  By that time, the hwmod has already 
> been enabled, and its state has been set to _HWMOD_STATE_ENABLED.  So 
> there shouldn't be anything preventing the hwmod from being idled at that 
> point?
>
> Maybe the problem is that some hwmods were failing _wait_target_ready() 
> and so were never entering the ENABLED state?  If so, that looks like it's 
> fixed appropriately by your patch 3.

Hmm, strange.  

Indeed, this patch predates patch 3, so may not be necessary anymore.  I will
check into it.

Kevin

Re: [PATCH 02/13] OMAP: hwmod: allow idle after HWMOD_INIT_NO_IDLE

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> Paul Walmsley <paul@pwsan.com> writes:
>
>> Hi Kevin,
>>
>> something doesn't make sense in this patch...
>>
>> On Wed, 23 Jun 2010, Kevin Hilman wrote:
>>
>>> If an omap_hwmod is setup using HWMOD_INIT_NO_IDLE flag, there is
>>> currently way to idle it since omap_hwmod_idle() requires the hwmod to
>>> be in the enabled state.
>>
>> The only thing that HWMOD_INIT_NO_IDLE does is prevent the hwmod from 
>> being idled at the end of _setup().  By that time, the hwmod has already 
>> been enabled, and its state has been set to _HWMOD_STATE_ENABLED.  So 
>> there shouldn't be anything preventing the hwmod from being idled at that 
>> point?
>>
>> Maybe the problem is that some hwmods were failing _wait_target_ready() 
>> and so were never entering the ENABLED state?  If so, that looks like it's 
>> fixed appropriately by your patch 3.
>
> Hmm, strange.  
>
> Indeed, this patch predates patch 3, so may not be necessary anymore.  I will
> check into it.
>

Just to update... this patch is no longer needed.  Dropping from the
series and an updated pm-hwmods branch has been pushed.

Kevin

[PATCH 03/13] OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST

[Kevin Hilman]

Since these hwmods do not have IDLEST, set the HWMOD_NO_IDLEST flag,
otherwise _enable() will fail due to failing _wait_target_ready().

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |    9 ++++++---
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |    9 ++++++---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   12 ++++++++----
 3 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index e5530c5..a8b57a6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -65,7 +65,8 @@ static struct omap_hwmod omap2420_l3_hwmod = {
 	.masters_cnt	= ARRAY_SIZE(omap2420_l3_masters),
 	.slaves		= omap2420_l3_slaves,
 	.slaves_cnt	= ARRAY_SIZE(omap2420_l3_slaves),
-	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+	.flags		= HWMOD_NO_IDLEST,
 };
 
 static struct omap_hwmod omap2420_l4_wkup_hwmod;
@@ -95,7 +96,8 @@ static struct omap_hwmod omap2420_l4_core_hwmod = {
 	.masters_cnt	= ARRAY_SIZE(omap2420_l4_core_masters),
 	.slaves		= omap2420_l4_core_slaves,
 	.slaves_cnt	= ARRAY_SIZE(omap2420_l4_core_slaves),
-	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+	.flags		= HWMOD_NO_IDLEST,
 };
 
 /* Slave interfaces on the L4_WKUP interconnect */
@@ -115,7 +117,8 @@ static struct omap_hwmod omap2420_l4_wkup_hwmod = {
 	.masters_cnt	= ARRAY_SIZE(omap2420_l4_wkup_masters),
 	.slaves		= omap2420_l4_wkup_slaves,
 	.slaves_cnt	= ARRAY_SIZE(omap2420_l4_wkup_slaves),
-	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+	.flags		= HWMOD_NO_IDLEST,
 };
 
 /* Master interfaces on the MPU device */
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 0852d95..8b1f74b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -65,7 +65,8 @@ static struct omap_hwmod omap2430_l3_hwmod = {
 	.masters_cnt	= ARRAY_SIZE(omap2430_l3_masters),
 	.slaves		= omap2430_l3_slaves,
 	.slaves_cnt	= ARRAY_SIZE(omap2430_l3_slaves),
-	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+	.flags		= HWMOD_NO_IDLEST,
 };
 
 static struct omap_hwmod omap2430_l4_wkup_hwmod;
@@ -97,7 +98,8 @@ static struct omap_hwmod omap2430_l4_core_hwmod = {
 	.masters_cnt	= ARRAY_SIZE(omap2430_l4_core_masters),
 	.slaves		= omap2430_l4_core_slaves,
 	.slaves_cnt	= ARRAY_SIZE(omap2430_l4_core_slaves),
-	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+	.flags		= HWMOD_NO_IDLEST,
 };
 
 /* Slave interfaces on the L4_WKUP interconnect */
@@ -117,7 +119,8 @@ static struct omap_hwmod omap2430_l4_wkup_hwmod = {
 	.masters_cnt	= ARRAY_SIZE(omap2430_l4_wkup_masters),
 	.slaves		= omap2430_l4_wkup_slaves,
 	.slaves_cnt	= ARRAY_SIZE(omap2430_l4_wkup_slaves),
-	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+	.flags		= HWMOD_NO_IDLEST,
 };
 
 /* Master interfaces on the MPU device */
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 39b0c0e..e288b20 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -76,7 +76,8 @@ static struct omap_hwmod omap3xxx_l3_hwmod = {
 	.masters_cnt	= ARRAY_SIZE(omap3xxx_l3_masters),
 	.slaves		= omap3xxx_l3_slaves,
 	.slaves_cnt	= ARRAY_SIZE(omap3xxx_l3_slaves),
-	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+	.flags		= HWMOD_NO_IDLEST,
 };
 
 static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
@@ -106,7 +107,8 @@ static struct omap_hwmod omap3xxx_l4_core_hwmod = {
 	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_core_masters),
 	.slaves		= omap3xxx_l4_core_slaves,
 	.slaves_cnt	= ARRAY_SIZE(omap3xxx_l4_core_slaves),
-	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+	.flags		= HWMOD_NO_IDLEST,
 };
 
 /* Slave interfaces on the L4_PER interconnect */
@@ -126,7 +128,8 @@ static struct omap_hwmod omap3xxx_l4_per_hwmod = {
 	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_per_masters),
 	.slaves		= omap3xxx_l4_per_slaves,
 	.slaves_cnt	= ARRAY_SIZE(omap3xxx_l4_per_slaves),
-	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+	.flags		= HWMOD_NO_IDLEST,
 };
 
 /* Slave interfaces on the L4_WKUP interconnect */
@@ -146,7 +149,8 @@ static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
 	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_wkup_masters),
 	.slaves		= omap3xxx_l4_wkup_slaves,
 	.slaves_cnt	= ARRAY_SIZE(omap3xxx_l4_wkup_slaves),
-	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+	.flags		= HWMOD_NO_IDLEST,
 };
 
 /* Master interfaces on the MPU device */
-- 
1.7.0.2

[PATCH 04/13] OMAP: hwmod: Fix the missing braces

[Kevin Hilman]

From: Benoit Cousson <b-cousson@ti.com>

As reported by Sergei, a couple of braces were missing after
the WARM removal patch.

[07/22] OMAP: hwmod: Replace WARN by pr_warning if clock lookup failed

https://patchwork.kernel.org/patch/100756/

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index ac75407..3d11523 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -409,10 +409,11 @@ static int _init_main_clk(struct omap_hwmod *oh)
 		return 0;
 
 	oh->_clk = omap_clk_get_by_name(oh->main_clk);
-	if (!oh->_clk)
+	if (!oh->_clk) {
 		pr_warning("omap_hwmod: %s: cannot clk_get main_clk %s\n",
 			   oh->name, oh->main_clk);
 		return -EINVAL;
+	}
 
 	if (!oh->_clk->clkdm)
 		pr_warning("omap_hwmod: %s: missing clockdomain for %s.\n",
@@ -444,10 +445,11 @@ static int _init_interface_clks(struct omap_hwmod *oh)
 			continue;
 
 		c = omap_clk_get_by_name(os->clk);
-		if (!c)
+		if (!c) {
 			pr_warning("omap_hwmod: %s: cannot clk_get interface_clk %s\n",
 				   oh->name, os->clk);
 			ret = -EINVAL;
+		}
 		os->_clk = c;
 	}
 
@@ -470,10 +472,11 @@ static int _init_opt_clks(struct omap_hwmod *oh)
 
 	for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++) {
 		c = omap_clk_get_by_name(oc->clk);
-		if (!c)
+		if (!c) {
 			pr_warning("omap_hwmod: %s: cannot clk_get opt_clk %s\n",
 				   oh->name, oc->clk);
 			ret = -EINVAL;
+		}
 		oc->_clk = c;
 	}
 
-- 
1.7.0.2

RE: [PATCH 04/13] OMAP: hwmod: Fix the missing braces

[Gadiyar, Anand]

Kevin Hilman wrote:
> Sent: Wednesday, June 23, 2010 6:43 PM
> To: linux-omap@vger.kernel.org
> Cc: paul@pwsan.com; Cousson, Benoit; Sergei Shtylyov
> Subject: [PATCH 04/13] OMAP: hwmod: Fix the missing braces
> 
> From: Benoit Cousson <b-cousson@ti.com>
> 
> As reported by Sergei, a couple of braces were missing after
> the WARM removal patch.

s/WARM/WARN?

> 
> [07/22] OMAP: hwmod: Replace WARN by pr_warning if clock lookup failed
> 
> https://patchwork.kernel.org/patch/100756/
> 
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Sergei Shtylyov <sshtylyov@mvista.com>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

RE: [PATCH 04/13] OMAP: hwmod: Fix the missing braces

[Paul Walmsley]

On Thu, 24 Jun 2010, Gadiyar, Anand wrote:

> Kevin Hilman wrote:
> > Sent: Wednesday, June 23, 2010 6:43 PM
> > To: linux-omap@vger.kernel.org
> > Cc: paul@pwsan.com; Cousson, Benoit; Sergei Shtylyov
> > Subject: [PATCH 04/13] OMAP: hwmod: Fix the missing braces
> > 
> > From: Benoit Cousson <b-cousson@ti.com>
> > 
> > As reported by Sergei, a couple of braces were missing after
> > the WARM removal patch.
> 
> s/WARM/WARN?

Thanks, just fixed that in the patch description.


- Paul

[PATCH 05/13] OMAP2&3: hwmod: Remove _hwmod prefix in name string

[Kevin Hilman]

From: Benoit Cousson <b-cousson@ti.com>

In the lastest OMAP4 hwmod data file, the _hwmod was removed
in order to save some memory space and because it does not
bring a lot.
Align OMAP2420, 2430 and 3430 data files with the same convention.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |    6 +++---
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |    6 +++---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |    8 ++++----
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a8b57a6..646386c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -59,7 +59,7 @@ static struct omap_hwmod_ocp_if *omap2420_l3_masters[] = {
 
 /* L3 */
 static struct omap_hwmod omap2420_l3_hwmod = {
-	.name		= "l3_hwmod",
+	.name		= "l3_main",
 	.class		= &l3_hwmod_class,
 	.masters	= omap2420_l3_masters,
 	.masters_cnt	= ARRAY_SIZE(omap2420_l3_masters),
@@ -90,7 +90,7 @@ static struct omap_hwmod_ocp_if *omap2420_l4_core_masters[] = {
 
 /* L4 CORE */
 static struct omap_hwmod omap2420_l4_core_hwmod = {
-	.name		= "l4_core_hwmod",
+	.name		= "l4_core",
 	.class		= &l4_hwmod_class,
 	.masters	= omap2420_l4_core_masters,
 	.masters_cnt	= ARRAY_SIZE(omap2420_l4_core_masters),
@@ -111,7 +111,7 @@ static struct omap_hwmod_ocp_if *omap2420_l4_wkup_masters[] = {
 
 /* L4 WKUP */
 static struct omap_hwmod omap2420_l4_wkup_hwmod = {
-	.name		= "l4_wkup_hwmod",
+	.name		= "l4_wkup",
 	.class		= &l4_hwmod_class,
 	.masters	= omap2420_l4_wkup_masters,
 	.masters_cnt	= ARRAY_SIZE(omap2420_l4_wkup_masters),
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 8b1f74b..b2100cf 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -59,7 +59,7 @@ static struct omap_hwmod_ocp_if *omap2430_l3_masters[] = {
 
 /* L3 */
 static struct omap_hwmod omap2430_l3_hwmod = {
-	.name		= "l3_hwmod",
+	.name		= "l3_main",
 	.class		= &l3_hwmod_class,
 	.masters	= omap2430_l3_masters,
 	.masters_cnt	= ARRAY_SIZE(omap2430_l3_masters),
@@ -92,7 +92,7 @@ static struct omap_hwmod_ocp_if *omap2430_l4_core_masters[] = {
 
 /* L4 CORE */
 static struct omap_hwmod omap2430_l4_core_hwmod = {
-	.name		= "l4_core_hwmod",
+	.name		= "l4_core",
 	.class		= &l4_hwmod_class,
 	.masters	= omap2430_l4_core_masters,
 	.masters_cnt	= ARRAY_SIZE(omap2430_l4_core_masters),
@@ -113,7 +113,7 @@ static struct omap_hwmod_ocp_if *omap2430_l4_wkup_masters[] = {
 
 /* L4 WKUP */
 static struct omap_hwmod omap2430_l4_wkup_hwmod = {
-	.name		= "l4_wkup_hwmod",
+	.name		= "l4_wkup",
 	.class		= &l4_hwmod_class,
 	.masters	= omap2430_l4_wkup_masters,
 	.masters_cnt	= ARRAY_SIZE(omap2430_l4_wkup_masters),
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index e288b20..ec6a5f8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -70,7 +70,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l3_masters[] = {
 
 /* L3 */
 static struct omap_hwmod omap3xxx_l3_hwmod = {
-	.name		= "l3_hwmod",
+	.name		= "l3_main",
 	.class		= &l3_hwmod_class,
 	.masters	= omap3xxx_l3_masters,
 	.masters_cnt	= ARRAY_SIZE(omap3xxx_l3_masters),
@@ -101,7 +101,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_core_masters[] = {
 
 /* L4 CORE */
 static struct omap_hwmod omap3xxx_l4_core_hwmod = {
-	.name		= "l4_core_hwmod",
+	.name		= "l4_core",
 	.class		= &l4_hwmod_class,
 	.masters	= omap3xxx_l4_core_masters,
 	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_core_masters),
@@ -122,7 +122,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_per_masters[] = {
 
 /* L4 PER */
 static struct omap_hwmod omap3xxx_l4_per_hwmod = {
-	.name		= "l4_per_hwmod",
+	.name		= "l4_per",
 	.class		= &l4_hwmod_class,
 	.masters	= omap3xxx_l4_per_masters,
 	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_per_masters),
@@ -143,7 +143,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_masters[] = {
 
 /* L4 WKUP */
 static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
-	.name		= "l4_wkup_hwmod",
+	.name		= "l4_wkup",
 	.class		= &l4_hwmod_class,
 	.masters	= omap3xxx_l4_wkup_masters,
 	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_wkup_masters),
-- 
1.7.0.2

Re: [PATCH 05/13] OMAP2&3: hwmod: Remove _hwmod prefix in name string

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5306 bytes --]

Benoît,

one minor comment here:

On Wed, 23 Jun 2010, Kevin Hilman wrote:

> From: Benoit Cousson <b-cousson@ti.com>
> 
> In the lastest OMAP4 hwmod data file, the _hwmod was removed
> in order to save some memory space and because it does not
> bring a lot.
> Align OMAP2420, 2430 and 3430 data files with the same convention.

Shouldn't we also synchronize the names of the structures as well?  i.e., 
if the name is changed to "l3_main", shouldn't the name of the structure 
also be changed from 

   static struct omap_hwmod omap2420_l3_hwmod = {

to 

   static struct omap_hwmod omap2420_l3_main_hwmod = {

(... as one example?)


- Paul

> 
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_2420_data.c |    6 +++---
>  arch/arm/mach-omap2/omap_hwmod_2430_data.c |    6 +++---
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |    8 ++++----
>  3 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> index a8b57a6..646386c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> @@ -59,7 +59,7 @@ static struct omap_hwmod_ocp_if *omap2420_l3_masters[] = {
>  
>  /* L3 */
>  static struct omap_hwmod omap2420_l3_hwmod = {
> -	.name		= "l3_hwmod",
> +	.name		= "l3_main",
>  	.class		= &l3_hwmod_class,
>  	.masters	= omap2420_l3_masters,
>  	.masters_cnt	= ARRAY_SIZE(omap2420_l3_masters),
> @@ -90,7 +90,7 @@ static struct omap_hwmod_ocp_if *omap2420_l4_core_masters[] = {
>  
>  /* L4 CORE */
>  static struct omap_hwmod omap2420_l4_core_hwmod = {
> -	.name		= "l4_core_hwmod",
> +	.name		= "l4_core",
>  	.class		= &l4_hwmod_class,
>  	.masters	= omap2420_l4_core_masters,
>  	.masters_cnt	= ARRAY_SIZE(omap2420_l4_core_masters),
> @@ -111,7 +111,7 @@ static struct omap_hwmod_ocp_if *omap2420_l4_wkup_masters[] = {
>  
>  /* L4 WKUP */
>  static struct omap_hwmod omap2420_l4_wkup_hwmod = {
> -	.name		= "l4_wkup_hwmod",
> +	.name		= "l4_wkup",
>  	.class		= &l4_hwmod_class,
>  	.masters	= omap2420_l4_wkup_masters,
>  	.masters_cnt	= ARRAY_SIZE(omap2420_l4_wkup_masters),
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> index 8b1f74b..b2100cf 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> @@ -59,7 +59,7 @@ static struct omap_hwmod_ocp_if *omap2430_l3_masters[] = {
>  
>  /* L3 */
>  static struct omap_hwmod omap2430_l3_hwmod = {
> -	.name		= "l3_hwmod",
> +	.name		= "l3_main",
>  	.class		= &l3_hwmod_class,
>  	.masters	= omap2430_l3_masters,
>  	.masters_cnt	= ARRAY_SIZE(omap2430_l3_masters),
> @@ -92,7 +92,7 @@ static struct omap_hwmod_ocp_if *omap2430_l4_core_masters[] = {
>  
>  /* L4 CORE */
>  static struct omap_hwmod omap2430_l4_core_hwmod = {
> -	.name		= "l4_core_hwmod",
> +	.name		= "l4_core",
>  	.class		= &l4_hwmod_class,
>  	.masters	= omap2430_l4_core_masters,
>  	.masters_cnt	= ARRAY_SIZE(omap2430_l4_core_masters),
> @@ -113,7 +113,7 @@ static struct omap_hwmod_ocp_if *omap2430_l4_wkup_masters[] = {
>  
>  /* L4 WKUP */
>  static struct omap_hwmod omap2430_l4_wkup_hwmod = {
> -	.name		= "l4_wkup_hwmod",
> +	.name		= "l4_wkup",
>  	.class		= &l4_hwmod_class,
>  	.masters	= omap2430_l4_wkup_masters,
>  	.masters_cnt	= ARRAY_SIZE(omap2430_l4_wkup_masters),
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index e288b20..ec6a5f8 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -70,7 +70,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l3_masters[] = {
>  
>  /* L3 */
>  static struct omap_hwmod omap3xxx_l3_hwmod = {
> -	.name		= "l3_hwmod",
> +	.name		= "l3_main",
>  	.class		= &l3_hwmod_class,
>  	.masters	= omap3xxx_l3_masters,
>  	.masters_cnt	= ARRAY_SIZE(omap3xxx_l3_masters),
> @@ -101,7 +101,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_core_masters[] = {
>  
>  /* L4 CORE */
>  static struct omap_hwmod omap3xxx_l4_core_hwmod = {
> -	.name		= "l4_core_hwmod",
> +	.name		= "l4_core",
>  	.class		= &l4_hwmod_class,
>  	.masters	= omap3xxx_l4_core_masters,
>  	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_core_masters),
> @@ -122,7 +122,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_per_masters[] = {
>  
>  /* L4 PER */
>  static struct omap_hwmod omap3xxx_l4_per_hwmod = {
> -	.name		= "l4_per_hwmod",
> +	.name		= "l4_per",
>  	.class		= &l4_hwmod_class,
>  	.masters	= omap3xxx_l4_per_masters,
>  	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_per_masters),
> @@ -143,7 +143,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_masters[] = {
>  
>  /* L4 WKUP */
>  static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
> -	.name		= "l4_wkup_hwmod",
> +	.name		= "l4_wkup",
>  	.class		= &l4_hwmod_class,
>  	.masters	= omap3xxx_l4_wkup_masters,
>  	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_wkup_masters),
> -- 
> 1.7.0.2
> 


- Paul

RE: [PATCH 05/13] OMAP2&3: hwmod: Remove _hwmod prefix in name string

[Cousson, Benoit]

Hi Paul,

>From: Paul Walmsley [mailto:paul@pwsan.com]
>Sent: Thursday, June 24, 2010 7:05 AM
>
>Benoît,
>
>one minor comment here:
>
>On Wed, 23 Jun 2010, Kevin Hilman wrote:
>
>> From: Benoit Cousson <b-cousson@ti.com>
>>
>> In the lastest OMAP4 hwmod data file, the _hwmod was removed
>> in order to save some memory space and because it does not
>> bring a lot.
>> Align OMAP2420, 2430 and 3430 data files with the same convention.
>
>Shouldn't we also synchronize the names of the structures as
>well?  i.e.,
>if the name is changed to "l3_main", shouldn't the name of the
>structure
>also be changed from
>
>   static struct omap_hwmod omap2420_l3_hwmod = {
>
>to
>
>   static struct omap_hwmod omap2420_l3_main_hwmod = {
>
>(... as one example?)

You're right, I didn't change that because only the string is relevant
for the lookup, but it will be much more consitent to change the structures
as well.

I'll do it.

Thanks,
Benoit

>
>
>- Paul
>
>>
>> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
>> Cc: Paul Walmsley <paul@pwsan.com>
>> Cc: Rajendra Nayak <rnayak@ti.com>
>> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
>> ---
>>  arch/arm/mach-omap2/omap_hwmod_2420_data.c |    6 +++---
>>  arch/arm/mach-omap2/omap_hwmod_2430_data.c |    6 +++---
>>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |    8 ++++----
>>  3 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
>b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
>> index a8b57a6..646386c 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
>> @@ -59,7 +59,7 @@ static struct omap_hwmod_ocp_if
>*omap2420_l3_masters[] = {
>>
>>  /* L3 */
>>  static struct omap_hwmod omap2420_l3_hwmod = {
>> -    .name           = "l3_hwmod",
>> +    .name           = "l3_main",
>>      .class          = &l3_hwmod_class,
>>      .masters        = omap2420_l3_masters,
>>      .masters_cnt    = ARRAY_SIZE(omap2420_l3_masters),
>> @@ -90,7 +90,7 @@ static struct omap_hwmod_ocp_if
>*omap2420_l4_core_masters[] = {
>>
>>  /* L4 CORE */
>>  static struct omap_hwmod omap2420_l4_core_hwmod = {
>> -    .name           = "l4_core_hwmod",
>> +    .name           = "l4_core",
>>      .class          = &l4_hwmod_class,
>>      .masters        = omap2420_l4_core_masters,
>>      .masters_cnt    = ARRAY_SIZE(omap2420_l4_core_masters),
>> @@ -111,7 +111,7 @@ static struct omap_hwmod_ocp_if
>*omap2420_l4_wkup_masters[] = {
>>
>>  /* L4 WKUP */
>>  static struct omap_hwmod omap2420_l4_wkup_hwmod = {
>> -    .name           = "l4_wkup_hwmod",
>> +    .name           = "l4_wkup",
>>      .class          = &l4_hwmod_class,
>>      .masters        = omap2420_l4_wkup_masters,
>>      .masters_cnt    = ARRAY_SIZE(omap2420_l4_wkup_masters),
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
>b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
>> index 8b1f74b..b2100cf 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
>> @@ -59,7 +59,7 @@ static struct omap_hwmod_ocp_if
>*omap2430_l3_masters[] = {
>>
>>  /* L3 */
>>  static struct omap_hwmod omap2430_l3_hwmod = {
>> -    .name           = "l3_hwmod",
>> +    .name           = "l3_main",
>>      .class          = &l3_hwmod_class,
>>      .masters        = omap2430_l3_masters,
>>      .masters_cnt    = ARRAY_SIZE(omap2430_l3_masters),
>> @@ -92,7 +92,7 @@ static struct omap_hwmod_ocp_if
>*omap2430_l4_core_masters[] = {
>>
>>  /* L4 CORE */
>>  static struct omap_hwmod omap2430_l4_core_hwmod = {
>> -    .name           = "l4_core_hwmod",
>> +    .name           = "l4_core",
>>      .class          = &l4_hwmod_class,
>>      .masters        = omap2430_l4_core_masters,
>>      .masters_cnt    = ARRAY_SIZE(omap2430_l4_core_masters),
>> @@ -113,7 +113,7 @@ static struct omap_hwmod_ocp_if
>*omap2430_l4_wkup_masters[] = {
>>
>>  /* L4 WKUP */
>>  static struct omap_hwmod omap2430_l4_wkup_hwmod = {
>> -    .name           = "l4_wkup_hwmod",
>> +    .name           = "l4_wkup",
>>      .class          = &l4_hwmod_class,
>>      .masters        = omap2430_l4_wkup_masters,
>>      .masters_cnt    = ARRAY_SIZE(omap2430_l4_wkup_masters),
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
>b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
>> index e288b20..ec6a5f8 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
>> @@ -70,7 +70,7 @@ static struct omap_hwmod_ocp_if
>*omap3xxx_l3_masters[] = {
>>
>>  /* L3 */
>>  static struct omap_hwmod omap3xxx_l3_hwmod = {
>> -    .name           = "l3_hwmod",
>> +    .name           = "l3_main",
>>      .class          = &l3_hwmod_class,
>>      .masters        = omap3xxx_l3_masters,
>>      .masters_cnt    = ARRAY_SIZE(omap3xxx_l3_masters),
>> @@ -101,7 +101,7 @@ static struct omap_hwmod_ocp_if
>*omap3xxx_l4_core_masters[] = {
>>
>>  /* L4 CORE */
>>  static struct omap_hwmod omap3xxx_l4_core_hwmod = {
>> -    .name           = "l4_core_hwmod",
>> +    .name           = "l4_core",
>>      .class          = &l4_hwmod_class,
>>      .masters        = omap3xxx_l4_core_masters,
>>      .masters_cnt    = ARRAY_SIZE(omap3xxx_l4_core_masters),
>> @@ -122,7 +122,7 @@ static struct omap_hwmod_ocp_if
>*omap3xxx_l4_per_masters[] = {
>>
>>  /* L4 PER */
>>  static struct omap_hwmod omap3xxx_l4_per_hwmod = {
>> -    .name           = "l4_per_hwmod",
>> +    .name           = "l4_per",
>>      .class          = &l4_hwmod_class,
>>      .masters        = omap3xxx_l4_per_masters,
>>      .masters_cnt    = ARRAY_SIZE(omap3xxx_l4_per_masters),
>> @@ -143,7 +143,7 @@ static struct omap_hwmod_ocp_if
>*omap3xxx_l4_wkup_masters[] = {
>>
>>  /* L4 WKUP */
>>  static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
>> -    .name           = "l4_wkup_hwmod",
>> +    .name           = "l4_wkup",
>>      .class          = &l4_hwmod_class,
>>      .masters        = omap3xxx_l4_wkup_masters,
>>      .masters_cnt    = ARRAY_SIZE(omap3xxx_l4_wkup_masters),
>> --
>> 1.7.0.2
>>
>
>
>- Paul
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920



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

Re: [PATCH 05/13] OMAP2&3: hwmod: Remove _hwmod prefix in name string

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 635 bytes --]

Hi,

On Wed, 23 Jun 2010, Kevin Hilman wrote:

> From: Benoit Cousson <b-cousson@ti.com>
> 
> In the lastest OMAP4 hwmod data file, the _hwmod was removed
> in order to save some memory space and because it does not
> bring a lot.
> Align OMAP2420, 2430 and 3430 data files with the same convention.
> 
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

I've taken Benoît's original patch for this, so have converted your 
Signed-off-by: into an Acked-by: for this patch.


- Paul

[PATCH 06/13] OMAP: hwmod: add non-locking versions of enable and idle functions

[Kevin Hilman]

Some hwmods may need to be idled/enabled in atomic context, so
non-locking versions of these functions are required.

Most users should not need these and usage of theses should be
controlled to understand why access is being done in atomic context.
For this reason, the non-locking functions are only exposed at the
hwmod level and not at the omap-device level.

The use-case that led to the need for the non-locking versions is
hwmods that are enabled/idled from within the core idle/suspend path.
Since interrupts are already disabled here, the mutex-based locking in
hwmod can sleep and will cause potential deadlocks.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/omap_hwmod.c             |   32 ++++++++++++++++++++++---
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    2 +
 2 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 3d11523..8b2b44a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1287,6 +1287,18 @@ int omap_hwmod_unregister(struct omap_hwmod *oh)
 }
 
 /**
+ * __omap_hwmod_enable - enable an omap_hwmod (non-locking version)
+ * @oh: struct omap_hwmod *
+ *
+ * Enable an omap_hwomd @oh.  Intended to be called in rare cases
+ * where usage is required in atomic context.
+ */
+int __omap_hwmod_enable(struct omap_hwmod *oh)
+{
+	return _enable(oh);
+}
+
+/**
  * omap_hwmod_enable - enable an omap_hwmod
  * @oh: struct omap_hwmod *
  *
@@ -1301,12 +1313,26 @@ int omap_hwmod_enable(struct omap_hwmod *oh)
 		return -EINVAL;
 
 	mutex_lock(&omap_hwmod_mutex);
-	r = _enable(oh);
+	r = __omap_hwmod_enable(oh);
 	mutex_unlock(&omap_hwmod_mutex);
 
 	return r;
 }
 
+
+/**
+ * __omap_hwmod_idle - idle an omap_hwmod (non-locking)
+ * @oh: struct omap_hwmod *
+ *
+ * Idle an omap_hwomd @oh.  Intended to be called in rare instances where
+ * used in atomic context.
+ */
+int __omap_hwmod_idle(struct omap_hwmod *oh)
+{
+	_idle(oh);
+	return 0;
+}
+
 /**
  * omap_hwmod_idle - idle an omap_hwmod
  * @oh: struct omap_hwmod *
@@ -1319,9 +1345,7 @@ int omap_hwmod_idle(struct omap_hwmod *oh)
 	if (!oh)
 		return -EINVAL;
 
-	mutex_lock(&omap_hwmod_mutex);
-	_idle(oh);
-	mutex_unlock(&omap_hwmod_mutex);
+	__omap_hwmod_idle(oh);
 
 	return 0;
 }
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 0eccc09..9a3f4dc 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -486,7 +486,9 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh));
 int omap_hwmod_late_init(void);
 
 int omap_hwmod_enable(struct omap_hwmod *oh);
+int __omap_hwmod_enable(struct omap_hwmod *oh);
 int omap_hwmod_idle(struct omap_hwmod *oh);
+int __omap_hwmod_idle(struct omap_hwmod *oh);
 int omap_hwmod_shutdown(struct omap_hwmod *oh);
 
 int omap_hwmod_enable_clocks(struct omap_hwmod *oh);
-- 
1.7.0.2

Re: [PATCH 06/13] OMAP: hwmod: add non-locking versions of enable and idle functions

[Paul Walmsley]

Hi Kevin

On Wed, 23 Jun 2010, Kevin Hilman wrote:

> Some hwmods may need to be idled/enabled in atomic context, so
> non-locking versions of these functions are required.
> 
> Most users should not need these and usage of theses should be
> controlled to understand why access is being done in atomic context.
> For this reason, the non-locking functions are only exposed at the
> hwmod level and not at the omap-device level.
> 
> The use-case that led to the need for the non-locking versions is
> hwmods that are enabled/idled from within the core idle/suspend path.
> Since interrupts are already disabled here, the mutex-based locking in
> hwmod can sleep and will cause potential deadlocks.

I accept the use-case.  But maybe it would be preferable to rename 
_enable(), _idle(), _shutdown() to _omap_hwmod_{enable,idle,shutdown}() ?
That would avoid the need to add new functions that just call the existing 
ones.


- Paul

> 
> Cc: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod.c             |   32 ++++++++++++++++++++++---
>  arch/arm/plat-omap/include/plat/omap_hwmod.h |    2 +
>  2 files changed, 30 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 3d11523..8b2b44a 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -1287,6 +1287,18 @@ int omap_hwmod_unregister(struct omap_hwmod *oh)
>  }
>  
>  /**
> + * __omap_hwmod_enable - enable an omap_hwmod (non-locking version)
> + * @oh: struct omap_hwmod *
> + *
> + * Enable an omap_hwomd @oh.  Intended to be called in rare cases
> + * where usage is required in atomic context.
> + */
> +int __omap_hwmod_enable(struct omap_hwmod *oh)
> +{
> +	return _enable(oh);
> +}
> +
> +/**
>   * omap_hwmod_enable - enable an omap_hwmod
>   * @oh: struct omap_hwmod *
>   *
> @@ -1301,12 +1313,26 @@ int omap_hwmod_enable(struct omap_hwmod *oh)
>  		return -EINVAL;
>  
>  	mutex_lock(&omap_hwmod_mutex);
> -	r = _enable(oh);
> +	r = __omap_hwmod_enable(oh);
>  	mutex_unlock(&omap_hwmod_mutex);
>  
>  	return r;
>  }
>  
> +
> +/**
> + * __omap_hwmod_idle - idle an omap_hwmod (non-locking)
> + * @oh: struct omap_hwmod *
> + *
> + * Idle an omap_hwomd @oh.  Intended to be called in rare instances where
> + * used in atomic context.
> + */
> +int __omap_hwmod_idle(struct omap_hwmod *oh)
> +{
> +	_idle(oh);
> +	return 0;
> +}
> +
>  /**
>   * omap_hwmod_idle - idle an omap_hwmod
>   * @oh: struct omap_hwmod *
> @@ -1319,9 +1345,7 @@ int omap_hwmod_idle(struct omap_hwmod *oh)
>  	if (!oh)
>  		return -EINVAL;
>  
> -	mutex_lock(&omap_hwmod_mutex);
> -	_idle(oh);
> -	mutex_unlock(&omap_hwmod_mutex);
> +	__omap_hwmod_idle(oh);
>  
>  	return 0;
>  }
> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> index 0eccc09..9a3f4dc 100644
> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> @@ -486,7 +486,9 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh));
>  int omap_hwmod_late_init(void);
>  
>  int omap_hwmod_enable(struct omap_hwmod *oh);
> +int __omap_hwmod_enable(struct omap_hwmod *oh);
>  int omap_hwmod_idle(struct omap_hwmod *oh);
> +int __omap_hwmod_idle(struct omap_hwmod *oh);
>  int omap_hwmod_shutdown(struct omap_hwmod *oh);
>  
>  int omap_hwmod_enable_clocks(struct omap_hwmod *oh);
> -- 
> 1.7.0.2
> 


- Paul

RE: [PATCH 06/13] OMAP: hwmod: add non-locking versions of enable and idle functions

[Basak, Partha]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Paul Walmsley
> Sent: Thursday, June 24, 2010 10:39 AM
> To: Kevin Hilman
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH 06/13] OMAP: hwmod: add non-locking versions of enable
> and idle functions
> 
> Hi Kevin
> 
> On Wed, 23 Jun 2010, Kevin Hilman wrote:
> 
> > Some hwmods may need to be idled/enabled in atomic context, so
> > non-locking versions of these functions are required.
> >
> > Most users should not need these and usage of theses should be
> > controlled to understand why access is being done in atomic context.
> > For this reason, the non-locking functions are only exposed at the
> > hwmod level and not at the omap-device level.
> >
> > The use-case that led to the need for the non-locking versions is
> > hwmods that are enabled/idled from within the core idle/suspend path.
> > Since interrupts are already disabled here, the mutex-based locking in
> > hwmod can sleep and will cause potential deadlocks.
> 
> I accept the use-case.  But maybe it would be preferable to rename
> _enable(), _idle(), _shutdown() to _omap_hwmod_{enable,idle,shutdown}() ?
> That would avoid the need to add new functions that just call the existing
> ones.
> 
> 
> - Paul
> 
> >
> > Cc: Paul Walmsley <paul@pwsan.com>
> > Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
> > ---
> >  arch/arm/mach-omap2/omap_hwmod.c             |   32
> ++++++++++++++++++++++---
> >  arch/arm/plat-omap/include/plat/omap_hwmod.h |    2 +
> >  2 files changed, 30 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-
> omap2/omap_hwmod.c
> > index 3d11523..8b2b44a 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod.c
> > @@ -1287,6 +1287,18 @@ int omap_hwmod_unregister(struct omap_hwmod *oh)
> >  }
> >
> >  /**
> > + * __omap_hwmod_enable - enable an omap_hwmod (non-locking version)
> > + * @oh: struct omap_hwmod *
> > + *
> > + * Enable an omap_hwomd @oh.  Intended to be called in rare cases
> > + * where usage is required in atomic context.
> > + */
> > +int __omap_hwmod_enable(struct omap_hwmod *oh)
> > +{
> > +	return _enable(oh);
> > +}
> > +
> > +/**
> >   * omap_hwmod_enable - enable an omap_hwmod
> >   * @oh: struct omap_hwmod *
> >   *
> > @@ -1301,12 +1313,26 @@ int omap_hwmod_enable(struct omap_hwmod *oh)
> >  		return -EINVAL;
> >
> >  	mutex_lock(&omap_hwmod_mutex);
> > -	r = _enable(oh);
> > +	r = __omap_hwmod_enable(oh);
> >  	mutex_unlock(&omap_hwmod_mutex);
> >
> >  	return r;
> >  }
> >
> > +
> > +/**
> > + * __omap_hwmod_idle - idle an omap_hwmod (non-locking)
> > + * @oh: struct omap_hwmod *
> > + *
> > + * Idle an omap_hwomd @oh.  Intended to be called in rare instances
> where
> > + * used in atomic context.
> > + */
> > +int __omap_hwmod_idle(struct omap_hwmod *oh)
> > +{
> > +	_idle(oh);
> > +	return 0;
> > +}
> > +
> >  /**
> >   * omap_hwmod_idle - idle an omap_hwmod
> >   * @oh: struct omap_hwmod *
> > @@ -1319,9 +1345,7 @@ int omap_hwmod_idle(struct omap_hwmod *oh)
> >  	if (!oh)
> >  		return -EINVAL;
> >
> > -	mutex_lock(&omap_hwmod_mutex);
> > -	_idle(oh);
> > -	mutex_unlock(&omap_hwmod_mutex);
> > +	__omap_hwmod_idle(oh);
> >
BTW: The mutex locks are missing. Typo?

> >  	return 0;
> >  }
> > diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> > index 0eccc09..9a3f4dc 100644
> > --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> > +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> > @@ -486,7 +486,9 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod
> *oh));
> >  int omap_hwmod_late_init(void);
> >
> >  int omap_hwmod_enable(struct omap_hwmod *oh);
> > +int __omap_hwmod_enable(struct omap_hwmod *oh);
> >  int omap_hwmod_idle(struct omap_hwmod *oh);
> > +int __omap_hwmod_idle(struct omap_hwmod *oh);
> >  int omap_hwmod_shutdown(struct omap_hwmod *oh);
> >
> >  int omap_hwmod_enable_clocks(struct omap_hwmod *oh);
> > --
> > 1.7.0.2
> >
> 
> 
> - Paul
> --
> 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

Re: [PATCH 06/13] OMAP: hwmod: add non-locking versions of enable and idle functions

[Kevin Hilman]

"Basak, Partha" <p-basak2@ti.com> writes:

[...]

>> >  /**
>> >   * omap_hwmod_idle - idle an omap_hwmod
>> >   * @oh: struct omap_hwmod *
>> > @@ -1319,9 +1345,7 @@ int omap_hwmod_idle(struct omap_hwmod *oh)
>> >  	if (!oh)
>> >  		return -EINVAL;
>> >
>> > -	mutex_lock(&omap_hwmod_mutex);
>> > -	_idle(oh);
>> > -	mutex_unlock(&omap_hwmod_mutex);
>> > +	__omap_hwmod_idle(oh);
>> >
>
> BTW: The mutex locks are missing. Typo?
>

Good catch Partha.  

I wish I could explain that as only a typo.  Unfortunately, it was just
a "not paying close enough attention" mistake.

Thanks,

Kevin

Re: [PATCH 06/13] OMAP: hwmod: add non-locking versions of enable and idle functions

[Kevin Hilman]

Paul Walmsley <paul@pwsan.com> writes:

> Hi Kevin
>
> On Wed, 23 Jun 2010, Kevin Hilman wrote:
>
>> Some hwmods may need to be idled/enabled in atomic context, so
>> non-locking versions of these functions are required.
>> 
>> Most users should not need these and usage of theses should be
>> controlled to understand why access is being done in atomic context.
>> For this reason, the non-locking functions are only exposed at the
>> hwmod level and not at the omap-device level.
>> 
>> The use-case that led to the need for the non-locking versions is
>> hwmods that are enabled/idled from within the core idle/suspend path.
>> Since interrupts are already disabled here, the mutex-based locking in
>> hwmod can sleep and will cause potential deadlocks.
>
> I accept the use-case.  But maybe it would be preferable to rename 
> _enable(), _idle(), _shutdown() to _omap_hwmod_{enable,idle,shutdown}() ?
> That would avoid the need to add new functions that just call the existing 
> ones.

OK, will make that change.

Kevin

[PATCH 07/13] OMAP: hwmod: don't auto-disable hwmod when !CONFIG_PM_RUNTIME

[Kevin Hilman]

When runtime PM is disabled, the pm_runtime_idle() and _enable()
functions will be effectively noops and will not result in enable
and idle calls at the hwmod level.

In order for drivers to still work when runtime PM is disabled, ensure
that all hwmods are left in an enabled state so that even without
runtime PM management, they will still work.

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 8b2b44a..0184d74 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1059,6 +1059,14 @@ static int _setup(struct omap_hwmod *oh)
 		}
 	}
 
+#ifndef CONFIG_PM_RUNTIME
+	/*
+	 * If runtime PM is not enabled, leave the device enabled
+	 * since runtime PM will not be dynamically managing the device.
+	 */
+	oh->flags |= HWMOD_INIT_NO_IDLE;
+#endif
+
 	if (!(oh->flags & HWMOD_INIT_NO_IDLE))
 		_idle(oh);
 
-- 
1.7.0.2

Re: [PATCH 07/13] OMAP: hwmod: don't auto-disable hwmod when !CONFIG_PM_RUNTIME

[Paul Walmsley]

Hi,

On Wed, 23 Jun 2010, Kevin Hilman wrote:

> When runtime PM is disabled, the pm_runtime_idle() and _enable()
> functions will be effectively noops and will not result in enable
> and idle calls at the hwmod level.
> 
> In order for drivers to still work when runtime PM is disabled, ensure
> that all hwmods are left in an enabled state so that even without
> runtime PM management, they will still work.
> 
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

I'd prefer to keep the hwmod code free of references to higher-layer code, 
so I'll use the following patch instead.


- Paul


OMAP: hwmod: allow omap_hwmod_late_init() caller to skip module idle in _setup()

From: Paul Walmsley <paul@pwsan.com>

On kernels that don't use the omap_device_enable() calls to enable
devices, leave all on-chip devices enabled in hwmod _setup().
Otherwise, accesses to those devices are likely to fail, crashing the
system.  It's expected that kernels built without CONFIG_PM_RUNTIME
will be the primary use-case for this.  This functionality is
controlled by adding an extra parameter to omap_hwmod_late_init().

This patch is based on the patch "OMAP: hwmod: don't auto-disable
hwmod when !CONFIG_PM_RUNTIME" by Kevin Hilman
<khilman@deeprootsystems.com>.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/io.c                     |    9 ++++++
 arch/arm/mach-omap2/omap_hwmod.c             |   37 ++++++++++++++++++--------
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    5 ++--
 3 files changed, 36 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4e1f53d..05c9cdb 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -313,6 +313,8 @@ static int __init _omap2_init_reprogram_sdrc(void)
 void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
 				 struct omap_sdrc_params *sdrc_cs1)
 {
+	u8 skip_setup_idle = 0;
+
 	pwrdm_init(powerdomains_omap);
 	clkdm_init(clockdomains_omap, clkdm_autodeps);
 	if (cpu_is_omap242x())
@@ -337,8 +339,13 @@ void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
 		pr_err("Could not init clock framework - unknown CPU\n");
 
 	omap_serial_early_init();
+
+#ifndef CONFIG_PM_RUNTIME
+	skip_setup_idle = 1;
+#endif
 	if (cpu_is_omap24xx() || cpu_is_omap34xx())   /* FIXME: OMAP4 */
-		omap_hwmod_late_init();
+		omap_hwmod_late_init(skip_setup_idle);
+
 	omap_pm_if_init();
 	if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
 		omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 47943ec..d9e96fa 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -761,6 +761,7 @@ static struct omap_hwmod *_lookup(const char *name)
 /**
  * _init_clocks - clk_get() all clocks associated with this hwmod
  * @oh: struct omap_hwmod *
+ * @data: not used; pass NULL
  *
  * Called by omap_hwmod_late_init() (after omap2_clk_init()).
  * Resolves all clock names embedded in the hwmod.  Must be called
@@ -768,7 +769,7 @@ static struct omap_hwmod *_lookup(const char *name)
  * has not yet been registered or if the clocks have already been
  * initialized, 0 on success, or a non-zero error on failure.
  */
-static int _init_clocks(struct omap_hwmod *oh)
+static int _init_clocks(struct omap_hwmod *oh, void *data)
 {
 	int ret = 0;
 
@@ -993,19 +994,25 @@ static int _shutdown(struct omap_hwmod *oh)
 /**
  * _setup - do initial configuration of omap_hwmod
  * @oh: struct omap_hwmod *
+ * @skip_setup_idle_p: do not idle hwmods at the end of the fn if 1
  *
  * Writes the CLOCKACTIVITY bits @clockact to the hwmod @oh
- * OCP_SYSCONFIG register.  Must be called with omap_hwmod_mutex
- * held.  Returns -EINVAL if the hwmod is in the wrong state or returns
- * 0.
+ * OCP_SYSCONFIG register.  Must be called with omap_hwmod_mutex held.
+ * @skip_setup_idle is intended to be used on a system that will not
+ * call omap_hwmod_enable() to enable devices (e.g., a system without
+ * PM runtime).  Returns -EINVAL if the hwmod is in the wrong state or
+ * returns 0.
  */
-static int _setup(struct omap_hwmod *oh)
+static int _setup(struct omap_hwmod *oh, void *data)
 {
 	int i, r;
+	u8 skip_setup_idle;
 
-	if (!oh)
+	if (!oh || !data)
 		return -EINVAL;
 
+	skip_setup_idle = *(u8 *)data;
+
 	/* Set iclk autoidle mode */
 	if (oh->slaves_cnt > 0) {
 		for (i = 0; i < oh->slaves_cnt; i++) {
@@ -1047,7 +1054,7 @@ static int _setup(struct omap_hwmod *oh)
 		}
 	}
 
-	if (!(oh->flags & HWMOD_INIT_NO_IDLE))
+	if (!(oh->flags & HWMOD_INIT_NO_IDLE) && !skip_setup_idle)
 		_omap_hwmod_idle(oh);
 
 	return 0;
@@ -1161,6 +1168,7 @@ struct omap_hwmod *omap_hwmod_lookup(const char *name)
 /**
  * omap_hwmod_for_each - call function for each registered omap_hwmod
  * @fn: pointer to a callback function
+ * @data: void * data to pass to callback function
  *
  * Call @fn for each registered omap_hwmod, passing @data to each
  * function.  @fn must return 0 for success or any other value for
@@ -1169,7 +1177,8 @@ struct omap_hwmod *omap_hwmod_lookup(const char *name)
  * caller of omap_hwmod_for_each().  @fn is called with
  * omap_hwmod_for_each() held.
  */
-int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh))
+int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh, void *data),
+			void *data)
 {
 	struct omap_hwmod *temp_oh;
 	int ret;
@@ -1179,7 +1188,7 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh))
 
 	mutex_lock(&omap_hwmod_mutex);
 	list_for_each_entry(temp_oh, &omap_hwmod_list, node) {
-		ret = (*fn)(temp_oh);
+		ret = (*fn)(temp_oh, data);
 		if (ret)
 			break;
 	}
@@ -1226,24 +1235,28 @@ int omap_hwmod_init(struct omap_hwmod **ohs)
 
 /**
  * omap_hwmod_late_init - do some post-clock framework initialization
+ * @skip_setup_idle: if 1, do not idle hwmods in _setup()
  *
  * Must be called after omap2_clk_init().  Resolves the struct clk names
  * to struct clk pointers for each registered omap_hwmod.  Also calls
  * _setup() on each hwmod.  Returns 0.
  */
-int omap_hwmod_late_init(void)
+int omap_hwmod_late_init(u8 skip_setup_idle)
 {
 	int r;
 
 	/* XXX check return value */
-	r = omap_hwmod_for_each(_init_clocks);
+	r = omap_hwmod_for_each(_init_clocks, NULL);
 	WARN(r, "omap_hwmod: omap_hwmod_late_init(): _init_clocks failed\n");
 
 	mpu_oh = omap_hwmod_lookup(MPU_INITIATOR_NAME);
 	WARN(!mpu_oh, "omap_hwmod: could not find MPU initiator hwmod %s\n",
 	     MPU_INITIATOR_NAME);
 
-	omap_hwmod_for_each(_setup);
+	if (skip_setup_idle)
+		pr_debug("omap_hwmod: will leave hwmods enabled during setup\n");
+
+	omap_hwmod_for_each(_setup, &skip_setup_idle);
 
 	return 0;
 }
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 253f6e5..aebfacb 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -482,8 +482,9 @@ int omap_hwmod_init(struct omap_hwmod **ohs);
 int omap_hwmod_register(struct omap_hwmod *oh);
 int omap_hwmod_unregister(struct omap_hwmod *oh);
 struct omap_hwmod *omap_hwmod_lookup(const char *name);
-int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh));
-int omap_hwmod_late_init(void);
+int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh, void *data),
+			void *data);
+int omap_hwmod_late_init(u8 skip_setup_idle);
 
 int omap_hwmod_enable(struct omap_hwmod *oh);
 int _omap_hwmod_enable(struct omap_hwmod *oh);

[PATCH 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4

[Kevin Hilman]

From: Rajendra Nayak <rnayak@ti.com>

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/plat-omap/Makefile |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 98f0191..9405831 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
 # omap_device support (OMAP2+ only at the moment)
 obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
 obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
+obj-$(CONFIG_ARCH_OMAP4) += omap_device.o
 
 obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
 obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o
-- 
1.7.0.2

Re: [PATCH 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4

[Paul Walmsley]

Hi Rajendra

On Wed, 23 Jun 2010, Kevin Hilman wrote:

> From: Rajendra Nayak <rnayak@ti.com>
> 

Please add a brief patch changelog entry here.  Maybe just say this is 
necessary for integration code using omap_device to work on OMAP4?

> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
> ---
>  arch/arm/plat-omap/Makefile |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
> index 98f0191..9405831 100644
> --- a/arch/arm/plat-omap/Makefile
> +++ b/arch/arm/plat-omap/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
>  # omap_device support (OMAP2+ only at the moment)
>  obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
>  obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
> +obj-$(CONFIG_ARCH_OMAP4) += omap_device.o
>  
>  obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
>  obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o
> -- 
> 1.7.0.2
> 


- Paul

RE: [PATCH 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4

[Nayak, Rajendra]

> -----Original Message-----
> From: Paul Walmsley [mailto:paul@pwsan.com]
> Sent: Thursday, June 24, 2010 12:11 AM
> To: Nayak, Rajendra
> Cc: Kevin Hilman; linux-omap@vger.kernel.org; Cousson, Benoit
> Subject: Re: [PATCH 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4
> 
> Hi Rajendra
> 
> On Wed, 23 Jun 2010, Kevin Hilman wrote:
> 
> > From: Rajendra Nayak <rnayak@ti.com>
> >
> 
> Please add a brief patch changelog entry here.  Maybe just say this is
> necessary for integration code using omap_device to work on OMAP4?

Yes, will do, not sure how that got missed. 
thanks

> 
> > Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> > Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> > Cc: Paul Walmsley <paul@pwsan.com>
> > Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
> > ---
> >  arch/arm/plat-omap/Makefile |    1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
> > index 98f0191..9405831 100644
> > --- a/arch/arm/plat-omap/Makefile
> > +++ b/arch/arm/plat-omap/Makefile
> > @@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
> >  # omap_device support (OMAP2+ only at the moment)
> >  obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
> >  obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
> > +obj-$(CONFIG_ARCH_OMAP4) += omap_device.o
> >
> >  obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
> >  obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o
> > --
> > 1.7.0.2
> >
> 
> 
> - Paul

Re: [PATCH 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

>> -----Original Message-----
>> From: Paul Walmsley [mailto:paul@pwsan.com]
>> Sent: Thursday, June 24, 2010 12:11 AM
>> To: Nayak, Rajendra
>> Cc: Kevin Hilman; linux-omap@vger.kernel.org; Cousson, Benoit
>> Subject: Re: [PATCH 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4
>> 
>> Hi Rajendra
>> 
>> On Wed, 23 Jun 2010, Kevin Hilman wrote:
>> 
>> > From: Rajendra Nayak <rnayak@ti.com>
>> >
>> 
>> Please add a brief patch changelog entry here.  Maybe just say this is
>> necessary for integration code using omap_device to work on OMAP4?
>
> Yes, will do, not sure how that got missed. 

Rajendra,

If you just reply here with the changelog entry, I will update it in
this series.

This patch is needed in this series as the patch 
"OMAP: create omap_devices for MPU, DSP, L3"  depends on it.

Thanks,

Kevin

RE: [PATCH 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4

[Nayak, Rajendra]

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Thursday, June 24, 2010 12:52 PM
> To: Nayak, Rajendra
> Cc: Paul Walmsley; linux-omap@vger.kernel.org; Cousson, Benoit
> Subject: Re: [PATCH 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4
> 
> "Nayak, Rajendra" <rnayak@ti.com> writes:
> 
> >> -----Original Message-----
> >> From: Paul Walmsley [mailto:paul@pwsan.com]
> >> Sent: Thursday, June 24, 2010 12:11 AM
> >> To: Nayak, Rajendra
> >> Cc: Kevin Hilman; linux-omap@vger.kernel.org; Cousson, Benoit
> >> Subject: Re: [PATCH 08/13] OMAP4: hwmod: Enable omap_device build for
> OMAP4
> >>
> >> Hi Rajendra
> >>
> >> On Wed, 23 Jun 2010, Kevin Hilman wrote:
> >>
> >> > From: Rajendra Nayak <rnayak@ti.com>
> >> >
> >>
> >> Please add a brief patch changelog entry here.  Maybe just say this is
> >> necessary for integration code using omap_device to work on OMAP4?
> >
> > Yes, will do, not sure how that got missed.
> 
> Rajendra,
> 
> If you just reply here with the changelog entry, I will update it in
> this series.

Ok, this one should do.

Enable omap_device layer support for OMAP4, so that drivers can
use them to enable/idle/shutdown devices.

> 
> This patch is needed in this series as the patch
> "OMAP: create omap_devices for MPU, DSP, L3"  depends on it.
> 
> Thanks,
> 
> Kevin

Re: [PATCH 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> Sent: Thursday, June 24, 2010 12:52 PM
>> To: Nayak, Rajendra
>> Cc: Paul Walmsley; linux-omap@vger.kernel.org; Cousson, Benoit
>> Subject: Re: [PATCH 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4
>> 
>> "Nayak, Rajendra" <rnayak@ti.com> writes:
>> 
>> >> -----Original Message-----
>> >> From: Paul Walmsley [mailto:paul@pwsan.com]
>> >> Sent: Thursday, June 24, 2010 12:11 AM
>> >> To: Nayak, Rajendra
>> >> Cc: Kevin Hilman; linux-omap@vger.kernel.org; Cousson, Benoit
>> >> Subject: Re: [PATCH 08/13] OMAP4: hwmod: Enable omap_device build for
>> OMAP4
>> >>
>> >> Hi Rajendra
>> >>
>> >> On Wed, 23 Jun 2010, Kevin Hilman wrote:
>> >>
>> >> > From: Rajendra Nayak <rnayak@ti.com>
>> >> >
>> >>
>> >> Please add a brief patch changelog entry here.  Maybe just say this is
>> >> necessary for integration code using omap_device to work on OMAP4?
>> >
>> > Yes, will do, not sure how that got missed.
>> 
>> Rajendra,
>> 
>> If you just reply here with the changelog entry, I will update it in
>> this series.
>
> Ok, this one should do.
>
> Enable omap_device layer support for OMAP4, so that drivers can
> use them to enable/idle/shutdown devices.
>

Thanks, will add for next spin of this series.

Thanks,

Kevin

Re: [PATCH 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1996 bytes --]

Hi,

On Wed, 23 Jun 2010, Kevin Hilman wrote:

> From: Rajendra Nayak <rnayak@ti.com>
> 
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

This patch has been updated to include Benoît's compile fix; revised patch 
below.


- Paul

OMAP4: hwmod: Enable omap_device build for OMAP4

From: Rajendra Nayak <rnayak@ti.com>

Enable omap_device layer support for OMAP4, so that drivers can
use them to enable/idle/shutdown devices.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/Makefile |    2 +-
 arch/arm/plat-omap/Makefile  |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 6c6d7c6..2fa3418 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -15,7 +15,7 @@ clock-common				= clock.o clock_common_data.o \
 
 obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(hwmod-common)
 obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(hwmod-common)
-obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common)
+obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common) $(hwmod-common)
 
 obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
 
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 98f0191..9405831 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
 # omap_device support (OMAP2+ only at the moment)
 obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
 obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
+obj-$(CONFIG_ARCH_OMAP4) += omap_device.o
 
 obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
 obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o

[PATCH 09/13] OMAP: omap_device: ensure hwmod tracks attached omap_device pointer

[Kevin Hilman]

The omap_hwmod struct has a field to track the omap_device that is
attached to it, but it was not being assigned.  Fix by assigning omap_device
pointer when omap_device is built.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/plat-omap/omap_device.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index f899603..6614cba 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -359,8 +359,8 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 	struct omap_device *od;
 	char *pdev_name2;
 	struct resource *res = NULL;
-	int res_count;
-	struct omap_hwmod **hwmods;
+	int i, res_count;
+	struct omap_hwmod *oh, **hwmods;
 
 	if (!ohs || oh_cnt == 0 || !pdev_name)
 		return ERR_PTR(-EINVAL);
@@ -416,6 +416,10 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 	else
 		ret = omap_device_register(od);
 
+	/* each hwmod has a pointer to its attached omap_device */
+	for (i = 0, oh = hwmods[0]; i < oh_cnt; i++, oh++)
+		oh->od = od;
+
 	if (ret)
 		goto odbs_exit4;
 
-- 
1.7.0.2

Re: [PATCH 09/13] OMAP: omap_device: ensure hwmod tracks attached omap_device pointer

[Paul Walmsley]

Hi,

On Wed, 23 Jun 2010, Kevin Hilman wrote:

> The omap_hwmod struct has a field to track the omap_device that is
> attached to it, but it was not being assigned.  Fix by assigning omap_device
> pointer when omap_device is built.
> 
> Cc: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

This patch has been modified to use array indexing rather than pointer 
arithmetic; I think it is easier to read and debug; revised patch below.


- Paul

OMAP: omap_device: ensure hwmod tracks attached omap_device pointer

From: Kevin Hilman <khilman@deeprootsystems.com>

The omap_hwmod struct has a field to track the omap_device that is
attached to it, but it was not being assigned.  Fix by assigning omap_device
pointer when omap_device is built.

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
[paul@pwsan.com: use an array index rather than pointer arithmetic]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/plat-omap/omap_device.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index f899603..f9dec0d 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -359,7 +359,7 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 	struct omap_device *od;
 	char *pdev_name2;
 	struct resource *res = NULL;
-	int res_count;
+	int i, res_count;
 	struct omap_hwmod **hwmods;
 
 	if (!ohs || oh_cnt == 0 || !pdev_name)
@@ -416,6 +416,9 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 	else
 		ret = omap_device_register(od);
 
+	for (i = 0; i < oh_cnt; i++)
+		hwmods[i]->od = od;
+
 	if (ret)
 		goto odbs_exit4;
 

[PATCH 10/13] OMAP: omap_device: add flag to disable automatic bus-level suspend/resume

[Kevin Hilman]

As part of the runtime PM support, bus-level code can automatically
handle the enable/idle for each omap_device.  There are, however, some
special cases where we don't want the bus-level layer to handle this,
and instead handle it manually.

Specific use cases are for omap_devices that are controlled
inside the idle path (like UART.)

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/plat-omap/include/plat/omap_device.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
index 3694b62..2cdbcdd 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -68,12 +68,16 @@ struct omap_device {
 	struct omap_device_pm_latency	*pm_lats;
 	u32				dev_wakeup_lat;
 	u32				_dev_wakeup_lat_limit;
+	u32                             flags;
 	u8				pm_lats_cnt;
 	s8				pm_lat_level;
 	u8				hwmods_cnt;
 	u8				_state;
 };
 
+/* flags for struct omap_device */
+#define OMAP_DEVICE_NO_BUS_SUSPEND     BIT(0)
+
 /* Device driver interface (call via platform_data fn ptrs) */
 
 int omap_device_enable(struct platform_device *pdev);
@@ -142,6 +146,7 @@ struct omap_device_pm_latency {
 	u32 flags;
 };
 
+/* flags for struct omap_device_pm_latency */
 #define OMAP_DEVICE_LATENCY_AUTO_ADJUST BIT(1)
 
 /* Get omap_device pointer from platform_device pointer */
-- 
1.7.0.2

Re: [PATCH 10/13] OMAP: omap_device: add flag to disable automatic bus-level suspend/resume

[Paul Walmsley]

Hi Kevin,

A few comments:

Your "add runtime PM support at bus-level" series has a unstated 
dependency on this patch.  If you fix one minor issue (below), it's 
probably easiest if you merge it with that other series to avoid 
cross-dependencies.

On Wed, 23 Jun 2010, Kevin Hilman wrote:

> As part of the runtime PM support, bus-level code can automatically
> handle the enable/idle for each omap_device.  There are, however, some
> special cases where we don't want the bus-level layer to handle this,
> and instead handle it manually.
> 
> Specific use cases are for omap_devices that are controlled
> inside the idle path (like UART.)
> 
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
> ---
>  arch/arm/plat-omap/include/plat/omap_device.h |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
> index 3694b62..2cdbcdd 100644
> --- a/arch/arm/plat-omap/include/plat/omap_device.h
> +++ b/arch/arm/plat-omap/include/plat/omap_device.h
> @@ -68,12 +68,16 @@ struct omap_device {
>  	struct omap_device_pm_latency	*pm_lats;
>  	u32				dev_wakeup_lat;
>  	u32				_dev_wakeup_lat_limit;
> +	u32                             flags;

This should be a u8.  Fix that and it is 

Acked-by: Paul Walmsley <paul@pwsan.com>

>  	u8				pm_lats_cnt;
>  	s8				pm_lat_level;
>  	u8				hwmods_cnt;
>  	u8				_state;
>  };
>  
> +/* flags for struct omap_device */
> +#define OMAP_DEVICE_NO_BUS_SUSPEND     BIT(0)
> +
>  /* Device driver interface (call via platform_data fn ptrs) */
>  
>  int omap_device_enable(struct platform_device *pdev);
> @@ -142,6 +146,7 @@ struct omap_device_pm_latency {
>  	u32 flags;
>  };
>  
> +/* flags for struct omap_device_pm_latency */
>  #define OMAP_DEVICE_LATENCY_AUTO_ADJUST BIT(1)
>  
>  /* Get omap_device pointer from platform_device pointer */
> -- 
> 1.7.0.2
> 
> --
> 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
> 


- Paul

Re: [PATCH 10/13] OMAP: omap_device: add flag to disable automatic bus-level suspend/resume

[Kevin Hilman]

Paul Walmsley <paul@pwsan.com> writes:

> Hi Kevin,
>
> A few comments:
>
> Your "add runtime PM support at bus-level" series has a unstated 
> dependency on this patch.  If you fix one minor issue (below), it's 
> probably easiest if you merge it with that other series to avoid 
> cross-dependencies.

If I switch (back) to just using pm_runtime_* API in the system PM
path _noirq methods, then rather than setting this flag at the
omap_device level, drivers that want to prevent this can simply
do a runtime_pm_get_sync() if they want to prevent a bus-level
suspend.

Any thoughts/objectsion to that?

Kevin


> On Wed, 23 Jun 2010, Kevin Hilman wrote:
>
>> As part of the runtime PM support, bus-level code can automatically
>> handle the enable/idle for each omap_device.  There are, however, some
>> special cases where we don't want the bus-level layer to handle this,
>> and instead handle it manually.
>> 
>> Specific use cases are for omap_devices that are controlled
>> inside the idle path (like UART.)
>> 
>> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
>> ---
>>  arch/arm/plat-omap/include/plat/omap_device.h |    5 +++++
>>  1 files changed, 5 insertions(+), 0 deletions(-)
>> 
>> diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
>> index 3694b62..2cdbcdd 100644
>> --- a/arch/arm/plat-omap/include/plat/omap_device.h
>> +++ b/arch/arm/plat-omap/include/plat/omap_device.h
>> @@ -68,12 +68,16 @@ struct omap_device {
>>  	struct omap_device_pm_latency	*pm_lats;
>>  	u32				dev_wakeup_lat;
>>  	u32				_dev_wakeup_lat_limit;
>> +	u32                             flags;
>
> This should be a u8.  Fix that and it is 
>
> Acked-by: Paul Walmsley <paul@pwsan.com>
>
>>  	u8				pm_lats_cnt;
>>  	s8				pm_lat_level;
>>  	u8				hwmods_cnt;
>>  	u8				_state;
>>  };
>>  
>> +/* flags for struct omap_device */
>> +#define OMAP_DEVICE_NO_BUS_SUSPEND     BIT(0)
>> +
>>  /* Device driver interface (call via platform_data fn ptrs) */
>>  
>>  int omap_device_enable(struct platform_device *pdev);
>> @@ -142,6 +146,7 @@ struct omap_device_pm_latency {
>>  	u32 flags;
>>  };
>>  
>> +/* flags for struct omap_device_pm_latency */
>>  #define OMAP_DEVICE_LATENCY_AUTO_ADJUST BIT(1)
>>  
>>  /* Get omap_device pointer from platform_device pointer */
>> -- 
>> 1.7.0.2
>> 
>> --
>> 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
>> 
>
>
> - Paul

Re: [PATCH 10/13] OMAP: omap_device: add flag to disable automatic bus-level suspend/resume

[Paul Walmsley]

On Thu, 24 Jun 2010, Kevin Hilman wrote:

> Paul Walmsley <paul@pwsan.com> writes:
> 
> > Hi Kevin,
> >
> > A few comments:
> >
> > Your "add runtime PM support at bus-level" series has a unstated 
> > dependency on this patch.  If you fix one minor issue (below), it's 
> > probably easiest if you merge it with that other series to avoid 
> > cross-dependencies.
> 
> If I switch (back) to just using pm_runtime_* API in the system PM
> path _noirq methods, then rather than setting this flag at the
> omap_device level, drivers that want to prevent this can simply
> do a runtime_pm_get_sync() if they want to prevent a bus-level
> suspend.
> 
> Any thoughts/objectsion to that?

Sounds fine to me.


- Paul

Re: [PATCH 10/13] OMAP: omap_device: add flag to disable automatic bus-level suspend/resume

[Kevin Hilman]

Paul Walmsley <paul@pwsan.com> writes:

> On Thu, 24 Jun 2010, Kevin Hilman wrote:
>
>> Paul Walmsley <paul@pwsan.com> writes:
>> 
>> > Hi Kevin,
>> >
>> > A few comments:
>> >
>> > Your "add runtime PM support at bus-level" series has a unstated 
>> > dependency on this patch.  If you fix one minor issue (below), it's 
>> > probably easiest if you merge it with that other series to avoid 
>> > cross-dependencies.
>> 
>> If I switch (back) to just using pm_runtime_* API in the system PM
>> path _noirq methods, then rather than setting this flag at the
>> omap_device level, drivers that want to prevent this can simply
>> do a runtime_pm_get_sync() if they want to prevent a bus-level
>> suspend.
>> 
>> Any thoughts/objectsion to that?
>
> Sounds fine to me.

OK, good.  Then I'll just drop this patch.

Thanks,

Kevin

[PATCH 11/13] OMAP: create omap_devices for MPU, DSP, L3

[Kevin Hilman]

Create simple omap_devices for the main processors and busses.

This is required to support the forth-coming device-based OPP
approach, where OPPs are managed and tracked at the device level.

So that these primary devices are available for early PM initialization,
they are created as early platform_devices.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/devices.c            |    2 +
 arch/arm/mach-omap2/io.c                 |   55 +++++++++++++++++++++++++++++-
 arch/arm/plat-omap/include/plat/common.h |    4 ++
 3 files changed, 60 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 03e6c9e..62920ac 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -15,6 +15,7 @@
 #include <linux/platform_device.h>
 #include <linux/io.h>
 #include <linux/clk.h>
+#include <linux/err.h>
 
 #include <mach/hardware.h>
 #include <mach/irqs.h>
@@ -29,6 +30,7 @@
 #include <mach/gpio.h>
 #include <plat/mmc.h>
 #include <plat/dma.h>
+#include <plat/omap_device.h>
 
 #include "mux.h"
 
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3cfb425..ecebbbf 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -45,7 +45,7 @@
 
 #include <plat/clockdomain.h>
 #include "clockdomains.h"
-#include <plat/omap_hwmod.h>
+#include <plat/omap_device.h>
 
 /*
  * The machine specific code may provide the extra mapping besides the
@@ -313,6 +313,58 @@ static int __init _omap2_init_reprogram_sdrc(void)
 	return v;
 }
 
+static struct omap_device_pm_latency *pm_lats;
+
+static DEFINE_PER_CPU(struct device *, mpu_dev);
+static struct device *dsp_dev;
+static struct device *l3_dev;
+
+struct device *omap_get_mpu_device(void)
+{
+	mpu_dev = per_cpu(mpu_dev, smp_processor_id());
+	WARN_ON_ONCE(!mpu_dev);
+	return mpu_dev;
+}
+
+struct device *omap_get_dsp_device(void)
+{
+	WARN_ON_ONCE(!dsp_dev);
+	return dsp_dev;
+}
+
+struct device *omap_get_l3_device(void)
+{
+	WARN_ON_ONCE(!l3_dev);
+	return l3_dev;
+}
+
+static int _init_omap_device(struct omap_hwmod *oh, void *user)
+{
+	struct omap_device *od;
+	const char *name = oh->name;
+	struct device **new_dev = (struct device **)user;
+
+	od = omap_device_build(name, 0, oh, NULL, 0, pm_lats, 0, true);
+	if (WARN(IS_ERR(od), "Could not build omap_device for %s\n", name))
+		return -ENODEV;
+
+	*new_dev = &od->pdev.dev;
+
+	return 0;
+}
+
+/*
+ * Build omap_devices for processors and bus.
+ */
+static void omap_init_processor_devices(void)
+{
+	mpu_dev = per_cpu(mpu_dev, smp_processor_id());
+
+	omap_hwmod_for_each_by_class("mpu", _init_omap_device, &mpu_dev);
+	omap_hwmod_for_each_by_class("dsp", _init_omap_device, &dsp_dev);
+	omap_hwmod_for_each_by_class("l3", _init_omap_device, &l3_dev);
+}
+
 void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
 				 struct omap_sdrc_params *sdrc_cs1)
 {
@@ -342,6 +394,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
 	omap_serial_early_init();
 	if (cpu_is_omap24xx() || cpu_is_omap34xx())   /* FIXME: OMAP4 */
 		omap_hwmod_late_init();
+	omap_init_processor_devices();
 	omap_pm_if_init();
 	if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
 		omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-omap/include/plat/common.h
index d265018..0059dec 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -87,4 +87,8 @@ void omap2_set_globals_uart(struct omap_globals *);
 	}							\
 })
 
+struct device *omap_get_mpu_device(void);
+struct device *omap_get_dsp_device(void);
+struct device *omap_get_l3_device(void);
+
 #endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
-- 
1.7.0.2

Re: [PATCH 11/13] OMAP: create omap_devices for MPU, DSP, L3

[Paul Walmsley]

Hi Kevin,

some comments below -

On Wed, 23 Jun 2010, Kevin Hilman wrote:

> Create simple omap_devices for the main processors and busses.
> 
> This is required to support the forth-coming device-based OPP
> approach, where OPPs are managed and tracked at the device level.
> 
> So that these primary devices are available for early PM initialization,
> they are created as early platform_devices.

The idea sounds good, but -

> 
> Cc: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
> ---
>  arch/arm/mach-omap2/devices.c            |    2 +
>  arch/arm/mach-omap2/io.c                 |   55 +++++++++++++++++++++++++++++-
>  arch/arm/plat-omap/include/plat/common.h |    4 ++
>  3 files changed, 60 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 03e6c9e..62920ac 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -15,6 +15,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/io.h>
>  #include <linux/clk.h>
> +#include <linux/err.h>
>  
>  #include <mach/hardware.h>
>  #include <mach/irqs.h>
> @@ -29,6 +30,7 @@
>  #include <mach/gpio.h>
>  #include <plat/mmc.h>
>  #include <plat/dma.h>
> +#include <plat/omap_device.h>
>  
>  #include "mux.h"
>  
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index 3cfb425..ecebbbf 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -45,7 +45,7 @@
>  
>  #include <plat/clockdomain.h>
>  #include "clockdomains.h"
> -#include <plat/omap_hwmod.h>
> +#include <plat/omap_device.h>
>  
>  /*
>   * The machine specific code may provide the extra mapping besides the
> @@ -313,6 +313,58 @@ static int __init _omap2_init_reprogram_sdrc(void)
>  	return v;
>  }
>  
> +static struct omap_device_pm_latency *pm_lats;
> +
> +static DEFINE_PER_CPU(struct device *, mpu_dev);
> +static struct devicee *dsp_dev;
> +static struct device *l3_dev;
> +
> +struct device *omap_get_mpu_device(void)
> +{
> +	mpu_dev = per_cpu(mpu_dev, smp_processor_id());

Looks like this will trash the per-CPU mpu_dev on SMP.  You'll need to 
rename one of these two mpu_devs.

Also, won't the use of smp_processor_id() mean that this will just return 
the struct device * for the MPU that is running this code?  So on a 
two-CPU system, it would be either CPU 0 or 1, randomly.  I guess one 
solution would be to pass in the processor ID to omap_get_mpu_device().

> +	WARN_ON_ONCE(!mpu_dev);
> +	return mpu_dev;
> +}
> +
> +struct device *omap_get_dsp_device(void)
> +{
> +	WARN_ON_ONCE(!dsp_dev);
> +	return dsp_dev;
> +}
> +
> +struct device *omap_get_l3_device(void)
> +{
> +	WARN_ON_ONCE(!l3_dev);
> +	return l3_dev;
> +}
> +
> +static int _init_omap_device(struct omap_hwmod *oh, void *user)
> +{
> +	struct omap_device *od;
> +	const char *name = oh->name;
> +	struct device **new_dev = (struct device **)user;
> +
> +	od = omap_device_build(name, 0, oh, NULL, 0, pm_lats, 0, true);
> +	if (WARN(IS_ERR(od), "Could not build omap_device for %s\n", name))
> +		return -ENODEV;
> +
> +	*new_dev = &od->pdev.dev;
> +
> +	return 0;
> +}
> +
> +/*
> + * Build omap_devices for processors and bus.
> + */
> +static void omap_init_processor_devices(void)
> +{
> +	mpu_dev = per_cpu(mpu_dev, smp_processor_id());

(same issues as above)

> +
> +	omap_hwmod_for_each_by_class("mpu", _init_omap_device, &mpu_dev);

This won't work on SMP - it will use the same mpu_dev variable for each 
MPU, so mpu_dev will contain the struct device * for the last MPU hwmod 
iterated over. 

Also, there is a hidden assumption that the hwmods of class "mpu" will be 
iterated over in the order that the per_cpu() variable expects...

> +	omap_hwmod_for_each_by_class("dsp", _init_omap_device, &dsp_dev);
> +	omap_hwmod_for_each_by_class("l3", _init_omap_device, &l3_dev);

If there is more than one hwmod in these classes, these will lose the 
omap_device pointers for all but the final omap_hwmod iterated over.

It's probably easier to just call omap_hwmod_lookup()/_init_omap_device() 
directly and forget about omap_hwmod_for_each_by_class() for the above 
two cases - maybe all three...

> +}
> +
>  void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
>  				 struct omap_sdrc_params *sdrc_cs1)
>  {
> @@ -342,6 +394,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
>  	omap_serial_early_init();
>  	if (cpu_is_omap24xx() || cpu_is_omap34xx())   /* FIXME: OMAP4 */
>  		omap_hwmod_late_init();
> +	omap_init_processor_devices();
>  	omap_pm_if_init();
>  	if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
>  		omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
> diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-omap/include/plat/common.h
> index d265018..0059dec 100644
> --- a/arch/arm/plat-omap/include/plat/common.h
> +++ b/arch/arm/plat-omap/include/plat/common.h
> @@ -87,4 +87,8 @@ void omap2_set_globals_uart(struct omap_globals *);
>  	}							\
>  })
>  
> +struct device *omap_get_mpu_device(void);
> +struct device *omap_get_dsp_device(void);
> +struct device *omap_get_l3_device(void);
> +
>  #endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
> -- 
> 1.7.0.2
> 


- Paul

Re: [PATCH 11/13] OMAP: create omap_devices for MPU, DSP, L3

[Paul Walmsley]

Hi Kevin,

one other thought.

On Thu, 24 Jun 2010, Paul Walmsley wrote:

> On Wed, 23 Jun 2010, Kevin Hilman wrote:
> 
> > Create simple omap_devices for the main processors and busses.
> > 
> > This is required to support the forth-coming device-based OPP
> > approach, where OPPs are managed and tracked at the device level.

If these omap_devices are only to deal with OPPs, you might only need one 
omap_device for the MPU subsystem for OMAP4, since I think both cores 
receive the same clock.  That might simplify this patch for the current 
timeframe.


- Paul

Re: [PATCH 11/13] OMAP: create omap_devices for MPU, DSP, L3

[Kevin Hilman]

Paul Walmsley <paul@pwsan.com> writes:

> Hi Kevin,
>
> one other thought.
>
> On Thu, 24 Jun 2010, Paul Walmsley wrote:
>
>> On Wed, 23 Jun 2010, Kevin Hilman wrote:
>> 
>> > Create simple omap_devices for the main processors and busses.
>> > 
>> > This is required to support the forth-coming device-based OPP
>> > approach, where OPPs are managed and tracked at the device level.
>
> If these omap_devices are only to deal with OPPs, you might only need one 
> omap_device for the MPU subsystem for OMAP4, since I think both cores 
> receive the same clock.  That might simplify this patch for the current 
> timeframe.

Agreed.

Again, I fall victim to my own last-minute changes.  Up until yesterday
I wasn't trying to deal with SMP, and decided to add it yesterday,
clearly without a good (enough) understanding of the PER_CPU stuff for
SMP.

Will re-spin without the SMP and multiple-devices-in-class support.

Kevin

RE: [PATCH 11/13] OMAP: create omap_devices for MPU, DSP, L3

[Shilimkar, Santosh]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Paul
> Walmsley
> Sent: Thursday, June 24, 2010 11:57 AM
> To: Kevin Hilman
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH 11/13] OMAP: create omap_devices for MPU, DSP, L3
> 
> Hi Kevin,
> 
> some comments below -
> 
> On Wed, 23 Jun 2010, Kevin Hilman wrote:
> 
> > Create simple omap_devices for the main processors and busses.
> >
> > This is required to support the forth-coming device-based OPP
> > approach, where OPPs are managed and tracked at the device level.
> >
> > So that these primary devices are available for early PM initialization,
> > they are created as early platform_devices.
> 
> The idea sounds good, but -
> 
> >
> > Cc: Paul Walmsley <paul@pwsan.com>
> > Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
> > ---
> >  arch/arm/mach-omap2/devices.c            |    2 +
> >  arch/arm/mach-omap2/io.c                 |   55 +++++++++++++++++++++++++++++-
> >  arch/arm/plat-omap/include/plat/common.h |    4 ++
> >  3 files changed, 60 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > index 03e6c9e..62920ac 100644
> > --- a/arch/arm/mach-omap2/devices.c
> > +++ b/arch/arm/mach-omap2/devices.c
> > @@ -15,6 +15,7 @@
> >  #include <linux/platform_device.h>
> >  #include <linux/io.h>
> >  #include <linux/clk.h>
> > +#include <linux/err.h>
> >
> >  #include <mach/hardware.h>
> >  #include <mach/irqs.h>
> > @@ -29,6 +30,7 @@
> >  #include <mach/gpio.h>
> >  #include <plat/mmc.h>
> >  #include <plat/dma.h>
> > +#include <plat/omap_device.h>
> >
> >  #include "mux.h"
> >
> > diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> > index 3cfb425..ecebbbf 100644
> > --- a/arch/arm/mach-omap2/io.c
> > +++ b/arch/arm/mach-omap2/io.c
> > @@ -45,7 +45,7 @@
> >
> >  #include <plat/clockdomain.h>
> >  #include "clockdomains.h"
> > -#include <plat/omap_hwmod.h>
> > +#include <plat/omap_device.h>
> >
> >  /*
> >   * The machine specific code may provide the extra mapping besides the
> > @@ -313,6 +313,58 @@ static int __init _omap2_init_reprogram_sdrc(void)
> >  	return v;
> >  }
> >
> > +static struct omap_device_pm_latency *pm_lats;
> > +
> > +static DEFINE_PER_CPU(struct device *, mpu_dev);
> > +static struct devicee *dsp_dev;
> > +static struct device *l3_dev;
> > +
> > +struct device *omap_get_mpu_device(void)
> > +{
> > +	mpu_dev = per_cpu(mpu_dev, smp_processor_id());
> 
> Looks like this will trash the per-CPU mpu_dev on SMP.  You'll need to
> rename one of these two mpu_devs.
> 
> Also, won't the use of smp_processor_id() mean that this will just return
> the struct device * for the MPU that is running this code?  So on a
> two-CPU system, it would be either CPU 0 or 1, randomly.  I guess one
> solution would be to pass in the processor ID to omap_get_mpu_device().
>
MPUSS and both CPU's are clocked from same clock source, so above assumption
still work on OMAP4.
 
> > +	WARN_ON_ONCE(!mpu_dev);
> > +	return mpu_dev;
> > +}
> > +
> > +struct device *omap_get_dsp_device(void)
> > +{
> > +	WARN_ON_ONCE(!dsp_dev);
> > +	return dsp_dev;
> > +}
> > +
> > +struct device *omap_get_l3_device(void)
> > +{
> > +	WARN_ON_ONCE(!l3_dev);
> > +	return l3_dev;
> > +}
> > +
> > +static int _init_omap_device(struct omap_hwmod *oh, void *user)
> > +{
> > +	struct omap_device *od;
> > +	const char *name = oh->name;
> > +	struct device **new_dev = (struct device **)user;
> > +
> > +	od = omap_device_build(name, 0, oh, NULL, 0, pm_lats, 0, true);
> > +	if (WARN(IS_ERR(od), "Could not build omap_device for %s\n", name))
> > +		return -ENODEV;
> > +
> > +	*new_dev = &od->pdev.dev;
> > +
> > +	return 0;
> > +}
> > +
> > +/*
> > + * Build omap_devices for processors and bus.
> > + */
> > +static void omap_init_processor_devices(void)
> > +{
> > +	mpu_dev = per_cpu(mpu_dev, smp_processor_id());
> 
> (same issues as above)
> 
> > +
> > +	omap_hwmod_for_each_by_class("mpu", _init_omap_device, &mpu_dev);
> 
> This won't work on SMP - it will use the same mpu_dev variable for each
> MPU, so mpu_dev will contain the struct device * for the last MPU hwmod
> iterated over.
> 
> Also, there is a hidden assumption that the hwmods of class "mpu" will be
> iterated over in the order that the per_cpu() variable expects...
> 
> > +	omap_hwmod_for_each_by_class("dsp", _init_omap_device, &dsp_dev);
> > +	omap_hwmod_for_each_by_class("l3", _init_omap_device, &l3_dev);
> 
> If there is more than one hwmod in these classes, these will lose the
> omap_device pointers for all but the final omap_hwmod iterated over.
> 
> It's probably easier to just call omap_hwmod_lookup()/_init_omap_device()
> directly and forget about omap_hwmod_for_each_by_class() for the above
> two cases - maybe all three...
> 
> > +}
> > +
> >  void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
> >  				 struct omap_sdrc_params *sdrc_cs1)
> >  {
> > @@ -342,6 +394,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
> >  	omap_serial_early_init();
> >  	if (cpu_is_omap24xx() || cpu_is_omap34xx())   /* FIXME: OMAP4 */
> >  		omap_hwmod_late_init();
> > +	omap_init_processor_devices();
> >  	omap_pm_if_init();
> >  	if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
> >  		omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
> > diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-omap/include/plat/common.h
> > index d265018..0059dec 100644
> > --- a/arch/arm/plat-omap/include/plat/common.h
> > +++ b/arch/arm/plat-omap/include/plat/common.h
> > @@ -87,4 +87,8 @@ void omap2_set_globals_uart(struct omap_globals *);
> >  	}							\
> >  })
> >
> > +struct device *omap_get_mpu_device(void);
> > +struct device *omap_get_dsp_device(void);
> > +struct device *omap_get_l3_device(void);
> > +
> >  #endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
> > --
> > 1.7.0.2
> >
> 
> 
> - Paul
> --
> 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

RE: [PATCH 11/13] OMAP: create omap_devices for MPU, DSP, L3

[Paul Walmsley]

On Thu, 24 Jun 2010, Shilimkar, Santosh wrote:

> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Paul
> > Walmsley
> > Sent: Thursday, June 24, 2010 11:57 AM

> > > +struct device *omap_get_mpu_device(void)
> > > +{
> > > +	mpu_dev = per_cpu(mpu_dev, smp_processor_id());
> > 
> > Looks like this will trash the per-CPU mpu_dev on SMP.  You'll need to
> > rename one of these two mpu_devs.
> > 
> > Also, won't the use of smp_processor_id() mean that this will just return
> > the struct device * for the MPU that is running this code?  So on a
> > two-CPU system, it would be either CPU 0 or 1, randomly.  I guess one
> > solution would be to pass in the processor ID to omap_get_mpu_device().
> >
> MPUSS and both CPU's are clocked from same clock source, so above assumption
> still work on OMAP4.

If the point is to only return an omap_device corresponding to the MPU 
subsystem, then all the per_cpu() stuff is unnecessary and can be dropped, 
and the function should be so named (e.g., omap_get_mpuss_device()).


- Paul

RE: [PATCH 11/13] OMAP: create omap_devices for MPU, DSP, L3

[Shilimkar, Santosh]

> -----Original Message-----
> From: Paul Walmsley [mailto:paul@pwsan.com]
> Sent: Thursday, June 24, 2010 12:50 PM
> To: Shilimkar, Santosh
> Cc: Kevin Hilman; linux-omap@vger.kernel.org
> Subject: RE: [PATCH 11/13] OMAP: create omap_devices for MPU, DSP, L3
> 
> On Thu, 24 Jun 2010, Shilimkar, Santosh wrote:
> 
> > > -----Original Message-----
> > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of
> Paul
> > > Walmsley
> > > Sent: Thursday, June 24, 2010 11:57 AM
> 
> > > > +struct device *omap_get_mpu_device(void)
> > > > +{
> > > > +	mpu_dev = per_cpu(mpu_dev, smp_processor_id());
> > >
> > > Looks like this will trash the per-CPU mpu_dev on SMP.  You'll need to
> > > rename one of these two mpu_devs.
> > >
> > > Also, won't the use of smp_processor_id() mean that this will just return
> > > the struct device * for the MPU that is running this code?  So on a
> > > two-CPU system, it would be either CPU 0 or 1, randomly.  I guess one
> > > solution would be to pass in the processor ID to omap_get_mpu_device().
> > >
> > MPUSS and both CPU's are clocked from same clock source, so above assumption
> > still work on OMAP4.
> 
> If the point is to only return an omap_device corresponding to the MPU
> subsystem, then all the per_cpu() stuff is unnecessary and can be dropped,
> and the function should be so named (e.g., omap_get_mpuss_device()).
> 
Indeed !!
Even otherwise the patch is not really initializing per-cpu device because
init(omap_hwmod_for_each_by_class("mpu", _init_omap_device, &mpu_dev);)
is called only on one CPU.

Regards,
Santosh

[PATCH 12/13] OMAP: hwmod data: add class for DSP hwmods

[Kevin Hilman]

Add a new hwmod class for DSP devices.  To be used when hwmods
are created for DSP on OMAP3 (a.k.a. IVA2.)

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/omap_hwmod_common_data.c |    3 +++
 arch/arm/mach-omap2/omap_hwmod_common_data.h |    1 +
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.c b/arch/arm/mach-omap2/omap_hwmod_common_data.c
index 1e80b91..09f1e98 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.c
@@ -66,3 +66,6 @@ struct omap_hwmod_class mpu_hwmod_class = {
 	.name = "mpu"
 };
 
+struct omap_hwmod_class dsp_hwmod_class = {
+	.name = "dsp"
+};
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.h b/arch/arm/mach-omap2/omap_hwmod_common_data.h
index 3645a28..d03ebfa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.h
@@ -20,5 +20,6 @@
 extern struct omap_hwmod_class l3_hwmod_class;
 extern struct omap_hwmod_class l4_hwmod_class;
 extern struct omap_hwmod_class mpu_hwmod_class;
+extern struct omap_hwmod_class dsp_hwmod_class;
 
 #endif
-- 
1.7.0.2

Re: [PATCH 12/13] OMAP: hwmod data: add class for DSP hwmods

[Paul Walmsley]

Hi Kevin,

On Wed, 23 Jun 2010, Kevin Hilman wrote:

> Add a new hwmod class for DSP devices.  To be used when hwmods
> are created for DSP on OMAP3 (a.k.a. IVA2.)

I guess this patch is not needed any more?  But if it is, it might be best 
to name the class "iva2" or something like that, since the IVA2 subsystem 
contains more than just the DSP; it also contains the dedicated hardware 
video accelerator blocks, which are separate from the DSP.

- Paul

> 
> Cc: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_common_data.c |    3 +++
>  arch/arm/mach-omap2/omap_hwmod_common_data.h |    1 +
>  2 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.c b/arch/arm/mach-omap2/omap_hwmod_common_data.c
> index 1e80b91..09f1e98 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_common_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_common_data.c
> @@ -66,3 +66,6 @@ struct omap_hwmod_class mpu_hwmod_class = {
>  	.name = "mpu"
>  };
>  
> +struct omap_hwmod_class dsp_hwmod_class = {
> +	.name = "dsp"
> +};
> diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.h b/arch/arm/mach-omap2/omap_hwmod_common_data.h
> index 3645a28..d03ebfa 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_common_data.h
> +++ b/arch/arm/mach-omap2/omap_hwmod_common_data.h
> @@ -20,5 +20,6 @@
>  extern struct omap_hwmod_class l3_hwmod_class;
>  extern struct omap_hwmod_class l4_hwmod_class;
>  extern struct omap_hwmod_class mpu_hwmod_class;
> +extern struct omap_hwmod_class dsp_hwmod_class;
>  
>  #endif
> -- 
> 1.7.0.2
> 


- Paul

Re: [PATCH 12/13] OMAP: hwmod data: add class for DSP hwmods

[Kevin Hilman]

Paul Walmsley <paul@pwsan.com> writes:

> Hi Kevin,
>
> On Wed, 23 Jun 2010, Kevin Hilman wrote:
>
>> Add a new hwmod class for DSP devices.  To be used when hwmods
>> are created for DSP on OMAP3 (a.k.a. IVA2.)
>
> I guess this patch is not needed any more?  But if it is, it might be best 
> to name the class "iva2" or something like that, since the IVA2 subsystem 
> contains more than just the DSP; it also contains the dedicated hardware 
> video accelerator blocks, which are separate from the DSP.

Right, I'll be dropping this patch too as I'm just switching to use
omap_hwmod_lookup() instead of the class iterators.

Kevin

Re: [PATCH 12/13] OMAP: hwmod data: add class for DSP hwmods

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> Paul Walmsley <paul@pwsan.com> writes:
>
>> Hi Kevin,
>>
>> On Wed, 23 Jun 2010, Kevin Hilman wrote:
>>
>>> Add a new hwmod class for DSP devices.  To be used when hwmods
>>> are created for DSP on OMAP3 (a.k.a. IVA2.)
>>
>> I guess this patch is not needed any more?  But if it is, it might be best 
>> to name the class "iva2" or something like that, since the IVA2 subsystem 
>> contains more than just the DSP; it also contains the dedicated hardware 
>> video accelerator blocks, which are separate from the DSP.
>
> Right, I'll be dropping this patch too as I'm just switching to use
> omap_hwmod_lookup() instead of the class iterators.

Turns out I need a class even when doing the omap_hwmod_lookup()
as omap_hwmod_register() fails if there is no class or class name.

I'll keep this pach but s/dsp/iva2/

Kevin

Re: [PATCH 12/13] OMAP: hwmod data: add class for DSP hwmods

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> Kevin Hilman <khilman@deeprootsystems.com> writes:
>
>> Paul Walmsley <paul@pwsan.com> writes:
>>
>>> Hi Kevin,
>>>
>>> On Wed, 23 Jun 2010, Kevin Hilman wrote:
>>>
>>>> Add a new hwmod class for DSP devices.  To be used when hwmods
>>>> are created for DSP on OMAP3 (a.k.a. IVA2.)
>>>
>>> I guess this patch is not needed any more?  But if it is, it might be best 
>>> to name the class "iva2" or something like that, since the IVA2 subsystem 
>>> contains more than just the DSP; it also contains the dedicated hardware 
>>> video accelerator blocks, which are separate from the DSP.
>>
>> Right, I'll be dropping this patch too as I'm just switching to use
>> omap_hwmod_lookup() instead of the class iterators.
>
> Turns out I need a class even when doing the omap_hwmod_lookup()
> as omap_hwmod_register() fails if there is no class or class name.
>
> I'll keep this pach but s/dsp/iva2/
>

On second thought, I'll use "iva" to match how the naming was done for
OMAP4.

Kevin

[PATCH 13/13] OMAP3: hwmod data: add data for OMAP3 IVA2

[Kevin Hilman]

Add hwmod data for DSP on OMAP3 (a.k.a. IVA2.)

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   31 ++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ec6a5f8..fe41089 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -32,6 +32,7 @@
  */
 
 static struct omap_hwmod omap3xxx_mpu_hwmod;
+static struct omap_hwmod omap3xxx_iva2_hwmod;
 static struct omap_hwmod omap3xxx_l3_hwmod;
 static struct omap_hwmod omap3xxx_l4_core_hwmod;
 static struct omap_hwmod omap3xxx_l4_per_hwmod;
@@ -168,12 +169,42 @@ static struct omap_hwmod omap3xxx_mpu_hwmod = {
 	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
 };
 
+/*
+ * IVA2_2 interface data
+ */
+
+/* IVA2 <- L3 interface */
+static struct omap_hwmod_ocp_if omap3xxx_l3__iva2 = {
+	.master		= &omap3xxx_l3_hwmod,
+	.slave		= &omap3xxx_iva2_hwmod,
+	.clk		= "iva2_ck",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap3xxx_iva2_masters[] = {
+	&omap3xxx_l3__iva2,
+};
+
+/*
+ * IVA2 (IVA2)
+ */
+
+static struct omap_hwmod omap3xxx_iva2_hwmod = {
+	.name		= "dsp",
+	.class		= &dsp_hwmod_class,
+	.main_clk	= "iva2_ck",
+	.masters	= omap3xxx_iva2_masters,
+	.masters_cnt	= ARRAY_SIZE(omap3xxx_iva2_masters),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+};
+
 static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
 	&omap3xxx_l3_hwmod,
 	&omap3xxx_l4_core_hwmod,
 	&omap3xxx_l4_per_hwmod,
 	&omap3xxx_l4_wkup_hwmod,
 	&omap3xxx_mpu_hwmod,
+	&omap3xxx_iva2_hwmod,
 	NULL,
 };
 
-- 
1.7.0.2

Re: [PATCH 13/13] OMAP3: hwmod data: add data for OMAP3 IVA2

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> Add hwmod data for DSP on OMAP3 (a.k.a. IVA2.)
>
> Cc: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Also changing the name here from "dsp" to "iva2".

Kevin

> ---
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   31 ++++++++++++++++++++++++++++
>  1 files changed, 31 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index ec6a5f8..fe41089 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -32,6 +32,7 @@
>   */
>  
>  static struct omap_hwmod omap3xxx_mpu_hwmod;
> +static struct omap_hwmod omap3xxx_iva2_hwmod;
>  static struct omap_hwmod omap3xxx_l3_hwmod;
>  static struct omap_hwmod omap3xxx_l4_core_hwmod;
>  static struct omap_hwmod omap3xxx_l4_per_hwmod;
> @@ -168,12 +169,42 @@ static struct omap_hwmod omap3xxx_mpu_hwmod = {
>  	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
>  };
>  
> +/*
> + * IVA2_2 interface data
> + */
> +
> +/* IVA2 <- L3 interface */
> +static struct omap_hwmod_ocp_if omap3xxx_l3__iva2 = {
> +	.master		= &omap3xxx_l3_hwmod,
> +	.slave		= &omap3xxx_iva2_hwmod,
> +	.clk		= "iva2_ck",
> +	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod_ocp_if *omap3xxx_iva2_masters[] = {
> +	&omap3xxx_l3__iva2,
> +};
> +
> +/*
> + * IVA2 (IVA2)
> + */
> +
> +static struct omap_hwmod omap3xxx_iva2_hwmod = {
> +	.name		= "dsp",
> +	.class		= &dsp_hwmod_class,
> +	.main_clk	= "iva2_ck",
> +	.masters	= omap3xxx_iva2_masters,
> +	.masters_cnt	= ARRAY_SIZE(omap3xxx_iva2_masters),
> +	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
> +};
> +
>  static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
>  	&omap3xxx_l3_hwmod,
>  	&omap3xxx_l4_core_hwmod,
>  	&omap3xxx_l4_per_hwmod,
>  	&omap3xxx_l4_wkup_hwmod,
>  	&omap3xxx_mpu_hwmod,
> +	&omap3xxx_iva2_hwmod,
>  	NULL,
>  };

Re: [PATCH 13/13] OMAP3: hwmod data: add data for OMAP3 IVA2

[Cousson, Benoit]

On 6/24/2010 10:43 PM, Kevin Hilman wrote:
> Kevin Hilman<khilman@deeprootsystems.com>  writes:
>
>> Add hwmod data for DSP on OMAP3 (a.k.a. IVA2.)
>>
>> Cc: Paul Walmsley<paul@pwsan.com>
>> Signed-off-by: Kevin Hilman<khilman@deeprootsystems.com>
>
> Also changing the name here from "dsp" to "iva2".

You should just name it iva. The 2 is a version information.
That's why we renamed as well ivahd -> iva in OMAP4.

In theory the dsp should be captured as a submodule of the iva in that case.

Benoit

>
> Kevin
>
>> ---
>>   arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   31 ++++++++++++++++++++++++++++
>>   1 files changed, 31 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
>> index ec6a5f8..fe41089 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
>> @@ -32,6 +32,7 @@
>>    */
>>
>>   static struct omap_hwmod omap3xxx_mpu_hwmod;
>> +static struct omap_hwmod omap3xxx_iva2_hwmod;
>>   static struct omap_hwmod omap3xxx_l3_hwmod;
>>   static struct omap_hwmod omap3xxx_l4_core_hwmod;
>>   static struct omap_hwmod omap3xxx_l4_per_hwmod;
>> @@ -168,12 +169,42 @@ static struct omap_hwmod omap3xxx_mpu_hwmod = {
>>   	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
>>   };
>>
>> +/*
>> + * IVA2_2 interface data
>> + */
>> +
>> +/* IVA2<- L3 interface */
>> +static struct omap_hwmod_ocp_if omap3xxx_l3__iva2 = {
>> +	.master		=&omap3xxx_l3_hwmod,
>> +	.slave		=&omap3xxx_iva2_hwmod,
>> +	.clk		= "iva2_ck",
>> +	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>> +};
>> +
>> +static struct omap_hwmod_ocp_if *omap3xxx_iva2_masters[] = {
>> +	&omap3xxx_l3__iva2,
>> +};
>> +
>> +/*
>> + * IVA2 (IVA2)
>> + */
>> +
>> +static struct omap_hwmod omap3xxx_iva2_hwmod = {
>> +	.name		= "dsp",
>> +	.class		=&dsp_hwmod_class,
>> +	.main_clk	= "iva2_ck",
>> +	.masters	= omap3xxx_iva2_masters,
>> +	.masters_cnt	= ARRAY_SIZE(omap3xxx_iva2_masters),
>> +	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
>> +};
>> +
>>   static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
>>   	&omap3xxx_l3_hwmod,
>>   	&omap3xxx_l4_core_hwmod,
>>   	&omap3xxx_l4_per_hwmod,
>>   	&omap3xxx_l4_wkup_hwmod,
>>   	&omap3xxx_mpu_hwmod,
>> +	&omap3xxx_iva2_hwmod,
>>   	NULL,
>>   };
> --
> 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