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/