From: lrg@slimlogic.co.uk (Liam Girdwood)
To: linux-arm-kernel@lists.infradead.org
Subject: Regulators vis-a-vis Power Domains
Date: Wed, 07 Apr 2010 10:38:07 +0100 [thread overview]
Message-ID: <1270633087.3248.27.camel@odin> (raw)
In-Reply-To: <20100406215725.GA11983@sirena.org.uk>
On Tue, 2010-04-06 at 22:57 +0100, Mark Brown wrote:
> On Tue, Apr 06, 2010 at 09:44:00PM +0100, Liam Girdwood wrote:
> > 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:
>
> > > > 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
>
> > > 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.
>
> Yes, once the control goes off chip the regulator framework definitely
> makes sense. It's only for things on the same die where there may be
> less of a clear separation for the power supplies and where there's
> likely to not be much more than simple power switching that it *might*
> be worth doing something custom which more directly represents what's
> going on.
I agree, although the concepts are pretty much the same wrt software in
that both external PMIC regulators and internal on die voltage domains
both control power to their consumers. We already have supply dependency
support and consumer ref counting in regulator core so voltage domain
support _may_ work well by adding a simplified method to register a
domain graph with the regulator core. There may be other small bits and
pieces to add too but I cant think of anything major atm.
Liam
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
prev parent reply other threads:[~2010-04-07 9:38 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
2010-04-06 21:57 ` Mark Brown
2010-04-07 9:38 ` Liam Girdwood [this message]
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=1270633087.3248.27.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).