Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp234023imm; Thu, 7 Jun 2018 17:29:36 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJU43X6LPuw6Fq6wy7LXMrr9yrGSUfDQxKcoB+zHL15UbWTmxp727bYoDeGKsW/3Wii/Kt9 X-Received: by 2002:a62:c8a:: with SMTP id 10-v6mr3713817pfm.27.1528417776042; Thu, 07 Jun 2018 17:29:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528417776; cv=none; d=google.com; s=arc-20160816; b=hJNdNy0HGb4u8DEbRcmKPiznE5p5N5RDtcgCnyYWpZbTVnEB0fBAlS5mld+n5fUGtQ j7TnX4OmkHjZ4Jkl2T3meQoiR3ZNiOk84HDx0I1X87dt7zJUQ+BFWZE77C3m64eq1R3D LlUJda0xJaXTuISxKAxSEPpMoStqAp6fKthvZ3w15o5ZqdzG01z43fmQAgIYxcsrbkfc S5SnjjVb+nmiKZDmCnvyi78Rj4G+nYt1HOdg4XwQaJ7hH1AjYpWnjzMFMj7N3mz8iOG6 y5TrXVHmnlCNlEobSPB8VlTA/5/8FrvRcPb8ScLHU0g/AmG0iKoiEKgqfZf2JrXXs56y 8Pmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=Lo7SKYbXqDmC1YEQCtWu9lkwtVcj6UT77iWGOUeGKTc=; b=hPqN4m/CWWtZO1X7803wquyAhsLiMV9Iu1JN910h65VLpYQ9gGiy0Wc2DjUfEq4JW5 9gMa7jLM5miTqQXcCJ5yA6aMp8L6M/aT9kVPMGzyxgfJo5vxihrYPYeY6rGt8ZmT1ZRd /8YGRlhCGErFFK4x3JhIT6Vs7EQTh1QT8bvwd1jxpxXIWtgVt1An8UcWzN1/ZjMgslvY yI12yruqIoPYkqcpC4SUmr0ssW9/G50x2sa4W5S6U3x7dK1z1b6chZpleIi9CfkEhgDf PP/ZyUf8qJ1q5UGKHeaPFl9nzn9K0mUKGnOFzgmjuACj++jTqr1VEdPOz/2FmnFW6JjK p0Uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=dDk3CvEN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l65-v6si23263488pge.46.2018.06.07.17.29.21; Thu, 07 Jun 2018 17:29:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=dDk3CvEN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752662AbeFHA05 (ORCPT + 99 others); Thu, 7 Jun 2018 20:26:57 -0400 Received: from mail-pl0-f67.google.com ([209.85.160.67]:35034 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752626AbeFHA0z (ORCPT ); Thu, 7 Jun 2018 20:26:55 -0400 Received: by mail-pl0-f67.google.com with SMTP id i5-v6so7164575plt.2 for ; Thu, 07 Jun 2018 17:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Lo7SKYbXqDmC1YEQCtWu9lkwtVcj6UT77iWGOUeGKTc=; b=dDk3CvENrNIBuW4K19sIdt0tqj9a0un5XwKXE10YpKZtGS8jBmnXUATHWaUIOXuosY jdqnq8rFEyUPvxBIYdMUoDkJu3uLyUQxnLl9Fz94TJ2AU+ZfsI6TYW4Y0mbEFjlib2My 8Msn1vi1UdqRWMI5x346YONguvHGCjLPv2XiA= 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:user-agent; bh=Lo7SKYbXqDmC1YEQCtWu9lkwtVcj6UT77iWGOUeGKTc=; b=DWSWlUgzTSZm7tuRCYcToP8tbxaZyUb0RUJWm6gMfSk3Yqq7HxTNOS8V/lmdHV+siX aDI6QmaS+gTWa2oIv5soFVN8xHmeppjSR8YLHNbIlMeAHoLAIDDA7uUl/7wp/UVGHSM7 yb43OKA4ydq6YgF8Ig5zFp+wtUloU8okZRhqMQ1cID4a+IOxlrfiAVO+xKgbSKx8ZNOQ L9ZHxzeOgf5AzVckahDEfA1Ed7V4j1/q43IpiR1HyuSvHzSVGd/V9HEVs4WcQK+MrH5Y uiN8V4E6fpuzvQOkN/D1hF+mXMUBCzqP+4nkBlXijQ7j7BP+J/R1gOhyyMaRU5a7VclZ 0qQA== X-Gm-Message-State: APt69E2+wh6CWMTuQP+pUY17FRyYCqtZ3guzvSlJSHxCpU3HeArwqdqb SoUs9ixfbACdgWwHDapcs2Uv/A== X-Received: by 2002:a17:902:e00a:: with SMTP id ca10-v6mr4072956plb.224.1528417614577; Thu, 07 Jun 2018 17:26:54 -0700 (PDT) Received: from localhost ([2620:0:1000:1501:8e2d:4727:1211:622]) by smtp.gmail.com with ESMTPSA id s28-v6sm62464744pfg.89.2018.06.07.17.26.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 07 Jun 2018 17:26:53 -0700 (PDT) Date: Thu, 7 Jun 2018 17:26:53 -0700 From: Matthias Kaehlcke To: David Collins Cc: broonie@kernel.org, lgirdwood@gmail.com, robh+dt@kernel.org, mark.rutland@arm.com, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, rnayak@codeaurora.org, sboyd@kernel.org, dianders@chromium.org Subject: Re: [PATCH v6 2/2] regulator: add QCOM RPMh regulator driver Message-ID: <20180608002653.GD88063@google.com> References: <6d7abf248493cf81d62eb17ecb5030783aa85f72.1528138319.git.collinsd@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6d7abf248493cf81d62eb17ecb5030783aa85f72.1528138319.git.collinsd@codeaurora.org> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, On Mon, Jun 04, 2018 at 12:15:12PM -0700, David Collins wrote: > Add the QCOM RPMh regulator driver to manage PMIC regulators > which are controlled via RPMh on some Qualcomm Technologies, Inc. > SoCs. RPMh is a hardware block which contains several > accelerators which are used to manage various hardware resources > that are shared between the processors of the SoC. The final > hardware state of a regulator is determined within RPMh by > performing max aggregation of the requests made by all of the > processors. > > Add support for PMIC regulator control via the voltage regulator > manager (VRM) and oscillator buffer (XOB) RPMh accelerators. > VRM supports manipulation of enable state, voltage, and mode. > XOB supports manipulation of enable state. > > Signed-off-by: David Collins > --- > drivers/regulator/Kconfig | 9 + > drivers/regulator/Makefile | 1 + > drivers/regulator/qcom-rpmh-regulator.c | 767 ++++++++++++++++++++++++++++++++ > 3 files changed, 777 insertions(+) > create mode 100644 drivers/regulator/qcom-rpmh-regulator.c > > ... > > diff --git a/drivers/regulator/qcom-rpmh-regulator.c b/drivers/regulator/qcom-rpmh-regulator.c > new file mode 100644 > index 0000000..a7fffb6 > --- /dev/null > +++ b/drivers/regulator/qcom-rpmh-regulator.c > > ... > static int rpmh_regulator_send_request(struct rpmh_vreg *vreg, > + struct tcs_cmd *cmd, int count, bool wait_for_ack) > nit: as of now this is only called with a single command. If you anticipate that this is unlikely to change consider removing 'count', not having it in the calls slightly improves readability. > ... > +static int _rpmh_regulator_vrm_set_voltage_sel(struct regulator_dev *rdev, > + unsigned int selector, bool wait_for_ack) > +{ > + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev); > + struct tcs_cmd cmd = { > + .addr = vreg->addr + RPMH_REGULATOR_REG_VRM_VOLTAGE, > + }; > + int ret; > + > + /* VRM voltage control register is set with voltage in millivolts. */ > + cmd.data = DIV_ROUND_UP(regulator_list_voltage_linear_range(rdev, > + selector), 1000); > + > + ret = rpmh_regulator_send_request(vreg, &cmd, 1, wait_for_ack); > + if (!ret) > + vreg->voltage_selector = selector; > + > + return 0; Shouldn't this return 'ret'? > +static int rpmh_regulator_enable(struct regulator_dev *rdev) > +{ > + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev); > + struct tcs_cmd cmd = { > + .addr = vreg->addr + RPMH_REGULATOR_REG_ENABLE, > + .data = 1, > + }; > + int ret; > + > + if (vreg->enabled == -EINVAL && > + vreg->voltage_selector != -ENOTRECOVERABLE) { > + ret = _rpmh_regulator_vrm_set_voltage_sel(rdev, > + vreg->voltage_selector, true); > + if (ret < 0) > + return ret; > + } > + > + ret = rpmh_regulator_send_request(vreg, &cmd, 1, true); > + if (!ret) > + vreg->enabled = true; > + > + return ret; > +} > + > +static int rpmh_regulator_disable(struct regulator_dev *rdev) > +{ > + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev); > + struct tcs_cmd cmd = { > + .addr = vreg->addr + RPMH_REGULATOR_REG_ENABLE, > + .data = 0, > + }; > + int ret; > + > + if (vreg->enabled == -EINVAL && > + vreg->voltage_selector != -ENOTRECOVERABLE) { > + ret = _rpmh_regulator_vrm_set_voltage_sel(rdev, > + vreg->voltage_selector, true); > + if (ret < 0) > + return ret; > + } > + > + ret = rpmh_regulator_send_request(vreg, &cmd, 1, false); > + if (!ret) > + vreg->enabled = false; > + > + return ret; > +} nit: rpmh_regulator_enable() and rpmh_regulator_disable() are essentially the same code, consider introducing a helper like _rpmh_regulator_enable(struct regulator_dev *rdev, bool enable). > +/** > + * rpmh_regulator_init_vreg() - initialize all attributes of an rpmh-regulator > + * vreg: Pointer to the individual rpmh-regulator resource > + * dev: Pointer to the top level rpmh-regulator PMIC device > + * node: Pointer to the individual rpmh-regulator resource > + * device node > + * pmic_id: String used to identify the top level rpmh-regulator > + * PMIC device on the board > + * rpmh_data: Pointer to a null-terminated array of rpmh-regulator > + * resources defined for the top level PMIC device > + * > + * Return: 0 on success, errno on failure > + */ > +static int rpmh_regulator_init_vreg(struct rpmh_vreg *vreg, struct device *dev, > + struct device_node *node, const char *pmic_id, > + const struct rpmh_vreg_init_data *rpmh_data) > +{ > + struct regulator_config reg_config = {}; > + char rpmh_resource_name[20] = ""; > + struct regulator_dev *rdev; > + struct regulator_init_data *init_data; > + int ret; > + > + vreg->dev = dev; > + > + for (; rpmh_data->name; rpmh_data++) > + if (!strcmp(rpmh_data->name, node->name)) > + break; nit: it's a bit odd to use the parameter itself for iteration, but I guess it's a matter of preferences. Thanks Matthias