On Thu, Nov 17, 2011 at 6:23 AM, Omar Ramirez Luna <or.rmz1@xxxxxxxxx> wrote: > On Wed, Nov 16, 2011 at 12:18 AM, DebBarma, Tarun Kanti > <tarun.kanti@xxxxxx> 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 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. If you send me the code snippet I can have a look. -- Tarun > > ... >> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
