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-prev] [day] [month] [year] [list]
Date:	Mon, 11 Jan 2016 18:34:15 -0800
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Georgi Djakov <georgi.djakov@...aro.org>
Cc:	Mark Brown <broonie@...nel.org>, andy.gross@...aro.org,
	lina.iyer@...aro.org, linux-soc@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] soc: qcom: Add support for SAW2 regulators

On 01/07, Georgi Djakov wrote:
> On 12/18/2015 07:22 PM, Mark Brown wrote:
> > On Fri, Dec 18, 2015 at 06:14:58PM +0200, Georgi Djakov wrote:
> >> The SAW2 (Subsystem Power Manager and Adaptive Voltage Scaling Wrapper)
> >> is part of the SPM subsystem. It is a hardware block found on some of the
> >> Qualcomm chipsets, which regulates the power to the CPU cores. Add some
> >> basic support for it, so that we can do dynamic voltage scaling.
> >>
> >> Signed-off-by: Georgi Djakov <georgi.djakov@...aro.org>
> >> ---
> >>  drivers/soc/qcom/spm.c |  149 +++++++++++++++++++++++++++++++++++++++++++++++-
> > 
> > Please don't implement regualtors outside of the regulator driver
> > directory unless there is a really strong reason to do so, it makes it
> > much easier to maintain the subsystem and keep track of what's going on.
> > 
> 
> The reason of implementing the regulator functionality in drivers/soc is
> that it is part of the same hardware. The saw2 hardware manages the power
> controls - switching to low-power sleep modes, adaptive voltage scaling,
> voltage control and messaging to the PMIC. Keeping all the functionality
> of this hardware into a single driver seemed the suitable approach to me.

It's also weird because sometimes we need to configure something
for the regulator that lives on the PMIC with SSBI or SPMI
transactions. So we get this split bus driver where we want to do
some stuff over the pmic bus (SSBI/SPMI) and then change voltages
with MMIO writes in the SAW IP block. Plus we can't figure out
the initial voltage for the regulator without reading the voltage
out over the pmic bus. A plain MMIO regulator through the SAW
hardware is pretty much limited to setting voltages and on/off.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ