linux-kernel - Re: [linux-pm] Power Domain Framework

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] [day] [month] [year] [list]

Message-ID: <20100527065129.GA22419@opensource.wolfsonmicro.com>
Date:	Thu, 27 May 2010 02:51:29 -0400
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Paul Mundt <lethal@...ux-sh.org>
Cc:	Sundar R IYER <sundar.iyer@...ricsson.com>,
	Sundar <sunder.svit@...il.com>,
	Viresh KUMAR <viresh.kumar@...com>,
	Rajeev KUMAR <rajeev-dlh.kumar@...com>,
	Linus WALLEIJ <linus.walleij@...ricsson.com>,
	Armando VISCONTI <armando.visconti@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Vipin KUMAR <vipin.kumar@...com>,
	Shiraz HASHIM <shiraz.hashim@...com>,
	STEricsson_nomadik_linux <STEricsson_nomadik_linux@...t.st.com>,
	"linux-pm@...ts.linux-foundation.org" 
	<linux-pm@...ts.linux-foundation.org>,
	Magnus Damm <magnus.damm@...il.com>
Subject: Re: [linux-pm] Power Domain Framework

On Thu, May 27, 2010 at 12:01:00PM +0900, Paul Mundt wrote:

> Having said that, building on top of the regulator API for these cases
> wouldn't be that much work either, since it largely has all of the
> infrastructure in place (ie, the static consumer case).

On the other hand given that all you're really getting here is the
enable/disable tracking it's also pretty easy to just copy.

> > It's perfectly sensible for the power domain to be a regulator consumer,
> > but having the individual consumer devices be regulator consumers seems
> > non-obvious.

> The common case on SH is that certain blocks are only available in
> certain power domains, while the on/off control remains uniform (albeit
> periodically ineffectual) regardless of state. We also don't have any
> ability to regulate voltage outside of things like PCMCIA.

That's also the case for the power domains on ARMs at the minute, though
the bus control element is pretty common and sometimes gets rolled in to
the operating modes since it's the same IP blocks that share the
resources.

> On/off control in this context is completely orthoganol from clock
> control in that many peripherals without a specific input clock still
> implement power gating in the same way as those that do (this is the case
> for things like the L2 cache, TLB, breakpoint controller, etc). These are
> presently handled through the clock API largely because there was really
> no better fit for them at the time.

Yup, that's pretty common.  The clocking stuff mostly comes into play
when your operating points also include an element of control for the
buses that the devices are hanging off - you end up doing DVFS for the
blocks, normally over the full block rather tha individual blocks.  It's
this stuff that usually has some crossover with regulators, though
mostly as consumers.
--
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/