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: <AANLkTikyqnKDNz7FIUvLDAvBReHskHvRCrEz2qBBqseH@mail.gmail.com>
Date:	Sun, 16 May 2010 16:43:52 +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
Subject: Re: [linux-pm] Power Domain Framework

Hi All,

The regulator framework documentation already refers to the concept of
power domains and I think the framework *can* be extended more to
support on-SoC power domains as well.

I have been working with the regulator framework for on-chip power
domains too and....

>2. Maintain a list of the different power domains present.
>3. The devices in a specific power domain, as per the requirements would get the power
>domain...
>4. Typically a usage count of zero for any power domai..
>5. The same could be mapped on to the PM framework..
>6. The model could further be build upon to check any dependency in the power domains

the above requirements can be leveraged through the current regulator
framework itself.

However, for working with power domains within the framework, I feel that,
- support must be added to allow additional domain-specific states
like retention, idle etc.
- controlling operating points for regulators, unlike setting optimal modes.
- controlling regulator modes via constraints enforced by clients and
managing transition to various states through the client requests and
pushing the client states up to the parent regulator.

>7. The advantages of the framework could be leveraged in the CPU idle time, by switching >off the Power domains with zero usage counts.

Yes. A simple platform specific list of all regulators ( and power
domains ) can be easily used in the CPUIdle driver for determining low
power states. Further, enforcing run time PM can club together any
peripheral's power sources in terms of external regulators, on-chip
domains ( and clock sources possibly).

i have a very primitive implementation for adding operating points and
constraints into the framework and currently i am able to control
regulator aka domain states based on various child domains and
contraints.

However, with more inputs, I think we can make the regulator framework
easily manage power sources, whether on-chip domains or external
conventional regulators...

Waiting for opinions and views,

Regards,
Sundar

 Mon, May 10, 2010 at 7:35 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Mon, May 10, 2010 at 07:16:06PM +0530, Deepak Sikri wrote:
>
>> In our System on chip we have several power domains. As such there is no
>> generic framework for the Power Domains in linux , and I find huge potential
>> in the software to control the domains and exploit the power management
>> capabilities.
>
>> There is one very small model that I could think of, something on the lines
>> of clock framework.
>
> Might be worth looking at what the OMAP and SH Mobile CPUs are doing
> here, they have existing handling for power domains.  Off-SoC the
> regulator API should already cope with a lot of this stuff.
> _______________________________________________
> linux-pm mailing list
> linux-pm@...ts.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
>
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ