Date:	Wed, 12 Mar 2008 13:52:46 -0800
From:	David Brownell <david-b@...bell.net>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Liam Girdwood <lg@...nsource.wolfsonmicro.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Dmitry Baryshkov <dbaryshkov@...il.com>
Subject: Re: [UPDATED v3][PATCH 1/7] regulator: consumer interface

On Wednesday 12 March 2008, Mark Brown wrote:
> On Tue, Mar 11, 2008 at 11:31:59PM -0800, David Brownell wrote:

> > > This is pretty much the model that is currently implemented.
> 
> > Then the tree should be a bit more of a first class citizen,
> > IMO, like it is in the clock framework.  Both clock and power
> > distribution have similar hardware infrastructure; the software
> > interfaces can be more similar than it is.
> 
> What do you see as being missing in the externally presented interface?

It's not *presented* as a tree of power domains, and it's not clear
that's the intended model.  Plus, what Liam said about the names
being global, not local/logical.


> As far as I can see the main difference between the two APIs on this
> front is that the regulator API explicitly separates the interface used
> to set up the tree from the interface used by consumers.

I'd say that differently.  The clock framework *has* no such
implementor/setup support ... which has caused problems for
many new implementations.  I'm unclear on the status of some
recent patches [1] from Dmitry Baryshkov to help address that.


> > > A given 
> > > power management IC can have several regulators (that is, things which
> > > have regulator IDs registered and can supply power). 
> 
> > Those are the outputs.  Are the inputs visible?  Like batteries
> > or loosely regulated DC voltages ... drivers/power/* stuff.
> 
> Not as part of this API at present unless the input is another
> regulator, though obviously drivers could set up associations in the
> device tree.

That may not be an issue; it's something which can be provided
by a PMIC driver, in any case.  If they both catch on, maybe
some integration will become useful.


> > > Each regulator can 
> > > have multiple clients bound to it (that is, things that have called
> > > regulator_get() and can consume power). 
> 
> > In the clock framework, clk_get_parent() exposes one part of this
> > relationship.  But there's also the association of logical clock
> > names to devices ... 
> 
> Right, though that does tend to break down when clocks go off chip - the
> association of devices with symbolic names is generally only done for
> things that are hard wired as part of the same chip since the devices
> are registered along with the clock.   Other clocks generally just get
> the name that the chip documents for them.  Indeed, looking around the
> tree almost all current use of clock API appears to be for on-SoC devices.

That's because there's essentially no way to plug in other clocks
in an arch-neutral way ... so the only implementations of clocks
are arch-specific!!  This is at least partly addressed by [1], but
platforms would also need to adopt that implementation framework.
So far the only patches showing that are on PXA and SA-1100, which
hardly present challenges in that area ... compared to e.g. OMAP.

Specifically, it's awkard even to do simple things like binding
one of a SOC's programmable clocks onto an off-chip audio codec
or video controller; that's got to go through platform_data or
something similar.  And plugging in external clock generators ...
not portably, no way!

You seem to be aiming to not recreate those problems, which is good.


> What might be nicer would be an API that platform code could use to map
> regulators to device/name tuples.  The core could then search these when
> a client calls regulator_get() (either by maintaining a separate table
> or by setting up virtual regulators).

Right.


> > > While the leaf enable/disable operations do happen at the client level
> > > the core reference counts the enabled clients to control enabling of the
> > > actual supply.
> 
> > Right.  But what I was getting at was that there can be
> > domains hooked up like:
> 
> >     Power --> Regulator -+-> Switch-1 -+-> Switch-2 --> [Dev-A]
> >                          |             |
> >                          |             +-> [Dev-B], [Dev-C]
> >                          |
> >                          +-> [Dev-D], [Dev-E]
> 
> > Those switches can be as simple as a MOSFET under GPIO control.
> 
> > And I'd expect power domains under Linux to be able to represent
> > all of those ... including software controls wherevever they're
> > practical, which in this case might include everything except the
> > battery input.
> 
> I don't see a particular problem fitting this into the structure of
> the current API - to me the switches inflexible regulators with no
> configurable voltage control of their own.

To me, they aren't regulators at all.  :)

I see power domains as having various capabilities.  Most of them
support on/off switching ... else there's no reason to list them
(except for the root nodes of the tree).  Some are programmable,
and suppport configuring the voltage or current drive.

That maps exactly to the clock tree model.  Not all clocks can
support clk_set_rate() or clk_set_parent().  Not all power domains
can support a set_voltage() call, etc.

This just suggests a bit of refocusing of your current code,
so it'll be more widely applicable.

- Dave

[1] http://marc.info/?l=linux-kernel&m=120237673527430&w=2
    http://marc.info/?l=linux-kernel&m=120237674327434&w=2


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