[PATCH v16 09/12] OMAP: dmtimer: low-power mode support

[DebBarma, Tarun Kanti]

On Thu, Nov 17, 2011 at 6:23 AM, Omar Ramirez Luna <or.rmz1 at gmail.com> wrote:
> On Wed, Nov 16, 2011 at 12:18 AM, DebBarma, Tarun Kanti
> <tarun.kanti at ti.com> wrote:
> ...
>>> My use case is as follows:
>>>
>>> DSP sends a mailbox message to ARM, this triggers a tasklet in mailbox
>>> for processing the message, when it reaches tidspbridge it turns out
>>> that the DSP wants to enable a gpt timer; however, locks involved
>>> "clocks_mutex" and "dm_timer_lock" now could cause a deadlock as they
>>> have been called from unsafe contexts in the past
>>> (http://pastebin.com/7Dtz8t0f).
>>>
>>> Is the intention to restrict enabling the dmtimer clocks from hard|soft irqs?
>> The aim is to prevent client drivers perform clock enable/disable independently.
>> Instead just use the request/start/stop APIs. In that way we can make clock
>> enable/disable functions static in the future.
>
> Those are the APIs I'm using, omap_dm_timer_request_specific from a
> softirq triggers this warning, this was not hinted by the patch or
> cover letter of the series, hence the question:
>
> Was this change intentional? Does omap_dm_timer_request_specific
> should be allowed on other contexts (soft|hard irq)?
omap_dm_timer_request_specific() uses spin_lock_irqsave and
spin_unlock_irqrestore
to protect the timer list. There is nothing specific to prevent this
function from being
called from interrupt context. But you probably have to be careful to
avoid deadlock
in the interrupt context by disabling interrupts appropriately so that
we avoid trying
to re-acquire the lock. If you send me the code snippet I can have a look.
--
Tarun
>
> ...
>> You are right. This change some how got missed in mainline.
>> I have posted a patch for this already.
>
> Ok.
>
> Regards,
>
> Omar
>