Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1232674 > unrolled thread

Voltage setting on chained regulators, how?

Back to article view | Back to linux.kernel

Contents

  Voltage setting on chained regulators, how? Sascha Hauer <s.hauer@pengutronix.de> - 2015-09-25 11:10 +0200
    Re: Voltage setting on chained regulators, how? Mark Brown <broonie@kernel.org> - 2015-09-25 18:50 +0200
      Re: Voltage setting on chained regulators, how? Sascha Hauer <s.hauer@pengutronix.de> - 2015-09-29 10:10 +0200
        Re: Voltage setting on chained regulators, how? Mark Brown <broonie@kernel.org> - 2015-09-29 17:10 +0200

#1232674 — Voltage setting on chained regulators, how?

Hi,

On i.MX6 we have the situation that the CPU is supplied by a SoC
internal linear regulator which in turn is supplied by an external
switching regulator:

---> Switching regulator ---> LDO ---> CPU

For energy efficiency reasons we want to minimize the dropout voltage on
the LDO.

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.

Another possibility of course would be to implement this completely in
the cpufreq driver and not bother the regulator framework. Looking at
drivers/cpufreq/imx6q-cpufreq.c the regulator handling code in there is
already complicated enough since in reality it's not one LDO but three
and we would have to add another two regulators to this driver.

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.

Any ideas/input how to proceed?

Thanks
  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 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1232938

[Multipart message — attachments visible in raw view] — view raw

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.

> 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.  Having a DCDC
doing most of the voltage drop for efficiency with a LDO to clean up the
output of the DCDC is pretty common.

[toc] | [prev] | [next] | [standalone]

#1234798

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 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1235209

[Multipart message — attachments visible in raw view] — view raw

On Tue, Sep 29, 2015 at 10:00:44AM +0200, Sascha Hauer wrote:
> On Fri, Sep 25, 2015 at 09:47:26AM -0700, Mark Brown wrote:

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

Yeah, that sounds pretty standard.  It would be really good to get
support for minimising the voltage drop over the LDO, there are going to
be quite a few systems which could get a power consumption benefit from
dynamically tuning the voltages of DCDCs like this.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web