Paul Walmsley <[email protected]> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
