[patch 2.6.29-rc7 regulator-next] regulator: init fixes

From: David Brownell
Date: Wed Mar 11 2009 - 22:32:29 EST


From: David Brownell <dbrownell@xxxxxxxxxxxxxxxxxxxxx>

Make the regulator setup code cope more consistently with
regulators undesirably left enabled by the bootloader.

Building on the previous refcount patch:

* Unless the "boot_on" or "always_on" machine constraints
were set, disable() the regulator. This gives drivers
a clean start state: enable state matches usecount,
regardless of boot_on/always_on flag state.

* To help make some integration stages easier, add a new
"devmode" machine constraint where state the bootloader
left isn't touched, but enable state and usecount may
not match. (System boots but some drivers act odd ...
debuggable. System dies part way through booting ...
often painful.)

Consider a bootloader that leaves an MMC/SD regulator active
when it loads Linux from an SD card. It may take some time
before the MMC/SD driver gets loaded, if ever ... to save
power, that (LDO) regulator should be disabled ASAP. Then
later when the MMC driver starts up, the Linux MMC stack will
need to start from a "power off" state. It can't just

if (regulator_is_enabled(r))
regulator_disable(r);

unless enable state and usecount are matched ... but without
this patch, they *will* be mismatched whenever the bootloader
happens to have left that regulator active! Similar issues
can crop up with almost any regulator.

Signed-off-by: David Brownell <dbrownell@xxxxxxxxxxxxxxxxxxxxx>
---
drivers/regulator/core.c | 47 +++++++++++++++++++++++++++++-------
include/linux/regulator/machine.h | 3 +-
2 files changed, 40 insertions(+), 10 deletions(-)

--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -799,18 +799,47 @@ static int set_machine_constraints(struc
}
}

- /* If the constraints say the regulator should be on at this point
- * and we have control then make sure it is enabled.
+ /* During integration, developers may need time to sort out what
+ * to do with this regulator; leave the bootloader's setting alone.
+ * Regulator consumers won't get consistent behavior.
+ *
+ * Else the constraints say whether it should be on or off; we
+ * don't leave it in an unknown state.
*/
- if ((constraints->always_on || constraints->boot_on) && ops->enable) {
- ret = ops->enable(rdev);
- if (ret < 0) {
- printk(KERN_ERR "%s: failed to enable %s\n",
- __func__, name);
- rdev->constraints = NULL;
- goto out;
+ if (constraints->devmode) {
+ char *label = "unknown";
+
+ if (ops->is_enabled) {
+ ret = ops->is_enabled(rdev);
+ if (ret == 0)
+ label = "disabled";
+ else if (ret > 0)
+ label = "enabled";
+ ret = 0;
+ }
+ pr_warning("%s: devmode regulator '%s' state is '%s'\n",
+ __func__, name, label);
+ } else if (constraints->always_on || constraints->boot_on) {
+ if (ops->enable) {
+ ret = ops->enable(rdev);
+ if (ret < 0) {
+ pr_err("%s: failed enabling %s\n",
+ __func__, name);
+ rdev->constraints = NULL;
+ goto out;
+ }
}
rdev->use_count = 1;
+ } else {
+ if (ops->disable) {
+ ret = ops->disable(rdev);
+ if (ret < 0) {
+ pr_err("%s: failed disabling %s\n",
+ __func__, name);
+ rdev->constraints = NULL;
+ goto out;
+ }
+ }
}

print_constraints(rdev);
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -117,7 +117,8 @@ struct regulation_constraints {
/* mode to set on startup */
unsigned int initial_mode;

- /* constriant flags */
+ /* constraint flags */
+ unsigned devmode:1; /* state after setup is indeterminate */
unsigned always_on:1; /* regulator never off when system is on */
unsigned boot_on:1; /* bootloader/firmware enabled regulator */
unsigned apply_uV:1; /* apply uV constraint iff min == max */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/