Felipe Balbi had written, on 09/02/2010 05:28 AM, the following:
Hi,
On Thu, 2 Sep 2010 05:17:01 -0500, Nishanth Menon <[email protected]> wrote:
note - if we allow unlock of irqs at this point, we cannot predictably
progress down the logic.
spin_unlock() would not re-enable IRQs, would it ? Isn't it so that
spin_unlock_irq() would be the one re-enabling IRQ ?
oopss.. my bad.. if we were to do regulator based implementation of
voltage framework, looking closer at the code, driver/regulator/core.c
-> rdev->mutex is held for set_voltage, set_mode and all entry functions
for regulator operations -> this would be the only concern i have.. I
may be barking up the wrong tree here, but i think if i read
Documentation/mutex-design.txt right, "contexts such as tasklets and
timers" and "mutexes may not be used in hardware or software interrupt"
means to me dont do this in irq locked context such as the sitn in
omap_sram_idle?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
