>> -----Original Message----- >> From: Karicheri, Muralidharan >> Sent: Friday, September 14, 2012 3:15 PM >> To: Mike Turquette >> Cc: [email protected]; [email protected] - >> MPBU >> Linux Development Team (May contain non-TIers) >> Subject: RE: common clock API clk_prepare() and run time power management >> >> >> -----Original Message----- >> >> From: Mike Turquette [mailto:[email protected]] >> >> Sent: Friday, September 14, 2012 2:56 PM >> >> To: Karicheri, Muralidharan >> >> Cc: [email protected]; >> >> [email protected] - MPBU >> >> Linux Development Team (May contain non-TIers) >> >> Subject: Re: common clock API clk_prepare() and run time power management >> >> >> >> Quoting Karicheri, Muralidharan (2012-09-14 09:25:40) >> >> > Hi Mike, >> >> > >> >> > >> >> > >> >> > During my common clock migration work for DaVinci, I got a problem in >> >> > davinci >> >> > mdio driver that calls the clk_enable() through run time power >> >> > management API >> >> > and got following WARNING in drivers/clk/clk.c. Could you help me >> >> > understand >> >> > how clk_prepare() gets called in this scenario and what I need to take >> >> > are to >> >> > have this work for common clock framework? >> >> > >> >> >> >> <snip> >> >> > WARNING: at drivers/clk/clk.c:512 __clk_enable+0x98/0xa4() >> >> > >> >> >> >> Hi Murali, >> >> >> >> That warning is tripped because clk->prepare_count is 0 and you're >> >> calling clk_enable, which is bad. >> >> >> >> clk_prepare must be called (and complete) before calling clk_enable. >> >> For most platforms clk_prepare is a no-op, but for correctness sake your >> >> driver (or PM runtime callbacks) must call clk_prepare first. >> >> >> >> This is why the new clk_prepare_enable call has become popular. >> >> >> >> Note that clk_prepare may sleep, so don't call it from interrupt >> >> context. >> >> >> >> See the kerneldoc in include/linux/clk.h and also Documentation/clk.txt >> >> for more details and let me know if you need further explanation. >> >> >> >> Mike, >> >> In the case of PM, I believe the base/power/clock_ops.c is calling >> clk_enable() and >> clk_disable(). Does this mean I need to submit a patch to convert these to >> clk_prepare_enable() or driver should prepare the clock by doing >> clk_prepare() and pass >> the same to PM. Doing it clock_ops.c seems to me the correct way. What do >> you think? >> For i2c driver, I have clk_prepare_enable() already in the driver, but I >> still see same >> issue. I am debugging it currently.
After doing some research, here is what I understood from the code. Traditionally the clk API is called by individual driver and enabled. But with PM support added to base device driver, the clk_enable() or clk_prepare_enable() call in the driver becomes redundant. The clocks used by a driver gets managed by PM which takes care of enable/disable the same when driver is added or removed. So I believe we need to change clk_enable()/disable() in clock_ops.c to clk_prepare_enable()/disable(). I will send a patch for this. >> >> Thanks >> >> Murali >> >> >> Regards, >> >> Mike _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
