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

Message-ID: <33A307AF30D7BF4F811B1568FE7A9B180B67C60C@EXDCVYMBSTM006.EQ1STM.local>
Date:	Wed, 26 May 2010 10:33:49 +0200
From:	Sundar R IYER <sundar.iyer@...ricsson.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Sundar <sunder.svit@...il.com>
Cc:	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>
Subject: RE: [linux-pm] Power Domain Framework

Hello Mark,

>-----Original Message-----
>From: Mark Brown [mailto:broonie@...nsource.wolfsonmicro.com]
>This is just one example of something that might come up and need
>fitting in to the regulator API which is substantially different to the
>needs of the core regulator applications.  As I keep saying I'm just not
>seeing much more overlap here with the regulator API than I do with the
>clock API: it feels like you've got another use case which needs an API
>with a similar structure and the reference counted enable and disable
>calls but otherwise very little overlap.

As I agreed earlier, its true about requirement. It is also true that the clock API can suffice.
But what is essential here is: we are talking about regulators here.
Why would we need to model a seemingly similar regulator as a clock?

>I don't think the enable and disable calls are enough of an overlap to
>mean that the regulator use case and the operating point use case are
>going to overlap well, it feels like it'd cause pain trying to match the
>concepts between the two APIs.

Again here, more similarities for a power domain with a regulator.

1. Both power domains and a regulator can be enabled/disabled.
2. Both power domains and a regulator can be controlled to a specific voltage.
3. Every peripheral is dependent on both power domains and a regulator to be essentially
   on. Turning off the clocks will disable the peripheral, but it is not the same as turning off
   the peripheral. And here is where the biggest difference from the clock API. You can disable
   the peripheral clock with the clk_disable, but turning it off will be encroachment there. Whilst
   a regulator_disable is the most logical fit here.
4. Both power domains and a regulator can be enforced upon constraints from their clients.

*What* power domains and regulators differ about is:
1.a the nature of constraints is a bit different. On SoC regulators aka power domains have usually
     a fixed set of clients which don't vary, but off SoC regulators can have varying clients.
2.a On SoC regulators aka power domains allow you controlling operational states like 
     On/Off/Retention/Idle etc, whilst conventional regulators are more happy judging their current loads.
     However, this still doesn't stop anyone from actually adding operational states to regulators.

I agree with your reservations about pains trying to co-relate exactly a power domain and a regulator.
If you agree, from the top, reaching out to bottom, there are only subtle differences and these 
differences (1.a/2.a) can also be incorporated into conventional regulators which can be gradually 
diminishing, whereas the similarities, (1,2,3,4) can only possible increase!

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