linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: lrg@slimlogic.co.uk (Liam Girdwood)
To: linux-arm-kernel@lists.infradead.org
Subject: Regulators vis-a-vis Power Domains
Date: Tue, 06 Apr 2010 21:44:00 +0100	[thread overview]
Message-ID: <1270586640.3229.72.camel@odin> (raw)
In-Reply-To: <20100406155812.GR31126@trinity.fluff.org>

On Tue, 2010-04-06 at 16:58 +0100, Ben Dooks wrote: 
> On Sun, Apr 04, 2010 at 02:10:58PM +0100, Mark Brown wrote:
> > On Sat, Apr 03, 2010 at 08:12:56PM +0200, Sundar R IYER wrote:
> > 
> > Please fix your mail client to word wrap within paragraphs; not doing
> > this makes your messages harder to read and reply to.  I've reflowed below.
> > 
> > > 1. The documentation for the regulators mentions "power domains" and
> > > "switches" to be modeled as regulators. I am planning to model multiple
> > > "switches" for controlling supplies to various peripherals from a main
> > > master regulator as multiple regulators, childed from the parent
> > > regulator. Is this the right way to proceed ahead? Further the options
> > 
> > If you want to do this in the regulator framework, yes.
> > 
> > > for these switches will be only a logical on/off. (BTW, I saw lots of TI
> > > stuff which is something related to power domains, but it doesn't model
> > > the regulator framework.)
> > 
> > Nor does the SH stuff.  With the power domains of a CPU it often doesn't
> > buy terribly much to use the regulator framework - the power domains are
> > often a small part of a much bigger picture for the CPU internal power
> > management, often incorporating thing 
> 
> I personally think there is merit to having the regulator framework at
> least play a part in these, as is possible the powerdomains are being
> fed from external regulators and/or power switches. I see it as good
> way of using existing support to do useful work.

I tend to agree here, although I think it's still early days for this
technology and maybe some hybrid approach will eventually emerge.

Fwiw, I'm adding regulator support to other types of tightly coupled
CPU/DSP voltage control i.e. OMAP4 SmartReflex. 

Liam  

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

  reply	other threads:[~2010-04-06 20:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-03 18:12 Regulators vis-a-vis Power Domains Sundar R IYER
2010-04-04 13:10 ` Mark Brown
2010-04-06 15:58   ` Ben Dooks
2010-04-06 20:44     ` Liam Girdwood [this message]
2010-04-06 21:57       ` Mark Brown
2010-04-07  9:38         ` Liam Girdwood

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=1270586640.3229.72.camel@odin \
    --to=lrg@slimlogic.co.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).