All of lore.kernel.org
 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: 12+ 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 15:58   ` Ben Dooks
2010-04-06 20:44     ` Liam Girdwood [this message]
2010-04-06 21:57       ` Mark Brown
2010-04-06 21:57         ` Mark Brown
2010-04-07  9:38         ` Liam Girdwood
2010-04-07  9:38         ` Liam Girdwood
2010-04-06 20:44     ` Liam Girdwood
2010-04-04 13:10 ` Mark Brown
  -- strict thread matches above, loose matches on Subject: below --
2010-04-03 18:12 Sundar R IYER

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.