From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752394AbcAGNsH (ORCPT ); Thu, 7 Jan 2016 08:48:07 -0500 Received: from mail-wm0-f53.google.com ([74.125.82.53]:38585 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751941AbcAGNsE (ORCPT ); Thu, 7 Jan 2016 08:48:04 -0500 Subject: Re: [PATCH] soc: qcom: Add support for SAW2 regulators To: Mark Brown References: <1450455298-1987-1-git-send-email-georgi.djakov@linaro.org> <20151218172206.GD5727@sirena.org.uk> 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 From: Georgi Djakov Message-ID: <568E6C8F.6020509@linaro.org> Date: Thu, 7 Jan 2016 15:47:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151218172206.GD5727@sirena.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: 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