From mboxrd@z Thu Jan 1 00:00:00 1970 From: Georgi Djakov Subject: Re: [PATCH] soc: qcom: Add support for SAW2 regulators Date: Thu, 7 Jan 2016 15:47:59 +0200 Message-ID: <568E6C8F.6020509@linaro.org> References: <1450455298-1987-1-git-send-email-georgi.djakov@linaro.org> <20151218172206.GD5727@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wm0-f45.google.com ([74.125.82.45]:34633 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751931AbcAGNsD (ORCPT ); Thu, 7 Jan 2016 08:48:03 -0500 Received: by mail-wm0-f45.google.com with SMTP id u188so99032853wmu.1 for ; Thu, 07 Jan 2016 05:48:03 -0800 (PST) In-Reply-To: <20151218172206.GD5727@sirena.org.uk> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Mark Brown Cc: andy.gross@linaro.org, lina.iyer@linaro.org, sboyd@codeaurora.org, linux-soc@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org 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 >> --- >> 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. But if you think this is not a strong reason, then the approach probably would be to export parts of the existing driver and use syscon from a separate driver in drivers/regulator? Thanks, Georgi