From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Tero Kristo <t-kristo@ti.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Liam Girdwood <lrg@ti.com>, Samuel Ortiz <sameo@linux.intel.com>,
Kevin Hilman <khilman@ti.com>
Subject: Re: [PATCH] regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators
Date: Fri, 24 Feb 2012 14:01:10 +0000 [thread overview]
Message-ID: <20120224140109.GG5450@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1330091765.4102.547.camel@sokoban>
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
On Fri, Feb 24, 2012 at 03:56:05PM +0200, Tero Kristo wrote:
> So, do you want me to also change the num_voltages value for the
> regulator from zero to be the same as max_uV, as we have this check
> within regulator/core:
> if (!ops->list_voltage || selector >= rdev->desc->n_voltages)
> return -EINVAL;
> This will also potentially make some code to iterate over regulator
> voltages for ~1.5M times. I still don't think adding list_voltage for
> the SMPS regulators makes any sense, unless either the API for
> regulator_list_voltage is changed, or we change the control for these
> regulators completely from set_voltage() based to set_voltage_sel()
> based implementation.
Well, the important thing here is to fill in something useful for the
returned selector rather than just leaving it undefined. Providing a
list_voltage() would be nice and make things more robust.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators
Date: Fri, 24 Feb 2012 14:01:10 +0000 [thread overview]
Message-ID: <20120224140109.GG5450@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1330091765.4102.547.camel@sokoban>
On Fri, Feb 24, 2012 at 03:56:05PM +0200, Tero Kristo wrote:
> So, do you want me to also change the num_voltages value for the
> regulator from zero to be the same as max_uV, as we have this check
> within regulator/core:
> if (!ops->list_voltage || selector >= rdev->desc->n_voltages)
> return -EINVAL;
> This will also potentially make some code to iterate over regulator
> voltages for ~1.5M times. I still don't think adding list_voltage for
> the SMPS regulators makes any sense, unless either the API for
> regulator_list_voltage is changed, or we change the control for these
> regulators completely from set_voltage() based to set_voltage_sel()
> based implementation.
Well, the important thing here is to fill in something useful for the
returned selector rather than just leaving it undefined. Providing a
list_voltage() would be nice and make things more robust.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120224/61da7e25/attachment.sig>
next prev parent reply other threads:[~2012-02-24 14:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-23 11:05 [PATCH] regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators Tero Kristo
2012-02-23 11:05 ` Tero Kristo
2012-02-23 15:34 ` Mark Brown
2012-02-23 15:34 ` Mark Brown
2012-02-24 9:38 ` Tero Kristo
2012-02-24 9:38 ` Tero Kristo
2012-02-24 11:49 ` Mark Brown
2012-02-24 11:49 ` Mark Brown
2012-02-24 13:16 ` Tero Kristo
2012-02-24 13:16 ` Tero Kristo
2012-02-24 13:24 ` Mark Brown
2012-02-24 13:24 ` Mark Brown
2012-02-24 13:56 ` Tero Kristo
2012-02-24 13:56 ` Tero Kristo
2012-02-24 14:01 ` Mark Brown [this message]
2012-02-24 14:01 ` Mark Brown
2012-02-24 14:25 ` Tero Kristo
2012-02-24 14:25 ` Tero Kristo
2012-02-24 14:34 ` Mark Brown
2012-02-24 14:34 ` Mark Brown
2012-02-24 14:42 ` Tero Kristo
2012-02-24 14:42 ` Tero Kristo
2012-02-24 14:50 ` Mark Brown
2012-02-24 14:50 ` Mark Brown
2012-02-24 15:04 ` Tero Kristo
2012-02-24 15:04 ` Tero Kristo
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=20120224140109.GG5450@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=lrg@ti.com \
--cc=sameo@linux.intel.com \
--cc=t-kristo@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.