From: Mark Brown <broonie@kernel.org>
To: Nisha Kumari <nishakumari@codeaurora.org>
Cc: bjorn.andersson@linaro.org, robh+dt@kernel.org,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
agross@kernel.org, lgirdwood@gmail.com, mark.rutland@arm.com,
david.brown@linaro.org, linux-kernel@vger.kernel.org,
kgunda@codeaurora.org, rnayak@codeaurora.org
Subject: Re: [PATCH 3/4] regulator: Add labibb driver
Date: Thu, 13 Jun 2019 18:25:18 +0100 [thread overview]
Message-ID: <20190613172518.GN5316@sirena.org.uk> (raw)
In-Reply-To: <1560337252-27193-4-git-send-email-nishakumari@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 4484 bytes --]
On Wed, Jun 12, 2019 at 04:30:51PM +0530, Nisha Kumari wrote:
> +static int qcom_labibb_read(struct qcom_labibb *labibb, u16 address,
> + u8 *val, int count)
> +{
> + int ret;
> +
> + ret = regmap_bulk_read(labibb->regmap, address, val, count);
> + if (ret < 0)
> + dev_err(labibb->dev, "spmi read failed ret=%d\n", ret);
> +
> + return ret;
> +}
This (and the write function) are utterly trivial wrappers around the
corresponding regmap functions...
> +static int qcom_labibb_masked_write(struct qcom_labibb *labibb, u16 address,
> + u8 mask, u8 val)
> +{
> + int ret;
> +
> + ret = regmap_update_bits(labibb->regmap, address, mask, val);
> + if (ret < 0)
> + dev_err(labibb->dev, "spmi write failed: ret=%d\n", ret);
> +
> + return ret;
> +}
...as is this but it changes the name for some reason.
> +static int qcom_enable_ibb(struct qcom_labibb *labibb, bool enable)
> +{
> + int ret;
> + u8 val = enable ? IBB_CONTROL_ENABLE : 0;
Please write normal conditional statements, it makes things easier to
read. Though this function is so trivial it seems better to just inline
it into the callers.
> +static int qcom_lab_regulator_enable(struct regulator_dev *rdev)
> +{
> + int ret;
> + u8 val;
> + struct qcom_labibb *labibb = rdev_get_drvdata(rdev);
> +
> + val = LAB_ENABLE_CTL_EN;
> + ret = qcom_labibb_write(labibb,
> + labibb->lab_base + REG_LAB_ENABLE_CTL,
> + &val, 1);
Why not just use regmap_write()? It'd be clearer.
> + labibb->lab_vreg.vreg_enabled = 1;
What function does this serve? It never seems to be read.
> + ret = qcom_labibb_write(labibb,
> + labibb->lab_base + REG_LAB_ENABLE_CTL,
> + &val, 1);
> + if (ret < 0) {
> + dev_err(labibb->dev, "Write register failed ret = %d\n", ret);
> + return ret;
> + }
> + /* after this delay, lab should get disabled */
> + usleep_range(POWER_DELAY, POWER_DELAY + 100);
> +
> + ret = qcom_labibb_read(labibb, labibb->lab_base +
> + REG_LAB_STATUS1, &val, 1);
> + if (ret < 0) {
> + dev_err(labibb->dev, "Read register failed ret = %d\n", ret);
> + return ret;
> + }
I'm not clear that these status checks are actually a good idea, and if
they are it feels like they should be factored out into the framework -
these are just regular enable or disable followed by the usual dead
reckoning delay for completion and then a get_status() call to confirm
if the operation worked. That's not at all driver specific so if it's
useful the core should do it for all regulators with status readback and
if you didn't do it you could use the standard regmap helpers for these
operations.
> +static int qcom_lab_regulator_is_enabled(struct regulator_dev *rdev)
> +{
> + int ret;
> + u8 val;
> + struct qcom_labibb *labibb = rdev_get_drvdata(rdev);
> +
> + ret = qcom_labibb_read(labibb, labibb->lab_base +
> + REG_LAB_STATUS1, &val, 1);
> + if (ret < 0) {
> + dev_err(labibb->dev, "Read register failed ret = %d\n", ret);
> + return ret;
> + }
> +
> + return val & LAB_STATUS1_VREG_OK_BIT;
> +}
Please use the standard helper for this, and this is a get_status()
operation not an is_enabled() - it checks if the regulator is working,
not what status was requested.
> + while (retries--) {
> + /* Wait for a small period before reading IBB_STATUS1 */
> + usleep_range(POWER_DELAY, POWER_DELAY + 100);
> +
> + ret = qcom_labibb_read(labibb, labibb->ibb_base +
> + REG_IBB_STATUS1, &val, 1);
> + if (ret < 0) {
> + dev_err(labibb->dev,
> + "Read register failed ret = %d\n", ret);
> + return ret;
> + }
> +
> + if (val & IBB_STATUS1_VREG_OK_BIT) {
> + labibb->ibb_vreg.vreg_enabled = 1;
> + return 0;
> + }
> + }
This is doing more than the other regulator was but it's not clear why -
is it just that the delays are different for the two regulators?
> +static int register_lab_regulator(struct qcom_labibb *labibb,
> + struct device_node *of_node)
> +{
> + int ret = 0;
> + struct regulator_init_data *init_data;
> + struct regulator_config cfg = {};
> +
> + cfg.dev = labibb->dev;
> + cfg.driver_data = labibb;
> + cfg.of_node = of_node;
> + init_data =
> + of_get_regulator_init_data(labibb->dev,
> + of_node, &lab_desc);
> + if (!init_data) {
> + dev_err(labibb->dev,
> + "unable to get init data for LAB\n");
> + return -ENOMEM;
> + }
The core will parse the DT for you.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-06-13 17:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-12 11:00 [PATCH 0/4] Add labibb regulator support for LCD display mode Nisha Kumari
2019-06-12 11:00 ` [PATCH 1/4] dt-bindings: regulator: Add labibb regulator Nisha Kumari
2019-06-13 16:05 ` Mark Brown
2019-06-13 16:28 ` Bjorn Andersson
2019-06-18 5:52 ` Nisha Kumari
2019-06-12 11:00 ` [PATCH 2/4] arm64: dts: qcom: pmi8998: Add nodes for LAB and IBB regulators Nisha Kumari
2019-06-12 11:00 ` [PATCH 3/4] regulator: Add labibb driver Nisha Kumari
2019-06-13 17:04 ` Bjorn Andersson
2019-06-18 6:13 ` Nisha Kumari
2019-06-13 17:25 ` Mark Brown [this message]
2019-06-18 6:21 ` Nisha Kumari
2019-06-18 10:59 ` Mark Brown
2019-06-12 11:00 ` [PATCH 4/4] regulator: adding interrupt handling in labibb regulator Nisha Kumari
2019-06-13 17:27 ` Mark Brown
2019-06-18 6:23 ` Nisha Kumari
2020-04-28 5:16 ` Sumit Semwal
2020-04-28 11:09 ` Mark Brown
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=20190613172518.GN5316@sirena.org.uk \
--to=broonie@kernel.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=david.brown@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=kgunda@codeaurora.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=nishakumari@codeaurora.org \
--cc=rnayak@codeaurora.org \
--cc=robh+dt@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