linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Voltage setting on chained regulators, how?
@ 2015-09-25  9:07 Sascha Hauer
  2015-09-25 16:47 ` Mark Brown
  0 siblings, 1 reply; 4+ messages in thread
From: Sascha Hauer @ 2015-09-25  9:07 UTC (permalink / raw)
  To: linux-kernel
  Cc: linux-pm, Liam Girdwood, Mark Brown, kernel, Rafael J. Wysocki,
	Viresh Kumar

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 |

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Voltage setting on chained regulators, how?
  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
  0 siblings, 1 reply; 4+ messages in thread
From: Mark Brown @ 2015-09-25 16:47 UTC (permalink / raw)
  To: Sascha Hauer
  Cc: linux-kernel, linux-pm, Liam Girdwood, kernel, Rafael J. Wysocki,
	Viresh Kumar

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Voltage setting on chained regulators, how?
  2015-09-25 16:47 ` Mark Brown
@ 2015-09-29  8:00   ` Sascha Hauer
  2015-09-29 15:00     ` Mark Brown
  0 siblings, 1 reply; 4+ messages in thread
From: Sascha Hauer @ 2015-09-29  8:00 UTC (permalink / raw)
  To: Mark Brown
  Cc: linux-kernel, linux-pm, Liam Girdwood, kernel, Rafael J. Wysocki,
	Viresh Kumar

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 |

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Voltage setting on chained regulators, how?
  2015-09-29  8:00   ` Sascha Hauer
@ 2015-09-29 15:00     ` Mark Brown
  0 siblings, 0 replies; 4+ messages in thread
From: Mark Brown @ 2015-09-29 15:00 UTC (permalink / raw)
  To: Sascha Hauer
  Cc: linux-kernel, linux-pm, Liam Girdwood, kernel, Rafael J. Wysocki,
	Viresh Kumar

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-09-29 15:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2015-09-29 15:00     ` Mark Brown

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