On Thu, Nov 17, 2011 at 3:42 AM, DebBarma, Tarun Kanti
>>>> Is the intention to restrict enabling the dmtimer clocks from hard|soft
>>> The aim is to prevent client drivers perform clock enable/disable
>>> 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.
? ...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