From patchwork Thu Nov 2 16:11:52 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 10038939 X-Patchwork-Delegate: agross@codeaurora.org Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id AB121603B5 for ; Thu, 2 Nov 2017 16:11:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9CB76290DA for ; Thu, 2 Nov 2017 16:11:59 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9128A291CB; Thu, 2 Nov 2017 16:11:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E82A2291D2 for ; Thu, 2 Nov 2017 16:11:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933871AbdKBQL6 (ORCPT ); Thu, 2 Nov 2017 12:11:58 -0400 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:59414 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932833AbdKBQL5 (ORCPT ); Thu, 2 Nov 2017 12:11:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=Date:Message-Id:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner: List-Archive; bh=Kb5Ty57kireQxGNqbGHoRmNlpTHobWIqj1sC1dIlgZk=; b=vY5wmeKKe4kC QPKShNMQpDpgu6ApLDXtj9CJb11r1Mur0FTnGW5H34e+cq94KzBhVN8n0HFnQTVjjHd667wk6biAl F7lHpohWA8ZEr3UBg8doVwF70kLLY4MrFXF8Nt6208/WGvuDLpcliV6dQkpRAutdYqGlV7Bn6SFkw rKhFM=; Received: from debutante.sirena.org.uk ([2001:470:1f1d:6b5::3] helo=debutante) by heliosphere.sirena.org.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1eAI5w-0006h5-Pj; Thu, 02 Nov 2017 16:11:52 +0000 Received: from broonie by debutante with local (Exim 4.89) (envelope-from ) id 1eAI5w-0002ua-2z; Thu, 02 Nov 2017 16:11:52 +0000 From: Mark Brown To: Stephen Boyd Cc: Mark Brown , Mark Brown , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Applied "regulator: qcom_spmi: Include offset when translating voltages" to the regulator tree In-Reply-To: <20171102050619.32204-1-sboyd@codeaurora.org> Message-Id: Date: Thu, 02 Nov 2017 16:11:52 +0000 Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The patch regulator: qcom_spmi: Include offset when translating voltages has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark From ab953b9db3a1169fbc675c8de3d2dab919ce3211 Mon Sep 17 00:00:00 2001 From: Stephen Boyd Date: Wed, 1 Nov 2017 22:06:19 -0700 Subject: [PATCH] regulator: qcom_spmi: Include offset when translating voltages This driver converts voltages from a non-linear range in hardware to a linear range in software and vice versa. During the conversion, we exclude certain voltages that are invalid to use because the software interface is more flexible than reality. For example, the FTSMPS2P5 regulators have a voltage range from 80000uV to 1355000uV that software could support, but we only want to use the range of 350000uV to 1355000uV. If we don't account for the hw selectors between 80000uV and 350000uV we'll pick a hw selector of 0 to mean 350000uV when it really means 80000uV. This can cause us to program voltages into the hardware that are significantly lower than what we're expecting. And when we read it back from the hardware we'll have the same problem, voltages that are in the invalid band will end up being calculated as some software selector that represents a larger voltage than what is programmed and the user will be confused. Fix all this by properly offsetting the software selector and hw selector when converting from one number space to another. Fixes: 1b5b19689278 ("regulator: qcom_spmi: Only use selector based regulator ops") Signed-off-by: Stephen Boyd Signed-off-by: Mark Brown --- drivers/regulator/qcom_spmi-regulator.c | 39 ++++++++++++++++++++++++++++----- 1 file changed, 33 insertions(+), 6 deletions(-) diff --git a/drivers/regulator/qcom_spmi-regulator.c b/drivers/regulator/qcom_spmi-regulator.c index 16c5f84e06a7..c372b244f3da 100644 --- a/drivers/regulator/qcom_spmi-regulator.c +++ b/drivers/regulator/qcom_spmi-regulator.c @@ -593,13 +593,20 @@ static int spmi_sw_selector_to_hw(struct spmi_regulator *vreg, u8 *voltage_sel) { const struct spmi_voltage_range *range, *end; + unsigned offset; range = vreg->set_points->range; end = range + vreg->set_points->count; for (; range < end; range++) { if (selector < range->n_voltages) { - *voltage_sel = selector; + /* + * hardware selectors between set point min and real + * min are invalid so we ignore them + */ + offset = range->set_point_min_uV - range->min_uV; + offset /= range->step_uV; + *voltage_sel = selector + offset; *range_sel = range->range_sel; return 0; } @@ -613,15 +620,35 @@ static int spmi_sw_selector_to_hw(struct spmi_regulator *vreg, static int spmi_hw_selector_to_sw(struct spmi_regulator *vreg, u8 hw_sel, const struct spmi_voltage_range *range) { - int sw_sel = hw_sel; + unsigned sw_sel = 0; + unsigned offset, max_hw_sel; const struct spmi_voltage_range *r = vreg->set_points->range; - - while (r != range) { + const struct spmi_voltage_range *end = r + vreg->set_points->count; + + for (; r < end; r++) { + if (r == range && range->n_voltages) { + /* + * hardware selectors between set point min and real + * min and between set point max and real max are + * invalid so we return an error if they're + * programmed into the hardware + */ + offset = range->set_point_min_uV - range->min_uV; + offset /= range->step_uV; + if (hw_sel < offset) + return -EINVAL; + + max_hw_sel = range->set_point_max_uV - range->min_uV; + max_hw_sel /= range->step_uV; + if (hw_sel > max_hw_sel) + return -EINVAL; + + return sw_sel + hw_sel - offset; + } sw_sel += r->n_voltages; - r++; } - return sw_sel; + return -EINVAL; } static const struct spmi_voltage_range *