Paul Walmsley <paul@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
