On Thu, Nov 17, 2011 at 6:23 AM, Omar Ramirez Luna <or.r...@gmail.com> wrote:
> On Wed, Nov 16, 2011 at 12:18 AM, DebBarma, Tarun Kanti
> <tarun.ka...@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
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.
> ...
>> You are right. This change some how got missed in mainline.
>> I have posted a patch for this already.
> Ok.
> Regards,
> Omar
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to