On 12 October 2015 at 09:53, Ritesh Harjani <ritesh.l...@gmail.com> wrote: > Hi Ulf, > > Wanted to understand this better, related to clk-gating and runtime-PM > before we completely remove clk-gating functionality. > Inline queries - > > > On Thu, Oct 8, 2015 at 11:05 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> On 2 October 2015 at 10:56, Ulf Hansson <ulf.hans...@linaro.org> wrote: >>> MMC_CLKGATE was once invented to save power by gating the bus clock at >>> request inactivity. At that time it served its purpose. The modern way to >>> deal with power saving for these scenarios, is by using runtime PM. > > Inactivity duration of clk-gating and runtime PM can actually vary largely. > clk-gating can be used to turn the clks-off after a very short > duration of request inactivity say 200ms - (which can be used to save > the power of some voltage rail or something) > While runtime-PM would need ~10sec since it involves chain of devices > to be suspended.
What do you mean by "chain of devices"? You may refer to that runtime PM respect parent/child relations, but even so, each device can be runtime PM managed on its own. Regarding the inactivity duration, currently most mmc host drivers which have enabled the runtime PM autosuspend feature, uses 50 ms as the *default* timeout value. I haven't heard of anyone considering a ~10s or in that range, but if that's the case I guess power saving is just less important for these cases. > > For that to happen, we would need a longer duration of request > inactivity otherwise we would end up loosing power > if suspend keeps failing and often resumes are done to serve the request. Why would suspend fail? > > > So, do you suggest to use runtime-PM in a way that can be used to gate > the clks-off in shorter duration and > then schedule the work for suspending of devices after longer duration > of request inactivity. Well, what I suggested was to remove MMC_CLKGATE and use runtime PM instead. :-) It seem like you think you need an intermediate phase, where clock gating make sense in the first phase and the actual runtime_suspend of the device in second phase. I have yet understood why, but if I assume that's the case one could potentially use the ->runtime_idle() callback and friends, to deal with this. > > Sorry, if I am sounding foolish at any place, but I would like to > understand how are we handling the above problem if we remove > clk-gating? No, worries - thanks for you comments! Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
