linux-kernel - Re: Fwd: [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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1274127650.2698.159.camel@finisterre.wolfsonmicro.main>
Date:	Mon, 17 May 2010 13:20:50 -0700
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Sundar <sunder.svit@...il.com>
Cc:	Deepak Sikri <deepak.sikri79@...il.com>, viresh.kumar@...com,
	rajeev-dlh.kumar@...com, armando.visconti@...com,
	linux-kernel@...r.kernel.org, vipin.kumar@...com,
	shiraz.hashim@...com, linux-pm@...ts.linux-foundation.org,
	linus.walleij@...ricsson.com, STEricsson_nomadik_linux@...t.st.com
Subject: Re: Fwd: [linux-pm] Power Domain Framework

On Mon, 2010-05-17 at 21:53 +0530, Sundar wrote:
> On Mon, May 17, 2010 at 8:03 PM, Mark Brown
> > On Mon, May 17, 2010 at 07:03:57PM +0530, Sundar wrote:

> > The major goal of the regulator API is to allow us to match up consumer
> > drivers with regulator drivers without having any device specific tie
> > between the two.  Pushing things that need such tie in through the API
> > breaks that.

> Aren't machine constraints, setting maximum current limit based on total loads
> similar to primitive tie ups between devices and regulator driver?

Like I say, there are similarities - it's the way the parts of the
system are connected and the level of knowledge they can have of each
other that differs.

> I am still confused about the knowledge of regulator about its consumer. How
> I see is, with the added controls, it is still devoid of any
> information about its
> clients. All that a regulator still would know is if at all there are
> any clients which

As I said in reply to the patch I am concerned that this may be an
oversimplification relative to what general hardware needs.

> require it at full load. I think the function *set_optimal_load is
> very similar to a OPP
> control mechanism. Instead of summing up load currents, now there are
> constraints.
> Probably you may look at the patch set at the end of this mail and comment.

Right, and if we could work out some generic constraints that meshed
well with the regulator API constraints it might be sensible to do this
(though it may still be more sensible to just clone the bits shared with
regulator API if there's not enough overlap in anything except really
basic stuff like enables).

> > includes a strong tie in with information about the device clocking.
> > Typically changing the operating mode will change or limit the clock
> > rates in use in various parts of the device.

> cannot these be handled with existing/new notifiers in place?

Things may start to get complicated there when the clocking and
operating points get tightly enough interlinked, and I would worry that
you'd end up spending more time faffing about with back and forth
callbacks than would be required to just implement something specific to
operating modes.

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