From: David Collins <collinsd@codeaurora.org>
To: Mark Brown <broonie@kernel.org>
Cc: 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, mka@chromium.org
Subject: Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver
Date: Mon, 9 Jul 2018 16:44:14 -0700 [thread overview]
Message-ID: <9bbfb628-018d-2d89-257b-9cc4e716cb46@codeaurora.org> (raw)
In-Reply-To: <20180702102853.GI18211@sirena.org.uk>
Hello Mark,
On 07/02/2018 03:28 AM, Mark Brown wrote:
> On Fri, Jun 22, 2018 at 05:46:14PM -0700, David Collins wrote:
>
>> --- /dev/null
>> +++ b/drivers/regulator/qcom-rpmh-regulator.c
>> @@ -0,0 +1,746 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Copyright (c) 2018, The Linux Foundation. All rights reserved. */
>> +
>
> Please make the entire header block C++ so it looks intentional.
Sure, I'll change this.
I was trying to follow the guideline that kernel C source files should use
C style comments while at the same time following the SPDX guideline that
C++ style comments are needed for the SPDX line in C source files [1].
>> + cmd.data = bypassed ? PMIC4_BOB_MODE_PASS : pmic_mode;
>
> Please just write normal if statements, the ternery operator isn't
> really helping legibility.
I'll change this.
>> +static const int pmic_mode_map_pmic4_ldo[REGULATOR_MODE_STANDBY + 1] = {
>> + [REGULATOR_MODE_INVALID] = -EINVAL,
>> + [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,
>> +};
>
> This mapping is really weird, I'd expect one of the modes to correspond
> to the normal operating mode of the regulator.
My thinking here was to have a consistent mapping for consumers to use
between REGULATOR_MODE_* and physical regulator modes for both LDO and
SMPS type regulators:
REGULATOR_MODE_STANDBY --> Retention (if supported)
REGULATOR_MODE_IDLE --> Low power mode (if supported)
LPM for LDO and PFM for SMPS
REGULATOR_MODE_NORMAL --> Auto HW switching between low and high power
mode (if supported)
REGULATOR_MODE_FAST --> High power mode
HPM for LDO and PWM for SMPS
This allows a consumer to request NORMAL in typical use cases and FAST in
use cases that require low voltage ripple. If NORMAL is not supported,
then it automatically gets upgraded to FAST by the regulator framework.
I could change it so that REGULATOR_MODE_NORMAL maps to LDO HPM mode.
However, doing so would make it so that REGULATOR_MODE_FAST requests would
fail for LDOs. Thus, consumers would need to know if their supply is an
LDO or an SMPS (which seems undesirable).
Would it be acceptable to have both NORMAL and FAST map to LDO HPM?
>> +static unsigned int rpmh_regulator_pmic4_ldo_of_map_mode(unsigned int mode)
>> +{
>> + static const unsigned int of_mode_map[RPMH_REGULATOR_MODE_COUNT] = {
>> + [RPMH_REGULATOR_MODE_RET] = REGULATOR_MODE_STANDBY,
>> + [RPMH_REGULATOR_MODE_LPM] = REGULATOR_MODE_IDLE,
>> + [RPMH_REGULATOR_MODE_AUTO] = REGULATOR_MODE_INVALID,
>> + [RPMH_REGULATOR_MODE_HPM] = REGULATOR_MODE_FAST,
>> + };
>
> Same here, based on that it looks like auto mode is a good map for
> normal.
LDO type regulators physically do not support AUTO mode. That is why I
specified REGULATOR_MODE_INVALID in the mapping.
>> + if (mode >= RPMH_REGULATOR_MODE_COUNT)
>> + return -EINVAL;
>
> Why not use ARRAY_SIZE?
I'll change this.
Thanks,
David
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst?h=v4.18-rc4#n74
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2018-07-09 23:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-23 0:46 [PATCH v8 0/2] regulator: add QCOM RPMh regulator driver David Collins
2018-06-23 0:46 ` [PATCH v8 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings David Collins
2018-06-23 0:46 ` [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver David Collins
2018-06-25 18:50 ` Doug Anderson
2018-06-26 12:07 ` Mark Brown
2018-06-26 15:00 ` Doug Anderson
2018-06-26 15:02 ` Mark Brown
2018-06-26 18:15 ` Doug Anderson
2018-06-27 15:01 ` Mark Brown
2018-06-27 16:28 ` Doug Anderson
2018-06-28 10:18 ` Mark Brown
2018-06-28 18:04 ` David Collins
2018-06-29 11:06 ` Mark Brown
2018-07-02 10:28 ` Mark Brown
2018-07-09 23:44 ` David Collins [this message]
2018-07-12 16:54 ` Mark Brown
2018-07-13 1:34 ` David Collins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9bbfb628-018d-2d89-257b-9cc4e716cb46@codeaurora.org \
--to=collinsd@codeaurora.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mka@chromium.org \
--cc=rnayak@codeaurora.org \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).