Received: by 10.192.165.156 with SMTP id m28csp439620imm; Tue, 17 Apr 2018 12:49:25 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/FtrZUchHfQ/LN8z4WHiuBcihxHamBAjtqjZLbpbDrFmznR3g8y+oZYR2Q/ija/knfsybM X-Received: by 2002:a17:902:aa46:: with SMTP id c6-v6mr3180675plr.154.1523994565784; Tue, 17 Apr 2018 12:49:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523994565; cv=none; d=google.com; s=arc-20160816; b=cD674e2bE4P93NCkAHhT/jp7DKKsjFOLW3pB62Wb96oPdCLmDn3LIZUvjDGxVgH0TA XZnPcr6nyQ1B8WbW+LAhOJmWG4ff29BzF5d7s4d6GDVyechdmdLVRHyZoGmynq2sU9q5 P08H6iCxn3o2511245gimOJRkA/Xlx9cT2MaOelsOmWN+u8L3M401XSYZIFeTIV9gWCC IX5nBmlWzISDFpCYjMeHPvblOki0Tr90nBvy/drbbcrBBV1l4dAfxRnXBdM6/fQhGbB3 EPGQAnJ5JAxXmp2f450L6+IRa0Yne5U25+Lj7wN1qVtXWmtUR0y35HyKIs82Z9IneowU sM3w== 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=KEgpIMBQWfUQxz3UXpm8NCY3GFndxphMyfosTyig3Cw=; b=BJUA11iemfhQvNqe/lrefoQiK9WUbNnwysp33706VRTQlBdL3eK7PbZcRzbqlf6HjQ ifZ3oj+YaaPyFcGAX1/0N1h0aayn4ru5DLhS4rUXFzRUMgLzPjc2f0CZHYP905OJ5Nx3 54p5blX7Xwvpy8L2Er1yKHK5xF7OZcrDD2dZt560fKfCCrwjS+U0PH/cCZnit2EteuvA nOQOrQyFAHHAvc53FxLj52B1XsDBNeLS5xC+Vgc2a+1BpvPQhk3reYm43dX/RJu970Ab h14Y5u7eHpbJu8b0/8WGRH1SgEketKulknaZRqz3FxQFr3JA2CwwYEhh33eBco+tHa5q bZcg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=hinkG+H6; 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 r4si11929975pgt.7.2018.04.17.12.49.11; Tue, 17 Apr 2018 12:49:25 -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=hinkG+H6; 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 S1752087AbeDQTr6 (ORCPT + 99 others); Tue, 17 Apr 2018 15:47:58 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:45947 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751879AbeDQTr4 (ORCPT ); Tue, 17 Apr 2018 15:47:56 -0400 Received: by mail-pg0-f67.google.com with SMTP id z21so2170833pgv.12 for ; Tue, 17 Apr 2018 12:47:56 -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=KEgpIMBQWfUQxz3UXpm8NCY3GFndxphMyfosTyig3Cw=; b=hinkG+H6QjMC6bCPvVGcnset4uHQAJuP3tMIqmM35/H4rsClDdtUu0qAw5m+tlPo5D 2ho4USFs1uW34vifR69O/hxI2xUMPL+e0KBhVk9TbqPoCpAs1tS+EYOMgpbGTcMmrsEB jf3m9N2sYLNmNUvGG9aGHsme+JlrP1wkhq6cs= 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=KEgpIMBQWfUQxz3UXpm8NCY3GFndxphMyfosTyig3Cw=; b=fCGc0iy8PAWcjoWjeIncClb7o1VfASlwXrh/lYtuBgua4j/HNvpmG9erWnxknxfM1n JIe4EaCn4TVhCFlQE3BKKBEl95USrDQHKic82/JeUmn0MdRYh6+DNf5MESMXisAIqtRj 6nAP9gnIGTG8uszvnur9q6NnVNm8Gk7Y7jJU7EImSzQ4ALGHTyRHg9m1QdZOvKEzoWl8 AM5C1+RFTOlEIgXeNL8E/dNY4eYnOXfjas8fS0fulG+it2AXObGFeFvjNKKm4sBrKKgy 9tfi0H30w7KZJiVAinRv/dzjsq4lkorW5hDF58TJ7PaaJjg2jOKwU1Agpd5t5PYUCFXl +UNg== X-Gm-Message-State: ALQs6tABxH3IHXmr3oa+kZRReHBg0Rb4ZzfXVtHiIHb+g23v9YT+979P FRRxSU9ubZgxpB6Aa2NDB6O8Lw== X-Received: by 10.99.114.88 with SMTP id c24mr2851350pgn.453.1523994476235; Tue, 17 Apr 2018 12:47:56 -0700 (PDT) Received: from localhost ([2620:0:1000:1501:8e2d:4727:1211:622]) by smtp.gmail.com with ESMTPSA id m4sm4387553pfk.151.2018.04.17.12.47.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 17 Apr 2018 12:47:55 -0700 (PDT) Date: Tue, 17 Apr 2018 12:47:55 -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: [v2,2/2] regulator: add QCOM RPMh regulator driver Message-ID: <20180417194755.GE244487@google.com> References: <4b45f41996ea3344340e44fab2dc9e487572e209.1523673467.git.collinsd@codeaurora.org> <20180417182347.GD244487@google.com> <2e45c0e5-7e79-3479-de18-9613e8eacf15@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2e45c0e5-7e79-3479-de18-9613e8eacf15@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 On Tue, Apr 17, 2018 at 12:15:18PM -0700, David Collins wrote: > On 04/17/2018 11:23 AM, Matthias Kaehlcke wrote: > > On Fri, Apr 13, 2018 at 07:50:35PM -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. > >> [...] > >> +/** > >> + * struct rpmh_vreg_hw_data - RPMh regulator hardware configurations > >> + * @regulator_type: RPMh accelerator type used to manage this > >> + * regulator > >> + * @ops: Pointer to regulator ops callback structure > >> + * @voltage_range: The single range of voltages supported by this > >> + * PMIC regulator type > >> + * @n_voltages: The number of unique voltage set points defined > >> + * by voltage_range > >> + * @pmic_mode_map: Array indexed by regulator framework mode > >> + * containing PMIC hardware modes. Must be large > >> + * enough to index all framework modes supported > >> + * by this regulator hardware type. > >> + * @of_map_mode: Maps an RPMH_REGULATOR_MODE_* mode value defined > >> + * in device tree to a regulator framework mode > > > > The name of the field is a bit misleading, this is a map of RPMh mode > > to regulator framework mode, the device tree just happens to be the > > place where this mapping is defined. > > of_map_mode name is used here to match the struct regulator_desc field by > the same name that it is assigned to [1]. Do you think that the name > should be changed to something else? Thanks, I missed that it's the name of the field in struct regulator_desc field, in that case it certainly makes sense to use the same name. > >> +/** > >> + * struct rpmh_vreg - individual rpmh regulator data structure encapsulating a > >> + * single regulator device > >> + * @rpmh_client: Handle used for rpmh communications > > > > nit: RPMh > > I'll change this. > > > >> +struct rpmh_vreg { > >> + struct rpmh_client *rpmh_client; > >> + u32 addr; > >> + struct regulator_desc rdesc; > >> + const struct rpmh_vreg_hw_data *hw_data; > >> + enum rpmh_regulator_type regulator_type; > > > > This value is already available via rpmh_vreg->hw_data->regulator_type, > > why duplicate it? The field is assigned in rpmh_regulator_init_vreg() > > and only read once in the same function, there seems to be no need for > > it, not even to improve readability. > > This is present to specifically allow for a future change to support > overriding the regulator_type value from device tree in order to force > RPMh resources to be handled via XOB instead of VRM in a board-specific > manner. I included support of the property qcom,rpmh-resource-type in the > first version of this patch. I removed this property from the second > version of the patch based upon review feedback since SDM845 does not > explicitly need it (though an upcoming chip will). > > I'll remove regulator_type from struct rpmh_vreg. It shouldn't be > particularly painful to add it back in when needed for XOB override support. > > > >> +static int rpmh_regulator_vrm_set_load(struct regulator_dev *rdev, int load_uA) > >> +{ > >> + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev); > >> + int i; > >> + > >> + for (i = 0; i < vreg->drms_mode_count - 1; i++) > >> + if (load_uA < vreg->drms_mode_max_uA[i]) > > > > Shouldn't this be '<='? > > > > nit: IMO 'vreg->drms_mode_max_uA[i] >= load_uA' would be more readable. > > I chose to use '<' here in order to maintain the non-inclusive limit > semantics of the downstream RPMh regulator driver. E.g. with an LPM > threshold of 10000 uA, load_uA == 10000 would result in a request for HPM > instead of LPM. > > I suppose that I can change this to '<=' to be more logically consistent. > > > >> +static const u32 pmic_mode_map_pmic4_ldo[REGULATOR_MODE_STANDBY + 1] = { > >> + [REGULATOR_MODE_STANDBY] = 4, > >> + [REGULATOR_MODE_IDLE] = 5, > >> + [REGULATOR_MODE_NORMAL] = -EINVAL, > >> + [REGULATOR_MODE_FAST] = 7, > >> +}; > > > > Define constants for the modes on the PMIC4 side? > > Are you suggesting something like this? > > #define PMIC4_LDO_MODE_RETENTION 4 > #define PMIC4_LDO_MODE_LPM 5 > #define PMIC4_LDO_MODE_HPM 7 > > static const u32 pmic_mode_map_pmic4_ldo[REGULATOR_MODE_STANDBY + 1] = { > [REGULATOR_MODE_STANDBY] = PMIC4_LDO_MODE_RETENTION, > [REGULATOR_MODE_IDLE] = PMIC4_LDO_MODE_LPM, > [REGULATOR_MODE_NORMAL] = -EINVAL, > [REGULATOR_MODE_FAST] = PMIC4_LDO_MODE_HPM, > }; > > #define PMIC4_SMPS_MODE_RETENTION 4 > #define PMIC4_SMPS_MODE_PFM 5 > #define PMIC4_SMPS_MODE_AUTO 6 > #define PMIC4_SMPS_MODE_PWM 7 > > static const u32 pmic_mode_map_pmic4_smps[REGULATOR_MODE_STANDBY + 1] = { > [REGULATOR_MODE_STANDBY] = PMIC4_SMPS_MODE_RETENTION, > [REGULATOR_MODE_IDLE] = PMIC4_SMPS_MODE_PFM, > [REGULATOR_MODE_NORMAL] = PMIC4_SMPS_MODE_AUTO, > [REGULATOR_MODE_FAST] = PMIC4_SMPS_MODE_PWM, > }; > > I considered using this approach, but it didn't seem like it increased > readability and did increase the line count. Each of the constants would > only be used once. Would you prefer this style (or something else)? Personally I prefer this style, since the constants are more expressive than the literals. I agree that the 'inline' constant definition is a bit noisy, perhaps it would be better to move the definitions to the top of the file or group them before the definition of pmic_mode_map_pmic4_ldo. Alteratively you could create a drivers/regulator/qcom_rpmh-regulator.h and also move the definitions of struct struct rpmh_vreg_hw_data, rpmh_vreg, ... there. Thanks Matthias