linux-kernel - Re: [RFC] sdhci: use ios->clock to know when sdhci is idle

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTimbTwKMHrpmREwnq+19vwWZv6qYwQCkB=jr3aUp@mail.gmail.com>
Date:	Sun, 2 Jan 2011 20:45:31 +0100
From:	Pierre Tardy <tardyp@...il.com>
To:	"Gao, Yunpeng" <yunpeng.gao@...el.com>
Cc:	Linus Walleij <linus.ml.walleij@...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

On Thu, Dec 30, 2010 at 11:37 AM, Gao, Yunpeng <yunpeng.gao@...el.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
--
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/