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]

Date:	Wed, 29 Dec 2010 10:31:50 +0100
From:	Linus Walleij <linus.ml.walleij@...il.com>
To:	"Gao, Yunpeng" <yunpeng.gao@...el.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

2010/12/29 Gao, Yunpeng <yunpeng.gao@...el.com>:

> 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.

A better question is why the clock gating does not use runtime
PM abstractions.

The hysteresis (timeout after inactivity, in the MMC spec >= 8 MCLK
cycles) can possibly be handled by refactoring the runtime PM
framework, someone offered to look at this later actually.

> Also, I noticed that in the current 'aggressive clock gating
> framework' patch, the clock gating of SDIO card has been
> disabled (please reference code and comments of function
> mmc_host_may_gate_card() in that patch).

We discussed different approaches to this, from marking an
SDIO slot as suspendable by using platform data, or whitelisting
the SDIO cards that can handle clock gating.

It was decided to keep SDIO cards out of it until we have this
infrastructure in place. So now you will have the opportunity
to fix this!

Not all SDIO cards will work properly if you try to gate them
so we need a mechanism to selectively do this.
Any suggestions?

Yours,
Linus Walleij
--
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/