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

Message-ID: <AANLkTinZRhUpFTOOUCdH5dEl3QaXn10USL_hPPQX8cie@mail.gmail.com>
Date:	Mon, 17 May 2010 19:03:57 +0530
From:	Sundar <sunder.svit@...il.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.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: Fwd: [linux-pm] Power Domain Framework

Hi,

On Mon, May 17, 2010 at 8:46 AM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Sun, May 16, 2010 at 04:43:52PM +0530, Sundar wrote:
>
> Please don't top post, it breaks the thread of discussion.
Sorry.

> I'm really not convinced that this is a good idea.  Generally I suspect
> the implementations of these concepts that I've seen would introduce
> layering violations if done via the regulator API - from what I've seen
> the power domains can end up knowing rather more about the things that
> are being powered than is healthy for the regulator API and...

I am sorry but I do not understand how this can violate the framework APIs.
Even know, a regulator knows about its machine constraints, valid features
w.r.t operating modes, DRMS, load currents etc. What additional information
the regulator would be associated with would be operating points, constraints
w.r.t peripherals etc.

> I do think it's likely that you'll want something that looks like the
> regulator API at the edges, but that a separate implementation that
> avoids having to shoehorn through the abstractions of the regulator API
> for the on-chip work seems much more sensible (and is what OMAP and SH

True. But a separate implementation is not needed because the current
framework already provides me support for a majority of features. Features like
OPP control, power states which are usually associated with SoC power domains
are available on modem regulators. When such features will eventually creep in
the regular framework, then why distinguish between on-SoC power sources
and on-board power sources..

> are already doing).  This is fairly similar to the relationship between
> the clock and regulator APIs - they look a lot alike, especially from a
> user point of view, but they are separate because there are enough
> differences in what they are trying to represent to make it sensible to
> keep them apart.

Agreed. But if I compare a SoC power domain and a regulator power domain, I
dont see differences to keep them apart. Please correct me if I am wrong.

> However, if you have patches it's probably easier to talk about those
> than architecture astronauting; perhaps your implementation avoids my
> concerns.
>
Okay. I will surely send them out.

Regards,
Sundar
--
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/