From patchwork Tue Nov 10 08:19:38 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Vaittinen, Matti" X-Patchwork-Id: 321237 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 204F8C388F7 for ; Tue, 10 Nov 2020 08:19:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CD61C2080A for ; Tue, 10 Nov 2020 08:19:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726827AbgKJITs (ORCPT ); Tue, 10 Nov 2020 03:19:48 -0500 Received: from mail-lf1-f67.google.com ([209.85.167.67]:46506 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726690AbgKJITs (ORCPT ); Tue, 10 Nov 2020 03:19:48 -0500 Received: by mail-lf1-f67.google.com with SMTP id v144so16211479lfa.13; Tue, 10 Nov 2020 00:19:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=UlXbMpsFa244UJuIxjSMkR1LlqiCKu1MwIsUY/puf+k=; b=TDVXqybh0Rc2vGrgqqSgCKmbHD94AKd8jvr38BIof3xj9OoF8cJz3XmRRdfP4/qcU2 4/+OoZKzUjCQ5kr1vfWPr3wKVrOO+hSIBmC7ZSHi3gUIfBUhP+U6d2BHgVQ/CdeSIpw1 8lpIbU2W5iYgE15MqoP/rA/sDGjawbJqMack4gECXaCGdLpHV3ASA9+32VBMq/oMFCkq lcugXeW0os+O0rhnctvZcmovKbMMvmA79z05aCIU3IA7VmPr8MYjT57D4GTxu8WCSWz2 9x4jEVmKO+JsgZ1IS9rMsybOqb/aO1e/hUwAgTkBNp/peSYNso9T2ncg4grZgLkhWjNo uIdg== X-Gm-Message-State: AOAM531cR0IuvYV2a/g7Lm4cZdtUniSBzrZ9IIn43EX3HIo+Q9SS87jC omNniG5zWkl30X4Z5Z0B4gM= X-Google-Smtp-Source: ABdhPJytIDfg1YooZqoNZODuaWFEQsklBhO+zntVJC+zyChrPvMgicM2aZPNrGfVcfd3B0Dhsu6u2A== X-Received: by 2002:ac2:5687:: with SMTP id 7mr7047702lfr.149.1604996385134; Tue, 10 Nov 2020 00:19:45 -0800 (PST) Received: from localhost.localdomain (62-78-225-252.bb.dnainternet.fi. [62.78.225.252]) by smtp.gmail.com with ESMTPSA id t5sm2030280lfc.75.2020.11.10.00.19.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Nov 2020 00:19:44 -0800 (PST) Date: Tue, 10 Nov 2020 10:19:38 +0200 From: Matti Vaittinen To: mazziesaccount@gmail.com, matti.vaittinen@gmail.com Cc: Liam Girdwood , Mark Brown , Rob Herring , Matti Vaittinen , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-power@fi.rohmeurope.com Subject: [RFC PATCH 1/3] dt-bindings: regulator: BD71837 support commonly used feedback connection Message-ID: <9959924313db7c7165598604f9a07bf227f471a8.1604994184.git.matti.vaittinen@fi.rohmeurope.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org The BD71837 buck output voltages are in a few cases scaled using external connection which adds a pull-up to regulator feedback pin. This connection will adjust output voltage from regulator in a deterministic way. Add support for describing this HW connection so that driver can adjust voltage ranges accordingly. Signed-off-by: Matti Vaittinen --- .../regulator/rohm,bd71837-regulator.yaml | 48 +++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml index f5e31196a646..1941b36cf1ef 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml @@ -105,6 +105,54 @@ patternProperties: PMIC hardware state machine. type: boolean + # Setups where regulator (especially the buck8) output voltage is scaled + # by adding external connection where some other regulator output is + # connected to feedback-pin (over suitable resistors) is getting popular + # amongst users of BD71837. (This allows for example scaling down the + # buck8 voltages to suit lover GPU voltages for projects where buck8 is + # (ab)used to supply power for GPU. + # + # So we allow describing this external connection from DT and scale the + # voltages accordingly. This is what the connection should look like: + # + # |---------------| + # | buck 8 |-------+----->Vout + # | | | + # |---------------| | + # | | + # | | + # +-------+--R2----+ + # | + # R1 + # | + # V FB-pull-up + # + # Here the buck output is sifted according to formula: + # + # Vout_o = Vo - (Vpu - Vo)*R2/R1 + # Linear_step = step_orig*(R1+R2)/R1 + # + # where: + # Vout_o is adjusted voltage output at vsel reg value 0 + # Vo is original voltage output at vsel reg value 0 + # Vpu is the pull-up voltage V FB-pull-up in the picture + # R1 and R2 are resistor values. + + rohm,fb-pull-up-microvolt: + description: + Feedback-pin has pull-up connection to adjust voltage range. This is + the used pull-up voltage before R1. + + rohm,feedback-pull-up-r1-ohms: + description: + Feedback-pin has pull-up connection to adjust voltage range. This is + the used R1 resistor. + + rohm,feedback-pull-up-r2-ohms: + description: + Feedback-pin has pull-up connection to adjust voltage range. This is + the used R2 resistor. + required: - regulator-name From patchwork Tue Nov 10 08:20:17 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Vaittinen, Matti" X-Patchwork-Id: 321236 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9B5A3C388F7 for ; Tue, 10 Nov 2020 08:20:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4CCE1208FE for ; Tue, 10 Nov 2020 08:20:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726825AbgKJIU1 (ORCPT ); Tue, 10 Nov 2020 03:20:27 -0500 Received: from mail-lf1-f65.google.com ([209.85.167.65]:36579 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726462AbgKJIU1 (ORCPT ); Tue, 10 Nov 2020 03:20:27 -0500 Received: by mail-lf1-f65.google.com with SMTP id f11so10003323lfs.3; Tue, 10 Nov 2020 00:20:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=IDSxpkxHLT4rWHHSEG+47MZJHtsvhN3aVv1OmkPtH0M=; b=Sb8h9kHvMBga7Jpxbh4sn5Z1vh86Lr89Sy9TBJwzRSIJmvjOw0lurUGuIpnMdZC5+g tstxSyyQCbbW5fPtdd+QoQcCdmAXlf+uiBeYvKqc9XgvA239vVI0W7iKGkcwFigfltkd C8GvzPoKCOhZ5gBq4Owg6mm+96IulV3ABp9lodib0PI3MwJcHgYSq21PvjC9s9Qmt/eE bHHv6RaPisA/CoLM5dEHUn+2z+vR5L/9Sh7PfBNemRjUbhBOhXPGH6fVwOrnlgGYwI4V k+81Qp5oHFe7yKrewZZLFD/QDJDk+rKh9BNeb9IjN0SPtAi8EgjxuFQql3kq9W1EhpI1 KkJA== X-Gm-Message-State: AOAM532Ak8PdolazoigYdWdbKyj5TjA/0Ede1K5HmpquSoIEMaftvNuM 06M8qzGXLxC6TSXSE9FwFzc= X-Google-Smtp-Source: ABdhPJxHXj0HApjWxiqo2OFKAOybvwc2pXzmMZ7/tBEKstH5VZM68Pu2HpiknM7iE3TFy9713zs+WQ== X-Received: by 2002:a19:794:: with SMTP id 142mr184661lfh.232.1604996423735; Tue, 10 Nov 2020 00:20:23 -0800 (PST) Received: from localhost.localdomain (62-78-225-252.bb.dnainternet.fi. [62.78.225.252]) by smtp.gmail.com with ESMTPSA id z5sm2133915ljk.136.2020.11.10.00.20.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Nov 2020 00:20:23 -0800 (PST) Date: Tue, 10 Nov 2020 10:20:17 +0200 From: Matti Vaittinen To: mazziesaccount@gmail.com, matti.vaittinen@gmail.com Cc: Liam Girdwood , Mark Brown , Rob Herring , Matti Vaittinen , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-power@fi.rohmeurope.com Subject: [RFC PATCH 3/3] regulator: bd718x7: Support external connection to scale voltages Message-ID: <89b2be87074f307a8823f15f34e1f662023cbf36.1604994184.git.matti.vaittinen@fi.rohmeurope.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Setups where regulator (especially the buck8) output voltage is scaled by adding external connection where some other regulator output is connected to feedback-pin (over suitable resistors) is getting popular amongst users of BD71837. This allows for example scaling down the buck8 voltages to suit lover GPU voltages for projects where buck8 is (ab)used to supply power for GPU. As a note - some setups do allow DVS for buck8. This do produce voltage spikes and the HW must be evaluated to be able to survive them. Thus this commit still keep the DVS disabled for non DVS bucks by default. Let's not help you burn your proto board. Allow describing this external connection from DT and scale the voltages accordingly. This is what the connection should look like: |------------| | buck 8 |-------+----->Vout | | | |------------| | | FB pin | | | +-------+--R2---+ | R1 | V FB-pull-up Here the buck output is sifted according to formula: Vout_o = Vo - (Vpu - Vo)*R2/R1 Linear_step = step_orig*(R1+R2)/R1 where: Vout_o is adjusted voltage output at vsel reg value 0 Vo is original voltage output at vsel reg value 0 Vpu is the pull-up voltage V FB-pull-up in the picture R1 and R2 are resistor values. Bring support for specifying the Vpu, R1 and R2 from device tree and scale voltages if they are given. Signed-off-by: Matti Vaittinen --- drivers/regulator/bd718x7-regulator.c | 164 ++++++++++++++++++++++++-- 1 file changed, 157 insertions(+), 7 deletions(-) diff --git a/drivers/regulator/bd718x7-regulator.c b/drivers/regulator/bd718x7-regulator.c index 0774467994fb..e6d5d98c3cea 100644 --- a/drivers/regulator/bd718x7-regulator.c +++ b/drivers/regulator/bd718x7-regulator.c @@ -1323,13 +1323,142 @@ static void mark_hw_controlled(struct device *dev, struct device_node *np, dev_warn(dev, "Bad regulator node\n"); } -static int get_hw_controlled_regulators(struct device *dev, - struct bd718xx_regulator_data *reg_data, - unsigned int num_reg_data, int *info) +/* + * Setups where regulator (especially the buck8) output voltage is scaled + * by adding external connection where some other regulator output is connected + * to feedback-pin (over suitable resistors) is getting popular amongst users + * of BD71837. (This allows for example scaling down the buck8 voltages to suit + * lover GPU voltages for projects where buck8 is (ab)used to supply power + * for GPU. Additionally some setups do allow DVS for buck8 but as this do + * produce voltage spikes the HW must be evaluated to be able to survive this + * - hence I keep the DVS disabled for non DVS bucks by default. I don't want + * to help you burn your proto board) + * + * So we allow describing this external connection from DT and scale the + * voltages accordingly. This is what the connection should look like: + * + * |------------| + * | buck 8 |-------+----->Vout + * | | | + * |------------| | + * | FB pin | + * | | + * +-------+--R2---+ + * | + * R1 + * | + * V FB-pull-up + * + * Here the buck output is sifted according to formula: + * + * Vout_o = Vo - (Vpu - Vo)*R2/R1 + * Linear_step = step_orig*(R1+R2)/R1 + * + * where: + * Vout_o is adjusted voltage output at vsel reg value 0 + * Vo is original voltage output at vsel reg value 0 + * Vpu is the pull-up voltage V FB-pull-up in the picture + * R1 and R2 are resistor values. + * + * As a real world example for buck8 and a specific GPU: + * VLDO = 1.6V (used as FB-pull-up) + * R1 = 1000ohms + * R2 = 150ohms + * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V + * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV + */ +static int setup_feedback_loop(struct device *dev, struct device_node *np, + struct bd718xx_regulator_data *reg_data, + unsigned int num_reg_data, int fb_uv) { + int i, r1, r2, ret; + + /* + * We do adjust the values in the global desc based on DT settings. + * This may not be best approach as it can cause problems if more than + * one PMIC is controlled from same processor. I don't see such use-case + * for BD718x7 now - so we spare some bits. + * + * If this will point out to be a problem - then we can allocate new + * bd718xx_regulator_data array at probe and just use the global + * array as a template where we copy initial values. Then we can + * use allocated descs for regultor registration and do IC specific + * modifications to this copy while leaving other PMICs untouched. But + * that means allocating new array for each PMIC - and currently I see + * no need for that. + */ + + for (i = 0; i < num_reg_data; i++) { + struct regulator_desc *desc = ®_data[i].desc; + int j; + + if (!of_node_name_eq(np, desc->of_match)) + continue; + + pr_info("Looking at node '%s'\n", desc->of_match); + + /* The feedback loop connection does not make sense for LDOs */ + if (desc->id >= BD718XX_LDO1) + return -EINVAL; + + ret = of_property_read_u32(np, "rohm,feedback-pull-up-r1-ohms", + &r1); + if (ret) + return ret; + + if (!r1) + return -EINVAL; + + ret = of_property_read_u32(np, "rohm,feedback-pull-up-r2-ohms", + &r2); + if (ret) + return ret; + + if (desc->n_linear_ranges && desc->linear_ranges) { + struct linear_range *new; + + new = devm_kzalloc(dev, desc->n_linear_ranges * + sizeof(struct linear_range), + GFP_KERNEL); + if (!new) + return -ENOMEM; + + for (j = 0; j < desc->n_linear_ranges; j++) { + int min = desc->linear_ranges[j].min; + int step = desc->linear_ranges[j].step; + + min -= (fb_uv - min)*r2/r1; + step = step * (r1 + r2); + step /= r1; + + new[j].min = min; + new[j].step = step; + + dev_dbg(dev, "%s: old range min %d, step %d\n", + desc->name, desc->linear_ranges[j].min, + desc->linear_ranges[j].step); + dev_dbg(dev, "new range min %d, step %d\n", min, + step); + } + desc->linear_ranges = new; + } + dev_dbg(dev, "regulator '%s' has FB pull-up configured\n", + desc->name); + + return 0; + } + + return -ENODEV; +} + +static int get_special_regulators(struct device *dev, + struct bd718xx_regulator_data *reg_data, + unsigned int num_reg_data, int *info) +{ + int ret; struct device_node *np; struct device_node *nproot = dev->of_node; - const char *prop = "rohm,no-regulator-enable-control"; + int uv; *info = 0; @@ -1338,13 +1467,32 @@ static int get_hw_controlled_regulators(struct device *dev, dev_err(dev, "failed to find regulators node\n"); return -ENODEV; } - for_each_child_of_node(nproot, np) - if (of_property_read_bool(np, prop)) + for_each_child_of_node(nproot, np) { + if (of_property_read_bool(np, "rohm,no-regulator-enable-control")) mark_hw_controlled(dev, np, reg_data, num_reg_data, info); + ret = of_property_read_u32(np, "rohm,fb-pull-up-microvolt", + &uv); + if (ret) { + if (ret == -EINVAL) + continue; + else + goto err_out; + } + + ret = setup_feedback_loop(dev, np, reg_data, num_reg_data, uv); + if (ret) + goto err_out; + } of_node_put(nproot); return 0; + +err_out: + of_node_put(np); + of_node_put(nproot); + + return ret; } static int bd718xx_probe(struct platform_device *pdev) @@ -1432,8 +1580,10 @@ static int bd718xx_probe(struct platform_device *pdev) * be affected by PMIC state machine - Eg. regulator is likely to stay * on even in SUSPEND */ - get_hw_controlled_regulators(pdev->dev.parent, reg_data, num_reg_data, + err = get_special_regulators(pdev->dev.parent, reg_data, num_reg_data, &omit_enable); + if (err) + return err; for (i = 0; i < num_reg_data; i++) {