On Wed, Nov 16, 2011 at 12:18 AM, DebBarma, Tarun Kanti
>> 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
>> Is the intention to restrict enabling the dmtimer clocks from hard|soft irqs?
> 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)?
> You are right. This change some how got missed in mainline.
> I have posted a patch for this already.
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