[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CE761E84DADF2947A4AF22FB8D97A47331E875CD@shsmsx501.ccr.corp.intel.com>
Date: Thu, 30 Dec 2010 18:37:39 +0800
From: "Gao, Yunpeng" <yunpeng.gao@...el.com>
To: Linus Walleij <linus.ml.walleij@...il.com>
CC: Pierre Tardy <tardyp@...il.com>,
"Yuan, Hang" <hang.yuan@...el.com>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Chris Ball <cjb@...top.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Alan Cox <alan@...ux.intel.com>, Takashi Iwai <tiwai@...e.de>,
Maxim Levitsky <maximlevitsky@...il.com>,
Ohad Ben-Cohen <ohad@...ery.com>
Subject: RE: [RFC] sdhci: use ios->clock to know when sdhci is idle
>> 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.
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.
Thanks.
Regards,
Yunpeng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists