Messages in this thread | | | Date | Sun, 2 Jan 2011 20:45:31 +0100 | Subject | Re: [RFC] sdhci: use ios->clock to know when sdhci is idle | From | Pierre Tardy <> |
| |
On Thu, Dec 30, 2010 at 11:37 AM, Gao, Yunpeng <yunpeng.gao@intel.com> wrote: >>> So, why we have to move to the 'aggressive clock gating framework'? >> >>The aggressive clock gating makes more sense since the different >>drivers will know better how to handle the gating. ios with f=0 can >>be interpreted differently. Else every driver has to register >>runtime PM hooks for this, which is less elegant. > > Thanks for the response. I just curious that is this the only reason to change the framework? To my understanding, seems it's not a very strong reason :-) > > Take the example of sd/mmc card - > by using the aggressive clock gating framework, it means the host controller will gate (clock gating or power gating) itself if not receiving requests for 8 clocks even if the request queue of mmc block driver is not empty at that time. So the host controller has to be gated / ungated repeatedly until the current request queue of mmc block driver becomes empty. I don't think this is elegant since most of the gating / ungating operations are not necessary.
I'm also concerned by thrashing. Please see my original patch. I am using pm_runtime_put_autosuspend() so that suspend timeout can be tweaked in user space.
Please also note that clock gating only platforms must also be concerned by thrashing, as clock_disable() call might endup with PLL power down that will have to be warmed up again later...
> > Instead, if we do it in the mmc block driver by just call the pm_runtime_put() once the current request queue is empty and call pm_runtime_get() once any new request comes, then the host controller can be gated/ungated appropriately. My original patch does not include any ignore_child() call. So that children can decide wether they want to prevent suspension of their parent.That will be the case of a wifi card who uses runtime_pm to manage its own power, and still wants its sdio bus to suspend automatically when not used (wifi idle)
Regards, Pierre
| |