On Thu, Nov 17, 2011 at 3:42 AM, DebBarma, Tarun Kanti
<tarun.ka...@ti.com> wrote:
>>>> 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.

? ...interrupt context should have interrupts disabled.

>If you send me the code snippet I can have a look.

Here it is a module that triggers this:


Please apply this patch too, otherwise OOT modules disable lockdep:


Also enable Schedule-while-atomic checks as this triggers errors even
on process context, I have prepared a patch for those, will submit

And BTW, these errors are seen since patch "ARM: OMAP: dmtimer:
switch-over to platform device driver", where code to do clk_get was
placed under spin_lock_irqsave, clk_get is the one holding a
mutex_lock which can't be done under a spin_lock.


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