On Wed, May 26, 2010 at 10:33:49AM +0200, Sundar R IYER wrote:
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.
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.
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.
A different set of constraints, though - there's not much overlap here.
As I keep saying the interaction between the consumer and the supplier
is also rather different between the two use cases.
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'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.
--
