| Message ID | 1355129761-8088-3-git-send-email-lee.jones@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Dec 10, 2012 at 08:55:51AM +0000, Lee Jones wrote: > If a regulator is specified as always-on, then it can't have an > enable/disable pin, as it can't be turned off. Sometimes always on gets set for regulators which do have a physical control wired up - the control might exist for use in suspend mode for example. Is the ability to specify an enable pin causing a practical problem for systems? If it is we should fix that.
On Mon, 10 Dec 2012, Mark Brown wrote: > On Mon, Dec 10, 2012 at 08:55:51AM +0000, Lee Jones wrote: > > If a regulator is specified as always-on, then it can't have an > > enable/disable pin, as it can't be turned off. > > Sometimes always on gets set for regulators which do have a physical > control wired up - the control might exist for use in suspend mode for > example. Is the ability to specify an enable pin causing a practical > problem for systems? If it is we should fix that. I'm not sure I understand. My logic is that there is no point in requesting a pin which can disable a regulator that can't be disabled. Then we can follow on from that logic and say that if a regulator is _not_ always on this we _require_ a way to disable it, thus we insist on an enable GPIO pin. With me?
On Thu, Dec 13, 2012 at 11:48:18AM +0000, Lee Jones wrote: > On Mon, 10 Dec 2012, Mark Brown wrote: > > On Mon, Dec 10, 2012 at 08:55:51AM +0000, Lee Jones wrote: > > > If a regulator is specified as always-on, then it can't have an > > > enable/disable pin, as it can't be turned off. > > Sometimes always on gets set for regulators which do have a physical > > control wired up - the control might exist for use in suspend mode for > > example. Is the ability to specify an enable pin causing a practical > > problem for systems? If it is we should fix that. > My logic is that there is no point in requesting a pin which can > disable a regulator that can't be disabled. Then we can follow > on from that logic and say that if a regulator is _not_ always on > this we _require_ a way to disable it, thus we insist on an enable > GPIO pin. > With me? No. Making the enable pin optional for always on regulators is fine, forbidding it is not - that won't work for things like the suspend case I mentioned.
diff --git a/drivers/regulator/gpio-regulator.c b/drivers/regulator/gpio-regulator.c index 1a71be2..3afa46a 100644 --- a/drivers/regulator/gpio-regulator.c +++ b/drivers/regulator/gpio-regulator.c @@ -160,7 +160,14 @@ of_get_gpio_regulator_config(struct device *dev, struct device_node *np) of_property_read_u32(np, "startup-delay-us", &config->startup_delay); - config->enable_gpio = of_get_named_gpio(np, "enable-gpio", 0); + if (!config->init_data->constraints.always_on) { + config->enable_gpio = of_get_named_gpio(np, "enable-gpio", 0); + if (config->enable_gpio < 0) { + dev_err(dev, "Couldn't get 'enable-gpio' (%d)\n", + config->enable_gpio); + return ERR_PTR(config->enable_gpio); + } + } /* Fetch GPIOs. */ for (i = 0; ; i++)
If a regulator is specified as always-on, then it can't have an enable/disable pin, as it can't be turned off. Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> --- drivers/regulator/gpio-regulator.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)