On Thu, Nov 17, 2011 at 3:42 AM, DebBarma, Tarun Kanti <tarun.kanti@xxxxxx> 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: http://pastebin.com/bfcWtmQp Please apply this patch too, otherwise OOT modules disable lockdep: http://comments.gmane.org/gmane.linux.kernel/1216036 Also enable Schedule-while-atomic checks as this triggers errors even on process context, I have prepared a patch for those, will submit soon. 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. Regards, Omar -- 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
