From: Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
To: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: lrg-l0cyMroinI0@public.gmane.org,
jedu-kDsPt+C1G03kYMGBc/C6ZA@public.gmane.org,
sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
gg-kDsPt+C1G03kYMGBc/C6ZA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH V3] regulator: tps65910: Sleep control through external inputs
Date: Fri, 27 Jan 2012 17:07:58 +0000 [thread overview]
Message-ID: <20120127170757.GD18572@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1327506510-15948-1-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
On Wed, Jan 25, 2012 at 09:18:30PM +0530, Laxman Dewangan wrote:
> +static int tps65910_set_suspend_enable(struct regulator_dev *dev)
> +{
> + struct tps65910_reg *pmic = rdev_get_drvdata(dev);
> + int id = rdev_get_id(dev);
> + /*
> + * If regulator is controlled through external control then
> + * it can be enable/disable by toggling external signal.
> + */
> + if (pmic->board_ext_control[id])
> + return 0;
> + else
> + return tps65910_set_mode(dev, REGULATOR_MODE_NORMAL);
> +}
I'm really confuseed now. This definitely looks like it's doing the
wrong thing for the non-ext_control case, it's setting the mode which
really isn't what this is supposed to do and collides with any actual
configuration of the mode that might happen...
> + /*
> + * Keep the regulator in OFF state if it needs to be disable
> + * in suspend state.
> + */
> + if (pmic->board_ext_control[id]) {
> + u8 regoffs = (pmic->ext_sleep_control[id] >> 8) & 0xFF;
> + u8 bit_pos = (1 << pmic->ext_sleep_control[id] & 0xFF);
> + int ret;
> + ret = tps65910_clear_bits(mfd,
> + TPS65910_SLEEP_KEEP_LDO_ON + regoffs, bit_pos);
> + if (!ret)
> + ret = tps65910_set_bits(mfd,
> + TPS65910_SLEEP_SET_LDO_OFF + regoffs, bit_pos);
> + if (ret < 0)
> + dev_err(mfd->dev,
> + "Error in configuring SLEEP register\n");
...and I'd really expect something that reverses these changes?
The actual bits setting up the ext_control look OK - can you split those
off from the bits implementing the suspend mode callbacks please so they
can be applied while the callbacks are reviewed?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Laxman Dewangan <ldewangan@nvidia.com>
Cc: lrg@ti.com, jedu@slimlogic.co.uk, sameo@linux.intel.com,
gg@slimlogic.co.uk, linux-kernel@vger.kernel.org,
linux-tegra@vger.kernel.org
Subject: Re: [PATCH V3] regulator: tps65910: Sleep control through external inputs
Date: Fri, 27 Jan 2012 17:07:58 +0000 [thread overview]
Message-ID: <20120127170757.GD18572@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1327506510-15948-1-git-send-email-ldewangan@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
On Wed, Jan 25, 2012 at 09:18:30PM +0530, Laxman Dewangan wrote:
> +static int tps65910_set_suspend_enable(struct regulator_dev *dev)
> +{
> + struct tps65910_reg *pmic = rdev_get_drvdata(dev);
> + int id = rdev_get_id(dev);
> + /*
> + * If regulator is controlled through external control then
> + * it can be enable/disable by toggling external signal.
> + */
> + if (pmic->board_ext_control[id])
> + return 0;
> + else
> + return tps65910_set_mode(dev, REGULATOR_MODE_NORMAL);
> +}
I'm really confuseed now. This definitely looks like it's doing the
wrong thing for the non-ext_control case, it's setting the mode which
really isn't what this is supposed to do and collides with any actual
configuration of the mode that might happen...
> + /*
> + * Keep the regulator in OFF state if it needs to be disable
> + * in suspend state.
> + */
> + if (pmic->board_ext_control[id]) {
> + u8 regoffs = (pmic->ext_sleep_control[id] >> 8) & 0xFF;
> + u8 bit_pos = (1 << pmic->ext_sleep_control[id] & 0xFF);
> + int ret;
> + ret = tps65910_clear_bits(mfd,
> + TPS65910_SLEEP_KEEP_LDO_ON + regoffs, bit_pos);
> + if (!ret)
> + ret = tps65910_set_bits(mfd,
> + TPS65910_SLEEP_SET_LDO_OFF + regoffs, bit_pos);
> + if (ret < 0)
> + dev_err(mfd->dev,
> + "Error in configuring SLEEP register\n");
...and I'd really expect something that reverses these changes?
The actual bits setting up the ext_control look OK - can you split those
off from the bits implementing the suspend mode callbacks please so they
can be applied while the callbacks are reviewed?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-01-27 17:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-25 15:48 [PATCH V3] regulator: tps65910: Sleep control through external inputs Laxman Dewangan
[not found] ` <1327506510-15948-1-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-01-27 17:07 ` Mark Brown [this message]
2012-01-27 17:07 ` Mark Brown
2012-01-28 9:36 ` Laxman Dewangan
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=20120127170757.GD18572@opensource.wolfsonmicro.com \
--to=broonie-yzvpicuk2aatku/dhu1wvuem+bqzidxxqq4iyu8u01e@public.gmane.org \
--cc=gg-kDsPt+C1G03kYMGBc/C6ZA@public.gmane.org \
--cc=jedu-kDsPt+C1G03kYMGBc/C6ZA@public.gmane.org \
--cc=ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lrg-l0cyMroinI0@public.gmane.org \
--cc=sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.