On Mon, Jul 30, 2012 at 03:42:13PM -0700, Turquette, Mike wrote: > On Mon, Jul 30, 2012 at 3:31 PM, Paul Walmsley <paul@xxxxxxxxx> wrote: > > So if we make a change like this one, it seems like we would basically > > expect it to break once we start doing anything meaningful with > > clk_prepare(), like using clk_prepare() for voltage scaling or something > > that requires I2C? We'd also probably want to mark this with some kind of > > "HACK" comment. > > Hi Paul, > > Did you have anything in mind to start using clk_prepare? I still > hope to get rid of it some day and replace that call with a > combination of clk_enable and a check like clk_enable_can_sleep. Don't you dare. We arrived at the clk_prepare()/clk_enable() split after lots of discussion between different platform maintainers and their requirements. Shoving crap like "clk_enable_can_sleep()" down into drivers is totally and utterly idiotic. We've had the situation *already* where some drivers can be used on some platforms but not on others because of differences in clk_enable() expectations. Don't go back there. clk_prepare() and clk_enable() are separate calls for a very good reason. One is sleepable, the other can be called from any atomic contexts. -- 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
