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

On Tuesday 11 March 2008, Mark Brown wrote:
> On Tue, Mar 11, 2008 at 02:25:10PM -0800, David Brownell wrote:
> > On Tuesday 11 March 2008, David Brownell wrote:
> > > How would you see your notion of a "regulator" (client?)
> > > relating to a "power domain"? ?My first thought is that
> > > there's a one-to-one correspondence but they may not be
> > Actually, it's clearly not one-to-one.  Counter-example:
> > a 3V3 regulator powering one of a SOC's I/O power domains,
> > which is managed by a digital switch.  That same regulator
> > can power several I/O devices too.  It may even feed a 1V8
> > regulator.
> It's also common for devices to have multiple power inputs which can be
> run separately if required but which are normally tied together unless
> there is a special reason to do so.

I've not happened across that idiom.  Is that common on
particular larger systems?

> > So the relationship is probably that regulators define a
> > domain ... but such domains can be subdivided.  There's
> > a tree; it's probably more shallow than the clock tree.
> 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.

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

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

> It is also possible to tell the 
> core that one regulator supplies another - if this is done then the core
> will take care of ensuring that parents are enabled when their children
> need them.

Right.  clk_enable()/clk_disable() uses a refcounting model for
that stuff; similar.

> > And enable/disable primitives probably map best to power
> > domains, not all of which are entire regulators.
> 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]

That is:  five power domains, one regulator:

  - Input power, e.g. a battery
  - Regulator output, maybe configurable
  - Devices D and E share a domain coupled to the regulator
  - Devices B and C share a switched domain
  - Device A has its own switched domain

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.

- Dave

  reply	other threads:[~2008-03-12  7:32 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 [this message]
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
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).