lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150925090724.GH7858@pengutronix.de>
Date:	Fri, 25 Sep 2015 11:07:24 +0200
From:	Sascha Hauer <s.hauer@...gutronix.de>
To:	linux-kernel@...r.kernel.org
Cc:	linux-pm@...r.kernel.org, Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>, kernel@...gutronix.de,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Viresh Kumar <viresh.kumar@...aro.org>
Subject: 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ