linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Liam Girdwood <lgirdwood@gmail.com>,
	kernel@pengutronix.de, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: Voltage setting on chained regulators, how?
Date: Tue, 29 Sep 2015 10:00:44 +0200	[thread overview]
Message-ID: <20150929080044.GS7858@pengutronix.de> (raw)
In-Reply-To: <20150925164726.GI30445@sirena.org.uk>

On Fri, Sep 25, 2015 at 09:47:26AM -0700, Mark Brown wrote:
> On Fri, Sep 25, 2015 at 11:07:24AM +0200, Sascha Hauer wrote:
> 
> > Any idea how such a scenario could be implemented? The regulator
> > framework already has some idea of supply regulators, but it only takes
> > care of en/disabling the supplies and will not change the voltage on the
> > supplies. Should this be implemented in the regulator framework?  Some
> > first experiments brought me into a locking hell quite fast.
> 
> It's just a case of implementation, but yes the locking is fun.  I don't
> think it's that big a deal to rethink it, it's partly complicated since
> the existing locking is designed to be really simple and easy to review.

Ok, it seems you're generally ok with putting this into the regulator
core. I'll try and see what I can come up with. Maybe I leave the
locking part for later to see if this otherwise solves my problem or if
there are other pitfalls I don't see yet.

> 
> > For added fun ideally we want to put the LDOs in bypass mode instead of
> > configuring them for minimum dropout. The bypass mode doesn't work for
> > the 1.2GHz operating point though since the ripple on the switching
> > regulator gets too high. So we can't just statically configure bypass
> > mode but have to enable it dynamically based on the operating points.
> 
> I suspect you always want the LDO in there to clean the supply up, it's
> just a more serious issue when more power is being drawn.

I just had a look at the i.MX6 datasheets and saw that while it's
possible to put the LDOs in bypass mode the expected lifetime of the SoC
decreases without the LDOs. So it seems better to let them enabled and
just make the voltage drop as small as possible.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2015-09-29  8:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-25  9:07 Voltage setting on chained regulators, how? Sascha Hauer
2015-09-25 16:47 ` Mark Brown
2015-09-29  8:00   ` Sascha Hauer [this message]
2015-09-29 15:00     ` Mark Brown

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=20150929080044.GS7858@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=broonie@kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=viresh.kumar@linaro.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).