linux-kernel - Re: [PATCH] soc: qcom: Add support for SAW2 regulators

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]

Message-ID: <20160112023415.GX22188@codeaurora.org>
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