Hi, On Thu, 2 Sep 2010 05:40:56 -0500, Nishanth Menon <nm@xxxxxx> wrote: > 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 <nm@xxxxxx> 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? true, some re-work would have to be done if you want to use requlator framework. -- balbi -- 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
