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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux