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)? ... > 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
