From: David Brownell <[email protected]>
Make the <linux/regulator.h> framework treat enable/disable call
pairs like the <linux/clk.h> and <linux/interrupt.h> frameworks do:
they're refcounted, so that different parts of a driver don't need
to put work into coordination that frameworks normally handle.
It's a minor object code shrink.
It also makes the regulator_is_disabled() kerneldoc say what it's
actually returning: return value is not a refcount, and may report
an error (e.g. I/O error from I2C).
It also fixes some minor regulator_put() goofage: removing unlocked
access to the enable state. (But still not making regulator put/get
match the refcounting pattern they invoke.)
Signed-off-by: David Brownell <[email protected]>
---
drivers/regulator/core.c | 71 ++++++++++++++++++++++-----------------------
1 file changed, 36 insertions(+), 35 deletions(-)
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -79,7 +79,7 @@ struct regulator {
int uA_load;
int min_uV;
int max_uV;
- int enabled; /* client has called enabled */
+ int enabled; /* count of client enables */
char *supply_name;
struct device_attribute dev_attr;
struct regulator_dev *rdev;
@@ -933,16 +933,13 @@ void regulator_put(struct regulator *reg
if (regulator == NULL || IS_ERR(regulator))
return;
- if (regulator->enabled) {
- printk(KERN_WARNING "Releasing supply %s while enabled\n",
- regulator->supply_name);
- WARN_ON(regulator->enabled);
- regulator_disable(regulator);
- }
-
mutex_lock(®ulator_list_mutex);
rdev = regulator->rdev;
+ if (WARN(regulator->enabled, "Releasing supply %s while enabled\n",
+ regulator->supply_name))
+ _regulator_disable(rdev);
+
/* remove any sysfs entries */
if (regulator->dev) {
sysfs_remove_link(&rdev->dev.kobj, regulator->supply_name);
@@ -1012,21 +1009,17 @@ static int _regulator_enable(struct regu
*/
int regulator_enable(struct regulator *regulator)
{
- int ret;
-
- if (regulator->enabled) {
- printk(KERN_CRIT "Regulator %s already enabled\n",
- regulator->supply_name);
- WARN_ON(regulator->enabled);
- return 0;
- }
+ struct regulator_dev *rdev = regulator->rdev;
+ int ret = 0;
- mutex_lock(®ulator->rdev->mutex);
- regulator->enabled = 1;
- ret = _regulator_enable(regulator->rdev);
- if (ret != 0)
- regulator->enabled = 0;
- mutex_unlock(®ulator->rdev->mutex);
+ mutex_lock(&rdev->mutex);
+ if (regulator->enabled == 0)
+ ret = _regulator_enable(rdev);
+ else if (regulator->enabled < 0)
+ ret = -EIO;
+ if (ret == 0)
+ regulator->enabled++;
+ mutex_unlock(&rdev->mutex);
return ret;
}
EXPORT_SYMBOL_GPL(regulator_enable);
@@ -1078,19 +1071,21 @@ static int _regulator_disable(struct reg
*/
int regulator_disable(struct regulator *regulator)
{
- int ret;
-
- if (!regulator->enabled) {
- printk(KERN_ERR "%s: not in use by this consumer\n",
- __func__);
- return 0;
- }
+ struct regulator_dev *rdev = regulator->rdev;
+ int ret = 0;
- mutex_lock(®ulator->rdev->mutex);
- regulator->enabled = 0;
- regulator->uA_load = 0;
- ret = _regulator_disable(regulator->rdev);
- mutex_unlock(®ulator->rdev->mutex);
+ mutex_lock(&rdev->mutex);
+ if (regulator->enabled == 1) {
+ ret = _regulator_disable(rdev);
+ if (ret == 0)
+ regulator->uA_load = 0;
+ } else if (WARN(regulator->enabled <= 0,
+ "unbalanced disables for supply %s\n",
+ regulator->supply_name))
+ ret = -EIO;
+ if (ret == 0)
+ regulator->enabled--;
+ mutex_unlock(&rdev->mutex);
return ret;
}
EXPORT_SYMBOL_GPL(regulator_disable);
@@ -1166,7 +1161,13 @@ out:
* regulator_is_enabled - is the regulator output enabled
* @regulator: regulator source
*
- * Returns zero for disabled otherwise return number of enable requests.
+ * Returns positive if the regulator driver backing the source/client
+ * has requested that the device be enabled, zero if it hasn't, else a
+ * negative errno code.
+ *
+ * Note that the device backing this regulator handle can have multiple
+ * users, so it might be enabled even if regulator_enable() was never
+ * called for this particular source.
*/
int regulator_is_enabled(struct regulator *regulator)
{
On Sun, Nov 16, 2008 at 11:44:46AM -0800, David Brownell wrote:
> + mutex_lock(&rdev->mutex);
> + if (regulator->enabled == 1) {
> + ret = _regulator_disable(rdev);
> + if (ret == 0)
> + regulator->uA_load = 0;
Why clear the load here? I'd expect to be able to enable and disable
the regulator while preserving the configuration.
On Monday 17 November 2008, Mark Brown wrote:
> On Sun, Nov 16, 2008 at 11:44:46AM -0800, David Brownell wrote:
>
> > + mutex_lock(&rdev->mutex);
> > + if (regulator->enabled == 1) {
> > + ret = _regulator_disable(rdev);
> > + if (ret == 0)
> > + regulator->uA_load = 0;
>
> Why clear the load here? I'd expect to be able to enable and disable
> the regulator while preserving the configuration.
That clear was in the original code. Didn't make much sense
to me either, but I was just caring it forward...
On Mon, 2008-11-17 at 08:21 -0800, David Brownell wrote:
> On Monday 17 November 2008, Mark Brown wrote:
> > On Sun, Nov 16, 2008 at 11:44:46AM -0800, David Brownell wrote:
> >
> > > + mutex_lock(&rdev->mutex);
> > > + if (regulator->enabled == 1) {
> > > + ret = _regulator_disable(rdev);
> > > + if (ret == 0)
> > > + regulator->uA_load = 0;
> >
> > Why clear the load here? I'd expect to be able to enable and disable
> > the regulator while preserving the configuration.
>
> That clear was in the original code. Didn't make much sense
> to me either, but I was just caring it forward...
>
Hmm, this looks like a bug - I'll fix in a subsequent patch.
Will have time to look over the rest later tonight.
Thanks
Liam
On Sun, 2008-11-16 at 11:44 -0800, David Brownell wrote:
> From: David Brownell <[email protected]>
Both -rc5 patches applied.
Thanks
Liam
On Wednesday 19 November 2008, Liam Girdwood wrote:
> Both -rc5 patches applied.
How about the other two which seemed non-controversial?
http://marc.info/?l=linux-kernel&m=122645403604873&w=2 (code shrink)
http://marc.info/?l=linux-kernel&m=122645416305013&w=2 (attribute shrink)
Those were sent against RC4.
- Dave
On Wed, 2008-11-19 at 14:12 -0800, David Brownell wrote:
> On Wednesday 19 November 2008, Liam Girdwood wrote:
> > Both -rc5 patches applied.
>
> How about the other two which seemed non-controversial?
>
> http://marc.info/?l=linux-kernel&m=122645403604873&w=2 (code shrink)
> http://marc.info/?l=linux-kernel&m=122645416305013&w=2 (attribute shrink)
>
> Those were sent against RC4.
Both applied.
Thanks
Liam
On Thursday 20 November 2008, Liam Girdwood wrote:
> On Wed, 2008-11-19 at 14:12 -0800, David Brownell wrote:
> > On Wednesday 19 November 2008, Liam Girdwood wrote:
> > > Both -rc5 patches applied.
> >
> > How about the other two which seemed non-controversial?
> >
> > http://marc.info/?l=linux-kernel&m=122645403604873&w=2 (code shrink)
> > http://marc.info/?l=linux-kernel&m=122645416305013&w=2 (attribute shrink)
> >
> > Those were sent against RC4.
>
> Both applied.
Great! Now, I think I have some comments from Mark to respond to ...
He seems to be saying a new regulator_ops method is needed.
- Dave