summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-omap2
diff options
context:
space:
mode:
authorKevin Hilman <khilman@deeprootsystems.com>2010-07-26 16:34:29 -0600
committerPaul Walmsley <paul@pwsan.com>2010-07-26 16:34:29 -0600
commit848240223c35fcc71c424ad51a8e8aef42d3879c (patch)
tree6c11872b61e0aa4eed0db43e362cdbac8c7c9284 /arch/arm/mach-omap2
parentfa98347ebf1c516e49694e1584cd96a63428676a (diff)
downloadop-kernel-dev-848240223c35fcc71c424ad51a8e8aef42d3879c.zip
op-kernel-dev-848240223c35fcc71c424ad51a8e8aef42d3879c.tar.gz
OMAP: hwmod: add non-locking versions of enable and idle functions
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. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
Diffstat (limited to 'arch/arm/mach-omap2')
-rw-r--r--arch/arm/mach-omap2/omap_hwmod.c19
1 files changed, 10 insertions, 9 deletions
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index b7a4133..a23a60a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -886,7 +886,7 @@ static int _reset(struct omap_hwmod *oh)
}
/**
- * _enable - enable an omap_hwmod
+ * _omap_hwmod_enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
* Enables an omap_hwmod @oh such that the MPU can access the hwmod's
@@ -894,7 +894,7 @@ static int _reset(struct omap_hwmod *oh)
* Returns -EINVAL if the hwmod is in the wrong state or passes along
* the return value of _wait_target_ready().
*/
-static int _enable(struct omap_hwmod *oh)
+int _omap_hwmod_enable(struct omap_hwmod *oh)
{
int r;
@@ -939,7 +939,7 @@ static int _enable(struct omap_hwmod *oh)
* no further work. Returns -EINVAL if the hwmod is in the wrong
* state or returns 0.
*/
-static int _idle(struct omap_hwmod *oh)
+int _omap_hwmod_idle(struct omap_hwmod *oh)
{
if (oh->_state != _HWMOD_STATE_ENABLED) {
WARN(1, "omap_hwmod: %s: idle state can only be entered from "
@@ -1029,7 +1029,7 @@ static int _setup(struct omap_hwmod *oh)
oh->_state = _HWMOD_STATE_INITIALIZED;
- r = _enable(oh);
+ r = _omap_hwmod_enable(oh);
if (r) {
pr_warning("omap_hwmod: %s: cannot be enabled (%d)\n",
oh->name, oh->_state);
@@ -1041,7 +1041,7 @@ static int _setup(struct omap_hwmod *oh)
* XXX Do the OCP_SYSCONFIG bits need to be
* reprogrammed after a reset? If not, then this can
* be removed. If they do, then probably the
- * _enable() function should be split to avoid the
+ * _omap_hwmod_enable() function should be split to avoid the
* rewrite of the OCP_SYSCONFIG register.
*/
if (oh->class->sysc) {
@@ -1051,7 +1051,7 @@ static int _setup(struct omap_hwmod *oh)
}
if (!(oh->flags & HWMOD_INIT_NO_IDLE))
- _idle(oh);
+ _omap_hwmod_idle(oh);
return 0;
}
@@ -1292,12 +1292,13 @@ 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
* @oh: struct omap_hwmod *
@@ -1311,7 +1312,7 @@ int omap_hwmod_idle(struct omap_hwmod *oh)
return -EINVAL;
mutex_lock(&omap_hwmod_mutex);
- _idle(oh);
+ _omap_hwmod_idle(oh);
mutex_unlock(&omap_hwmod_mutex);
return 0;
@@ -1413,7 +1414,7 @@ int omap_hwmod_reset(struct omap_hwmod *oh)
mutex_lock(&omap_hwmod_mutex);
r = _reset(oh);
if (!r)
- r = _enable(oh);
+ r = _omap_hwmod_enable(oh);
mutex_unlock(&omap_hwmod_mutex);
return r;
OpenPOWER on IntegriCloud