LKML Archive on
help / color / mirror / Atom feed
From: Mark Brown <>
To: David Brownell <>
Cc: Liam Girdwood <>,
	Andrew Morton <>,,
	linux-kernel <>,
	Dmitry Baryshkov <>
Subject: Re: [UPDATED v3][PATCH 1/7] regulator: consumer interface
Date: Wed, 12 Mar 2008 23:57:15 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Mar 12, 2008 at 01:52:46PM -0800, David Brownell wrote:
> On Wednesday 12 March 2008, Mark Brown wrote:

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

Hrm.  I suspect that the documentation which Liam is currently writing
(together with some actual in-tree users) will help here.

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

Well, the platforms I've looked at do implement a fairly standard
registration API to set up their clocks, even if it's only used to
configure things for the particular SoC variant in use and does tend to
omit things not used on the platform in question.

> many new implementations.  I'm unclear on the status of some
> recent patches [1] from Dmitry Baryshkov to help address that.

That looks like it'd help a lot in making the feature set implemented by
the clock API consistent over platforms.

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

Right; any regulator API is going to need to cope with connecting
multiple chips together since that's such a core use case.

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

We'll try to implement this before we next resubmit.

> > >     Power --> Regulator -+-> Switch-1 -+-> Switch-2 --> [Dev-A]
> > >                          |             |
> > >                          |             +-> [Dev-B], [Dev-C]
> > >                          |
> > >                          +-> [Dev-D], [Dev-E]

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


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

That's the aim, and some of this works already.  For example, regulators
with no set_voltage() are supported by the core.

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

In API terms I'm not sure it even needs a refocusing - I think the API
can already support everything you're asking for in this subthread
except for the addition of an API to allow platforms to map a symbolic
name and device tuple to an actual regulator.  Some of the cases that
can be set up will require additional work in the core to support them
but doing that shouldn't affect anything that doesn't directly deal with
those cases.

  parent reply	other threads:[~2008-03-12 23:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-06 18:10 Liam Girdwood
2008-03-08  3:43 ` David Brownell
2008-03-09 11:10   ` Liam Girdwood
2008-03-11  0:39     ` David Brownell
2008-03-11 10:20       ` Liam Girdwood
2008-03-11 21:36         ` David Brownell
2008-03-11 22:25           ` David Brownell
2008-03-12  0:00             ` Mark Brown
2008-03-12  7:31               ` David Brownell
2008-03-12 13:02                 ` Mark Brown
2008-03-12 21:52                   ` David Brownell
2008-03-12 23:26                     ` ian
2008-03-13  4:39                       ` David Brownell
2008-03-12 23:57                     ` Mark Brown [this message]
2008-03-13  5:08                       ` David Brownell
2008-03-13 12:00                         ` Mark Brown
2008-03-11  2:00     ` David Brownell
2008-03-11 15:19       ` Liam Girdwood
2008-03-12  6:29         ` David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [UPDATED v3][PATCH 1/7] regulator: consumer interface' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).