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

[Omar Ramirez Luna]

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

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