Message-ID: <20100526210728.GB19188@opensource.wolfsonmicro.com>
Date:	Wed, 26 May 2010 17:07:28 -0400
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Sundar R IYER <sundar.iyer@...ricsson.com>
Cc:	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>
Subject: Re: [linux-pm] Power Domain Framework

On Wed, May 26, 2010 at 10:33:49AM +0200, Sundar R IYER wrote:

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

You're missing the point here.  I'm not saying use the clock API, I'm
saying that it feels like you want a parallel API that's aimed at the
needs of operating points which mirrors the structure of the existing
clock and regulator APIs.

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

This isn't universal by any stretch of the imagination and manner in
which this is done is very different to how a regulator consumer would
operate.  A regulator consumer knows which voltage it wants to work at
directly and is selecting that voltage purely for itself, generally in a
way that applies to all implementations of the device.  With an
operating point a voltage is not set by the individual consumer but
rather for the power domain as a whole based on the needs of all the
consumers in the power domain.  If the same consumer driver is used in
multiple SoCs it's likely that the particular voltages needed will vary 
depending on the implementation on a given device.

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.

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

This is very much dependant on hardware again, some devices require a
clock for even basic functionality such as register access and there are
things such as dynamic RAM which won't even provide retention if they
are declocked.

You also need to remember that a key part of the operating point
configuration of some devices is the clock rate - normally the voltage
required by the block will be driven by the clock rates in operation in
the block.  The clock rates required may be a function of the operation
of the individual blocks but are often also driven by things like the
overall bandwidth needed on the various buses in the system.

As I keep saying the operating point selection in general hardware is
often a function of both the clocking and voltage selection, and often
chosen in a different way.

> 4. Both power domains and a regulator can be enforced upon constraints from their clients.

A different set of constraints, though - there's not much overlap here.

> *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.

As I keep saying the interaction between the consumer and the supplier
is also rather different between the two use cases.

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

Can you identify how operating points might be added to regulators?  The
physical connection between the regulators and the devices they are
supplying is very clear and does not leave much (if any) room for
flexibility here, and as I discussed in a prior message the trend in
hardware implementation is towards reducing the control which systems
use rather than increasing it.

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

I'm still not seeing any meaningful overlap between the two things - it
seems unlikely that a substantial proportion of the drivers that need to
interact with operating points will also wish to explicitly use anything
other than enable and disable that the regulator API offers so even if
the two ended up being implemented in the same API you'd still have two
disjoint blocks of code implementing different things.

There are many interfaces in the kernel which work together to provide
power efficiency and to me it seems like you have identified a need for
a new one.  I'd also repeat my previous suggestion to look in more
detail at the operating point implementations that already exist in the
kernel and the needs of the hardware out there.
--
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