From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: "Kim, Milo" <Milo.Kim@ti.com>
Cc: Axel Lin <axel.lin@ingics.com>, "Girdwood, Liam" <lrg@ti.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/4] regulator-core: manage enable GPIO list
Date: Sun, 27 Jan 2013 14:06:36 +0800 [thread overview]
Message-ID: <20130127060532.GB8952@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <A874F61F95741C4A9BA573A70FE3998F69E12B35@DQHE02.ent.ti.com>
[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]
On Tue, Jan 15, 2013 at 04:35:46AM +0000, Kim, Milo wrote:
> +/**
> + * Balance enable_count of each GPIO and actual GPIO pin control.
> + * GPIO is enabled in case of initial use. (enable_count is 0)
> + * GPIO is disabled when it is not shared any more. (enable_count is 1)
> + */
> +static void _do_ena_gpio_ctrl(struct regulator_enable_gpio *pin,
> + struct regulator_dev *rdev, bool enable)
> +{
> + if (enable) {
> + /* Enable GPIO at initial use */
> + if (pin->enable_count == 0)
> + gpio_set_value_cansleep(rdev->ena_gpio,
> + !rdev->ena_gpio_invert);
> +
> + rdev->ena_gpio_state = 1;
ena_gpio_state is redundant with this patch, we can just replace
references to it with pin->enable_count.
We'll also need a request count to keep track of how many regulators are
using the GPIO for use in cleanup.
> + } else {
> + rdev->ena_gpio_state = 0;
> + if (pin->enable_count > 1) {
> + pin->enable_count--;
> + return;
> + }
> +
> + /* Disable GPIO if not used */
> + if (pin->enable_count == 1) {
> + gpio_set_value_cansleep(rdev->ena_gpio,
> + rdev->ena_gpio_invert);
> + pin->enable_count = 0;
> + }
Ideally we should also check if we're trying to take the enable count
below zero and complain about that.
> +static void regulator_ena_gpio_ctrl(struct regulator_dev *rdev, bool enable)
> +{
> + struct regulator_enable_gpio *pin;
> +
> + list_for_each_entry(pin, ®ulator_ena_gpio_list, list) {
> + if (pin->gpio == rdev->ena_gpio) {
> + _do_ena_gpio_ctrl(pin, rdev, enable);
> + return;
> + }
> + }
> +}
This should return an error code as the users return errors, the GPIO
API won't give us errors but we can generate them internally. It'd be
better to just add a pointer to the GPIO struct to the regulator_dev (in
place of the GPIO) so we don't need to scan through the list every time
we look for the GPIO.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2013-01-27 6:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-15 4:35 [PATCH v2 2/4] regulator-core: manage enable GPIO list Kim, Milo
2013-01-27 6:06 ` Mark Brown [this message]
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=20130127060532.GB8952@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=Milo.Kim@ti.com \
--cc=axel.lin@ingics.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.com \
/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.