Re: [PATCH] regulator: Provide optional dummy regulator for consumers
From: Mark Brown
Date: Fri Feb 12 2010 - 18:25:52 EST
On 12 Feb 2010, at 23:01, Grazvydas Ignotas <notasas@xxxxxxxxx> wrote:
On Fri, Feb 12, 2010 at 12:18 PM, Mark Brown
<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
In order to ease transitions with drivers are boards start using
regulators
provide an option to cause all regulator_get() calls to succeed,
with a
dummy always on regulator being supplied where one has not been
configured.
A warning is printed whenever the dummy regulator is used to aid
system
development.
This regulator does not implement any regulator operations but will
allow
simple consumers which only do enable() and disable() calls to run.
It
is kept separate from the fixed voltage regulator to avoid Kconfig
confusion on the part of users when it is extended to allow boards to
explicitly use the dummy regulator to simplify cases where the
majority
of supplies are from fixed regulators without software control.
This option is currently only effective for systems which do not
specify
full constriants. If required an override could also be provided to
allow
these systems to use the dummy regulator, though it is likely that
unconfigured supplies on such systems will lead to error due to
regulators being powered down more aggressively when not in use.
Signed-off-by: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
---
hm, tried intentionally nuking regulator setup on my board to test
dummy and drivers started failing on regulator_enable() with -1
(EPERM?). Looks like dummy doesn't have constraints defined, so not
much use of this if _enable() is failing anyway.
Hrmpf. That was working for me - are you running the latest regulator
code? There was a bug where it was requiring CHANGE_STATUS even if the
regulator is always on, which isn't sensible since there is no
possibility of actually changing the status. It should now only be
checking for permission to change status if it would actually do so.
There was also a patch yesterday to make regulators that don't define
an is_enabled() report as enabled.
BTW, drivers/mmc/host/omap_hsmmc.c has quite a lot of logic related to
vcc_aux being available or not (vcc_aux is typically used to power
some MMC pins and is unused on devices with SD cards, like pandora). I
wonder if it may cause some functionality change there.
Yeah, quite possibly. This sort of stuff is one of the reasons it's
much nicer to specify full constraints where possible; it allows
drivers that can have missing supplies to handle that.
--
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/